On 2016-10-21 09:17, jic23@xxxxxxxxxx wrote: > On 20.10.2016 19:17, Peter Rosin wrote: >> On 2016-10-20 19:37, Jonathan Cameron wrote: >>> http://marc.info/?l=linux-iio&m=138469765309868&w=2 I think... >> >> Interesting, one issue with that is that it is all in real world >> units, while I'd rather have the raw value. > Um.. It's been a while, but the principle was (IIRC) that every > _available would match the units fo the associated info mask element. > Thus if you have a _raw element it would be in adc counts (most likely). > > _input would be in relevant real world units, scale etc in the whatever > units the value itself is in. Ah, that was just me totally misreading the patch. I didn't realize that the iio_format_value function is also used for raw values and assumed it was all about real world units when that function was used. Feel rather silly ATM... >> So, I would need to >> convert back to the raw value using the scale, which sounds boring >> but doable. However, I wonder if calibration may also be involved >> with that conversion back to raw for some channels? That sounds a >> bit more driver specific and potentially troublesome... > I've not had a chance to look at your code (only picked up on this as > there was a fair length thread developing), but I wouldn't have thought > we'd > need to deal with calibrations. Might need them to move to real world > units from raw but that's always the case anyway (unfortunately). Right. Cheers, Peter -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
