[PATCH v2 5/5] iio: mxs-lradc: add write_raw function to modify scale

[Marek Vasut]

Dear Jonathan Cameron,

> On 07/19/2013 05:22 PM, Hector Palacios wrote:
> > Dear Marek,
> > 
> > On 07/19/2013 06:17 PM, Marek Vasut wrote:
> >>> Here you have three entries per channel:
> >>> in_voltageX_raw        -> the sample raw value
> >>> in_voltageX_scale    -> the scale to multiply the raw value to get the
> >> 
> >> voltage
> >> 
> >>> in mV in_voltageX_scale_available -> lists the available scales of the
> >>> channel
> >>> 
> >>> For example for channel 0:
> >>> 
> >>> # cat in_voltage0_scale_available
> >>> 0.451660156 0.903320312    (two scales available, first with divider by
> >>> two disabled, second with divider by two enabled)
> >>> 
> >>> # cat in_voltage0_scale
> >>> 0.451660156            (divider by two is currently disabled)
> >>> 
> >>> # cat in_voltage0_raw        (shows measured value)
> >>> 1000
> >>> 
> >>> If you multiply the value by the scale you get: 1000 * 0.451660156 =
> >>> 451.6 mV
> >>> 
> >>> # echo 0.903320312 > in_voltage0_scale    (enables the divider by two)
> >> 
> >> Ok, so I have to remember this value : '0.903320312' in case I want to
> >> enable divide-by-two functionality?
> > 
> > No you don't. That's why there is a 'in_voltage_scale_available' that
> > lists the available values.
> > 
> >> Hmmmm ... why would this interface not work:
> >> echo 2 > in_voltage0_scale
> >> 
> >> or
> >> 
> >> echo 1 > in_voltage0_scale
> > 
> > An easy thing like that is what I first submitted, but it was rejected
> > and I was told to use the scale_available descriptor instead, which is
> > the common interface the rest of drivers use.
> 
> This comes down to allowing us to have one generic predictable interface
> (which sometimes ends up looking uggly!).  The key thing is that if you
> are outputing using the _raw sysfs interfaces, the aim is to avoid doing
> nasty maths in kernel to get to 'standard' units such as mV.

OK, understood.

> Hence that scale attribute tells you what to apply to the value.  If you
> just wanted it to be 1 or 2 then the in_voltage0_raw value would have to
> be a long and nasty decimal.  Now we do have the option of
> in_voltage0_calibscale which would be applied internally to the value but
> it really isn't for this purpose (it's for devices with a 'trim' control)
> and you'd still have scale set to 0.903320312 or similar. Although they
> have meaning obviously, in this case 1 and 2 are little more than 'magic'
> numbers.
> 
> Note that when things are quite, I'm at least in theory working on a
> cleaner interface for these 'available' attributes that would also provide
> in kernel access for IIO consumers. Basically this will be another
> callback to get either the 'range' of pseudo continuous variables or the
> 'available' set for parameters like this.

Thanks for the explanation!

> Being lazy I'm happy to let someone else clean this corner up if they like?
> *looks hopeful*

Please don't look at me, I already am fully loaded with fixing my mess all 
around ;-/

Best regards,
Marek Vasut