[RFC PATCH 0/7] iio: add iio backend device type

[RFC PATCH 0/7] iio: add iio backend device type

[Olivier Moysan]

This RFC re-opens an old discussion regarding channel scaling
management in STM32 DFSDM driver [1]

The DFSDM is a peripheral provided by the STM32MP1x SoC family.
One objective is also to prepare the introduction of its successor in
the STM32MP12x SoC family: the MDF (Multi-function Digital Filter).
The MDF driver will have the same requirements as the DFSDM regarding
channel scaling management. So, the solution proposed here will apply
also for the future MDF driver.

[1]
https://patchwork.kernel.org/project/linux-iio/patch/20200204101008.11411-5-olivier.moysan@st.com/

As a short reminder of our previous discussion, the two main options
emerging were the following ones:

- Option1: Use the DFSDM as an hardware accelerator and expose the
scaled channels on SD modulator side.
Drawbak: this solution is leading to an very complex datapath, especially
for scan mode.

- Option2: Introduce a new IIO device type (so-called backend)
Retrieve scaling information from SD modulator scaling to expose a single
IIO device on DFSDM side. This solution is derivated from rcar-gyroadc
example, but with a more standard approach.
This was discussed in 
https://lore.kernel.org/lkml/20210919191414.09270f4e@jic23-huawei/

The patchset proposed in this RFC implements option2 (backend) solution.
These patches provide a minimal API implemented as a template.
The intented use of this API is illustrated through the DFSDM channel
scaling support basic implementation.

For sake of simplicity I did not include the related DT binding
in this serie. 

Below are some use case examples.

* DFSDM with SD modulator backend:
  -------------------------------
This use case corresponds to the example implemented in this RFC.
The channel attributes are retrieved from backend by the dfsdm, and
the resulting scaling is exposed through DFSDM IIO device sysfs

- Single channel:
+-------------+  ch attr   +--------+  sysfs (compound scaling)
| sd0 backend | ---------> | dfsdm0 | -------------------------->
+-------------+            +--------+

- Scan mode:
+-------------+  ch attr   +-------------+  sysfs (compound scaling)
| sd1 backend | ---------> |   dfsdm1    | -------------------------->
+-------------+            +-------------+
                             ^
                             |
+-------------+  ch attr     |
| sd2 backend |--------------+
+-------------+


* Voltage divider in front of an adc:
  ----------------------------------
By way of example, here is a comparison on scaling management with
a iio-rescale device, and how it could be managed with a backend device.

- iio-rescale implementation
Scaling is exposed both on ADC and iio-rescale IIO devices.
On iio-rescale device we get the compound scaling

+---------------------------+  ch attr   +------+  sysfs
|     iio-rescale (div)     | <--------- | adc0 | ------->
+---------------------------+            +------+
  |
  | sysfs (compound scaling)
  v

- Backend implementation:
Compound scaling is exposed on ADC IIO device.
No scaling exposed on backend device

+---------------+  ch attr   +------+  sysfs (compound scaling)
| backend (div) | ---------> | adc0 | -------------------------->
+---------------+            +------+


* Cascaded backends:
  -----------------
Backends may be cascaded to allow computation of the whole chain scaling
This is not part of this RFC, but it is identified as a potential
future use case.

+---------------+  attr   +-------------+  attr   +--------+  sysfs
| backend (div) | ------> | sd0 backend | ------> | dfsdm0 | ------->
+---------------+         +-------------+         +--------+

Olivier Moysan (7):
  iio: introduce iio backend device
  of: property: add device link support for io-backends
  iio: adc: stm32-dfsdm: manage dfsdm as a channel provider
  iio: adc: stm32-dfsdm: adopt generic channel bindings
  iio: adc: sd_adc_modulator: change to iio backend device
  iio: adc: stm32-dfsdm: add scaling support to dfsdm
  ARM: dts: stm32: add dfsdm iio suppport

 arch/arm/boot/dts/stm32mp157c-ev1.dts |  62 +++++++++
 drivers/iio/Makefile                  |   2 +
 drivers/iio/adc/sd_adc_modulator.c    |  92 +++++++++++---
 drivers/iio/adc/stm32-dfsdm-adc.c     | 176 ++++++++++++++++----------
 drivers/iio/industrialio-backend.c    |  59 +++++++++
 drivers/of/property.c                 |   2 +
 include/linux/iio/backend.h           |  29 +++++
 7 files changed, 336 insertions(+), 86 deletions(-)
 create mode 100644 drivers/iio/industrialio-backend.c
 create mode 100644 include/linux/iio/backend.h

-- 
2.25.1

[RFC PATCH 2/7] of: property: add device link support for io-backends

[Olivier Moysan]

Add support for creating device links out of more DT properties.

Signed-off-by: Olivier Moysan <olivier.moysan@foss.st.com>
---
 drivers/of/property.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/of/property.c b/drivers/of/property.c
index ddc75cd50825..864e29e4707c 100644
--- a/drivers/of/property.c
+++ b/drivers/of/property.c
@@ -1244,6 +1244,7 @@ DEFINE_SIMPLE_PROP(interconnects, "interconnects", "#interconnect-cells")
 DEFINE_SIMPLE_PROP(iommus, "iommus", "#iommu-cells")
 DEFINE_SIMPLE_PROP(mboxes, "mboxes", "#mbox-cells")
 DEFINE_SIMPLE_PROP(io_channels, "io-channel", "#io-channel-cells")
+DEFINE_SIMPLE_PROP(io_backends, "io-backend", "#io-backend-cells")
 DEFINE_SIMPLE_PROP(interrupt_parent, "interrupt-parent", NULL)
 DEFINE_SIMPLE_PROP(dmas, "dmas", "#dma-cells")
 DEFINE_SIMPLE_PROP(power_domains, "power-domains", "#power-domain-cells")
@@ -1332,6 +1333,7 @@ static const struct supplier_bindings of_supplier_bindings[] = {
 	{ .parse_prop = parse_iommu_maps, .optional = true, },
 	{ .parse_prop = parse_mboxes, },
 	{ .parse_prop = parse_io_channels, },
+	{ .parse_prop = parse_io_backends, },
 	{ .parse_prop = parse_interrupt_parent, },
 	{ .parse_prop = parse_dmas, .optional = true, },
 	{ .parse_prop = parse_power_domains, },
-- 
2.25.1

[RFC PATCH 7/7] ARM: dts: stm32: add dfsdm iio suppport

[Olivier Moysan]

This DT is an example of backend iio device use for STM32 DFSDM.
DFSDM filter0 has a single input channel, while filter1 is configured
for scan mode with two input channels.

Signed-off-by: Olivier Moysan <olivier.moysan@foss.st.com>
---
 arch/arm/boot/dts/stm32mp157c-ev1.dts | 62 +++++++++++++++++++++++++++
 1 file changed, 62 insertions(+)

diff --git a/arch/arm/boot/dts/stm32mp157c-ev1.dts b/arch/arm/boot/dts/stm32mp157c-ev1.dts
index ba8e9d9a42fa..ebd67a219df2 100644
--- a/arch/arm/boot/dts/stm32mp157c-ev1.dts
+++ b/arch/arm/boot/dts/stm32mp157c-ev1.dts
@@ -73,6 +73,24 @@ panel_backlight: panel-backlight {
 		default-on;
 		status = "okay";
 	};
+
+	sd_adc0: simple-sd-adc0 {
+		compatible = "sd-modulator";
+		io-backend-cells = <0>;
+		vref-supply = <&v3v3>;
+	};
+
+	sd_adc1: simple-sd-adc1 {
+		compatible = "sd-modulator";
+		io-backend-cells = <0>;
+		vref-supply = <&v3v3>;
+	};
+
+	sd_adc2: simple-sd-adc2 {
+		compatible = "sd-modulator";
+		io-backend-cells = <0>;
+		vref-supply = <&v3v3>;
+	};
 };
 
 &cec {
@@ -99,6 +117,50 @@ dcmi_0: endpoint {
 	};
 };
 
+&dfsdm {
+	spi-max-frequency = <2048000>;
+
+	clocks = <&rcc DFSDM_K>, <&rcc ADFSDM_K>;
+	clock-names = "dfsdm", "audio";
+	status = "disabled";
+
+	dfsdm0: filter@0 {
+		compatible = "st,stm32-dfsdm-adc";
+		st,filter-order = <3>;
+		status = "okay";
+
+		channel@1 {
+			reg = <1>;
+			label = "in1";
+			st,adc-channel-types = "SPI_R";
+			st,adc-channel-clk-src = "CLKOUT";
+			io-backend = <&sd_adc0>;
+		};
+	};
+
+	dfsdm1: filter@1 {
+		compatible = "st,stm32-dfsdm-adc";
+		st,filter-order = <3>;
+		status = "okay";
+
+		channel@2 {
+			reg = <2>;
+			label = "in2";
+			st,adc-channel-types = "SPI_R";
+			st,adc-channel-clk-src = "CLKOUT";
+			io-backend = <&sd_adc1>;
+		};
+
+		channel@3 {
+			reg = <3>;
+			label = "in3";
+			st,adc-channel-types = "SPI_F";
+			st,adc-channel-clk-src = "CLKOUT";
+			io-backend = <&sd_adc2>;
+		};
+	};
+};
+
 &dsi {
 	phy-dsi-supply = <&reg18>;
 	status = "okay";
-- 
2.25.1

Re: [RFC PATCH 0/7] iio: add iio backend device type

[Jonathan Cameron]

On Fri, 23 Jun 2023 16:09:36 +0200
Olivier Moysan <olivier.moysan@foss.st.com> wrote:

> This RFC re-opens an old discussion regarding channel scaling
> management in STM32 DFSDM driver [1]
> 
> The DFSDM is a peripheral provided by the STM32MP1x SoC family.
> One objective is also to prepare the introduction of its successor in
> the STM32MP12x SoC family: the MDF (Multi-function Digital Filter).
> The MDF driver will have the same requirements as the DFSDM regarding
> channel scaling management. So, the solution proposed here will apply
> also for the future MDF driver.
> 
> [1]
> https://patchwork.kernel.org/project/linux-iio/patch/20200204101008.11411-5-olivier.moysan@st.com/
> 
> As a short reminder of our previous discussion, the two main options
> emerging were the following ones:
> 
> - Option1: Use the DFSDM as an hardware accelerator and expose the
> scaled channels on SD modulator side.
> Drawbak: this solution is leading to an very complex datapath, especially
> for scan mode.
> 
> - Option2: Introduce a new IIO device type (so-called backend)
> Retrieve scaling information from SD modulator scaling to expose a single
> IIO device on DFSDM side. This solution is derivated from rcar-gyroadc
> example, but with a more standard approach.
> This was discussed in 
> https://lore.kernel.org/lkml/20210919191414.09270f4e@jic23-huawei/

Naming probably needs a rethink given the actual hardware we are talking about
here is normally called a frontend and so people will be confused...

I'm traveling at the moment, so only going to take a fairly superficial first
look at what you have here.

Jonathan

> 
> The patchset proposed in this RFC implements option2 (backend) solution.
> These patches provide a minimal API implemented as a template.
> The intented use of this API is illustrated through the DFSDM channel
> scaling support basic implementation.
> 
> For sake of simplicity I did not include the related DT binding
> in this serie. 
> 
> Below are some use case examples.
> 
> * DFSDM with SD modulator backend:
>   -------------------------------
> This use case corresponds to the example implemented in this RFC.
> The channel attributes are retrieved from backend by the dfsdm, and
> the resulting scaling is exposed through DFSDM IIO device sysfs
> 
> - Single channel:
> +-------------+  ch attr   +--------+  sysfs (compound scaling)
> | sd0 backend | ---------> | dfsdm0 | -------------------------->
> +-------------+            +--------+
> 
> - Scan mode:
> +-------------+  ch attr   +-------------+  sysfs (compound scaling)
> | sd1 backend | ---------> |   dfsdm1    | -------------------------->
> +-------------+            +-------------+
>                              ^
>                              |
> +-------------+  ch attr     |
> | sd2 backend |--------------+
> +-------------+
> 
> 
> * Voltage divider in front of an adc:
>   ----------------------------------
> By way of example, here is a comparison on scaling management with
> a iio-rescale device, and how it could be managed with a backend device.
> 
> - iio-rescale implementation
> Scaling is exposed both on ADC and iio-rescale IIO devices.
> On iio-rescale device we get the compound scaling
> 
> +---------------------------+  ch attr   +------+  sysfs
> |     iio-rescale (div)     | <--------- | adc0 | ------->
> +---------------------------+            +------+
>   |
>   | sysfs (compound scaling)
>   v
> 
> - Backend implementation:
> Compound scaling is exposed on ADC IIO device.
> No scaling exposed on backend device
> 
> +---------------+  ch attr   +------+  sysfs (compound scaling)
> | backend (div) | ---------> | adc0 | -------------------------->
> +---------------+            +------+
> 
> 
> * Cascaded backends:
>   -----------------
> Backends may be cascaded to allow computation of the whole chain scaling
> This is not part of this RFC, but it is identified as a potential
> future use case.
> 
> +---------------+  attr   +-------------+  attr   +--------+  sysfs
> | backend (div) | ------> | sd0 backend | ------> | dfsdm0 | ------->
> +---------------+         +-------------+         +--------+
> 
> Olivier Moysan (7):
>   iio: introduce iio backend device
>   of: property: add device link support for io-backends
>   iio: adc: stm32-dfsdm: manage dfsdm as a channel provider
>   iio: adc: stm32-dfsdm: adopt generic channel bindings
>   iio: adc: sd_adc_modulator: change to iio backend device
>   iio: adc: stm32-dfsdm: add scaling support to dfsdm
>   ARM: dts: stm32: add dfsdm iio suppport
> 
>  arch/arm/boot/dts/stm32mp157c-ev1.dts |  62 +++++++++
>  drivers/iio/Makefile                  |   2 +
>  drivers/iio/adc/sd_adc_modulator.c    |  92 +++++++++++---
>  drivers/iio/adc/stm32-dfsdm-adc.c     | 176 ++++++++++++++++----------
>  drivers/iio/industrialio-backend.c    |  59 +++++++++
>  drivers/of/property.c                 |   2 +
>  include/linux/iio/backend.h           |  29 +++++
>  7 files changed, 336 insertions(+), 86 deletions(-)
>  create mode 100644 drivers/iio/industrialio-backend.c
>  create mode 100644 include/linux/iio/backend.h
> 

Re: [RFC PATCH 0/7] iio: add iio backend device type

[Jonathan Cameron]

On Fri, 23 Jun 2023 16:09:36 +0200
Olivier Moysan <olivier.moysan@foss.st.com> wrote:

> This RFC re-opens an old discussion regarding channel scaling
> management in STM32 DFSDM driver [1]
> 
> The DFSDM is a peripheral provided by the STM32MP1x SoC family.
> One objective is also to prepare the introduction of its successor in
> the STM32MP12x SoC family: the MDF (Multi-function Digital Filter).
> The MDF driver will have the same requirements as the DFSDM regarding
> channel scaling management. So, the solution proposed here will apply
> also for the future MDF driver.
For next version, please make sure all patches go at least to linux-iio@vger.kernel.org

Re: [RFC PATCH 0/7] iio: add iio backend device type

[Jonathan Cameron]

On Sun, 2 Jul 2023 18:56:18 +0800
Jonathan Cameron <Jonathan.Cameron@Huawei.com> wrote:

> On Fri, 23 Jun 2023 16:09:36 +0200
> Olivier Moysan <olivier.moysan@foss.st.com> wrote:
> 
> > This RFC re-opens an old discussion regarding channel scaling
> > management in STM32 DFSDM driver [1]
> > 
> > The DFSDM is a peripheral provided by the STM32MP1x SoC family.
> > One objective is also to prepare the introduction of its successor in
> > the STM32MP12x SoC family: the MDF (Multi-function Digital Filter).
> > The MDF driver will have the same requirements as the DFSDM regarding
> > channel scaling management. So, the solution proposed here will apply
> > also for the future MDF driver.
> > 
> > [1]
> > https://patchwork.kernel.org/project/linux-iio/patch/20200204101008.11411-5-olivier.moysan@st.com/
> > 
> > As a short reminder of our previous discussion, the two main options
> > emerging were the following ones:
> > 
> > - Option1: Use the DFSDM as an hardware accelerator and expose the
> > scaled channels on SD modulator side.
> > Drawbak: this solution is leading to an very complex datapath, especially
> > for scan mode.
> > 
> > - Option2: Introduce a new IIO device type (so-called backend)
> > Retrieve scaling information from SD modulator scaling to expose a single
> > IIO device on DFSDM side. This solution is derivated from rcar-gyroadc
> > example, but with a more standard approach.
> > This was discussed in 
> > https://lore.kernel.org/lkml/20210919191414.09270f4e@jic23-huawei/  
> 
> Naming probably needs a rethink given the actual hardware we are talking about
> here is normally called a frontend and so people will be confused...

Hmm. I think the basic approach looks fine but needs fleshing out and
perhaps one or two more examples implemented to be sure that we have
something flexible enough to stand the test of time...

Jonathan

> 
> I'm traveling at the moment, so only going to take a fairly superficial first
> look at what you have here.
> 
> Jonathan
> 
> > 
> > The patchset proposed in this RFC implements option2 (backend) solution.
> > These patches provide a minimal API implemented as a template.
> > The intented use of this API is illustrated through the DFSDM channel
> > scaling support basic implementation.
> > 
> > For sake of simplicity I did not include the related DT binding
> > in this serie. 
> > 
> > Below are some use case examples.
> > 
> > * DFSDM with SD modulator backend:
> >   -------------------------------
> > This use case corresponds to the example implemented in this RFC.
> > The channel attributes are retrieved from backend by the dfsdm, and
> > the resulting scaling is exposed through DFSDM IIO device sysfs
> > 
> > - Single channel:
> > +-------------+  ch attr   +--------+  sysfs (compound scaling)
> > | sd0 backend | ---------> | dfsdm0 | -------------------------->
> > +-------------+            +--------+
> > 
> > - Scan mode:
> > +-------------+  ch attr   +-------------+  sysfs (compound scaling)
> > | sd1 backend | ---------> |   dfsdm1    | -------------------------->
> > +-------------+            +-------------+
> >                              ^
> >                              |
> > +-------------+  ch attr     |
> > | sd2 backend |--------------+
> > +-------------+
> > 
> > 
> > * Voltage divider in front of an adc:
> >   ----------------------------------
> > By way of example, here is a comparison on scaling management with
> > a iio-rescale device, and how it could be managed with a backend device.
> > 
> > - iio-rescale implementation
> > Scaling is exposed both on ADC and iio-rescale IIO devices.
> > On iio-rescale device we get the compound scaling
> > 
> > +---------------------------+  ch attr   +------+  sysfs
> > |     iio-rescale (div)     | <--------- | adc0 | ------->
> > +---------------------------+            +------+
> >   |
> >   | sysfs (compound scaling)
> >   v
> > 
> > - Backend implementation:
> > Compound scaling is exposed on ADC IIO device.
> > No scaling exposed on backend device
> > 
> > +---------------+  ch attr   +------+  sysfs (compound scaling)
> > | backend (div) | ---------> | adc0 | -------------------------->
> > +---------------+            +------+
> > 
> > 
> > * Cascaded backends:
> >   -----------------
> > Backends may be cascaded to allow computation of the whole chain scaling
> > This is not part of this RFC, but it is identified as a potential
> > future use case.
> > 
> > +---------------+  attr   +-------------+  attr   +--------+  sysfs
> > | backend (div) | ------> | sd0 backend | ------> | dfsdm0 | ------->
> > +---------------+         +-------------+         +--------+
> > 
> > Olivier Moysan (7):
> >   iio: introduce iio backend device
> >   of: property: add device link support for io-backends
> >   iio: adc: stm32-dfsdm: manage dfsdm as a channel provider
> >   iio: adc: stm32-dfsdm: adopt generic channel bindings
> >   iio: adc: sd_adc_modulator: change to iio backend device
> >   iio: adc: stm32-dfsdm: add scaling support to dfsdm
> >   ARM: dts: stm32: add dfsdm iio suppport
> > 
> >  arch/arm/boot/dts/stm32mp157c-ev1.dts |  62 +++++++++
> >  drivers/iio/Makefile                  |   2 +
> >  drivers/iio/adc/sd_adc_modulator.c    |  92 +++++++++++---
> >  drivers/iio/adc/stm32-dfsdm-adc.c     | 176 ++++++++++++++++----------
> >  drivers/iio/industrialio-backend.c    |  59 +++++++++
> >  drivers/of/property.c                 |   2 +
> >  include/linux/iio/backend.h           |  29 +++++
> >  7 files changed, 336 insertions(+), 86 deletions(-)
> >  create mode 100644 drivers/iio/industrialio-backend.c
> >  create mode 100644 include/linux/iio/backend.h
> >   
> 
>