lkml.org 
[lkml]   [2013]   [Jul]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH v2 5/5] iio: mxs-lradc: add write_raw function to modify scale
Date
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


\
 
 \ /
  Last update: 2013-07-20 21:41    [W:0.071 / U:0.264 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site