On 5/16/21 11:14 AM, Liam Beguin wrote:
On Sun May 16, 2021 at 12:26 PM EDT, Jonathan Cameron wrote:
On Sun, 16 May 2021 08:54:06 -0700
Guenter Roeck <linux@xxxxxxxxxxxx> wrote:
On 5/16/21 8:02 AM, Liam Beguin wrote:
Hi Jonathan,
On Sun May 16, 2021 at 5:06 AM EDT, Jonathan Cameron wrote:
On Sun, 16 May 2021 00:43:13 -0400
Liam Beguin <liambeguin@xxxxxxxxx> wrote:
Add a devicetree binding to optionally force a different IIO channel
type.
This is useful in cases where ADC channels are connected to a circuit
that represent another unit such as a temperature or a current.
`channel-types` was chosen instead of `io-channel-types` as this is not
part of the iio consumer bindings.
In the current form, this patch does what it's intended to do:
change the unit displayed by `sensors`, but feels like the wrong way to
address the problem.
Would it be possible to force the type of different IIO channels for
this kind of use case with a devicetree binding from the IIO subsystem?
It would be convenient to do it within the IIO subsystem to have the
right unit there too.
Thanks for your time,
Liam
Hi Liam,
+CC Peter for AFE part.
It's an interesting approach, but I would suggest we think about this
a different way.
Whenever a channel is being used to measure something 'different' from
what it actually measures (e.g. a voltage ADC measuring a current) that
reflects their being some analog component involved.
If you look at drivers/iio/afe/iio-rescale.c you can see the approach
we currently use to handle this.
Many thanks for pointing out the AFE code. That look like what I was
hoping to accomplish, but in a much better way.
Effectively what you add to devicetree is a consumer of the ADC channel
which in turn provides services to other devices. For this current case
it would be either a current-sense-amplifier or a current-sense-shunt
depending on what the analog front end looks like. We have to describe
the characteristics of that front end which isn't something that can
be done via a simple channel type.
Understood. My original intention was to use sensors.conf to do the
conversions and take into accounts those parameters.
That afe consumer device can then provide services to another consumer
(e.g. iio-hwmon) which work for your usecase.
The main limitation of this approach currently is you end up with
one device per channel. That could be improved upon if you have a
usecase
where it matters.
I don't think we currently have an equivalent for temperature sensing
but it would be easy enough to do something similar.
Wonderful, thanks again for pointing out the AFE!
Please don't reinvent the ntc_thermistor driver.
Agreed, I'd forgotten it existed :( Had a feeling we'd solved that
problem before
but couldn't remember the name of the driver.
The afe driver already deals with current / voltage scaling and
conversion
for common analog circuits. Potential dividers, current shunts etc, but
they
are all the linear cases IIRC.
ntc_thermistor deals with the much more complex job of dealing with a
thermistor.
I agree, no need to reinvent this.
Like Jonathan said, the ntc_thermistor driver seems to handle much more
complex cases. Where would be the best place to add support for PT100
and PT1000? iio-rescale?
Those sensors don't seem to be even useful for hardware monitoring, so
if they are linear (and it looks like that that the case) iio would be
a better place.
Guenter
