Re: [RFC] IIO way of representing device operation range ?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, 16 Apr 2020 07:49:38 +0000
"Berghe, Darius" <Darius.Berghe@xxxxxxxxxx> wrote:

> Hi Jonathan,
> 
> Some devices (think DAC or ADC) have selectable contiguous operation
> ranges per channel, Rmin...Rmax, where Rmin and Rmax are the range
> minimum and maximum values expressed in physical units as in datasheet
> (mA, mV, etc).
> 
> Example DAC:
>         current0 0...50mA 0...100mA 
>         current1 0...200mA -60...200mA 0...100mA -60...100mA
> 
> physical [mV, mA, etc] = (raw + offset) * scale
> 
> One way of approaching this that I could find is let the user select
> offset and scale from a list of available offsets and scales. But due
> to the formula above, offset has higher priority in the computation and
> needs to be selected first. Once the user selects the offset, the list
> of scales may be recomputed by the driver. At this point the user may
> query available scales and select one.
> 
> Usage example, user wants to select -60...200mA:
> # cd /sys/bus/iio/devices/iio:device0 
> # cat out_current1_offset
> 0.0
> # cat out_current1_scale_available
> 0.003051757 0.001525878# cat out_current1_offset_available
> 0.0 -15123.0 -24576.0
> # echo -123456.0 > out_current1_offset
> # cat out_current1_scale_available
> 0,003967364
> # echo 0,003967364 > out_current1_scale
> 
> 
> All this is rather complicated for the user, being a two step
> procedure. Also, the user cannot pick a range in physical units as
> specified in the datasheet, but in a fractional (dimensionless) scale
> or a raw ADC/DAC register (dimensionless) offset.

> 
> Is there a direct way to select a contiguous operation range in
> physical units (as in datasheet) with the current state of the IIO ? I
> would like the user to only care about specifying Rmin and Rmax.

This is really a question to address in a userspace library, not
a the level of the kernel interfaces.  Whilst it may look lovely and
elegant to do it down in the kernel, having two interfaces to the same
basic controls is often a recipe for long term disaster.  It's fine
for userspace to iterate through all the options of each control and
build up a set of range pairs complete with how to get to them.  We could
simplify this by putting precedence into the ABI description. Right now
I'm fairly sure we don't say anything on that.

Now, the additional problem you have here is that may you have to transition
through non existent states which makes for a slightly odd userspace interface.
If you enable the channel when not in a valid state then that enable will
have to fail.

One reason we have never gone there for DACs in particular is that its
not unheard of for changing the range to result in burnt tracks.  Hence
this is normally considered a board configuration question and pushed
to devicetree or similar.  Devicetree should at least provide a list of
'safe' limits.

What is the requirement driving this flexibility?

Thanks,

Jonathan

> 
> Thanks,
> Darius Berghe





[Index of Archives]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Input]     [Linux Kernel]     [Linux SCSI]     [X.org]

  Powered by Linux