Questions: IIO type for absorbance and float values in channels?

Questions: IIO type for absorbance and float values in channels?

[Stefan Lengfeld]

Hi all,

I'm currently working on a linux kernel driver for a new sensor design. It's a
special kind of light sensor that measures the reflection of emitted light.

I'm trying to fit this type of sensor into the IIO subsystem but I hit some
issues.


Question 1:

The sensor measures the absorbance[1] of a material. It's the negative
logarithmic quotient of the received and emitted light. It's a unit-less value.

As far as I can see there is currently no predefined IIO type in the kernel for
this.  I have search the list [2], but nothing matches.

Do I overlook something or what channel type should I use for this sensor
measurement value?


Question 2:

The sensor effectively returns a float value of the measurement. I grepped trough
the existing IIO drivers, but there seems only one driver that deals with float
values.  The sps30 driver[3] gets a float from the device, but converts it to a
integer value before passing it to the IIO subsystem.

I know that it's possible to provide a 'scale' attribute per channel to
userspace[4], which can be a float point number. So effectively the result of a
measurement can be a float-point value after it's computed in userspace.

Are floats really not supported as channel values? What is the recommend
approach to deal with these measurement values?


Question 3:

Is there another kernel subsystem/UAPI that fits this type of sensor
better?  (My guess would be: No, IIO is the correct subsystem.)


Thanks a lot for answering my question.


Kind regards,
Stefan

[1]: https://en.wikipedia.org/wiki/Absorbance
[2]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/uapi/linux/iio/types.h#n14
[3]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/iio/chemical/sps30.c#n39
[4]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/iio/dummy/iio_simple_dummy.c#n122

Re: Questions: IIO type for absorbance and float values in channels?

[Jonathan Cameron]

On Tue, 21 Jun 2022 14:18:55 +0200
Stefan Lengfeld <stefan.lengfeld@inovex.de> wrote:

> Hi all,

Hi Stefan,

> 
> I'm currently working on a linux kernel driver for a new sensor design. It's a
> special kind of light sensor that measures the reflection of emitted light.
> 
> I'm trying to fit this type of sensor into the IIO subsystem but I hit some
> issues.
> 
> 
> Question 1:
> 
> The sensor measures the absorbance[1] of a material. It's the negative
> logarithmic quotient of the received and emitted light. It's a unit-less value.
> 
> As far as I can see there is currently no predefined IIO type in the kernel for
> this.  I have search the list [2], but nothing matches.
> 
> Do I overlook something or what channel type should I use for this sensor
> measurement value?

So the closest we've seen to this is some of the health sensors (pulse oximeter
targeting devices) but in that case the processing is done with a custom userspace
library so we just pass values on in fixed point.

So probably needs a new channel type.

 
> 
> 
> Question 2:
> 
> The sensor effectively returns a float value of the measurement. I grepped trough
> the existing IIO drivers, but there seems only one driver that deals with float
> values.  The sps30 driver[3] gets a float from the device, but converts it to a
> integer value before passing it to the IIO subsystem.
> 
> I know that it's possible to provide a 'scale' attribute per channel to
> userspace[4], which can be a float point number.

More fixed point - though we have a couple of precision options. The aim there
is to ensure we only need a few bits of custom code to consume these values
in kernel. Raw value can also be fixed point.


> So effectively the result of a
> measurement can be a float-point value after it's computed in userspace.
> 
> Are floats really not supported as channel values? What is the recommend
> approach to deal with these measurement values?

So, in kernel we basically can't do floats (not quite true, but near enough that
it doesn't matter).  Given IIO can have in kernel consumers, that more or
less rules out true floating point handling.

We have in the past discussed simply passing them on to userspace (and
hence ruling out any interpretation of the value) but so far no one has added
the necessary support.  I'm not against adding that support, but I would
want to see the code / docs to fully understand why we are doing it.
It will be a special case in various code paths hence the extra consideration
needed.

> 
> 
> Question 3:
> 
> Is there another kernel subsystem/UAPI that fits this type of sensor
> better?  (My guess would be: No, IIO is the correct subsystem.)

Based on your description, IIO is the best option.

Jonathan

> 
> 
> Thanks a lot for answering my question.
> 
> 
> Kind regards,
> Stefan
> 
> [1]: https://en.wikipedia.org/wiki/Absorbance
> [2]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/uapi/linux/iio/types.h#n14
> [3]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/iio/chemical/sps30.c#n39
> [4]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/iio/dummy/iio_simple_dummy.c#n122

Re: Questions: IIO type for absorbance and float values in channels?

[Andy Shevchenko]

On Tue, Jun 21, 2022 at 2:29 PM Jonathan Cameron
<Jonathan.Cameron@huawei.com> wrote:
> On Tue, 21 Jun 2022 14:18:55 +0200
> Stefan Lengfeld <stefan.lengfeld@inovex.de> wrote:

...

> > Question 1:
> >
> > The sensor measures the absorbance[1] of a material. It's the negative
> > logarithmic quotient of the received and emitted light. It's a unit-less value.
> >
> > As far as I can see there is currently no predefined IIO type in the kernel for
> > this.  I have search the list [2], but nothing matches.
> >
> > Do I overlook something or what channel type should I use for this sensor
> > measurement value?
>
> So the closest we've seen to this is some of the health sensors (pulse oximeter
> targeting devices) but in that case the processing is done with a custom userspace
> library so we just pass values on in fixed point.
>
> So probably needs a new channel type.

Wouldn't this be a particular case of ambient (light) sensor?

-- 
With Best Regards,
Andy Shevchenko

Re: Questions: IIO type for absorbance and float values in channels?

[Jonathan Cameron]

On Tue, 21 Jun 2022 16:13:25 +0200
Andy Shevchenko <andy.shevchenko@gmail.com> wrote:

> On Tue, Jun 21, 2022 at 2:29 PM Jonathan Cameron
> <Jonathan.Cameron@huawei.com> wrote:
> > On Tue, 21 Jun 2022 14:18:55 +0200
> > Stefan Lengfeld <stefan.lengfeld@inovex.de> wrote:  
> 
> ...
> 
> > > Question 1:
> > >
> > > The sensor measures the absorbance[1] of a material. It's the negative
> > > logarithmic quotient of the received and emitted light. It's a unit-less value.
> > >
> > > As far as I can see there is currently no predefined IIO type in the kernel for
> > > this.  I have search the list [2], but nothing matches.
> > >
> > > Do I overlook something or what channel type should I use for this sensor
> > > measurement value?  
> >
> > So the closest we've seen to this is some of the health sensors (pulse oximeter
> > targeting devices) but in that case the processing is done with a custom userspace
> > library so we just pass values on in fixed point.
> >
> > So probably needs a new channel type.  
> 
> Wouldn't this be a particular case of ambient (light) sensor?
> 

Not IIO_LIGHT / illuminance (which is the human eye profile corrected light reading we
tend to care about), but could probably be considered intensity
with a modifier. The snag is we have colour modifiers for that and so
this is one of those corner cases where we would ideally allow
modifiers to stack, but we don't (and can't retrofit that because
of the space in the IIO_EVENT definition - there is no where to
put it :(  So it is like illuminance in the sense that it is a computed
value (or that's one implementation anyway) based on intensity channels.
I've never seen a sensor actually measure illuminance directly - they tend
to combine multiple sensors with different frequency responses using some
secret sauce (or attempt to bodge something reasonable from one reading based
on assumptions about the light source).  Arguably it's also like the
proximity devices that just use intensity of response relative to a light
source the control (the cheap ones :)

There isn't really a good answer as there is a bit too much to describe about this
channel type... 

Jonathan

 

Re: Questions: IIO type for absorbance and float values in channels?

[Stefan Lengfeld]

Hi Jonathan, 

On Tue, Jun 21, 2022 at 01:29:09PM +0100, Jonathan Cameron wrote:
> > Is there another kernel subsystem/UAPI that fits this type of sensor
> > better?  (My guess would be: No, IIO is the correct subsystem.)
> 
> Based on your description, IIO is the best option.

Great. This means that I'm on the right track.


> > Question 1:
> > 
> > The sensor measures the absorbance[1] of a material. It's the negative
> > logarithmic quotient of the received and emitted light. It's a unit-less value.
> > 
> > As far as I can see there is currently no predefined IIO type in the kernel for
> > this.  I have search the list [2], but nothing matches.
> > 
> > Do I overlook something or what channel type should I use for this sensor
> > measurement value?
> 
> So the closest we've seen to this is some of the health sensors (pulse oximeter
> targeting devices) but in that case the processing is done with a custom userspace
> library so we just pass values on in fixed point.

I have look at the 'oximeter' drivers in the IIO framework, namely
afe440x and max3010x. All use the IIO type IIO_INTENSITY and the
max30100x drivers also use the modifiers IIO_MOD_LIGHT_*.

You also referenced the modifiers in your response to Andy.


> So probably needs a new channel type.

Ok. This makes it a bit harder for us, because we want to provide a
kernel driver that also works for older kernels.

Is there a private IIO type range that can be use in the meantime,
until a new IIO type is accepted and merged upstream?

Another side note/question: Is there a documented mapping between the
IIO types and physical SI units?  I have found nothing about that in the
IIO documentation. It would have helped me to better understand the
differences between the various types.

Just for reference. I mentioned the absorbance, but there is also
another equivalent physical value: the refelctance[1]. It's the same
value just without the negative logarithm.


> > So effectively the result of a
> > measurement can be a float-point value after it's computed in userspace.
> > 
> > Are floats really not supported as channel values? What is the recommend
> > approach to deal with these measurement values?
> 
> So, in kernel we basically can't do floats (not quite true, but near enough that
> it doesn't matter).  Given IIO can have in kernel consumers, that more or
> less rules out true floating point handling.

Yes, float point math is frowned in the kernel. I have read the kernel
hacking documentation [2]. :-) But I also know that the functions
kernel_fpu_begin() and kernel_fpu_end() exist (including there
performance problems ;-) ).


> We have in the past discussed simply passing them on to userspace (and
> hence ruling out any interpretation of the value) but so far no one has added
> the necessary support.  I'm not against adding that support, but I would
> want to see the code / docs to fully understand why we are doing it.
> It will be a special case in various code paths hence the extra consideration
> needed.

Ack on that. My take way is that it's currently not implemented but
theoretical acceptable upstream to pass float point values from the chip
to userspace. But it would require a good/valid show case and extra work
in the IIO subsystem.

I take this information to the sensor engineers. Maybe we can rework the
communication/data protocol to pass the measurement as integer values
with a separate scale factor that does not require raw float point
values.


> > I know that it's possible to provide a 'scale' attribute per channel to
> > userspace[4], which can be a float point number.
> 
> More fixed point - though we have a couple of precision options. The aim there
> is to ensure we only need a few bits of custom code to consume these values
> in kernel. Raw value can also be fixed point.

Yes. I already saw and tested the IIO_VAL_* defines (like
IIO_VAL_INT_PLUS_NANO or IIO_VAL_FRACTIONAL) that can be used to provide
fixed point scale values to userspace. They work great and maybe we can
use them.

Thanks again!

Kind Regards, 
Stefan

[1]: https://en.wikipedia.org/wiki/Reflectance
[2]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/kernel-hacking/hacking.rst?id=9d2231c5d74e13b2a0546fee6737ee4446017903#n134

Re: Questions: IIO type for absorbance and float values in channels?

[Jonathan Cameron]

On Wed, 22 Jun 2022 17:42:25 +0200
Stefan Lengfeld <stefan.lengfeld@inovex.de> wrote:

> Hi Jonathan, 
> 
> On Tue, Jun 21, 2022 at 01:29:09PM +0100, Jonathan Cameron wrote:
> > > Is there another kernel subsystem/UAPI that fits this type of sensor
> > > better?  (My guess would be: No, IIO is the correct subsystem.)  
> > 
> > Based on your description, IIO is the best option.  
> 
> Great. This means that I'm on the right track.
> 
> 
> > > Question 1:
> > > 
> > > The sensor measures the absorbance[1] of a material. It's the negative
> > > logarithmic quotient of the received and emitted light. It's a unit-less value.
> > > 
> > > As far as I can see there is currently no predefined IIO type in the kernel for
> > > this.  I have search the list [2], but nothing matches.
> > > 
> > > Do I overlook something or what channel type should I use for this sensor
> > > measurement value?  
> > 
> > So the closest we've seen to this is some of the health sensors (pulse oximeter
> > targeting devices) but in that case the processing is done with a custom userspace
> > library so we just pass values on in fixed point.  
> 
> I have look at the 'oximeter' drivers in the IIO framework, namely
> afe440x and max3010x. All use the IIO type IIO_INTENSITY and the
> max30100x drivers also use the modifiers IIO_MOD_LIGHT_*.
> 
> You also referenced the modifiers in your response to Andy.
> 
> 
> > So probably needs a new channel type.  
> 
> Ok. This makes it a bit harder for us, because we want to provide a
> kernel driver that also works for older kernels.
> 
> Is there a private IIO type range that can be use in the meantime,
> until a new IIO type is accepted and merged upstream?

No unfortunately. Such ranges only work with a bunch of 'vendor id'
type magic to allow avoidance of clashes so tend to be complex unless
you expect to have long term vendor specific types.  The result
is that I know a bunch of vendors are carrying backports of core
IIO changes to enable new sensor types (and features sometimes),
obviously a bit harder to do if you are providing a single sensor
driver.

> 
> Another side note/question: Is there a documented mapping between the
> IIO types and physical SI units?  I have found nothing about that in the
> IIO documentation. It would have helped me to better understand the
> differences between the various types.

Documentation/ABI/testing/sysfs-bus-iio 
has most stuff.  We haven't done a great job at cross reference between
the other docs and there.


> 
> Just for reference. I mentioned the absorbance, but there is also
> another equivalent physical value: the refelctance[1]. It's the same
> value just without the negative logarithm.
> 
> 
> > > So effectively the result of a
> > > measurement can be a float-point value after it's computed in userspace.
> > > 
> > > Are floats really not supported as channel values? What is the recommend
> > > approach to deal with these measurement values?  
> > 
> > So, in kernel we basically can't do floats (not quite true, but near enough that
> > it doesn't matter).  Given IIO can have in kernel consumers, that more or
> > less rules out true floating point handling.  
> 
> Yes, float point math is frowned in the kernel. I have read the kernel
> hacking documentation [2]. :-) But I also know that the functions
> kernel_fpu_begin() and kernel_fpu_end() exist (including there
> performance problems ;-) ).
> 
> 
> > We have in the past discussed simply passing them on to userspace (and
> > hence ruling out any interpretation of the value) but so far no one has added
> > the necessary support.  I'm not against adding that support, but I would
> > want to see the code / docs to fully understand why we are doing it.
> > It will be a special case in various code paths hence the extra consideration
> > needed.  
> 
> Ack on that. My take way is that it's currently not implemented but
> theoretical acceptable upstream to pass float point values from the chip
> to userspace. But it would require a good/valid show case and extra work
> in the IIO subsystem.

Yup.

> 
> I take this information to the sensor engineers. Maybe we can rework the
> communication/data protocol to pass the measurement as integer values
> with a separate scale factor that does not require raw float point
> values.

Would be great if that is a fair representation of what is going on
in the device.   If the device is doing something hideously non linear
using an actual FPU then it might be very challenging.

> 
> 
> > > I know that it's possible to provide a 'scale' attribute per channel to
> > > userspace[4], which can be a float point number.  
> > 
> > More fixed point - though we have a couple of precision options. The aim there
> > is to ensure we only need a few bits of custom code to consume these values
> > in kernel. Raw value can also be fixed point.  
> 
> Yes. I already saw and tested the IIO_VAL_* defines (like
> IIO_VAL_INT_PLUS_NANO or IIO_VAL_FRACTIONAL) that can be used to provide
> fixed point scale values to userspace. They work great and maybe we can
> use them.
> 
> Thanks again!

Good luck. Looking forward to seeing the code + more details on
your sensor!

Jonathan

> 
> Kind Regards, 
> Stefan
> 
> [1]: https://en.wikipedia.org/wiki/Reflectance
> [2]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/kernel-hacking/hacking.rst?id=9d2231c5d74e13b2a0546fee6737ee4446017903#n134