Hi David,
Thanks for taking a look at this :)
On 26/02/2025 02:26, David Lechner wrote:
On 2/24/25 12:33 PM, Matti Vaittinen wrote:
There are ADC ICs which may have some of the AIN pins usable for other
functions. These ICs may have some of the AIN pins wired so that they
should not be used for ADC.
(Preferred?) way for marking pins which can be used as ADC inputs is to
add corresponding channels@N nodes in the device tree as described in
the ADC binding yaml.
I think "preferred?" is the key question here. Currently, it is assumed
that basically all IIO bindings have channels implicitly even if the
binding doesn't call them out. It just means that there is nothing
special about the channel that needs to be documented, but the channel
is still there.
I think this works well with the ADCs which have no other purpose for
the pins but the ADC. The BD79124 (and some others) do allow muxing the
ADC input pins for other purposes. There the DT bindings with nothing
but the "reg" are relevant, and channels can't be trusted to just be
there without those..
Similarly, on several drivers we added recently that make use of adc.yaml
(adi,ad7380, adi,ad4695) we wrote the bindings with the intention that
if a channel was wired in the default configuration, then you would just
omit the channel node for that input pin. Therefore, this helper couldn't
be used by these drivers since we always have a fixed number of channels
used in the driver regardless of if there are explicit channel nodes in
the devicetree or not.
I think this works with the ICs where channels, indeed, always are
there. But this is not the case with _all_ ICs. And in order to keep the
consistency I'd actually required that if channels are listed in the DT,
then _all_ the channels must be listed. Else it becomes less
straightforward for people to understand how many channels there are
based on the device tree. I believe this was also proposed by Jonathan
during the v1 review:
> > Hmm. That'd mean the ADC channels _must_ be defined in DT in order
to be
> > usable(?) Well, if this is the usual way, then it should be well known
> > by users. Thanks.
>
> Yes. We basically have two types of binding wrt to channels.
> 1) Always there - no explicit binding, but also no way to describe
> anything specific about the channels.
> 2) Subnode per channel with stuff from adc.yaml and anything device
> specific. Only channels that that have a node are enabled.
>
> There are a few drivers that for historical reasons support both
> options with 'no channels' meaning 'all channels'.
https://lore.kernel.org/all/20250201162631.2eab9a9a@jic23-huawei/
In my experience, the only time we don't populate all available channels
on an ADC, even if not used, is in cases like differential chips where
any two inputs can be mixed and matched to form a channel. Some of these,
like adi,ad7173-8 would have 100s or 1000s of channels if we tried to
include all possible channels. In those cases, we make an exception and
use a dynamic number of channels based on the devicetree. But for chips
that have less than 20 total possible channels or so we've always
provided all possible channels to userspace. It makes writing userspace
software for a specific chip easier if we can always assume that chip
has the same number of channels.
In any exception to this rule of describing all channels in DT should
just avoid using these helpers and do things as they're done now. No one
is forced to use them. But I am not really sure why would you not
describe all the channels in the device-tree for ICs with less than 20
channels? I'd assume that if the channels are unconditionally usable in
the hardware, then they should be in DT as well(?)
Add couple of helper functions which can be used to retrieve the channel
information from the device node.
Signed-off-by: Matti Vaittinen <mazziesaccount@xxxxxxxxx>
Yours,
-- Matti
