* [RFC] Spectral ID sensor + floating point questions @ 2018-05-20 14:21 Matt Ranostay 2018-05-20 16:11 ` Jonathan Cameron 0 siblings, 1 reply; 6+ messages in thread From: Matt Ranostay @ 2018-05-20 14:21 UTC (permalink / raw) To: linux-iio, Jonathan Cameron Jonathan et all, Currently looking at ams AS7262 Spectral ID sensor, and thinking about adding support to enable a project I'm working on. But I noticed it is a bit odd in that outputs data for the 6 color channels in either a) raw 16-bit ADC values b) or calibration adjusted values (factory calibration) but are presented as 32-bit single precision floats. Clearly the latter data is much more useful but of course it is a floating point which isn't exactly the ideal in the kernel and there isn't a precedent in iio (that I know of) for such values. Datasheet: https://www.mouser.com/ds/2/588/AS7262_DS000486_2-00-1082195.pdf Any thoughts, or suggestions? Thanks, Matt ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [RFC] Spectral ID sensor + floating point questions 2018-05-20 14:21 [RFC] Spectral ID sensor + floating point questions Matt Ranostay @ 2018-05-20 16:11 ` Jonathan Cameron 2018-05-21 5:56 ` Matt Ranostay 0 siblings, 1 reply; 6+ messages in thread From: Jonathan Cameron @ 2018-05-20 16:11 UTC (permalink / raw) To: Matt Ranostay; +Cc: linux-iio On Sun, 20 May 2018 22:21:03 +0800 Matt Ranostay <matt.ranostay@konsulko.com> wrote: > Jonathan et all, > > Currently looking at ams AS7262 Spectral ID sensor, and thinking about > adding support to enable a project I'm working on. > > But I noticed it is a bit odd in that outputs data for the 6 color > channels in either a) raw 16-bit ADC values b) or calibration adjusted > values (factory calibration) but are presented as 32-bit single > precision floats. > > Clearly the latter data is much more useful but of course it is a > floating point which isn't exactly the ideal in the kernel and there > isn't a precedent in iio (that I know of) for such values. > > Datasheet: https://www.mouser.com/ds/2/588/AS7262_DS000486_2-00-1082195.pdf > > Any thoughts, or suggestions? Hmm. Will need to think about this a little, but from a very high level look at the datasheet and you description, there is nothing technically stopping us supporting devices that do standards compliant floating point. The only similar case we have run into in the past was the mess of the HID sensor spec which could in theory change range over time and report it via the event path. Thankfully I don't think we have ever seen a part that actually does this. That was tricky because it wasn't in a standard format and so pretty much required in kernel reformatting. As this is real floating point, we probably just want to pass it straight through to userspace using the buffered interface and a suitable description of the type. What we can't sensibly do is any in kernel consumers (as they'd have to do fp maths) or anything involving maths in kernel on these. We could do read_raw support with a suitable float to str function if it is potentially useful... So I'm not totally against the idea. However, we do need better description of light channels as giving them colors is only going to get us so far as these devices expand their number of channels and bring in the frequency range for each. Go for generality when you work this one out. Fun looking part. I hope you go ahead with this one. Jonathan > > Thanks, > > Matt ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [RFC] Spectral ID sensor + floating point questions 2018-05-20 16:11 ` Jonathan Cameron @ 2018-05-21 5:56 ` Matt Ranostay 2018-05-22 17:12 ` Jonathan Cameron 0 siblings, 1 reply; 6+ messages in thread From: Matt Ranostay @ 2018-05-21 5:56 UTC (permalink / raw) To: Jonathan Cameron; +Cc: linux-iio On Mon, May 21, 2018 at 12:11 AM, Jonathan Cameron <jic23@kernel.org> wrote: > On Sun, 20 May 2018 22:21:03 +0800 > Matt Ranostay <matt.ranostay@konsulko.com> wrote: > >> Jonathan et all, >> >> Currently looking at ams AS7262 Spectral ID sensor, and thinking about >> adding support to enable a project I'm working on. >> >> But I noticed it is a bit odd in that outputs data for the 6 color >> channels in either a) raw 16-bit ADC values b) or calibration adjusted >> values (factory calibration) but are presented as 32-bit single >> precision floats. >> >> Clearly the latter data is much more useful but of course it is a >> floating point which isn't exactly the ideal in the kernel and there >> isn't a precedent in iio (that I know of) for such values. >> >> Datasheet: https://www.mouser.com/ds/2/588/AS7262_DS000486_2-00-1082195.pdf >> >> Any thoughts, or suggestions? > > Hmm. Will need to think about this a little, but from a very high > level look at the datasheet and you description, there is nothing technically > stopping us supporting devices that do standards compliant floating point. > > The only similar case we have run into in the past was the mess of the HID > sensor spec which could in theory change range over time and report it > via the event path. Thankfully I don't think we have ever seen a part > that actually does this. That was tricky because it wasn't in a standard > format and so pretty much required in kernel reformatting. > > As this is real floating point, we probably just want to pass it straight > through to userspace using the buffered interface and a suitable > description of the type. > What would you recommend for naming? IIO_VAL_FLOAT, IIO_VAL_SINGLE, or etc? > What we can't sensibly do is any in kernel consumers (as they'd have > to do fp maths) or anything involving maths in kernel on these. > > We could do read_raw support with a suitable float to str function if > it is potentially useful... Actually after thinking about this we wouldn't need this because reading one channel is useless, you need all six channels from the same sample reading to have a valid data. Which is nice to not need to hack a float_to_str() function in for the time being. > > So I'm not totally against the idea. > > However, we do need better description of light channels as giving > them colors is only going to get us so far as these devices expand > their number of channels and bring in the frequency range for each. > Go for generality when you work this one out. Yeah not sure what to do here.. my first instinct is to just use the IIO_LIGHT with no modifiers since it is up to userspace to know what channels map to what on which AS726x part. > > Fun looking part. I hope you go ahead with this one. > > Jonathan > >> >> Thanks, >> >> Matt > ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [RFC] Spectral ID sensor + floating point questions 2018-05-21 5:56 ` Matt Ranostay @ 2018-05-22 17:12 ` Jonathan Cameron 2018-05-24 5:31 ` Matt Ranostay 0 siblings, 1 reply; 6+ messages in thread From: Jonathan Cameron @ 2018-05-22 17:12 UTC (permalink / raw) To: Matt Ranostay; +Cc: linux-iio On Mon, 21 May 2018 13:56:16 +0800 Matt Ranostay <matt.ranostay@konsulko.com> wrote: > On Mon, May 21, 2018 at 12:11 AM, Jonathan Cameron <jic23@kernel.org> wrote: > > On Sun, 20 May 2018 22:21:03 +0800 > > Matt Ranostay <matt.ranostay@konsulko.com> wrote: > > > >> Jonathan et all, > >> > >> Currently looking at ams AS7262 Spectral ID sensor, and thinking about > >> adding support to enable a project I'm working on. > >> > >> But I noticed it is a bit odd in that outputs data for the 6 color > >> channels in either a) raw 16-bit ADC values b) or calibration adjusted > >> values (factory calibration) but are presented as 32-bit single > >> precision floats. > >> > >> Clearly the latter data is much more useful but of course it is a > >> floating point which isn't exactly the ideal in the kernel and there > >> isn't a precedent in iio (that I know of) for such values. > >> > >> Datasheet: https://www.mouser.com/ds/2/588/AS7262_DS000486_2-00-1082195.pdf > >> > >> Any thoughts, or suggestions? > > > > Hmm. Will need to think about this a little, but from a very high > > level look at the datasheet and you description, there is nothing technically > > stopping us supporting devices that do standards compliant floating point. > > > > The only similar case we have run into in the past was the mess of the HID > > sensor spec which could in theory change range over time and report it > > via the event path. Thankfully I don't think we have ever seen a part > > that actually does this. That was tricky because it wasn't in a standard > > format and so pretty much required in kernel reformatting. > > > > As this is real floating point, we probably just want to pass it straight > > through to userspace using the buffered interface and a suitable > > description of the type. > > > > What would you recommend for naming? IIO_VAL_FLOAT, IIO_VAL_SINGLE, or etc? We might have weird float lengths etc so howabout the IEEE standard in the name? > > > > What we can't sensibly do is any in kernel consumers (as they'd have > > to do fp maths) or anything involving maths in kernel on these. > > > > We could do read_raw support with a suitable float to str function if > > it is potentially useful... > > Actually after thinking about this we wouldn't need this because > reading one channel > is useless, you need all six channels from the same sample reading to > have a valid data. > > Which is nice to not need to hack a float_to_str() function in for the > time being. > > > > > So I'm not totally against the idea. > > > > However, we do need better description of light channels as giving > > them colors is only going to get us so far as these devices expand > > their number of channels and bring in the frequency range for each. > > Go for generality when you work this one out. > > Yeah not sure what to do here.. my first instinct is to just use the > IIO_LIGHT with no modifiers > since it is up to userspace to know what channels map to what on which > AS726x part. I think we should describe it. Treat it a bit like the low / high pass filters and come up with some descriptive stats that we export to userspace for each channel. > > > > > Fun looking part. I hope you go ahead with this one. > > > > Jonathan > > > >> > >> Thanks, > >> > >> Matt > > > -- > 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [RFC] Spectral ID sensor + floating point questions 2018-05-22 17:12 ` Jonathan Cameron @ 2018-05-24 5:31 ` Matt Ranostay 2018-05-25 15:16 ` Jonathan Cameron 0 siblings, 1 reply; 6+ messages in thread From: Matt Ranostay @ 2018-05-24 5:31 UTC (permalink / raw) To: Jonathan Cameron; +Cc: linux-iio On Wed, May 23, 2018 at 1:12 AM, Jonathan Cameron <jic23@kernel.org> wrote: > On Mon, 21 May 2018 13:56:16 +0800 > Matt Ranostay <matt.ranostay@konsulko.com> wrote: > >> On Mon, May 21, 2018 at 12:11 AM, Jonathan Cameron <jic23@kernel.org> wrote: >> > On Sun, 20 May 2018 22:21:03 +0800 >> > Matt Ranostay <matt.ranostay@konsulko.com> wrote: >> > >> >> Jonathan et all, >> >> >> >> Currently looking at ams AS7262 Spectral ID sensor, and thinking about >> >> adding support to enable a project I'm working on. >> >> >> >> But I noticed it is a bit odd in that outputs data for the 6 color >> >> channels in either a) raw 16-bit ADC values b) or calibration adjusted >> >> values (factory calibration) but are presented as 32-bit single >> >> precision floats. >> >> >> >> Clearly the latter data is much more useful but of course it is a >> >> floating point which isn't exactly the ideal in the kernel and there >> >> isn't a precedent in iio (that I know of) for such values. >> >> >> >> Datasheet: https://www.mouser.com/ds/2/588/AS7262_DS000486_2-00-1082195.pdf >> >> >> >> Any thoughts, or suggestions? >> > >> > Hmm. Will need to think about this a little, but from a very high >> > level look at the datasheet and you description, there is nothing technically >> > stopping us supporting devices that do standards compliant floating point. >> > >> > The only similar case we have run into in the past was the mess of the HID >> > sensor spec which could in theory change range over time and report it >> > via the event path. Thankfully I don't think we have ever seen a part >> > that actually does this. That was tricky because it wasn't in a standard >> > format and so pretty much required in kernel reformatting. >> > >> > As this is real floating point, we probably just want to pass it straight >> > through to userspace using the buffered interface and a suitable >> > description of the type. >> > >> >> What would you recommend for naming? IIO_VAL_FLOAT, IIO_VAL_SINGLE, or etc? > We might have weird float lengths etc so howabout the IEEE standard in the > name? > So I assume like IIO_VAL_IEEE754 ? >> >> >> > What we can't sensibly do is any in kernel consumers (as they'd have >> > to do fp maths) or anything involving maths in kernel on these. >> > >> > We could do read_raw support with a suitable float to str function if >> > it is potentially useful... >> >> Actually after thinking about this we wouldn't need this because >> reading one channel >> is useless, you need all six channels from the same sample reading to >> have a valid data. >> >> Which is nice to not need to hack a float_to_str() function in for the >> time being. >> >> > >> > So I'm not totally against the idea. >> > >> > However, we do need better description of light channels as giving >> > them colors is only going to get us so far as these devices expand >> > their number of channels and bring in the frequency range for each. >> > Go for generality when you work this one out. >> >> Yeah not sure what to do here.. my first instinct is to just use the >> IIO_LIGHT with no modifiers >> since it is up to userspace to know what channels map to what on which >> AS726x part. > > I think we should describe it. Treat it a bit like the low / high > pass filters and come up with some descriptive stats that we export > to userspace for each channel. Been out of the loop for bit so which drivers do this now? :) Also one important note is the AS7261 outputs in tri-stimulus XYZ (CIE 1931) format, and which I have little clue how one could make descriptive stats for that. > >> >> > >> > Fun looking part. I hope you go ahead with this one. >> > >> > Jonathan >> > >> >> >> >> Thanks, >> >> >> >> Matt >> > >> -- >> 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 > ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [RFC] Spectral ID sensor + floating point questions 2018-05-24 5:31 ` Matt Ranostay @ 2018-05-25 15:16 ` Jonathan Cameron 0 siblings, 0 replies; 6+ messages in thread From: Jonathan Cameron @ 2018-05-25 15:16 UTC (permalink / raw) To: Matt Ranostay; +Cc: Jonathan Cameron, linux-iio On Thu, 24 May 2018 13:31:57 +0800 Matt Ranostay <matt.ranostay@konsulko.com> wrote: > On Wed, May 23, 2018 at 1:12 AM, Jonathan Cameron <jic23@kernel.org> wrote: > > On Mon, 21 May 2018 13:56:16 +0800 > > Matt Ranostay <matt.ranostay@konsulko.com> wrote: > > > >> On Mon, May 21, 2018 at 12:11 AM, Jonathan Cameron <jic23@kernel.org> wrote: > >> > On Sun, 20 May 2018 22:21:03 +0800 > >> > Matt Ranostay <matt.ranostay@konsulko.com> wrote: > >> > > >> >> Jonathan et all, > >> >> > >> >> Currently looking at ams AS7262 Spectral ID sensor, and thinking about > >> >> adding support to enable a project I'm working on. > >> >> > >> >> But I noticed it is a bit odd in that outputs data for the 6 color > >> >> channels in either a) raw 16-bit ADC values b) or calibration adjusted > >> >> values (factory calibration) but are presented as 32-bit single > >> >> precision floats. > >> >> > >> >> Clearly the latter data is much more useful but of course it is a > >> >> floating point which isn't exactly the ideal in the kernel and there > >> >> isn't a precedent in iio (that I know of) for such values. > >> >> > >> >> Datasheet: https://www.mouser.com/ds/2/588/AS7262_DS000486_2-00-1082195.pdf > >> >> > >> >> Any thoughts, or suggestions? > >> > > >> > Hmm. Will need to think about this a little, but from a very high > >> > level look at the datasheet and you description, there is nothing technically > >> > stopping us supporting devices that do standards compliant floating point. > >> > > >> > The only similar case we have run into in the past was the mess of the HID > >> > sensor spec which could in theory change range over time and report it > >> > via the event path. Thankfully I don't think we have ever seen a part > >> > that actually does this. That was tricky because it wasn't in a standard > >> > format and so pretty much required in kernel reformatting. > >> > > >> > As this is real floating point, we probably just want to pass it straight > >> > through to userspace using the buffered interface and a suitable > >> > description of the type. > >> > > >> > >> What would you recommend for naming? IIO_VAL_FLOAT, IIO_VAL_SINGLE, or etc? > > We might have weird float lengths etc so howabout the IEEE standard in the > > name? > > > > So I assume like IIO_VAL_IEEE754 ? Could put float in there as well to make it more 'human' readable. IIO_VAL_FLOAT32_IEEE754 ? > > >> > >> > >> > What we can't sensibly do is any in kernel consumers (as they'd have > >> > to do fp maths) or anything involving maths in kernel on these. > >> > > >> > We could do read_raw support with a suitable float to str function if > >> > it is potentially useful... > >> > >> Actually after thinking about this we wouldn't need this because > >> reading one channel > >> is useless, you need all six channels from the same sample reading to > >> have a valid data. > >> > >> Which is nice to not need to hack a float_to_str() function in for the > >> time being. > >> > >> > > >> > So I'm not totally against the idea. > >> > > >> > However, we do need better description of light channels as giving > >> > them colors is only going to get us so far as these devices expand > >> > their number of channels and bring in the frequency range for each. > >> > Go for generality when you work this one out. > >> > >> Yeah not sure what to do here.. my first instinct is to just use the > >> IIO_LIGHT with no modifiers > >> since it is up to userspace to know what channels map to what on which > >> AS726x part. > > > > I think we should describe it. Treat it a bit like the low / high > > pass filters and come up with some descriptive stats that we export > > to userspace for each channel. > > Been out of the loop for bit so which drivers do this now? :) > > Also one important note is the AS7261 outputs in tri-stimulus XYZ (CIE > 1931) format, and which I have little > clue how one could make descriptive stats for that. Hohum. I'd missed that. Good old CIE colour formats. Ah well. Where it makes sense represent the colour bands, where it doesn't - don't ;) > > > > >> > >> > > >> > Fun looking part. I hope you go ahead with this one. > >> > > >> > Jonathan > >> > > >> >> > >> >> Thanks, > >> >> > >> >> Matt > >> > > >> -- > >> 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 > > > -- > 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2018-05-25 15:16 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2018-05-20 14:21 [RFC] Spectral ID sensor + floating point questions Matt Ranostay 2018-05-20 16:11 ` Jonathan Cameron 2018-05-21 5:56 ` Matt Ranostay 2018-05-22 17:12 ` Jonathan Cameron 2018-05-24 5:31 ` Matt Ranostay 2018-05-25 15:16 ` Jonathan Cameron
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).