On 10/24/11 16:05, Lars-Peter Clausen wrote: > On 10/24/2011 04:25 PM, Jonathan Cameron wrote: >> On 10/24/11 14:47, Lars-Peter Clausen wrote: >>> Hi, >>> >>> Some chips generate events which don't really map to a channel, but are >>> rather chip global. For example over-temperature events. >> That one is a channel. >>> Do you think this is something we should add support for or should we rather >>> use a dummy channel, which doesn't report any actual values, for propagating >>> the event? >> Yup, have a temp channel for that one. Conceptually you might have two chips >> that are otherwise identical but one has a readable temp channel, the other >> doesn't. Userspace that is interested only in events won't care about >> this difference. Also we want to report what the conditions are as if it were >> a channel we could read. We want to know at what temperature this occurs. > > Ok, what should a read on such a channel return, an error value or just an > dummy value? Definitely error. We might need some magic to stop the channel showing up in scan_elements if the chip uses buffering. Also, if I recall, the magic channel number -1 (as used for timestamps) stops it having a read attribute in the first place (in place for timestamps). > > >> [...] >>> >>> My idea for supporting channel-less events is to add a event_mask to struct >>> iio_info, which would be used just like a channels event_mask, but there >>> would be no index for the sysfs attributes and for events we would set the >>> event number to 0xffff. >> Could you give more examples? The temp one to my mind definitely needs a >> channel, perhaps others do not? I am not against in principal but not >> yet certain exactly when this would make sense... > > over-temperature is the only one i've seen so far. but other could be > under-current or voltage for the whole chip. There I'd also create a bonus voltage / current channel. Need these particular ones to map well because we'll probably have hwmon based in kernel users for them. -- 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
