All of lore.kernel.org
 help / color / mirror / Atom feed
* 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.