Kernel wishlist item: Better IIO API

Kernel wishlist item: Better IIO API

[Bastien Nocera]

Hey,

I've posted this a couple of days ago:
http://www.hadess.net/2014/10/a-gnome-kernel-wishlist.html
along with a mail to LKML:
http://thread.gmane.org/gmane.linux.kernel/1810083

I've recently added to my list an item about IIO:
https://wiki.gnome.org/BastienNocera/KernelWishlist

Are there any plans for a better API for the IIO subsystem? The API
might be good enough to drive from shell scripts, or helpers that only
need to work with one variant of a device, but my attempts at trying to
use the IIO subsystem to provide an accelerometer to do automatic
display rotation[1] showed that the API is really cumbersome.

The code I wrote spends most of its time creating sysfs paths, reading
values in different formats, and mangling filenames[2].

Is an ioctl-based API planned? Something where I could get/set
structures to gather metadata about the device, and set it up easily, so
reading data from it is easier?

Cheers

PS: I plan on updating my Kionix driver posted here:
http://thread.gmane.org/gmane.linux.kernel.iio/13793
once I've had the opportunity to double-check it works with the
aforementioned code.

[1]: https://github.com/hadess/iio-sensor-proxy
[2]: https://github.com/hadess/iio-sensor-proxy/blob/master/iio-sensor-proxy.c#L331

Re: Kernel wishlist item: Better IIO API

[Lars-Peter Clausen]

On 10/29/2014 03:30 PM, Bastien Nocera wrote:
> Hey,
>
> I've posted this a couple of days ago:
> http://www.hadess.net/2014/10/a-gnome-kernel-wishlist.html
> along with a mail to LKML:
> http://thread.gmane.org/gmane.linux.kernel/1810083
>
> I've recently added to my list an item about IIO:
> https://wiki.gnome.org/BastienNocera/KernelWishlist
>
> Are there any plans for a better API for the IIO subsystem? The API
> might be good enough to drive from shell scripts, or helpers that only
> need to work with one variant of a device, but my attempts at trying to
> use the IIO subsystem to provide an accelerometer to do automatic
> display rotation[1] showed that the API is really cumbersome.
>
> The code I wrote spends most of its time creating sysfs paths, reading
> values in different formats, and mangling filenames[2].
>
> Is an ioctl-based API planned? Something where I could get/set
> structures to gather metadata about the device, and set it up easily, so
> reading data from it is easier?

No, unfortunately not and I'm not sure if such a ABI would be accepted if 
proposed.

But checkout libiio[1][2], it hides the details of the sysfs file manipulation.

- Lars

[1] https://github.com/analogdevicesinc/libiio
[2] http://analogdevicesinc.github.io/libiio/

Re: Kernel wishlist item: Better IIO API

[Bastien Nocera]

On Wed, 2014-10-29 at 18:21 +0100, Lars-Peter Clausen wrote:
> On 10/29/2014 03:30 PM, Bastien Nocera wrote:
> > Hey,
> >
> > I've posted this a couple of days ago:
> > http://www.hadess.net/2014/10/a-gnome-kernel-wishlist.html
> > along with a mail to LKML:
> > http://thread.gmane.org/gmane.linux.kernel/1810083
> >
> > I've recently added to my list an item about IIO:
> > https://wiki.gnome.org/BastienNocera/KernelWishlist
> >
> > Are there any plans for a better API for the IIO subsystem? The API
> > might be good enough to drive from shell scripts, or helpers that only
> > need to work with one variant of a device, but my attempts at trying to
> > use the IIO subsystem to provide an accelerometer to do automatic
> > display rotation[1] showed that the API is really cumbersome.
> >
> > The code I wrote spends most of its time creating sysfs paths, reading
> > values in different formats, and mangling filenames[2].
> >
> > Is an ioctl-based API planned? Something where I could get/set
> > structures to gather metadata about the device, and set it up easily, so
> > reading data from it is easier?
> 
> No, unfortunately not and I'm not sure if such a ABI would be accepted if 
> proposed.

Why not?

> But checkout libiio[1][2], it hides the details of the sysfs file manipulation.

I'm not sure that's any better unfortunately. I've certainly tried to do
that already in my code, but that doesn't change that the user-space API
is barely usable.

Cheers

> [1] https://github.com/analogdevicesinc/libiio
> [2] http://analogdevicesinc.github.io/libiio/

Re: Kernel wishlist item: Better IIO API

[Lars-Peter Clausen]

On 10/29/2014 06:33 PM, Bastien Nocera wrote:
> On Wed, 2014-10-29 at 18:21 +0100, Lars-Peter Clausen wrote:
>> On 10/29/2014 03:30 PM, Bastien Nocera wrote:
>>> Hey,
>>>
>>> I've posted this a couple of days ago:
>>> http://www.hadess.net/2014/10/a-gnome-kernel-wishlist.html
>>> along with a mail to LKML:
>>> http://thread.gmane.org/gmane.linux.kernel/1810083
>>>
>>> I've recently added to my list an item about IIO:
>>> https://wiki.gnome.org/BastienNocera/KernelWishlist
>>>
>>> Are there any plans for a better API for the IIO subsystem? The API
>>> might be good enough to drive from shell scripts, or helpers that only
>>> need to work with one variant of a device, but my attempts at trying to
>>> use the IIO subsystem to provide an accelerometer to do automatic
>>> display rotation[1] showed that the API is really cumbersome.
>>>
>>> The code I wrote spends most of its time creating sysfs paths, reading
>>> values in different formats, and mangling filenames[2].
>>>
>>> Is an ioctl-based API planned? Something where I could get/set
>>> structures to gather metadata about the device, and set it up easily, so
>>> reading data from it is easier?
>>
>> No, unfortunately not and I'm not sure if such a ABI would be accepted if
>> proposed.
>
> Why not?

Because it means there will be ambiguity in the API on how to do things. 
Which is typically not a desired property.

>
>> But checkout libiio[1][2], it hides the details of the sysfs file manipulation.
>
> I'm not sure that's any better unfortunately. I've certainly tried to do
> that already in my code, but that doesn't change that the user-space API
> is barely usable.

It's not completely unusable ;)

- Lars

Re: Kernel wishlist item: Better IIO API

[Bastien Nocera]

On Wed, 2014-10-29 at 18:39 +0100, Lars-Peter Clausen wrote:
> On 10/29/2014 06:33 PM, Bastien Nocera wrote:
> > On Wed, 2014-10-29 at 18:21 +0100, Lars-Peter Clausen wrote:
> >> On 10/29/2014 03:30 PM, Bastien Nocera wrote:
> >>> Hey,
> >>>
> >>> I've posted this a couple of days ago:
> >>> http://www.hadess.net/2014/10/a-gnome-kernel-wishlist.html
> >>> along with a mail to LKML:
> >>> http://thread.gmane.org/gmane.linux.kernel/1810083
> >>>
> >>> I've recently added to my list an item about IIO:
> >>> https://wiki.gnome.org/BastienNocera/KernelWishlist
> >>>
> >>> Are there any plans for a better API for the IIO subsystem? The API
> >>> might be good enough to drive from shell scripts, or helpers that only
> >>> need to work with one variant of a device, but my attempts at trying to
> >>> use the IIO subsystem to provide an accelerometer to do automatic
> >>> display rotation[1] showed that the API is really cumbersome.
> >>>
> >>> The code I wrote spends most of its time creating sysfs paths, reading
> >>> values in different formats, and mangling filenames[2].
> >>>
> >>> Is an ioctl-based API planned? Something where I could get/set
> >>> structures to gather metadata about the device, and set it up easily, so
> >>> reading data from it is easier?
> >>
> >> No, unfortunately not and I'm not sure if such a ABI would be accepted if
> >> proposed.
> >
> > Why not?
> 
> Because it means there will be ambiguity in the API on how to do things. 
> Which is typically not a desired property.
> 
> >
> >> But checkout libiio[1][2], it hides the details of the sysfs file manipulation.
> >
> > I'm not sure that's any better unfortunately. I've certainly tried to do
> > that already in my code, but that doesn't change that the user-space API
> > is barely usable.
> 
> It's not completely unusable ;)

In the end, you prefer the "self-documenting" of using sysfs files,
rather than an API which you can document in a header file?

I don't understand that. My questions on this very mailing-list, and
comments that were made to users of my code[1] clearly show that the
existing API is anything but "not ambiguous".

I've used the Bluetooth, input, rfkill, and inotify APIs as provided
directly by the Linux kernel (not through a layer) and they're of better
quality than the IIO one.

I just don't see how one could support a class of IIO sensors with the
existing API.

Cheers

[1]: https://github.com/hadess/iio-sensor-proxy/issues/1#issuecomment-54536393

Re: Kernel wishlist item: Better IIO API

[Lars-Peter Clausen]

On 10/29/2014 06:47 PM, Bastien Nocera wrote:
> On Wed, 2014-10-29 at 18:39 +0100, Lars-Peter Clausen wrote:
>> On 10/29/2014 06:33 PM, Bastien Nocera wrote:
>>> On Wed, 2014-10-29 at 18:21 +0100, Lars-Peter Clausen wrote:
>>>> On 10/29/2014 03:30 PM, Bastien Nocera wrote:
>>>>> Hey,
>>>>>
>>>>> I've posted this a couple of days ago:
>>>>> http://www.hadess.net/2014/10/a-gnome-kernel-wishlist.html
>>>>> along with a mail to LKML:
>>>>> http://thread.gmane.org/gmane.linux.kernel/1810083
>>>>>
>>>>> I've recently added to my list an item about IIO:
>>>>> https://wiki.gnome.org/BastienNocera/KernelWishlist
>>>>>
>>>>> Are there any plans for a better API for the IIO subsystem? The API
>>>>> might be good enough to drive from shell scripts, or helpers that only
>>>>> need to work with one variant of a device, but my attempts at trying to
>>>>> use the IIO subsystem to provide an accelerometer to do automatic
>>>>> display rotation[1] showed that the API is really cumbersome.
>>>>>
>>>>> The code I wrote spends most of its time creating sysfs paths, reading
>>>>> values in different formats, and mangling filenames[2].
>>>>>
>>>>> Is an ioctl-based API planned? Something where I could get/set
>>>>> structures to gather metadata about the device, and set it up easily, so
>>>>> reading data from it is easier?
>>>>
>>>> No, unfortunately not and I'm not sure if such a ABI would be accepted if
>>>> proposed.
>>>
>>> Why not?
>>
>> Because it means there will be ambiguity in the API on how to do things.
>> Which is typically not a desired property.
>>
>>>
>>>> But checkout libiio[1][2], it hides the details of the sysfs file manipulation.
>>>
>>> I'm not sure that's any better unfortunately. I've certainly tried to do
>>> that already in my code, but that doesn't change that the user-space API
>>> is barely usable.
>>
>> It's not completely unusable ;)
>
> In the end, you prefer the "self-documenting" of using sysfs files,
> rather than an API which you can document in a header file?

If it was for me we'd be using a state-full IOCTL ABI rather than a 
stateless sysfs ABI. I'm definitely not happy with the current interface, 
but it's the interface we have. But the problem with userspace ABI (in 
comparison to in-kernel API) is that we can just change things at random, 
but we have to stick with the existing interface.

The sysfs ABI is not meant to be self documenting and it is not 
undocumented. The documentation for the different attributes can be found in 
Documentation/ABI/testing/sysfs-bus-iio[1].

>
> I don't understand that. My questions on this very mailing-list, and
> comments that were made to users of my code[1] clearly show that the
> existing API is anything but "not ambiguous".

That bug report sounds like bugs in the driver.

>
> I've used the Bluetooth, input, rfkill, and inotify APIs as provided
> directly by the Linux kernel (not through a layer) and they're of better
> quality than the IIO one.
>
> I just don't see how one could support a class of IIO sensors with the
> existing API.

I can understand your frustration. A API that is not usable in a generic way 
is not really useful. So we should try to fix that, but we are bound by the 
framework itself and can't just throw everything away.

So lets start by trying to identify what is missing. Which information do 
you think could be provided by using a IOCTL interface which you need or 
want which is not provided by the current sysfs interface or can not be 
provided by the current sysfs interface.

- Lars

[1] 
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/ABI/testing/sysfs-bus-iio

Re: Kernel wishlist item: Better IIO API

[Bastien Nocera]

On Wed, 2014-10-29 at 19:30 +0100, Lars-Peter Clausen wrote:
> On 10/29/2014 06:47 PM, Bastien Nocera wrote:
> > On Wed, 2014-10-29 at 18:39 +0100, Lars-Peter Clausen wrote:
> >> On 10/29/2014 06:33 PM, Bastien Nocera wrote:
> >>> On Wed, 2014-10-29 at 18:21 +0100, Lars-Peter Clausen wrote:
> >>>> On 10/29/2014 03:30 PM, Bastien Nocera wrote:
> >>>>> Hey,
> >>>>>
> >>>>> I've posted this a couple of days ago:
> >>>>> http://www.hadess.net/2014/10/a-gnome-kernel-wishlist.html
> >>>>> along with a mail to LKML:
> >>>>> http://thread.gmane.org/gmane.linux.kernel/1810083
> >>>>>
> >>>>> I've recently added to my list an item about IIO:
> >>>>> https://wiki.gnome.org/BastienNocera/KernelWishlist
> >>>>>
> >>>>> Are there any plans for a better API for the IIO subsystem? The API
> >>>>> might be good enough to drive from shell scripts, or helpers that only
> >>>>> need to work with one variant of a device, but my attempts at trying to
> >>>>> use the IIO subsystem to provide an accelerometer to do automatic
> >>>>> display rotation[1] showed that the API is really cumbersome.
> >>>>>
> >>>>> The code I wrote spends most of its time creating sysfs paths, reading
> >>>>> values in different formats, and mangling filenames[2].
> >>>>>
> >>>>> Is an ioctl-based API planned? Something where I could get/set
> >>>>> structures to gather metadata about the device, and set it up easily, so
> >>>>> reading data from it is easier?
> >>>>
> >>>> No, unfortunately not and I'm not sure if such a ABI would be accepted if
> >>>> proposed.
> >>>
> >>> Why not?
> >>
> >> Because it means there will be ambiguity in the API on how to do things.
> >> Which is typically not a desired property.
> >>
> >>>
> >>>> But checkout libiio[1][2], it hides the details of the sysfs file manipulation.
> >>>
> >>> I'm not sure that's any better unfortunately. I've certainly tried to do
> >>> that already in my code, but that doesn't change that the user-space API
> >>> is barely usable.
> >>
> >> It's not completely unusable ;)
> >
> > In the end, you prefer the "self-documenting" of using sysfs files,
> > rather than an API which you can document in a header file?
> 
> If it was for me we'd be using a state-full IOCTL ABI rather than a 
> stateless sysfs ABI. I'm definitely not happy with the current interface, 
> but it's the interface we have. But the problem with userspace ABI (in 
> comparison to in-kernel API) is that we can just change things at random, 
> but we have to stick with the existing interface.
> 
> The sysfs ABI is not meant to be self documenting and it is not 
> undocumented. The documentation for the different attributes can be found in 
> Documentation/ABI/testing/sysfs-bus-iio[1].

That's useful if a bit terse. Thanks though.

> > I don't understand that. My questions on this very mailing-list, and
> > comments that were made to users of my code[1] clearly show that the
> > existing API is anything but "not ambiguous".
> 
> That bug report sounds like bugs in the driver.

Not really. Some drivers need the "in_accel_hysteresis" set, some don't
have that sysfs file, for example.

> > I've used the Bluetooth, input, rfkill, and inotify APIs as provided
> > directly by the Linux kernel (not through a layer) and they're of better
> > quality than the IIO one.
> >
> > I just don't see how one could support a class of IIO sensors with the
> > existing API.
> 
> I can understand your frustration. A API that is not usable in a generic way 
> is not really useful. So we should try to fix that, but we are bound by the 
> framework itself and can't just throw everything away.
> 
> So lets start by trying to identify what is missing. Which information do 
> you think could be provided by using a IOCTL interface which you need or 
> want which is not provided by the current sysfs interface or can not be 
> provided by the current sysfs interface.

(pseudo code ahead)

First, being able to cut down on the string manipulation would be great.
So instead of doing:
accel_x_path = build_filename (sysfs_path, "in_accel_x_raw");
accel_y_path = build_filename (sysfs_path, "in_accel_y_raw");
accel_z_path = build_filename (sysfs_path, "in_accel_z_raw");
if (exists(accel_x_path) && exists(accel_y_path) && exists(accel_z_path)) {
  // We have an accelerometer
  do_something();
}
free(..x);
free(..y);
free(..z);
free(sysfs_path);

I could query for the device's capabilities:
fd = open ("/dev/iio0");
ioctl(fd, IIO_GET_CAPS, &caps);
if (caps.channels & (IIO_CAP_ACCEL_X | IIO_CAP_ACCEL_Y | IIO_CAP_ACCEL_Z)) {
  // We have an accelerometer
  do_something();
}

Note that, from the data given, I don't know how to make out whether
something is an accelerometer, or a quartenion sensor, or which one we
should prefer on specific machines.

This would also be stateful, so that 1) enabling the various channels,
2) changing the hysteresis would be reset when the fd is closed. That
would cut down on the power consumption when unused, or when the service
that uses that data crashes.

Finally, there's some documentation, and it's not quite finished, or
there's something fishy on this device:
$ ls /sys//devices/platform/80860F41:04/i2c-12/i2c-SMO8500:00/iio:device0/events
in_accel_x_thresh_thresh_en      in_accel_x_thresh_thresh_value
in_accel_y_thresh_thresh_period  in_accel_z_thresh_thresh_en
in_accel_z_thresh_thresh_value
in_accel_x_thresh_thresh_period  in_accel_y_thresh_thresh_en
in_accel_y_thresh_thresh_value   in_accel_z_thresh_thresh_period

Reading this is like singing Kool & the Gang with a lisp.

It's also very unclear to me when to use triggers, if there are any,
when there a scan_elements sub-directory, and when not, when there is an
events sub-directory, and when not, and whether properties (the various
sysfs files) are readable, writable or both.

I've had the experience of 2 accelerometer devices, one in the Yoga 13,
using the hid-sensor* family of accelerometers, and one in the Onda
v975w with the kxcj9 1013 variant. The first has triggers, and
scan_elements. The second has events with "super-thresh" filenames.

So I'm really a bit lost.

Cheers

Re: Kernel wishlist item: Better IIO API

[Jonathan Cameron]

On 03/11/14 23:01, Bastien Nocera wrote:
> On Wed, 2014-10-29 at 19:30 +0100, Lars-Peter Clausen wrote:
>> On 10/29/2014 06:47 PM, Bastien Nocera wrote:
>>> On Wed, 2014-10-29 at 18:39 +0100, Lars-Peter Clausen wrote:
>>>> On 10/29/2014 06:33 PM, Bastien Nocera wrote:
>>>>> On Wed, 2014-10-29 at 18:21 +0100, Lars-Peter Clausen wrote:
>>>>>> On 10/29/2014 03:30 PM, Bastien Nocera wrote:
>>>>>>> Hey,
>>>>>>>
>>>>>>> I've posted this a couple of days ago:
>>>>>>> http://www.hadess.net/2014/10/a-gnome-kernel-wishlist.html
>>>>>>> along with a mail to LKML:
>>>>>>> http://thread.gmane.org/gmane.linux.kernel/1810083
>>>>>>>
>>>>>>> I've recently added to my list an item about IIO:
>>>>>>> https://wiki.gnome.org/BastienNocera/KernelWishlist
>>>>>>>
>>>>>>> Are there any plans for a better API for the IIO subsystem? The API
>>>>>>> might be good enough to drive from shell scripts, or helpers that only
>>>>>>> need to work with one variant of a device, but my attempts at trying to
>>>>>>> use the IIO subsystem to provide an accelerometer to do automatic
>>>>>>> display rotation[1] showed that the API is really cumbersome.
>>>>>>>
>>>>>>> The code I wrote spends most of its time creating sysfs paths, reading
>>>>>>> values in different formats, and mangling filenames[2].
>>>>>>>
>>>>>>> Is an ioctl-based API planned? Something where I could get/set
>>>>>>> structures to gather metadata about the device, and set it up easily, so
>>>>>>> reading data from it is easier?
>>>>>>
>>>>>> No, unfortunately not and I'm not sure if such a ABI would be accepted if
>>>>>> proposed.
>>>>>
>>>>> Why not?
>>>>
>>>> Because it means there will be ambiguity in the API on how to do things.
>>>> Which is typically not a desired property.
>>>>
>>>>>
>>>>>> But checkout libiio[1][2], it hides the details of the sysfs file manipulation.
>>>>>
>>>>> I'm not sure that's any better unfortunately. I've certainly tried to do
>>>>> that already in my code, but that doesn't change that the user-space API
>>>>> is barely usable.
>>>>
>>>> It's not completely unusable ;)
>>>
>>> In the end, you prefer the "self-documenting" of using sysfs files,
>>> rather than an API which you can document in a header file?
>>
>> If it was for me we'd be using a state-full IOCTL ABI rather than a 
>> stateless sysfs ABI. I'm definitely not happy with the current interface, 
>> but it's the interface we have. But the problem with userspace ABI (in 
>> comparison to in-kernel API) is that we can just change things at random, 
>> but we have to stick with the existing interface.
>>
>> The sysfs ABI is not meant to be self documenting and it is not 
>> undocumented. The documentation for the different attributes can be found in 
>> Documentation/ABI/testing/sysfs-bus-iio[1].
> 
> That's useful if a bit terse. Thanks though.
> 
>>> I don't understand that. My questions on this very mailing-list, and
>>> comments that were made to users of my code[1] clearly show that the
>>> existing API is anything but "not ambiguous".
>>
>> That bug report sounds like bugs in the driver.
> 
> Not really. Some drivers need the "in_accel_hysteresis" set, some don't
> have that sysfs file, for example.
> 
>>> I've used the Bluetooth, input, rfkill, and inotify APIs as provided
>>> directly by the Linux kernel (not through a layer) and they're of better
>>> quality than the IIO one.
>>>
>>> I just don't see how one could support a class of IIO sensors with the
>>> existing API.
>>
>> I can understand your frustration. A API that is not usable in a generic way 
>> is not really useful. So we should try to fix that, but we are bound by the 
>> framework itself and can't just throw everything away.
>>
>> So lets start by trying to identify what is missing. Which information do 
>> you think could be provided by using a IOCTL interface which you need or 
>> want which is not provided by the current sysfs interface or can not be 
>> provided by the current sysfs interface.
> 
> (pseudo code ahead)
> 
> First, being able to cut down on the string manipulation would be great.
> So instead of doing:
> accel_x_path = build_filename (sysfs_path, "in_accel_x_raw");
> accel_y_path = build_filename (sysfs_path, "in_accel_y_raw");
> accel_z_path = build_filename (sysfs_path, "in_accel_z_raw");
> if (exists(accel_x_path) && exists(accel_y_path) && exists(accel_z_path)) {
>   // We have an accelerometer
>   do_something();
> }
> free(..x);
> free(..y);
> free(..z);
> free(sysfs_path);
> 
> I could query for the device's capabilities:
> fd = open ("/dev/iio0");
> ioctl(fd, IIO_GET_CAPS, &caps);
> if (caps.channels & (IIO_CAP_ACCEL_X | IIO_CAP_ACCEL_Y | IIO_CAP_ACCEL_Z)) {
>   // We have an accelerometer
>   do_something();
> }
> 
> Note that, from the data given, I don't know how to make out whether
> something is an accelerometer, or a quartenion sensor, or which one we
> should prefer on specific machines.
> 
> This would also be stateful, so that 1) enabling the various channels,
> 2) changing the hysteresis would be reset when the fd is closed. That
> would cut down on the power consumption when unused, or when the service
> that uses that data crashes.
> 
> Finally, there's some documentation, and it's not quite finished, or
> there's something fishy on this device:
> $ ls /sys//devices/platform/80860F41:04/i2c-12/i2c-SMO8500:00/iio:device0/events
> in_accel_x_thresh_thresh_en      in_accel_x_thresh_thresh_value
> in_accel_y_thresh_thresh_period  in_accel_z_thresh_thresh_en
> in_accel_z_thresh_thresh_value
> in_accel_x_thresh_thresh_period  in_accel_y_thresh_thresh_en
> in_accel_y_thresh_thresh_value   in_accel_z_thresh_thresh_period
Hi Bastien,

I'll catch up with this thread properly (probably tomorrow) but in the meantime
I would imagine this is perhaps a weird and wonderful symptom of:
https://lkml.org/lkml/2014/10/10/249

Due to some personal stuff I'm running about 10 days behind with patches - catch
up soon.

Jonathan
> 
> Reading this is like singing Kool & the Gang with a lisp.
> 
> It's also very unclear to me when to use triggers, if there are any,
> when there a scan_elements sub-directory, and when not, when there is an
> events sub-directory, and when not, and whether properties (the various
> sysfs files) are readable, writable or both.
> 
> I've had the experience of 2 accelerometer devices, one in the Yoga 13,
> using the hid-sensor* family of accelerometers, and one in the Onda
> v975w with the kxcj9 1013 variant. The first has triggers, and
> scan_elements. The second has events with "super-thresh" filenames.
> 
> So I'm really a bit lost.
> 
> Cheers
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: Kernel wishlist item: Better IIO API

[Daniel Baluta]

On Tue, Nov 4, 2014 at 1:01 AM, Bastien Nocera <hadess@hadess.net> wrote:
> On Wed, 2014-10-29 at 19:30 +0100, Lars-Peter Clausen wrote:
>> On 10/29/2014 06:47 PM, Bastien Nocera wrote:
>> > On Wed, 2014-10-29 at 18:39 +0100, Lars-Peter Clausen wrote:
>> >> On 10/29/2014 06:33 PM, Bastien Nocera wrote:
>> >>> On Wed, 2014-10-29 at 18:21 +0100, Lars-Peter Clausen wrote:
>> >>>> On 10/29/2014 03:30 PM, Bastien Nocera wrote:
>> >>>>> Hey,
>> >>>>>
>> >>>>> I've posted this a couple of days ago:
>> >>>>> http://www.hadess.net/2014/10/a-gnome-kernel-wishlist.html
>> >>>>> along with a mail to LKML:
>> >>>>> http://thread.gmane.org/gmane.linux.kernel/1810083
>> >>>>>
>> >>>>> I've recently added to my list an item about IIO:
>> >>>>> https://wiki.gnome.org/BastienNocera/KernelWishlist
>> >>>>>
>> >>>>> Are there any plans for a better API for the IIO subsystem? The API
>> >>>>> might be good enough to drive from shell scripts, or helpers that only
>> >>>>> need to work with one variant of a device, but my attempts at trying to
>> >>>>> use the IIO subsystem to provide an accelerometer to do automatic
>> >>>>> display rotation[1] showed that the API is really cumbersome.
>> >>>>>
>> >>>>> The code I wrote spends most of its time creating sysfs paths, reading
>> >>>>> values in different formats, and mangling filenames[2].
>> >>>>>
>> >>>>> Is an ioctl-based API planned? Something where I could get/set
>> >>>>> structures to gather metadata about the device, and set it up easily, so
>> >>>>> reading data from it is easier?
>> >>>>
>> >>>> No, unfortunately not and I'm not sure if such a ABI would be accepted if
>> >>>> proposed.
>> >>>
>> >>> Why not?
>> >>
>> >> Because it means there will be ambiguity in the API on how to do things.
>> >> Which is typically not a desired property.
>> >>
>> >>>
>> >>>> But checkout libiio[1][2], it hides the details of the sysfs file manipulation.
>> >>>
>> >>> I'm not sure that's any better unfortunately. I've certainly tried to do
>> >>> that already in my code, but that doesn't change that the user-space API
>> >>> is barely usable.
>> >>
>> >> It's not completely unusable ;)
>> >
>> > In the end, you prefer the "self-documenting" of using sysfs files,
>> > rather than an API which you can document in a header file?
>>
>> If it was for me we'd be using a state-full IOCTL ABI rather than a
>> stateless sysfs ABI. I'm definitely not happy with the current interface,
>> but it's the interface we have. But the problem with userspace ABI (in
>> comparison to in-kernel API) is that we can just change things at random,
>> but we have to stick with the existing interface.
>>
>> The sysfs ABI is not meant to be self documenting and it is not
>> undocumented. The documentation for the different attributes can be found in
>> Documentation/ABI/testing/sysfs-bus-iio[1].
>
> That's useful if a bit terse. Thanks though.
>
>> > I don't understand that. My questions on this very mailing-list, and
>> > comments that were made to users of my code[1] clearly show that the
>> > existing API is anything but "not ambiguous".
>>
>> That bug report sounds like bugs in the driver.
>
> Not really. Some drivers need the "in_accel_hysteresis" set, some don't
> have that sysfs file, for example.
>
>> > I've used the Bluetooth, input, rfkill, and inotify APIs as provided
>> > directly by the Linux kernel (not through a layer) and they're of better
>> > quality than the IIO one.
>> >
>> > I just don't see how one could support a class of IIO sensors with the
>> > existing API.
>>
>> I can understand your frustration. A API that is not usable in a generic way
>> is not really useful. So we should try to fix that, but we are bound by the
>> framework itself and can't just throw everything away.
>>
>> So lets start by trying to identify what is missing. Which information do
>> you think could be provided by using a IOCTL interface which you need or
>> want which is not provided by the current sysfs interface or can not be
>> provided by the current sysfs interface.
>
> (pseudo code ahead)
>
> First, being able to cut down on the string manipulation would be great.
> So instead of doing:
> accel_x_path = build_filename (sysfs_path, "in_accel_x_raw");
> accel_y_path = build_filename (sysfs_path, "in_accel_y_raw");
> accel_z_path = build_filename (sysfs_path, "in_accel_z_raw");
> if (exists(accel_x_path) && exists(accel_y_path) && exists(accel_z_path)) {
>   // We have an accelerometer
>   do_something();
> }
> free(..x);
> free(..y);
> free(..z);
> free(sysfs_path);
>
> I could query for the device's capabilities:
> fd = open ("/dev/iio0");
> ioctl(fd, IIO_GET_CAPS, &caps);
> if (caps.channels & (IIO_CAP_ACCEL_X | IIO_CAP_ACCEL_Y | IIO_CAP_ACCEL_Z)) {
>   // We have an accelerometer
>   do_something();
> }
>
> Note that, from the data given, I don't know how to make out whether
> something is an accelerometer, or a quartenion sensor, or which one we
> should prefer on specific machines.
>
> This would also be stateful, so that 1) enabling the various channels,
> 2) changing the hysteresis would be reset when the fd is closed. That
> would cut down on the power consumption when unused, or when the service
> that uses that data crashes.
>
> Finally, there's some documentation, and it's not quite finished, or
> there's something fishy on this device:
> $ ls /sys//devices/platform/80860F41:04/i2c-12/i2c-SMO8500:00/iio:device0/events
> in_accel_x_thresh_thresh_en      in_accel_x_thresh_thresh_value
> in_accel_y_thresh_thresh_period  in_accel_z_thresh_thresh_en
> in_accel_z_thresh_thresh_value
> in_accel_x_thresh_thresh_period  in_accel_y_thresh_thresh_en
> in_accel_y_thresh_thresh_value   in_accel_z_thresh_thresh_period

Could you paste here the initialization part of iio_chan_spec + iio_event_spec?


Daniel.

Re: Kernel wishlist item: Better IIO API

[Bastien Nocera]

On Tue, 2014-11-04 at 10:18 +0200, Daniel Baluta wrote:
> On Tue, Nov 4, 2014 at 1:01 AM, Bastien Nocera <hadess@hadess.net> wrote:
> > On Wed, 2014-10-29 at 19:30 +0100, Lars-Peter Clausen wrote:
> >> On 10/29/2014 06:47 PM, Bastien Nocera wrote:
> >> > On Wed, 2014-10-29 at 18:39 +0100, Lars-Peter Clausen wrote:
> >> >> On 10/29/2014 06:33 PM, Bastien Nocera wrote:
> >> >>> On Wed, 2014-10-29 at 18:21 +0100, Lars-Peter Clausen wrote:
> >> >>>> On 10/29/2014 03:30 PM, Bastien Nocera wrote:
> >> >>>>> Hey,
> >> >>>>>
> >> >>>>> I've posted this a couple of days ago:
> >> >>>>> http://www.hadess.net/2014/10/a-gnome-kernel-wishlist.html
> >> >>>>> along with a mail to LKML:
> >> >>>>> http://thread.gmane.org/gmane.linux.kernel/1810083
> >> >>>>>
> >> >>>>> I've recently added to my list an item about IIO:
> >> >>>>> https://wiki.gnome.org/BastienNocera/KernelWishlist
> >> >>>>>
> >> >>>>> Are there any plans for a better API for the IIO subsystem? The API
> >> >>>>> might be good enough to drive from shell scripts, or helpers that only
> >> >>>>> need to work with one variant of a device, but my attempts at trying to
> >> >>>>> use the IIO subsystem to provide an accelerometer to do automatic
> >> >>>>> display rotation[1] showed that the API is really cumbersome.
> >> >>>>>
> >> >>>>> The code I wrote spends most of its time creating sysfs paths, reading
> >> >>>>> values in different formats, and mangling filenames[2].
> >> >>>>>
> >> >>>>> Is an ioctl-based API planned? Something where I could get/set
> >> >>>>> structures to gather metadata about the device, and set it up easily, so
> >> >>>>> reading data from it is easier?
> >> >>>>
> >> >>>> No, unfortunately not and I'm not sure if such a ABI would be accepted if
> >> >>>> proposed.
> >> >>>
> >> >>> Why not?
> >> >>
> >> >> Because it means there will be ambiguity in the API on how to do things.
> >> >> Which is typically not a desired property.
> >> >>
> >> >>>
> >> >>>> But checkout libiio[1][2], it hides the details of the sysfs file manipulation.
> >> >>>
> >> >>> I'm not sure that's any better unfortunately. I've certainly tried to do
> >> >>> that already in my code, but that doesn't change that the user-space API
> >> >>> is barely usable.
> >> >>
> >> >> It's not completely unusable ;)
> >> >
> >> > In the end, you prefer the "self-documenting" of using sysfs files,
> >> > rather than an API which you can document in a header file?
> >>
> >> If it was for me we'd be using a state-full IOCTL ABI rather than a
> >> stateless sysfs ABI. I'm definitely not happy with the current interface,
> >> but it's the interface we have. But the problem with userspace ABI (in
> >> comparison to in-kernel API) is that we can just change things at random,
> >> but we have to stick with the existing interface.
> >>
> >> The sysfs ABI is not meant to be self documenting and it is not
> >> undocumented. The documentation for the different attributes can be found in
> >> Documentation/ABI/testing/sysfs-bus-iio[1].
> >
> > That's useful if a bit terse. Thanks though.
> >
> >> > I don't understand that. My questions on this very mailing-list, and
> >> > comments that were made to users of my code[1] clearly show that the
> >> > existing API is anything but "not ambiguous".
> >>
> >> That bug report sounds like bugs in the driver.
> >
> > Not really. Some drivers need the "in_accel_hysteresis" set, some don't
> > have that sysfs file, for example.
> >
> >> > I've used the Bluetooth, input, rfkill, and inotify APIs as provided
> >> > directly by the Linux kernel (not through a layer) and they're of better
> >> > quality than the IIO one.
> >> >
> >> > I just don't see how one could support a class of IIO sensors with the
> >> > existing API.
> >>
> >> I can understand your frustration. A API that is not usable in a generic way
> >> is not really useful. So we should try to fix that, but we are bound by the
> >> framework itself and can't just throw everything away.
> >>
> >> So lets start by trying to identify what is missing. Which information do
> >> you think could be provided by using a IOCTL interface which you need or
> >> want which is not provided by the current sysfs interface or can not be
> >> provided by the current sysfs interface.
> >
> > (pseudo code ahead)
> >
> > First, being able to cut down on the string manipulation would be great.
> > So instead of doing:
> > accel_x_path = build_filename (sysfs_path, "in_accel_x_raw");
> > accel_y_path = build_filename (sysfs_path, "in_accel_y_raw");
> > accel_z_path = build_filename (sysfs_path, "in_accel_z_raw");
> > if (exists(accel_x_path) && exists(accel_y_path) && exists(accel_z_path)) {
> >   // We have an accelerometer
> >   do_something();
> > }
> > free(..x);
> > free(..y);
> > free(..z);
> > free(sysfs_path);
> >
> > I could query for the device's capabilities:
> > fd = open ("/dev/iio0");
> > ioctl(fd, IIO_GET_CAPS, &caps);
> > if (caps.channels & (IIO_CAP_ACCEL_X | IIO_CAP_ACCEL_Y | IIO_CAP_ACCEL_Z)) {
> >   // We have an accelerometer
> >   do_something();
> > }
> >
> > Note that, from the data given, I don't know how to make out whether
> > something is an accelerometer, or a quartenion sensor, or which one we
> > should prefer on specific machines.
> >
> > This would also be stateful, so that 1) enabling the various channels,
> > 2) changing the hysteresis would be reset when the fd is closed. That
> > would cut down on the power consumption when unused, or when the service
> > that uses that data crashes.
> >
> > Finally, there's some documentation, and it's not quite finished, or
> > there's something fishy on this device:
> > $ ls /sys//devices/platform/80860F41:04/i2c-12/i2c-SMO8500:00/iio:device0/events
> > in_accel_x_thresh_thresh_en      in_accel_x_thresh_thresh_value
> > in_accel_y_thresh_thresh_period  in_accel_z_thresh_thresh_en
> > in_accel_z_thresh_thresh_value
> > in_accel_x_thresh_thresh_period  in_accel_y_thresh_thresh_en
> > in_accel_y_thresh_thresh_value   in_accel_z_thresh_thresh_period
> 
> Could you paste here the initialization part of iio_chan_spec + iio_event_spec?

How would I do that?

Re: Kernel wishlist item: Better IIO API

[Daniel Baluta]

On Tue, Nov 4, 2014 at 10:27 AM, Bastien Nocera <hadess@hadess.net> wrote:
> On Tue, 2014-11-04 at 10:18 +0200, Daniel Baluta wrote:
>> On Tue, Nov 4, 2014 at 1:01 AM, Bastien Nocera <hadess@hadess.net> wrote:
>> > On Wed, 2014-10-29 at 19:30 +0100, Lars-Peter Clausen wrote:
>> >> On 10/29/2014 06:47 PM, Bastien Nocera wrote:
>> >> > On Wed, 2014-10-29 at 18:39 +0100, Lars-Peter Clausen wrote:
>> >> >> On 10/29/2014 06:33 PM, Bastien Nocera wrote:
>> >> >>> On Wed, 2014-10-29 at 18:21 +0100, Lars-Peter Clausen wrote:
>> >> >>>> On 10/29/2014 03:30 PM, Bastien Nocera wrote:
>> >> >>>>> Hey,
>> >> >>>>>
>> >> >>>>> I've posted this a couple of days ago:
>> >> >>>>> http://www.hadess.net/2014/10/a-gnome-kernel-wishlist.html
>> >> >>>>> along with a mail to LKML:
>> >> >>>>> http://thread.gmane.org/gmane.linux.kernel/1810083
>> >> >>>>>
>> >> >>>>> I've recently added to my list an item about IIO:
>> >> >>>>> https://wiki.gnome.org/BastienNocera/KernelWishlist
>> >> >>>>>
>> >> >>>>> Are there any plans for a better API for the IIO subsystem? The API
>> >> >>>>> might be good enough to drive from shell scripts, or helpers that only
>> >> >>>>> need to work with one variant of a device, but my attempts at trying to
>> >> >>>>> use the IIO subsystem to provide an accelerometer to do automatic
>> >> >>>>> display rotation[1] showed that the API is really cumbersome.
>> >> >>>>>
>> >> >>>>> The code I wrote spends most of its time creating sysfs paths, reading
>> >> >>>>> values in different formats, and mangling filenames[2].
>> >> >>>>>
>> >> >>>>> Is an ioctl-based API planned? Something where I could get/set
>> >> >>>>> structures to gather metadata about the device, and set it up easily, so
>> >> >>>>> reading data from it is easier?
>> >> >>>>
>> >> >>>> No, unfortunately not and I'm not sure if such a ABI would be accepted if
>> >> >>>> proposed.
>> >> >>>
>> >> >>> Why not?
>> >> >>
>> >> >> Because it means there will be ambiguity in the API on how to do things.
>> >> >> Which is typically not a desired property.
>> >> >>
>> >> >>>
>> >> >>>> But checkout libiio[1][2], it hides the details of the sysfs file manipulation.
>> >> >>>
>> >> >>> I'm not sure that's any better unfortunately. I've certainly tried to do
>> >> >>> that already in my code, but that doesn't change that the user-space API
>> >> >>> is barely usable.
>> >> >>
>> >> >> It's not completely unusable ;)
>> >> >
>> >> > In the end, you prefer the "self-documenting" of using sysfs files,
>> >> > rather than an API which you can document in a header file?
>> >>
>> >> If it was for me we'd be using a state-full IOCTL ABI rather than a
>> >> stateless sysfs ABI. I'm definitely not happy with the current interface,
>> >> but it's the interface we have. But the problem with userspace ABI (in
>> >> comparison to in-kernel API) is that we can just change things at random,
>> >> but we have to stick with the existing interface.
>> >>
>> >> The sysfs ABI is not meant to be self documenting and it is not
>> >> undocumented. The documentation for the different attributes can be found in
>> >> Documentation/ABI/testing/sysfs-bus-iio[1].
>> >
>> > That's useful if a bit terse. Thanks though.
>> >
>> >> > I don't understand that. My questions on this very mailing-list, and
>> >> > comments that were made to users of my code[1] clearly show that the
>> >> > existing API is anything but "not ambiguous".
>> >>
>> >> That bug report sounds like bugs in the driver.
>> >
>> > Not really. Some drivers need the "in_accel_hysteresis" set, some don't
>> > have that sysfs file, for example.
>> >
>> >> > I've used the Bluetooth, input, rfkill, and inotify APIs as provided
>> >> > directly by the Linux kernel (not through a layer) and they're of better
>> >> > quality than the IIO one.
>> >> >
>> >> > I just don't see how one could support a class of IIO sensors with the
>> >> > existing API.
>> >>
>> >> I can understand your frustration. A API that is not usable in a generic way
>> >> is not really useful. So we should try to fix that, but we are bound by the
>> >> framework itself and can't just throw everything away.
>> >>
>> >> So lets start by trying to identify what is missing. Which information do
>> >> you think could be provided by using a IOCTL interface which you need or
>> >> want which is not provided by the current sysfs interface or can not be
>> >> provided by the current sysfs interface.
>> >
>> > (pseudo code ahead)
>> >
>> > First, being able to cut down on the string manipulation would be great.
>> > So instead of doing:
>> > accel_x_path = build_filename (sysfs_path, "in_accel_x_raw");
>> > accel_y_path = build_filename (sysfs_path, "in_accel_y_raw");
>> > accel_z_path = build_filename (sysfs_path, "in_accel_z_raw");
>> > if (exists(accel_x_path) && exists(accel_y_path) && exists(accel_z_path)) {
>> >   // We have an accelerometer
>> >   do_something();
>> > }
>> > free(..x);
>> > free(..y);
>> > free(..z);
>> > free(sysfs_path);
>> >
>> > I could query for the device's capabilities:
>> > fd = open ("/dev/iio0");
>> > ioctl(fd, IIO_GET_CAPS, &caps);
>> > if (caps.channels & (IIO_CAP_ACCEL_X | IIO_CAP_ACCEL_Y | IIO_CAP_ACCEL_Z)) {
>> >   // We have an accelerometer
>> >   do_something();
>> > }
>> >
>> > Note that, from the data given, I don't know how to make out whether
>> > something is an accelerometer, or a quartenion sensor, or which one we
>> > should prefer on specific machines.
>> >
>> > This would also be stateful, so that 1) enabling the various channels,
>> > 2) changing the hysteresis would be reset when the fd is closed. That
>> > would cut down on the power consumption when unused, or when the service
>> > that uses that data crashes.
>> >
>> > Finally, there's some documentation, and it's not quite finished, or
>> > there's something fishy on this device:
>> > $ ls /sys//devices/platform/80860F41:04/i2c-12/i2c-SMO8500:00/iio:device0/events
>> > in_accel_x_thresh_thresh_en      in_accel_x_thresh_thresh_value
>> > in_accel_y_thresh_thresh_period  in_accel_z_thresh_thresh_en
>> > in_accel_z_thresh_thresh_value
>> > in_accel_x_thresh_thresh_period  in_accel_y_thresh_thresh_en
>> > in_accel_y_thresh_thresh_value   in_accel_z_thresh_thresh_period
>>
>> Could you paste here the initialization part of iio_chan_spec + iio_event_spec?
>
> How would I do that?

Just look into the code and search for iio_chan_spec and
iio_event_spec declaration.

e.g:

For iio_chan_spec:

static const struct iio_chan_spec iio_dummy_channels[] = {
»       {
»       »       .type = IIO_VOLTAGE,
»       »       .info_mask_separate = BIT(IIO_CHAN_INFO_RAW),
»       »       .output = 1,
»       »       .indexed = 1,
»       »       .channel = 0,
»       },
};

For iio_event_spec:
static const struct iio_event_spec iio_dummy_event = {
»       .type = IIO_EV_TYPE_THRESH,
»       .dir = IIO_EV_DIR_RISING,
»       .mask_separate = BIT(IIO_EV_INFO_VALUE) | BIT(IIO_EV_INFO_ENABLE),
};

Re: Kernel wishlist item: Better IIO API

[Bastien Nocera]

On Tue, 2014-11-04 at 10:37 +0200, Daniel Baluta wrote:
> On Tue, Nov 4, 2014 at 10:27 AM, Bastien Nocera <hadess@hadess.net> wrote:
> > On Tue, 2014-11-04 at 10:18 +0200, Daniel Baluta wrote:
> >> On Tue, Nov 4, 2014 at 1:01 AM, Bastien Nocera <hadess@hadess.net> wrote:
> >> > On Wed, 2014-10-29 at 19:30 +0100, Lars-Peter Clausen wrote:
> >> >> On 10/29/2014 06:47 PM, Bastien Nocera wrote:
> >> >> > On Wed, 2014-10-29 at 18:39 +0100, Lars-Peter Clausen wrote:
> >> >> >> On 10/29/2014 06:33 PM, Bastien Nocera wrote:
> >> >> >>> On Wed, 2014-10-29 at 18:21 +0100, Lars-Peter Clausen wrote:
> >> >> >>>> On 10/29/2014 03:30 PM, Bastien Nocera wrote:
> >> >> >>>>> Hey,
> >> >> >>>>>
> >> >> >>>>> I've posted this a couple of days ago:
> >> >> >>>>> http://www.hadess.net/2014/10/a-gnome-kernel-wishlist.html
> >> >> >>>>> along with a mail to LKML:
> >> >> >>>>> http://thread.gmane.org/gmane.linux.kernel/1810083
> >> >> >>>>>
> >> >> >>>>> I've recently added to my list an item about IIO:
> >> >> >>>>> https://wiki.gnome.org/BastienNocera/KernelWishlist
> >> >> >>>>>
> >> >> >>>>> Are there any plans for a better API for the IIO subsystem? The API
> >> >> >>>>> might be good enough to drive from shell scripts, or helpers that only
> >> >> >>>>> need to work with one variant of a device, but my attempts at trying to
> >> >> >>>>> use the IIO subsystem to provide an accelerometer to do automatic
> >> >> >>>>> display rotation[1] showed that the API is really cumbersome.
> >> >> >>>>>
> >> >> >>>>> The code I wrote spends most of its time creating sysfs paths, reading
> >> >> >>>>> values in different formats, and mangling filenames[2].
> >> >> >>>>>
> >> >> >>>>> Is an ioctl-based API planned? Something where I could get/set
> >> >> >>>>> structures to gather metadata about the device, and set it up easily, so
> >> >> >>>>> reading data from it is easier?
> >> >> >>>>
> >> >> >>>> No, unfortunately not and I'm not sure if such a ABI would be accepted if
> >> >> >>>> proposed.
> >> >> >>>
> >> >> >>> Why not?
> >> >> >>
> >> >> >> Because it means there will be ambiguity in the API on how to do things.
> >> >> >> Which is typically not a desired property.
> >> >> >>
> >> >> >>>
> >> >> >>>> But checkout libiio[1][2], it hides the details of the sysfs file manipulation.
> >> >> >>>
> >> >> >>> I'm not sure that's any better unfortunately. I've certainly tried to do
> >> >> >>> that already in my code, but that doesn't change that the user-space API
> >> >> >>> is barely usable.
> >> >> >>
> >> >> >> It's not completely unusable ;)
> >> >> >
> >> >> > In the end, you prefer the "self-documenting" of using sysfs files,
> >> >> > rather than an API which you can document in a header file?
> >> >>
> >> >> If it was for me we'd be using a state-full IOCTL ABI rather than a
> >> >> stateless sysfs ABI. I'm definitely not happy with the current interface,
> >> >> but it's the interface we have. But the problem with userspace ABI (in
> >> >> comparison to in-kernel API) is that we can just change things at random,
> >> >> but we have to stick with the existing interface.
> >> >>
> >> >> The sysfs ABI is not meant to be self documenting and it is not
> >> >> undocumented. The documentation for the different attributes can be found in
> >> >> Documentation/ABI/testing/sysfs-bus-iio[1].
> >> >
> >> > That's useful if a bit terse. Thanks though.
> >> >
> >> >> > I don't understand that. My questions on this very mailing-list, and
> >> >> > comments that were made to users of my code[1] clearly show that the
> >> >> > existing API is anything but "not ambiguous".
> >> >>
> >> >> That bug report sounds like bugs in the driver.
> >> >
> >> > Not really. Some drivers need the "in_accel_hysteresis" set, some don't
> >> > have that sysfs file, for example.
> >> >
> >> >> > I've used the Bluetooth, input, rfkill, and inotify APIs as provided
> >> >> > directly by the Linux kernel (not through a layer) and they're of better
> >> >> > quality than the IIO one.
> >> >> >
> >> >> > I just don't see how one could support a class of IIO sensors with the
> >> >> > existing API.
> >> >>
> >> >> I can understand your frustration. A API that is not usable in a generic way
> >> >> is not really useful. So we should try to fix that, but we are bound by the
> >> >> framework itself and can't just throw everything away.
> >> >>
> >> >> So lets start by trying to identify what is missing. Which information do
> >> >> you think could be provided by using a IOCTL interface which you need or
> >> >> want which is not provided by the current sysfs interface or can not be
> >> >> provided by the current sysfs interface.
> >> >
> >> > (pseudo code ahead)
> >> >
> >> > First, being able to cut down on the string manipulation would be great.
> >> > So instead of doing:
> >> > accel_x_path = build_filename (sysfs_path, "in_accel_x_raw");
> >> > accel_y_path = build_filename (sysfs_path, "in_accel_y_raw");
> >> > accel_z_path = build_filename (sysfs_path, "in_accel_z_raw");
> >> > if (exists(accel_x_path) && exists(accel_y_path) && exists(accel_z_path)) {
> >> >   // We have an accelerometer
> >> >   do_something();
> >> > }
> >> > free(..x);
> >> > free(..y);
> >> > free(..z);
> >> > free(sysfs_path);
> >> >
> >> > I could query for the device's capabilities:
> >> > fd = open ("/dev/iio0");
> >> > ioctl(fd, IIO_GET_CAPS, &caps);
> >> > if (caps.channels & (IIO_CAP_ACCEL_X | IIO_CAP_ACCEL_Y | IIO_CAP_ACCEL_Z)) {
> >> >   // We have an accelerometer
> >> >   do_something();
> >> > }
> >> >
> >> > Note that, from the data given, I don't know how to make out whether
> >> > something is an accelerometer, or a quartenion sensor, or which one we
> >> > should prefer on specific machines.
> >> >
> >> > This would also be stateful, so that 1) enabling the various channels,
> >> > 2) changing the hysteresis would be reset when the fd is closed. That
> >> > would cut down on the power consumption when unused, or when the service
> >> > that uses that data crashes.
> >> >
> >> > Finally, there's some documentation, and it's not quite finished, or
> >> > there's something fishy on this device:
> >> > $ ls /sys//devices/platform/80860F41:04/i2c-12/i2c-SMO8500:00/iio:device0/events
> >> > in_accel_x_thresh_thresh_en      in_accel_x_thresh_thresh_value
> >> > in_accel_y_thresh_thresh_period  in_accel_z_thresh_thresh_en
> >> > in_accel_z_thresh_thresh_value
> >> > in_accel_x_thresh_thresh_period  in_accel_y_thresh_thresh_en
> >> > in_accel_y_thresh_thresh_value   in_accel_z_thresh_thresh_period
> >>
> >> Could you paste here the initialization part of iio_chan_spec + iio_event_spec?
> >
> > How would I do that?
> 
> Just look into the code and search for iio_chan_spec and
> iio_event_spec declaration.

Oh, the code. Well, you've already sent a patch for it, so you should
know ;)

I've sent the patch adding support for the accelerometer in my device
yesterday:
http://thread.gmane.org/gmane.linux.kernel.iio/14487

I'll test your patch in a little while once I've had the chance to play
with the Bluetooth support code.

Cheers

Re: Kernel wishlist item: Better IIO API

[Daniel Baluta]

On Tue, Nov 4, 2014 at 10:45 AM, Bastien Nocera <hadess@hadess.net> wrote:
> On Tue, 2014-11-04 at 10:37 +0200, Daniel Baluta wrote:
>> On Tue, Nov 4, 2014 at 10:27 AM, Bastien Nocera <hadess@hadess.net> wrote:
>> > On Tue, 2014-11-04 at 10:18 +0200, Daniel Baluta wrote:
>> >> On Tue, Nov 4, 2014 at 1:01 AM, Bastien Nocera <hadess@hadess.net> wrote:
>> >> > On Wed, 2014-10-29 at 19:30 +0100, Lars-Peter Clausen wrote:
>> >> >> On 10/29/2014 06:47 PM, Bastien Nocera wrote:
>> >> >> > On Wed, 2014-10-29 at 18:39 +0100, Lars-Peter Clausen wrote:
>> >> >> >> On 10/29/2014 06:33 PM, Bastien Nocera wrote:
>> >> >> >>> On Wed, 2014-10-29 at 18:21 +0100, Lars-Peter Clausen wrote:
>> >> >> >>>> On 10/29/2014 03:30 PM, Bastien Nocera wrote:
>> >> >> >>>>> Hey,
>> >> >> >>>>>
>> >> >> >>>>> I've posted this a couple of days ago:
>> >> >> >>>>> http://www.hadess.net/2014/10/a-gnome-kernel-wishlist.html
>> >> >> >>>>> along with a mail to LKML:
>> >> >> >>>>> http://thread.gmane.org/gmane.linux.kernel/1810083
>> >> >> >>>>>
>> >> >> >>>>> I've recently added to my list an item about IIO:
>> >> >> >>>>> https://wiki.gnome.org/BastienNocera/KernelWishlist
>> >> >> >>>>>
>> >> >> >>>>> Are there any plans for a better API for the IIO subsystem? The API
>> >> >> >>>>> might be good enough to drive from shell scripts, or helpers that only
>> >> >> >>>>> need to work with one variant of a device, but my attempts at trying to
>> >> >> >>>>> use the IIO subsystem to provide an accelerometer to do automatic
>> >> >> >>>>> display rotation[1] showed that the API is really cumbersome.
>> >> >> >>>>>
>> >> >> >>>>> The code I wrote spends most of its time creating sysfs paths, reading
>> >> >> >>>>> values in different formats, and mangling filenames[2].
>> >> >> >>>>>
>> >> >> >>>>> Is an ioctl-based API planned? Something where I could get/set
>> >> >> >>>>> structures to gather metadata about the device, and set it up easily, so
>> >> >> >>>>> reading data from it is easier?
>> >> >> >>>>
>> >> >> >>>> No, unfortunately not and I'm not sure if such a ABI would be accepted if
>> >> >> >>>> proposed.
>> >> >> >>>
>> >> >> >>> Why not?
>> >> >> >>
>> >> >> >> Because it means there will be ambiguity in the API on how to do things.
>> >> >> >> Which is typically not a desired property.
>> >> >> >>
>> >> >> >>>
>> >> >> >>>> But checkout libiio[1][2], it hides the details of the sysfs file manipulation.
>> >> >> >>>
>> >> >> >>> I'm not sure that's any better unfortunately. I've certainly tried to do
>> >> >> >>> that already in my code, but that doesn't change that the user-space API
>> >> >> >>> is barely usable.
>> >> >> >>
>> >> >> >> It's not completely unusable ;)
>> >> >> >
>> >> >> > In the end, you prefer the "self-documenting" of using sysfs files,
>> >> >> > rather than an API which you can document in a header file?
>> >> >>
>> >> >> If it was for me we'd be using a state-full IOCTL ABI rather than a
>> >> >> stateless sysfs ABI. I'm definitely not happy with the current interface,
>> >> >> but it's the interface we have. But the problem with userspace ABI (in
>> >> >> comparison to in-kernel API) is that we can just change things at random,
>> >> >> but we have to stick with the existing interface.
>> >> >>
>> >> >> The sysfs ABI is not meant to be self documenting and it is not
>> >> >> undocumented. The documentation for the different attributes can be found in
>> >> >> Documentation/ABI/testing/sysfs-bus-iio[1].
>> >> >
>> >> > That's useful if a bit terse. Thanks though.
>> >> >
>> >> >> > I don't understand that. My questions on this very mailing-list, and
>> >> >> > comments that were made to users of my code[1] clearly show that the
>> >> >> > existing API is anything but "not ambiguous".
>> >> >>
>> >> >> That bug report sounds like bugs in the driver.
>> >> >
>> >> > Not really. Some drivers need the "in_accel_hysteresis" set, some don't
>> >> > have that sysfs file, for example.
>> >> >
>> >> >> > I've used the Bluetooth, input, rfkill, and inotify APIs as provided
>> >> >> > directly by the Linux kernel (not through a layer) and they're of better
>> >> >> > quality than the IIO one.
>> >> >> >
>> >> >> > I just don't see how one could support a class of IIO sensors with the
>> >> >> > existing API.
>> >> >>
>> >> >> I can understand your frustration. A API that is not usable in a generic way
>> >> >> is not really useful. So we should try to fix that, but we are bound by the
>> >> >> framework itself and can't just throw everything away.
>> >> >>
>> >> >> So lets start by trying to identify what is missing. Which information do
>> >> >> you think could be provided by using a IOCTL interface which you need or
>> >> >> want which is not provided by the current sysfs interface or can not be
>> >> >> provided by the current sysfs interface.
>> >> >
>> >> > (pseudo code ahead)
>> >> >
>> >> > First, being able to cut down on the string manipulation would be great.
>> >> > So instead of doing:
>> >> > accel_x_path = build_filename (sysfs_path, "in_accel_x_raw");
>> >> > accel_y_path = build_filename (sysfs_path, "in_accel_y_raw");
>> >> > accel_z_path = build_filename (sysfs_path, "in_accel_z_raw");
>> >> > if (exists(accel_x_path) && exists(accel_y_path) && exists(accel_z_path)) {
>> >> >   // We have an accelerometer
>> >> >   do_something();
>> >> > }
>> >> > free(..x);
>> >> > free(..y);
>> >> > free(..z);
>> >> > free(sysfs_path);
>> >> >
>> >> > I could query for the device's capabilities:
>> >> > fd = open ("/dev/iio0");
>> >> > ioctl(fd, IIO_GET_CAPS, &caps);
>> >> > if (caps.channels & (IIO_CAP_ACCEL_X | IIO_CAP_ACCEL_Y | IIO_CAP_ACCEL_Z)) {
>> >> >   // We have an accelerometer
>> >> >   do_something();
>> >> > }
>> >> >
>> >> > Note that, from the data given, I don't know how to make out whether
>> >> > something is an accelerometer, or a quartenion sensor, or which one we
>> >> > should prefer on specific machines.
>> >> >
>> >> > This would also be stateful, so that 1) enabling the various channels,
>> >> > 2) changing the hysteresis would be reset when the fd is closed. That
>> >> > would cut down on the power consumption when unused, or when the service
>> >> > that uses that data crashes.
>> >> >
>> >> > Finally, there's some documentation, and it's not quite finished, or
>> >> > there's something fishy on this device:
>> >> > $ ls /sys//devices/platform/80860F41:04/i2c-12/i2c-SMO8500:00/iio:device0/events
>> >> > in_accel_x_thresh_thresh_en      in_accel_x_thresh_thresh_value
>> >> > in_accel_y_thresh_thresh_period  in_accel_z_thresh_thresh_en
>> >> > in_accel_z_thresh_thresh_value
>> >> > in_accel_x_thresh_thresh_period  in_accel_y_thresh_thresh_en
>> >> > in_accel_y_thresh_thresh_value   in_accel_z_thresh_thresh_period
>> >>
>> >> Could you paste here the initialization part of iio_chan_spec + iio_event_spec?
>> >
>> > How would I do that?
>>
>> Just look into the code and search for iio_chan_spec and
>> iio_event_spec declaration.
>
> Oh, the code. Well, you've already sent a patch for it, so you should
> know ;)
>
> I've sent the patch adding support for the accelerometer in my device
> yesterday:
> http://thread.gmane.org/gmane.linux.kernel.iio/14487
>
> I'll test your patch in a little while once I've had the chance to play
> with the Bluetooth support code.

I forgot that SMO8500 is KXCJ9.

Should work with https://lkml.org/lkml/2014/10/10/249 :).

Daniel.

Re: Kernel wishlist item: Better IIO API

[Bastien Nocera]

On Tue, 2014-11-04 at 10:56 +0200, Daniel Baluta wrote:
> On Tue, Nov 4, 2014 at 10:45 AM, Bastien Nocera <hadess@hadess.net> wrote:
> > On Tue, 2014-11-04 at 10:37 +0200, Daniel Baluta wrote:
> >> On Tue, Nov 4, 2014 at 10:27 AM, Bastien Nocera <hadess@hadess.net> wrote:
> >> > On Tue, 2014-11-04 at 10:18 +0200, Daniel Baluta wrote:
> >> >> On Tue, Nov 4, 2014 at 1:01 AM, Bastien Nocera <hadess@hadess.net> wrote:
<snip>
> >> >> > Finally, there's some documentation, and it's not quite finished, or
> >> >> > there's something fishy on this device:
> >> >> > $ ls /sys//devices/platform/80860F41:04/i2c-12/i2c-SMO8500:00/iio:device0/events
> >> >> > in_accel_x_thresh_thresh_en      in_accel_x_thresh_thresh_value
> >> >> > in_accel_y_thresh_thresh_period  in_accel_z_thresh_thresh_en
> >> >> > in_accel_z_thresh_thresh_value
> >> >> > in_accel_x_thresh_thresh_period  in_accel_y_thresh_thresh_en
> >> >> > in_accel_y_thresh_thresh_value   in_accel_z_thresh_thresh_period
<snip>
> I forgot that SMO8500 is KXCJ9.
> 
> Should work with https://lkml.org/lkml/2014/10/10/249 :).

$ ls events/
in_accel_x_thresh_either_en      in_accel_x_thresh_either_value
in_accel_y_thresh_either_period  in_accel_z_thresh_either_en
in_accel_z_thresh_either_value
in_accel_x_thresh_either_period  in_accel_y_thresh_either_en
in_accel_y_thresh_either_value   in_accel_z_thresh_either_period

Yeah, better.

Re: Kernel wishlist item: Better IIO API

[Bastien Nocera]

On Wed, 2014-10-29 at 19:30 +0100, Lars-Peter Clausen wrote:
<snip>
> The sysfs ABI is not meant to be self documenting and it is not 
> undocumented. The documentation for the different attributes can be found in 
> Documentation/ABI/testing/sysfs-bus-iio[1].
<snip>
> I can understand your frustration. A API that is not usable in a generic way 
> is not really useful. So we should try to fix that, but we are bound by the 
> framework itself and can't just throw everything away.

I'll go back to this e-mail, and start again with very concrete examples
of my problems. I'm looking for shorter term gains here, while you can
look at my questions as inspiration for what needs fixing longer term :)

My goal is to move iio-sensor-proxy[1] into systemd's codebase, probably
in logind. I know of two different "types" of sensors that I'd like to
support, and 2 very different types of drivers.

The driver used in the Lenovo Yoga Pros (hid-sensor-accel-3d), which I
used to write the iio-sensor-proxy, requires the following procedure to
be used:
- find the accelerometer iio device (with the "accel_3d" name)
- find the associated trigger
- enable the sensors by writing to some files in scan_elements/
- enable the ring buffer by writing to buffer/enable
- enable the trigger found above by writing to trigger/current_trigger
- parse the files in scan_elements/ to find the channel array
- find the scale of each axis
- on some variants, tweak the hysteresis [2] to trigger changes
- and then read from the ring buffer on a regular basis, parse those
buffers, scale them, and we finally have the 3 dimensions we needed

The driver used in the Onda tablet I have is far less featureful.
- find the accelerometer iio device (this time called "i2c-SMO8500:00")
- build the channel array (?? I haven't found how)
- read the scale of each axis
- read directly from the sysfs files for each axis (?? surely not) on a
regular basis, scale the values, and we have the 3 dimensions

Is this at all correct? Is there documentation (the sysfs-bus-iio
doesn't tell me how to use this "API") that's available somewhere else,
or is there a more turn-key user-space library available?

Cheers

(I've been told that the Yoga should probably use the quaternion sensor
instead, it's planned, and so is writing user-space front-ends for the
compass in some devices).

[1]: https://github.com/hadess/iio-sensor-proxy
[2]: https://github.com/hadess/iio-sensor-proxy/issues/1#issuecomment-54536393

Re: Kernel wishlist item: Better IIO API

[Jonathan Cameron]

On 13/11/14 20:05, Bastien Nocera wrote:
> On Wed, 2014-10-29 at 19:30 +0100, Lars-Peter Clausen wrote:
> <snip>
>> The sysfs ABI is not meant to be self documenting and it is not 
>> undocumented. The documentation for the different attributes can be found in 
>> Documentation/ABI/testing/sysfs-bus-iio[1].
> <snip>
>> I can understand your frustration. A API that is not usable in a generic way 
>> is not really useful. So we should try to fix that, but we are bound by the 
>> framework itself and can't just throw everything away.
> 
> I'll go back to this e-mail, and start again with very concrete examples
> of my problems. I'm looking for shorter term gains here, while you can
> look at my questions as inspiration for what needs fixing longer term :)
Sorry for my lack of proper reply.  Been a busy few weeks and long term
discussions always seem to get queued up behind patch reviews that need doing,
> 
> My goal is to move iio-sensor-proxy[1] into systemd's codebase, probably
> in logind. I know of two different "types" of sensors that I'd like to
> support, and 2 very different types of drivers.
cool
> 
> The driver used in the Lenovo Yoga Pros (hid-sensor-accel-3d), which I
> used to write the iio-sensor-proxy, requires the following procedure to
> be used:
> - find the accelerometer iio device (with the "accel_3d" name)
> - find the associated trigger
> - enable the sensors by writing to some files in scan_elements/
> - enable the ring buffer by writing to buffer/enable
> - enable the trigger found above by writing to trigger/current_trigger
You'll need to set the trigger before enabling the buffer...
> - parse the files in scan_elements/ to find the channel array
> - find the scale of each axis
> - on some variants, tweak the hysteresis [2] to trigger changes
interesting one. - Note I personally don't mind fixes for firmware bugs
in kernel - if there is a simple way of identifying parts with the problem.
> - and then read from the ring buffer on a regular basis, parse those
> buffers, scale them, and we finally have the 3 dimensions we needed
Hmm.. We did have a handy watermark patch set back in August that got
stuck up on details and would make this slightly nicer.  I'll chase
that one up when I get a chance.
> 
> The driver used in the Onda tablet I have is far less featureful.
> - find the accelerometer iio device (this time called "i2c-SMO8500:00")
> - build the channel array (?? I haven't found how)
> - read the scale of each axis
> - read directly from the sysfs files for each axis (?? surely not) on a
> regular basis, scale the values, and we have the 3 dimensions
On this second one, the driver has trigger and buffer support
(not all drivers have as it's optional - doesn't make any sense for very
 slow devices and adds some complexity).

However, looking at that driver - the interrupt is optional. If
it's not there (i.e. either the pin isn't connected, or the relevant
information isn't supplied to the driver to tell it which interrupt
is in use) then the driver does indeed only enable the polled mode.
That is, it doesn't set up either the trigger or the buffer.

So the question is whether the tablet really doesn't route that pin
or whether there is an issue in the driver identifying it.

Looking briefly back at the patch that added support for the SM08500
it was clear then that we didn't have the interrupt.
Hence we are into the realms of polling at some level...

It would be fine to add support to the driver for a trigger that
instead of using the interrupt simply polls the device - ugly but
about all we can do here.  Looks like reading the int_source1 register
will tell us whether new data is available...

So in conclusion - the issue here is that a rather nasty work around
is needed for either a bad configuration or non optimal hardware design.

Still I guess there isn't much we can do about it...
> 
> Is this at all correct? Is there documentation (the sysfs-bus-iio
> doesn't tell me how to use this "API")
True enough, the docs are rather more in the form of the example
program (drivers/staging/iio/Documentation) than explicit docs.
The docs that do exist tend to lag behind the code unfortunately
and since things have gotten rather more stable no one has had
the time to write a full set.

> that's available somewhere else,
> or is there a more turn-key user-space library available?
> 
> Cheers
> 
> (I've been told that the Yoga should probably use the quaternion sensor
> instead, it's planned, and so is writing user-space front-ends for the
> compass in some devices).
> 
> [1]: https://github.com/hadess/iio-sensor-proxy
> [2]: https://github.com/hadess/iio-sensor-proxy/issues/1#issuecomment-54536393
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: Kernel wishlist item: Better IIO API

[Bastien Nocera]

> On 16 Nov 2014, at 23:12, Jonathan Cameron <jic23@kernel.org> wrote:
> 
>> The driver used in the Onda tablet I have is far less featureful.
>> - find the accelerometer iio device (this time called "i2c-SMO8500:00")
>> - build the channel array (?? I haven't found how)
>> - read the scale of each axis
>> - read directly from the sysfs files for each axis (?? surely not) on a
>> regular basis, scale the values, and we have the 3 dimensions
> On this second one, the driver has trigger and buffer support
> (not all drivers have as it's optional - doesn't make any sense for very
> slow devices and adds some complexity).
> 
> However, looking at that driver - the interrupt is optional. If
> it's not there (i.e. either the pin isn't connected, or the relevant
> information isn't supplied to the driver to tell it which interrupt
> is in use) then the driver does indeed only enable the polled mode.
> That is, it doesn't set up either the trigger or the buffer.
> 
> So the question is whether the tablet really doesn't route that pin
> or whether there is an issue in the driver identifying it.
> 
> Looking briefly back at the patch that added support for the SM08500
> it was clear then that we didn't have the interrupt.
> Hence we are into the realms of polling at some level...

I'll try to ask somebody with Windows on that tablet whether there is an interrupt associated with the device or not. It could very well be a problem with the ACPI support on that tablet (I'm still chasing battery reporting...)

> It would be fine to add support to the driver for a trigger that
> instead of using the interrupt simply polls the device - ugly but
> about all we can do here.  Looks like reading the int_source1 register
> will tell us whether new data is available...
> 
> So in conclusion - the issue here is that a rather nasty work around
> is needed for either a bad configuration or non optimal hardware design.
> 
> Still I guess there isn't much we can do about it...

But without the scan_elements subdir, I can't know what the device would spit out, so I need to use sysfs directly, not the dev node. Is that correct?

Cheers

Re: Kernel wishlist item: Better IIO API

[Jonathan Cameron]

Frankie

On November 16, 2014 10:42:36 PM GMT+00:00, Bastien Nocera <hadess@hadess.net> wrote:
>
>> On 16 Nov 2014, at 23:12, Jonathan Cameron <jic23@kernel.org> wrote:
>> 
>>> The driver used in the Onda tablet I have is far less featureful.
>>> - find the accelerometer iio device (this time called
>"i2c-SMO8500:00")
>>> - build the channel array (?? I haven't found how)
>>> - read the scale of each axis
>>> - read directly from the sysfs files for each axis (?? surely not)
>on a
>>> regular basis, scale the values, and we have the 3 dimensions
>> On this second one, the driver has trigger and buffer support
>> (not all drivers have as it's optional - doesn't make any sense for
>very
>> slow devices and adds some complexity).
>> 
>> However, looking at that driver - the interrupt is optional. If
>> it's not there (i.e. either the pin isn't connected, or the relevant
>> information isn't supplied to the driver to tell it which interrupt
>> is in use) then the driver does indeed only enable the polled mode.
>> That is, it doesn't set up either the trigger or the buffer.
>> 
>> So the question is whether the tablet really doesn't route that pin
>> or whether there is an issue in the driver identifying it.
>> 
>> Looking briefly back at the patch that added support for the SM08500
>> it was clear then that we didn't have the interrupt.
>> Hence we are into the realms of polling at some level...
>
>I'll try to ask somebody with Windows on that tablet whether there is
>an interrupt associated with the device or not. It could very well be a
>problem with the ACPI support on that tablet (I'm still chasing battery
>reporting...)
>
>> It would be fine to add support to the driver for a trigger that
>> instead of using the interrupt simply polls the device - ugly but
>> about all we can do here.  Looks like reading the int_source1
>register
>> will tell us whether new data is available...
>> 
>> So in conclusion - the issue here is that a rather nasty work around
>> is needed for either a bad configuration or non optimal hardware
>design.
>> 
>> Still I guess there isn't much we can do about it...
>
>But without the scan_elements subdir, I can't know what the device
>would spit out, so I need to use sysfs directly, not the dev node. Is
>that correct?

Support could be added to the driver for polling of the register (effectively faking interrupt support).

Then it would work as if the interrupt was present.


>
>Cheers
>--
>To unsubscribe from this list: send the line "unsubscribe linux-iio" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

Re: Kernel wishlist item: Better IIO API

[Elad Alfassa]

Jonathan Cameron <jic23@...> writes:
[snip]
> > - on some variants, tweak the hysteresis [2] to trigger changes
> interesting one. - Note I personally don't mind fixes for firmware bugs
> in kernel - if there is a simple way of identifying parts with the problem.

Late followup, but (hopefully) better than nothing:

I have such device that has the hysteresis issue.

I don't know if there's a sure way to identify devices with this issue...
either automatically tweak the hysteresis when getting EAGAIN, or keep a
list of USB device IDs which require the hysteresis fix and apply them
automatically. Does this make sense? 

I would really prefer that this sort of fix will live in the kernel and not
in any userspace utility that might want to use the sensors.


> > [2]:
https://github.com/hadess/iio-sensor-proxy/issues/1#issuecomment-54536393