>> I have a driver for an ADC block that measures miscellaneous values in
>> various units (temperature, voltage, current...) to be read from
>> drivers in other kernel subsystems (the power supply class, for
>> instance).
>
> This already works today with the current implementation of
> iio_read_channel_processed.
Indeed.
>
> Unit conversion has to be done by the IIO device itself as
>> it's done using tables that are provided by various vendors who don't
>> want them published.
>
> So how do you include the tables in the IIO driver if they can't be published?
I will load them as a blob from the device tree. It doesn't need to
have a very high level of protection - I just need to ensure that
those values aren't hard-coded in a file under the GPL.
>
>> Hence my need to call iio_read_channel_processed
>> and not entrust anyone else with the conversion.
>
> Ah, ok, so your driver implements IIO_CHAN_INFO_PROCESSED instead of
> IIO_CHAN_INFO_RAW. And you want to be able to specify your value with
> sub-decimal precession, is this correct?
Absolutely.
>
>>
>> Could _you_ please explain what your concern with using the same format is?
>
> Because the definition of IIO_CHAN_INFO_PROCESSED is that the value has
> already the proper unit and no unit conversion is necessary.
Now I see, thanks.
Getting back to the precision issue, I see that in
iio_convert_raw_to_processed_unlocked() there is the following code:
case IIO_VAL_INT_PLUS_MICRO:
if (scale_val2 < 0)
*processed = -raw64 * scale_val;
else
*processed = raw64 * scale_val;
*processed += div_s64(raw64 * (s64)scale_val2 * scale,
1000000LL);
break;
case IIO_VAL_INT_PLUS_NANO:
if (scale_val2 < 0)
*processed = -raw64 * scale_val;
else
*processed = raw64 * scale_val;
*processed += div_s64(raw64 * (s64)scale_val2 * scale,
with processed being of type int *. So the sub-decimal precision is
indeed lost. Is there a big issue with adapting the code to also
handle sub-decimal precision, then?
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
