* Questions: IIO type for absorbance and float values in channels? @ 2022-06-21 12:18 Stefan Lengfeld 2022-06-21 12:29 ` Jonathan Cameron 0 siblings, 1 reply; 6+ messages in thread From: Stefan Lengfeld @ 2022-06-21 12:18 UTC (permalink / raw) To: linux-iio 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Questions: IIO type for absorbance and float values in channels? 2022-06-21 12:18 Questions: IIO type for absorbance and float values in channels? Stefan Lengfeld @ 2022-06-21 12:29 ` Jonathan Cameron 2022-06-21 14:13 ` Andy Shevchenko 2022-06-22 15:42 ` Stefan Lengfeld 0 siblings, 2 replies; 6+ messages in thread From: Jonathan Cameron @ 2022-06-21 12:29 UTC (permalink / raw) To: Stefan Lengfeld; +Cc: linux-iio 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Questions: IIO type for absorbance and float values in channels? 2022-06-21 12:29 ` Jonathan Cameron @ 2022-06-21 14:13 ` Andy Shevchenko 2022-06-21 19:26 ` Jonathan Cameron 2022-06-22 15:42 ` Stefan Lengfeld 1 sibling, 1 reply; 6+ messages in thread From: Andy Shevchenko @ 2022-06-21 14:13 UTC (permalink / raw) To: Jonathan Cameron; +Cc: Stefan Lengfeld, linux-iio 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Questions: IIO type for absorbance and float values in channels? 2022-06-21 14:13 ` Andy Shevchenko @ 2022-06-21 19:26 ` Jonathan Cameron 0 siblings, 0 replies; 6+ messages in thread From: Jonathan Cameron @ 2022-06-21 19:26 UTC (permalink / raw) To: Andy Shevchenko; +Cc: Jonathan Cameron, Stefan Lengfeld, linux-iio 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Questions: IIO type for absorbance and float values in channels? 2022-06-21 12:29 ` Jonathan Cameron 2022-06-21 14:13 ` Andy Shevchenko @ 2022-06-22 15:42 ` Stefan Lengfeld 2022-06-25 13:21 ` Jonathan Cameron 1 sibling, 1 reply; 6+ messages in thread From: Stefan Lengfeld @ 2022-06-22 15:42 UTC (permalink / raw) To: Jonathan Cameron; +Cc: linux-iio 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Questions: IIO type for absorbance and float values in channels? 2022-06-22 15:42 ` Stefan Lengfeld @ 2022-06-25 13:21 ` Jonathan Cameron 0 siblings, 0 replies; 6+ messages in thread From: Jonathan Cameron @ 2022-06-25 13:21 UTC (permalink / raw) To: Stefan Lengfeld; +Cc: Jonathan Cameron, linux-iio 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2022-06-25 13:12 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2022-06-21 12:18 Questions: IIO type for absorbance and float values in channels? Stefan Lengfeld 2022-06-21 12:29 ` Jonathan Cameron 2022-06-21 14:13 ` Andy Shevchenko 2022-06-21 19:26 ` Jonathan Cameron 2022-06-22 15:42 ` Stefan Lengfeld 2022-06-25 13:21 ` Jonathan Cameron
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.