>> >> - if IIO_INT_VAL_PLUS_NANO is returned (common when dealing with >> current sources), 32 bits is a bit tight - which is why the read_raw >> function pointer in iio_info has (val, val2) in the first place. >> - People like me who do not use the iio_convert_raw_to_processed >> path() but need to support IIO_CHAN_INFO_PROCESSED directly in their >> driver have an issue: we would need to be passed the scale in the >> read_raw function of iio_info. That would impact _all_ IIO drivers. > > IIO_CHAN_INFO_PROCESSED is by definition supposed to return the value in the > proper unit. If that doesn't work for you use IIO_CHAN_INFO_RAW + > IIO_CHAN_INFO_SCALE. Think of IIO_CHAN_INFO_PROCESSED as IIO_CHAN_INFO_RAW > with the scale set to 1.0 This isn't a unit problem, this is a precision problem: if I want to return a current in Ampères, for instance 5.000000001, I can't get that by calling iio_read_channel_processed() (or iio_read_channel_raw() for that matter) as the precision is too big to fit in only one integer. The issue is that the callback that handles IIO_CHAN_INFO_PROCESSED and IIO_CHAN_INFO_RAW does allow to return such a value. There's an inconsistency in the interface. > >> - The scale parameter to iio_convert_raw_to_processed() itself is an >> int, and IIO_CHAN_INFO_SCALE can return a scale in the >> IIO_VAL_INT_PLUS_NANO scheme. It means somewhere along the road, >> precision is lost. > > The scale would be passed in by the consumer, so the consumer is able to > specify the amount of precision it wants. Not if they want a precision as high as the IIO driver is able to deliver: the scale returned by a IIO_CHAN_INFO_SCALE is a 64-bits fixed point integer. The scaled passed to iio_convert_raw_to_processed() is a 32 bit integer. If one needs great precision on big numbers, it won't fit. Guillaume -- 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
