Channel-less IIO events

Channel-less IIO events

[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.
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

Re: Channel-less IIO events

[Jonathan Cameron]

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.

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.
> 
> 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...
> 
> Thanks
> - Lars
> 

Re: Channel-less IIO events

[Lars-Peter Clausen]

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?


> [...]
>>
>> 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.

Thanks
- Lars

Re: Channel-less IIO events

[Jonathan Cameron]

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.