Re: [PATCH 0/4] IIO wrapper drivers, dpot-dac and envelope-detector

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

 




On 20.10.2016 19:17, Peter Rosin wrote:
On 2016-10-20 19:37, Jonathan Cameron wrote:
On 20 October 2016 18:30:19 BST, Jonathan Cameron <jic23@xxxxxxxxxxxxxxxxxxxxx> wrote:
On 20 October 2016 13:55:12 BST, Lars-Peter Clausen <lars@xxxxxxxxxx> wrote:
On 10/20/2016 11:25 AM, Peter Rosin wrote:
Also, is there some agreed-upon way to dig out the maximum value from an iio channel? If so, "dpot-dac,max-ohms" can be eliminated from the
dt bindings, which would have been nice...

Yes, this is something we could really use. In a sense it exists for
the
devices with buffer-capable channels where there is the real_bits field which tells us the data width of the channel. But a dedicated mechanism
for
querying the maximum (and minimum) valid code seems like a useful
feature.
Not only for in-kernel clients, but also for userspace.

This was something that was addressed by the rather ancient patch
series i posted that added
an available call back which provided info on range and values for all
info mask elements.
Series got buried by there being a lot of precursors but quite a few of
those have merged since.

Hmm Google won't let me find it on my phone. Was a while back now. Will
try to get on pc with
decent email archive later and dig out a reference.
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.

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).

Jonathan

Cheers,
Peter

--
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
--
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



[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]
  Powered by Linux