On Mon, 21 May 2018 13:56:16 +0800 Matt Ranostay <matt.ranostay@xxxxxxxxxxxx> wrote: > On Mon, May 21, 2018 at 12:11 AM, Jonathan Cameron <jic23@xxxxxxxxxx> wrote: > > On Sun, 20 May 2018 22:21:03 +0800 > > Matt Ranostay <matt.ranostay@xxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx > 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
