[RFC] Spectral ID sensor + floating point questions

[RFC] Spectral ID sensor + floating point questions

[Matt Ranostay]

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

Re: [RFC] Spectral ID sensor + floating point questions

[Jonathan Cameron]

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

Re: [RFC] Spectral ID sensor + floating point questions

[Matt Ranostay]

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
>

Re: [RFC] Spectral ID sensor + floating point questions

[Jonathan Cameron]

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

Re: [RFC] Spectral ID sensor + floating point questions

[Matt Ranostay]

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
>

Re: [RFC] Spectral ID sensor + floating point questions

[Jonathan Cameron]

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