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