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? > 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 > -- 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
