Channel-less IIO events
Hi,
Some chips generate events which don't really map to a channel, but are rather chip global. For example over-temperature events.
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?
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.
Thanks
- Lars
Quoted 4 lines · Lars-Peter Clausen
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.
Quoted 3 lines
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.
There are others events such as loss of tracking / wire out for the resolvers, but they so far have always corresponded to 'gah, it's all gone wrong' events. Last time I asked more generally about this, Alan Cox suggested using the signals typically employed for network sockets. General view is we didn't want them coming through our normal event path and for example being blocked behind the handling of another event. I then got bogged down with this in kernel interface stuff so haven't looked at it again.
Quoted 5 lines
My idea for supporting channel-less events is to add a
event_maskto structiio_info, which would be used just like a channelsevent_mask, but there would be no index for the sysfs attributes and for events we would set the event number to0xffff.
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...
Quoted 4 lines
Thanks
- Lars
Quoted 6 lines · Jonathan Cameron
Quoted 4 lines · Lars-Peter Clausen
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.
Quoted 8 lines
Quoted 3 lines
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?
Quoted 9 lines
[...]
Quoted 5 lines
My idea for supporting channel-less events is to add a
event_maskto structiio_info, which would be used just like a channelsevent_mask, but there would be no index for the sysfs attributes and for events we would set the event number to0xffff.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.
Thanks
- Lars
Quoted 10 lines · Lars-Peter Clausen
Quoted 9 lines · Jonathan Cameron
Quoted 4 lines · Lars-Peter Clausen
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.
Quoted 3 lines
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?
Quoted 8 lines
Quoted 5 lines
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).
Quoted 8 lines
Quoted 8 lines
[...]
Quoted 5 lines
My idea for supporting channel-less events is to add a
event_maskto structiio_info, which would be used just like a channelsevent_mask, but there would be no index for the sysfs attributes and for events we would set the event number to0xffff.
Quoted 6 lines
Quoted 3 lines
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.