* Reading ADC that comes from a multiplexer
@ 2021-09-22 2:18 Fabio Estevam
2021-09-22 7:27 ` Peter Rosin
0 siblings, 1 reply; 13+ messages in thread
From: Fabio Estevam @ 2021-09-22 2:18 UTC (permalink / raw)
To: Peter Rosin; +Cc: linux-iio
Hi Peter,
I have a SN74LV4051 multiplexer that is controlled by 3 GPIOs and I
described like this in DT:
adcmux: mux-controller {
compatible = "gpio-mux";
#mux-control-cells = <0>;
mux-gpios = <&gpio3 31 GPIO_ACTIVE_HIGH>,
<&gpio3 30 GPIO_ACTIVE_HIGH>,
<&gpio3 26 GPIO_ACTIVE_HIGH>;
};
adc-mux {
compatible = "io-channel-mux";
io-channels = <&adc 4>;
io-channel-names = "parent";
mux-controls = <&adcmux>;
channels = "chan0", "chan1", "chan2", "chan3",
"chan4", "chan5", "chan6", "chan7";
};
/sys/class/mux/muxchip0/ is created:
# ls /sys/class/mux/muxchip0/
device of_node power subsystem uevent
Sorry for the trivial question, but I haven't found any examples.
What is the userspace command if I want to expose "chan3" to be read
by the ADC 4 channel?
Thanks,
Fabio Estevam
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Reading ADC that comes from a multiplexer
2021-09-22 2:18 Reading ADC that comes from a multiplexer Fabio Estevam
@ 2021-09-22 7:27 ` Peter Rosin
2021-09-22 11:37 ` Fabio Estevam
0 siblings, 1 reply; 13+ messages in thread
From: Peter Rosin @ 2021-09-22 7:27 UTC (permalink / raw)
To: Fabio Estevam; +Cc: linux-iio
On 2021-09-22 04:18, Fabio Estevam wrote:
> Hi Peter,
>
> I have a SN74LV4051 multiplexer that is controlled by 3 GPIOs and I
> described like this in DT:
>
> adcmux: mux-controller {
> compatible = "gpio-mux";
> #mux-control-cells = <0>;
> mux-gpios = <&gpio3 31 GPIO_ACTIVE_HIGH>,
> <&gpio3 30 GPIO_ACTIVE_HIGH>,
> <&gpio3 26 GPIO_ACTIVE_HIGH>;
> };
>
> adc-mux {
> compatible = "io-channel-mux";
> io-channels = <&adc 4>;
> io-channel-names = "parent";
> mux-controls = <&adcmux>;
> channels = "chan0", "chan1", "chan2", "chan3",
> "chan4", "chan5", "chan6", "chan7";
> };
>
> /sys/class/mux/muxchip0/ is created:
>
> # ls /sys/class/mux/muxchip0/
> device of_node power subsystem uevent
>
> Sorry for the trivial question, but I haven't found any examples.
>
> What is the userspace command if I want to expose "chan3" to be read
> by the ADC 4 channel?
Basically, the whole point is that you simply don't. The iio-mux exposes
the channels as 8 new ADCs, and whenever you read a value from one of
them, the iio-mux operates the gpios for you, giving you the impression
that you have 8 independet ADCs. They are of course not independent, but...
Anyway, I have almost the exact same setup in
arch/arm/boot/dts/at91-tse850-3.dts
mux: mux-controller {
compatible = "gpio-mux";
#mux-control-cells = <0>;
mux-gpios = <&pioA 0 GPIO_ACTIVE_HIGH>,
<&pioA 1 GPIO_ACTIVE_HIGH>,
<&pioA 2 GPIO_ACTIVE_HIGH>;
idle-state = <0>;
};
envelope-detector-mux {
compatible = "io-channel-mux";
io-channels = <&env_det 0>;
io-channel-names = "parent";
mux-controls = <&mux>;
channels = "", "",
"sync-1",
"in",
"out",
"sync-2",
"sys-reg",
"ana-reg";
};
(but with the added complication that my ADC is not an ordinary ADC, but
instead a DAC and a comparator, such that the envelope of an AC signal can
be detected by a series of measurements, and I only use 6 channels)
That's exposed to user-space as:
$ ls "/sys/bus/iio/devices/iio:device3"
in_altvoltage2_compare_interval in_altvoltage5_scale
in_altvoltage2_invert in_altvoltage6_compare_interval
in_altvoltage2_raw in_altvoltage6_invert
in_altvoltage2_scale in_altvoltage6_raw
in_altvoltage3_compare_interval in_altvoltage6_scale
in_altvoltage3_invert in_altvoltage7_compare_interval
in_altvoltage3_raw in_altvoltage7_invert
in_altvoltage3_scale in_altvoltage7_raw
in_altvoltage4_compare_interval in_altvoltage7_scale
in_altvoltage4_invert name
in_altvoltage4_raw of_node
in_altvoltage4_scale power
in_altvoltage5_compare_interval subsystem
in_altvoltage5_invert uevent
in_altvoltage5_raw
$ cat "/sys/bus/iio/devices/iio:device3/name"
envelope-detector-mux
But the above gets tedious fast, and iio:device3 can of course be something
else etc etc, which is why libiio is the recommended interface.
ctx = iio_create_local_context();
dev = iio_context_find_device(ctx, "envelope-detector-mux");
chn = iio_device_find_channel(dev, "altvoltage2", 0);
iio_channel_attr_read_longlong(chn, "raw", &value);
Hope that helps!
Cheers,
Peter
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Reading ADC that comes from a multiplexer
2021-09-22 7:27 ` Peter Rosin
@ 2021-09-22 11:37 ` Fabio Estevam
2021-09-22 12:44 ` Fabio Estevam
2021-09-22 12:44 ` Peter Rosin
0 siblings, 2 replies; 13+ messages in thread
From: Fabio Estevam @ 2021-09-22 11:37 UTC (permalink / raw)
To: Peter Rosin; +Cc: linux-iio
Hi Peter,
On Wed, Sep 22, 2021 at 4:27 AM Peter Rosin <peda@axentia.se> wrote:
> Basically, the whole point is that you simply don't. The iio-mux exposes
> the channels as 8 new ADCs, and whenever you read a value from one of
> them, the iio-mux operates the gpios for you, giving you the impression
> that you have 8 independet ADCs. They are of course not independent, but...
Thanks for the clarification. It was helpful.
> That's exposed to user-space as:
>
> $ ls "/sys/bus/iio/devices/iio:device3"
> in_altvoltage2_compare_interval in_altvoltage5_scale
> in_altvoltage2_invert in_altvoltage6_compare_interval
> in_altvoltage2_raw in_altvoltage6_invert
> in_altvoltage2_scale in_altvoltage6_raw
> in_altvoltage3_compare_interval in_altvoltage6_scale
> in_altvoltage3_invert in_altvoltage7_compare_interval
> in_altvoltage3_raw in_altvoltage7_invert
> in_altvoltage3_scale in_altvoltage7_raw
> in_altvoltage4_compare_interval in_altvoltage7_scale
> in_altvoltage4_invert name
> in_altvoltage4_raw of_node
> in_altvoltage4_scale power
> in_altvoltage5_compare_interval subsystem
> in_altvoltage5_invert uevent
> in_altvoltage5_raw
> $ cat "/sys/bus/iio/devices/iio:device3/name"
> envelope-detector-mux
Ah, so that's my issue then. I don't see a new device inside
/sys/bus/iio/devices/.
I only see the original stmpe ADC:
ls "/sys/bus/iio/devices/iio:device0"
dev in_voltage5_raw in_voltage_scale power
in_temp8_input in_voltage6_raw name subsystem
in_voltage4_raw in_voltage7_raw of_node uevent
Maybe my dts is not correct to make the mux appear under
/sys/bus/iio/devices/iio:device1.
Here is my dts that shows more context with the STMPE811 ADC:
https://pastebin.com/raw/7Nn2aAtN
stmpe811 is an mfd device that can be used as a touchscreen and as a normal adc.
I only use the adc functionality.
Any suggestions are welcome.
Thanks,
Fabio Estevam
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Reading ADC that comes from a multiplexer
2021-09-22 11:37 ` Fabio Estevam
@ 2021-09-22 12:44 ` Fabio Estevam
2021-09-22 12:53 ` Peter Rosin
2021-09-22 12:44 ` Peter Rosin
1 sibling, 1 reply; 13+ messages in thread
From: Fabio Estevam @ 2021-09-22 12:44 UTC (permalink / raw)
To: Peter Rosin; +Cc: linux-iio
On Wed, Sep 22, 2021 at 8:37 AM Fabio Estevam <festevam@gmail.com> wrote:
>
> Hi Peter,
>
> On Wed, Sep 22, 2021 at 4:27 AM Peter Rosin <peda@axentia.se> wrote:
>
> > Basically, the whole point is that you simply don't. The iio-mux exposes
> > the channels as 8 new ADCs, and whenever you read a value from one of
> > them, the iio-mux operates the gpios for you, giving you the impression
> > that you have 8 independet ADCs. They are of course not independent, but...
>
> Thanks for the clarification. It was helpful.
>
> > That's exposed to user-space as:
> >
> > $ ls "/sys/bus/iio/devices/iio:device3"
> > in_altvoltage2_compare_interval in_altvoltage5_scale
> > in_altvoltage2_invert in_altvoltage6_compare_interval
> > in_altvoltage2_raw in_altvoltage6_invert
> > in_altvoltage2_scale in_altvoltage6_raw
> > in_altvoltage3_compare_interval in_altvoltage6_scale
> > in_altvoltage3_invert in_altvoltage7_compare_interval
> > in_altvoltage3_raw in_altvoltage7_invert
> > in_altvoltage3_scale in_altvoltage7_raw
> > in_altvoltage4_compare_interval in_altvoltage7_scale
> > in_altvoltage4_invert name
> > in_altvoltage4_raw of_node
> > in_altvoltage4_scale power
> > in_altvoltage5_compare_interval subsystem
> > in_altvoltage5_invert uevent
> > in_altvoltage5_raw
> > $ cat "/sys/bus/iio/devices/iio:device3/name"
> > envelope-detector-mux
>
> Ah, so that's my issue then. I don't see a new device inside
> /sys/bus/iio/devices/.
>
> I only see the original stmpe ADC:
>
> ls "/sys/bus/iio/devices/iio:device0"
> dev in_voltage5_raw in_voltage_scale power
> in_temp8_input in_voltage6_raw name subsystem
> in_voltage4_raw in_voltage7_raw of_node uevent
>
> Maybe my dts is not correct to make the mux appear under
> /sys/bus/iio/devices/iio:device1.
Just realized that iio-mux.c does not get probed.
In mux_probe():
parent = devm_iio_channel_get(dev, "parent");
is always returning -EPROBE_DEFER, even though I passed:
io-channel-names = "parent";
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Reading ADC that comes from a multiplexer
2021-09-22 11:37 ` Fabio Estevam
2021-09-22 12:44 ` Fabio Estevam
@ 2021-09-22 12:44 ` Peter Rosin
1 sibling, 0 replies; 13+ messages in thread
From: Peter Rosin @ 2021-09-22 12:44 UTC (permalink / raw)
To: Fabio Estevam; +Cc: linux-iio
On 2021-09-22 13:37, Fabio Estevam wrote:
> Hi Peter,
>
> On Wed, Sep 22, 2021 at 4:27 AM Peter Rosin <peda@axentia.se> wrote:
>
>> Basically, the whole point is that you simply don't. The iio-mux exposes
>> the channels as 8 new ADCs, and whenever you read a value from one of
>> them, the iio-mux operates the gpios for you, giving you the impression
>> that you have 8 independet ADCs. They are of course not independent, but...
>
> Thanks for the clarification. It was helpful.
>
>> That's exposed to user-space as:
>>
>> $ ls "/sys/bus/iio/devices/iio:device3"
>> in_altvoltage2_compare_interval in_altvoltage5_scale
>> in_altvoltage2_invert in_altvoltage6_compare_interval
>> in_altvoltage2_raw in_altvoltage6_invert
>> in_altvoltage2_scale in_altvoltage6_raw
>> in_altvoltage3_compare_interval in_altvoltage6_scale
>> in_altvoltage3_invert in_altvoltage7_compare_interval
>> in_altvoltage3_raw in_altvoltage7_invert
>> in_altvoltage3_scale in_altvoltage7_raw
>> in_altvoltage4_compare_interval in_altvoltage7_scale
>> in_altvoltage4_invert name
>> in_altvoltage4_raw of_node
>> in_altvoltage4_scale power
>> in_altvoltage5_compare_interval subsystem
>> in_altvoltage5_invert uevent
>> in_altvoltage5_raw
>> $ cat "/sys/bus/iio/devices/iio:device3/name"
>> envelope-detector-mux
>
> Ah, so that's my issue then. I don't see a new device inside
> /sys/bus/iio/devices/.
>
> I only see the original stmpe ADC:
>
> ls "/sys/bus/iio/devices/iio:device0"
> dev in_voltage5_raw in_voltage_scale power
> in_temp8_input in_voltage6_raw name subsystem
> in_voltage4_raw in_voltage7_raw of_node uevent
>
> Maybe my dts is not correct to make the mux appear under
> /sys/bus/iio/devices/iio:device1.
>
> Here is my dts that shows more context with the STMPE811 ADC:
> https://pastebin.com/raw/7Nn2aAtN
>
> stmpe811 is an mfd device that can be used as a touchscreen and as a normal adc.
>
> I only use the adc functionality.
>
> Any suggestions are welcome.
Don't you get any output from the iio-mux driver during probe? I'd expect
a "failed to get parent channel" or something like that?
I don't know, but looking around a bit makes me think you should
investigate /arch/arm/boot/dts/am5729-beagleboneai.dts and/or
/arch/arm/boot/dts/exynos4412-p4note.dtsi.
I think you need to move the adc: label in the dts to the stmpe_adc child
node, or something like that?
Cheers,
Peter
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Reading ADC that comes from a multiplexer
2021-09-22 12:44 ` Fabio Estevam
@ 2021-09-22 12:53 ` Peter Rosin
2021-09-22 13:41 ` Fabio Estevam
0 siblings, 1 reply; 13+ messages in thread
From: Peter Rosin @ 2021-09-22 12:53 UTC (permalink / raw)
To: Fabio Estevam; +Cc: linux-iio
On 2021-09-22 14:44, Fabio Estevam wrote:
> Just realized that iio-mux.c does not get probed.
>
> In mux_probe():
>
> parent = devm_iio_channel_get(dev, "parent");
>
> is always returning -EPROBE_DEFER, even though I passed:
>
> io-channel-names = "parent";
>
I think that's because the "parent" channel (i.e. <&adc 4> in your case)
is referring to a node that is not providing any iio channels at all.
Just because you added "#io-channel-cells = <1>;" to that node, does not
make it so. The driver has to support it as well.
Cheers,
Peter
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Reading ADC that comes from a multiplexer
2021-09-22 12:53 ` Peter Rosin
@ 2021-09-22 13:41 ` Fabio Estevam
2021-09-22 14:20 ` Fabio Estevam
0 siblings, 1 reply; 13+ messages in thread
From: Fabio Estevam @ 2021-09-22 13:41 UTC (permalink / raw)
To: Peter Rosin; +Cc: linux-iio
Hi Peter,
On Wed, Sep 22, 2021 at 9:53 AM Peter Rosin <peda@axentia.se> wrote:
> I think that's because the "parent" channel (i.e. <&adc 4> in your case)
> is referring to a node that is not providing any iio channels at all.
>
> Just because you added "#io-channel-cells = <1>;" to that node, does not
> make it so. The driver has to support it as well.
I tried to use the same approach as in arch/arm/boot/dts/am5729-beagleboneai.dts
as per your suggestion:
--- a/arch/arm/boot/dts/imx6qdl-apalis.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-apalis.dtsi
@@ -139,6 +139,23 @@
spdif-out;
status = "disabled";
};
+
+ adcmux: mux-controller {
+ compatible = "gpio-mux";
+ #mux-control-cells = <0>;
+ mux-gpios = <&gpio3 31 GPIO_ACTIVE_HIGH>,
+ <&gpio3 30 GPIO_ACTIVE_HIGH>,
+ <&gpio3 26 GPIO_ACTIVE_HIGH>;
+ };
+
+ adc-mux {
+ compatible = "io-channel-mux";
+ io-channels = <&adc0 4>;
+ io-channel-names = "parent";
+ mux-controls = <&adcmux>;
+ channels = "chan0", "chan1", "chan2", "chan3",
+ "chan4", "chan5", "chan6", "chan7";
+ };
};
&audmux {
@@ -362,6 +379,11 @@
compatible = "st,stmpe-adc";
/* forbid to use ADC channels 3-0 (touch) */
st,norequest-mask = <0x0F>;
+ adc0: iio-device {
+ #io-channel-cells = <1>;
+ iio-channels = <&adc0 4>, <&adc0 5>,
<&adc0 6>, <&adc0 7>;
+ iio-channel-names = "adc4", "adc5",
"adc6", "adc7";
+ };
};
};
};
but still the parent channel cannot be found.
So I don't have the DT properly describing the ADC to the mux relationship yet.
Thanks for your patience,
Fabio Estevam
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Reading ADC that comes from a multiplexer
2021-09-22 13:41 ` Fabio Estevam
@ 2021-09-22 14:20 ` Fabio Estevam
2021-09-22 14:28 ` Peter Rosin
0 siblings, 1 reply; 13+ messages in thread
From: Fabio Estevam @ 2021-09-22 14:20 UTC (permalink / raw)
To: Peter Rosin; +Cc: linux-iio
Hi Peter,
On Wed, Sep 22, 2021 at 10:41 AM Fabio Estevam <festevam@gmail.com> wrote:
> but still the parent channel cannot be found.
>
> So I don't have the DT properly describing the ADC to the mux relationship yet.
It works fine now :-)
The trick was to change it like this:
- stmpe_adc {
+ adc0: stmpe_adc {
compatible = "st,stmpe-adc";
/* forbid to use ADC channels 3-0 (touch) */
st,norequest-mask = <0x0F>;
+ #io-channel-cells = <1>;
};
};
Thanks a lot!
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Reading ADC that comes from a multiplexer
2021-09-22 14:20 ` Fabio Estevam
@ 2021-09-22 14:28 ` Peter Rosin
2021-09-22 14:50 ` Fabio Estevam
0 siblings, 1 reply; 13+ messages in thread
From: Peter Rosin @ 2021-09-22 14:28 UTC (permalink / raw)
To: Fabio Estevam; +Cc: linux-iio
On 2021-09-22 16:20, Fabio Estevam wrote:
> Hi Peter,
>
> On Wed, Sep 22, 2021 at 10:41 AM Fabio Estevam <festevam@gmail.com> wrote:
>
>> but still the parent channel cannot be found.
>>
>> So I don't have the DT properly describing the ADC to the mux relationship yet.
>
> It works fine now :-)
>
> The trick was to change it like this:
>
> - stmpe_adc {
> + adc0: stmpe_adc {
> compatible = "st,stmpe-adc";
> /* forbid to use ADC channels 3-0 (touch) */
> st,norequest-mask = <0x0F>;
> + #io-channel-cells = <1>;
> };
> };
>
> Thanks a lot!
>
Nice!
While I don't completely understand that iio-device node in the beaglebone
dts that didn't work for you, it looks like it's just a renumbering thing?
However, your version only remapped 4 channels, and in that case your new
iio-device only had those, i.e. 0-3. But the iio-mux was looking for the
missing channel 4. Maybe that was why that variant didn't work?
So, yeah, copying the exynos4412-p4note was simpler.
Cheers,
Peter
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Reading ADC that comes from a multiplexer
2021-09-22 14:28 ` Peter Rosin
@ 2021-09-22 14:50 ` Fabio Estevam
2021-09-23 10:28 ` Jonathan Cameron
0 siblings, 1 reply; 13+ messages in thread
From: Fabio Estevam @ 2021-09-22 14:50 UTC (permalink / raw)
To: Peter Rosin; +Cc: linux-iio
Hi Peter,
On Wed, Sep 22, 2021 at 11:28 AM Peter Rosin <peda@axentia.se> wrote:
> Nice!
>
> While I don't completely understand that iio-device node in the beaglebone
> dts that didn't work for you, it looks like it's just a renumbering thing?
The beaglebone dts uses some undocumented properties such as:
iio-channels and iio-channel-names.
> However, your version only remapped 4 channels, and in that case your new
> iio-device only had those, i.e. 0-3. But the iio-mux was looking for the
> missing channel 4. Maybe that was why that variant didn't work?
Yes, this is where I got confused.
The stmpe811 has 8 channels. On the apalis board, the first four channels
(0 to 3) are used for touchscreen. The other 4 channels are for general purpose.
The ADC that is connected to the MUX is channel 4 (which is the first
one that is
free for general usage), so I had to pass:
io-channels = <&adc0 0>;
in the mux, instead of io-channels = <&adc0 4> that I was originally trying.
and now the mapping is correct and I can read proper voltages when I
switch the mux.
Thanks!
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Reading ADC that comes from a multiplexer
2021-09-22 14:50 ` Fabio Estevam
@ 2021-09-23 10:28 ` Jonathan Cameron
2021-09-24 14:41 ` Fabio Estevam
0 siblings, 1 reply; 13+ messages in thread
From: Jonathan Cameron @ 2021-09-23 10:28 UTC (permalink / raw)
To: Fabio Estevam; +Cc: Peter Rosin, linux-iio
On Wed, 22 Sep 2021 11:50:14 -0300
Fabio Estevam <festevam@gmail.com> wrote:
> Hi Peter,
>
> On Wed, Sep 22, 2021 at 11:28 AM Peter Rosin <peda@axentia.se> wrote:
>
> > Nice!
> >
> > While I don't completely understand that iio-device node in the beaglebone
> > dts that didn't work for you, it looks like it's just a renumbering thing?
>
> The beaglebone dts uses some undocumented properties such as:
> iio-channels and iio-channel-names.
Some of this comes from the dts-schema repo. We haven't been strict in
adding the entries to individual ADCs until they actually use them - which
has the advantage it gives us a window to think about the of_xlate (see below)
https://github.com/devicetree-org/dt-schema/blob/main/meta-schemas/iio.yaml
Not that it helps much as little in the way of docs in the dt-schema repo.
>
> > However, your version only remapped 4 channels, and in that case your new
> > iio-device only had those, i.e. 0-3. But the iio-mux was looking for the
> > missing channel 4. Maybe that was why that variant didn't work?
>
> Yes, this is where I got confused.
>
> The stmpe811 has 8 channels. On the apalis board, the first four channels
> (0 to 3) are used for touchscreen. The other 4 channels are for general purpose.
>
> The ADC that is connected to the MUX is channel 4 (which is the first
> one that is
> free for general usage), so I had to pass:
>
> io-channels = <&adc0 0>;
>
> in the mux, instead of io-channels = <&adc0 4> that I was originally trying.
>
> and now the mapping is correct and I can read proper voltages when I
> switch the mux.
It's possible to add a translation routine to a given driver to deal with this
sort of case. I guess no one needed on the that driver before + all this
infrastructure post dates that driver.
See the of_xlate callbacks that let you map more obvious numbering to a particular
channel.
We are in an unfortunate mess here, but I'd argue the lack of io-channels entry
in the dt binding should in theory mean no one is using this property (as they
should be verifying against that). The problem will occur if we have a pre
yaml conversion binding out in the wild with a mux or other consumer. We could
cross our fingers and fix this now...
Jonathan
>
> Thanks!
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Reading ADC that comes from a multiplexer
2021-09-23 10:28 ` Jonathan Cameron
@ 2021-09-24 14:41 ` Fabio Estevam
2021-09-25 14:32 ` Jonathan Cameron
0 siblings, 1 reply; 13+ messages in thread
From: Fabio Estevam @ 2021-09-24 14:41 UTC (permalink / raw)
To: Jonathan Cameron; +Cc: Peter Rosin, linux-iio
Hi Jonathan,
On Thu, Sep 23, 2021 at 7:29 AM Jonathan Cameron
<Jonathan.Cameron@huawei.com> wrote:
> > The beaglebone dts uses some undocumented properties such as:
> > iio-channels and iio-channel-names.
>
> Some of this comes from the dts-schema repo. We haven't been strict in
> adding the entries to individual ADCs until they actually use them - which
> has the advantage it gives us a window to think about the of_xlate (see below)
>
> https://github.com/devicetree-org/dt-schema/blob/main/meta-schemas/iio.yaml
On this document, we have "io-channels" and "io-channel-names.
What I wanted to say is that in
arch/arm/boot/dts/am5729-beagleboneai.dts we have:
"iio-channels" and "iio-channel-names" (Note the 'iio' versus 'io').
This is what I mentioned as undocumented properties.
Maybe I can send a patch fixing it.
On my imx6 board all is working fine now.
Thanks,
Fabio Estevam
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Reading ADC that comes from a multiplexer
2021-09-24 14:41 ` Fabio Estevam
@ 2021-09-25 14:32 ` Jonathan Cameron
0 siblings, 0 replies; 13+ messages in thread
From: Jonathan Cameron @ 2021-09-25 14:32 UTC (permalink / raw)
To: Fabio Estevam; +Cc: Jonathan Cameron, Peter Rosin, linux-iio
On Fri, 24 Sep 2021 11:41:38 -0300
Fabio Estevam <festevam@gmail.com> wrote:
> Hi Jonathan,
>
> On Thu, Sep 23, 2021 at 7:29 AM Jonathan Cameron
> <Jonathan.Cameron@huawei.com> wrote:
>
> > > The beaglebone dts uses some undocumented properties such as:
> > > iio-channels and iio-channel-names.
> >
> > Some of this comes from the dts-schema repo. We haven't been strict in
> > adding the entries to individual ADCs until they actually use them - which
> > has the advantage it gives us a window to think about the of_xlate (see below)
> >
> > https://github.com/devicetree-org/dt-schema/blob/main/meta-schemas/iio.yaml
>
> On this document, we have "io-channels" and "io-channel-names.
>
> What I wanted to say is that in
> arch/arm/boot/dts/am5729-beagleboneai.dts we have:
>
> "iio-channels" and "iio-channel-names" (Note the 'iio' versus 'io').
>
> This is what I mentioned as undocumented properties.
>
> Maybe I can send a patch fixing it.
Ah! Got you. That definitely seems wrong so a fix would be welcome.
Thanks,
Jonathan
>
> On my imx6 board all is working fine now.
>
> Thanks,
>
> Fabio Estevam
^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2021-09-25 14:29 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-09-22 2:18 Reading ADC that comes from a multiplexer Fabio Estevam
2021-09-22 7:27 ` Peter Rosin
2021-09-22 11:37 ` Fabio Estevam
2021-09-22 12:44 ` Fabio Estevam
2021-09-22 12:53 ` Peter Rosin
2021-09-22 13:41 ` Fabio Estevam
2021-09-22 14:20 ` Fabio Estevam
2021-09-22 14:28 ` Peter Rosin
2021-09-22 14:50 ` Fabio Estevam
2021-09-23 10:28 ` Jonathan Cameron
2021-09-24 14:41 ` Fabio Estevam
2021-09-25 14:32 ` Jonathan Cameron
2021-09-22 12:44 ` Peter Rosin
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.