On Friday 25 March 2011, Jonathan Cameron wrote: > > I need some background information here. Why do you expose the configuration > > register directly? Is this something that users normally access? > > > > I would assume that it's highly device specific and would need to be > > abstracted by the kernel. > We could cache what events are enabled, and in some drivers we do. Here it is > just simpler to ask the device as it has a convenient bitmap of what is enabled. > > It's actually a real pain to completely abstract this away because some > devices only support sets of events at a time and exactly which are > supported can be extremely complex. The common cases are: > > 1) Separate comparators for each event. (simple as we have here!) > 2) n comparators which can be configured to any n events from a large list (adis16350 > is a classic example though we haven't finally merged event support for that > part yet). > 3) n comparators each of which can be configured to a subset of thresholds. e.g. one > comparator per channel, lots of different things it can compare about the channel. > > It is possible that we can abstract these at some point, but right now I'm not even > tempted to try! We are mostly avoiding the nastiest case at the moment which is > where you have controllable compound events. In this particular device you can > either have the events as 'or' as we do or 'and' for any set of them. Right now > we simply don't implement the 'and' case. Ok, thanks for the explanation. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-iio" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
