On Thu, 24 May 2018 13:31:57 +0800 Matt Ranostay <matt.ranostay@xxxxxxxxxxxx> wrote: > On Wed, May 23, 2018 at 1:12 AM, Jonathan Cameron <jic23@xxxxxxxxxx> wrote: > > 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? > > > > 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@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 -- 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
