[PATCH 0/3] iio: adc: stm32: add mdf support for stm32mp2

[PATCH 0/3] iio: adc: stm32: add mdf support for stm32mp2

[Olivier Moysan]

This series adds support for the STM32 Multi-function Digital Filter (MDF)
found on STM32MP2 SoCs. MDF filters bitstreams from external sigma-delta
modulators and PDM microphones into samples for IIO and ASoC consumers.

The first patch documents the MDF core, serial interfaces, filters and
their connections in the devicetree binding.

The second patch adds the core, serial interface and filter drivers.
It supports IIO voltage channels for external sigma-delta modulators,
with direct reads or DMA buffering, and PDM microphone capture through
a cyclic DMA buffer. It also provides CIC filter configuration,
synchronization and filter interleaving.

The lastest patches add an ASoC DAI for PDM microphone capture.

Olivier Moysan (3):
  dt-bindings: iio: adc: add bindings for stm32 mdf filter
  iio: adc: add stm32 mdf support
  ASoC: stm32: add mdf dai support

 .../bindings/iio/adc/st,stm32-mdf-adc.yaml    |  383 +++
 drivers/iio/adc/Kconfig                       |   27 +
 drivers/iio/adc/Makefile                      |    3 +
 drivers/iio/adc/stm32-mdf-adc.c               | 2078 +++++++++++++++++
 drivers/iio/adc/stm32-mdf-core.c              |  857 +++++++
 drivers/iio/adc/stm32-mdf-serial.c            |  309 +++
 drivers/iio/adc/stm32-mdf.h                   |  312 +++
 include/linux/iio/adc/stm32-mdf-adc.h         |   19 +
 sound/soc/stm/Kconfig                         |   15 +
 sound/soc/stm/Makefile                        |    3 +
 sound/soc/stm/stm32_amdf.c                    |  376 +++
 11 files changed, 4382 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/iio/adc/st,stm32-mdf-adc.yaml
 create mode 100644 drivers/iio/adc/stm32-mdf-adc.c
 create mode 100644 drivers/iio/adc/stm32-mdf-core.c
 create mode 100644 drivers/iio/adc/stm32-mdf-serial.c
 create mode 100644 drivers/iio/adc/stm32-mdf.h
 create mode 100644 include/linux/iio/adc/stm32-mdf-adc.h
 create mode 100644 sound/soc/stm/stm32_amdf.c


base-commit: 9ee8306121495d2a25aa5d1bfd519f2748786b83
-- 
2.43.0

[PATCH 1/3] dt-bindings: iio: adc: add bindings for stm32 mdf filter

[Olivier Moysan]

Add bindings that describes STM32 MDF settings to support
digital filtering for Pulse Density Modulation (PDM) microphones
and analog sigma delta modulators.

Signed-off-by: Olivier Moysan <olivier.moysan@foss.st.com>
---
 .../bindings/iio/adc/st,stm32-mdf-adc.yaml    | 383 ++++++++++++++++++
 1 file changed, 383 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/iio/adc/st,stm32-mdf-adc.yaml

diff --git a/Documentation/devicetree/bindings/iio/adc/st,stm32-mdf-adc.yaml b/Documentation/devicetree/bindings/iio/adc/st,stm32-mdf-adc.yaml
new file mode 100644
index 000000000000..f2fbc3e150e8
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/st,stm32-mdf-adc.yaml
@@ -0,0 +1,383 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/adc/st,stm32-mdf-adc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: STMicroelectronics STM32 Multi-function Digital Filter (MDF) ADC
+
+maintainers:
+  - Olivier Moysan <olivier.moysan@foss.st.com>
+
+description: |
+  STM32 MDF ADC is a sigma delta analog-to-digital converter dedicated to
+  interface external sigma delta modulators to STM32 micro controllers.
+
+properties:
+  compatible:
+    enum:
+      - st,stm32mp25-mdf
+      - st,stm32mp23-mdf
+
+  reg:
+    minItems: 1
+    maxItems: 2
+
+  clocks:
+    maxItems: 1
+
+  clock-names:
+    description: Internal clock used for MDF digital processing.
+    items:
+      - const: ker_ck
+
+  "#clock-cells":
+    enum: [0, 1]
+
+  clock-output-names:
+    description: |
+      CCK0 and CCK1 are optional output clocks, which share the same clock frequency,
+      but can be gated independently to save power.
+    minItems: 1
+    maxItems: 2
+    oneOf:
+      - items:
+          - const: cck0
+      - items:
+          - const: cck1
+      - items:
+          - const: cck0
+          - const: cck1
+
+  clock-frequency:
+    description: |
+      Common clock frequency (Hz) for CCK0 and CCK1 output clocks.
+      The frequency must be a multiple of the "ker_ck" clock frequency.
+    maximum: 25000000
+
+  "#address-cells":
+    const: 1
+
+  "#size-cells":
+    const: 1
+
+  ranges: true
+
+  clock-ranges: true
+
+  resets:
+    maxItems: 1
+
+  reset-names:
+    items:
+      - const: mdf
+
+  access-controllers:
+    $ref: /schemas/types.yaml#/definitions/phandle-array
+    description: |
+      Phandle to the rifsc device to check access right.
+
+  power-domains:
+    maxItems: 1
+
+  st,interleave:
+    description: |
+      List of phandles of interleaved filters. The indexes of interleaved filters must be
+      consecutives starting from 0 (i.e in range [0..N]). The samples from interleaved filters
+      are muxed in a single channel and retrieved through the device associated to the filter 0.
+      The filters 1..N have to be enabled, but inherit their configuration from filter 0.
+    $ref: /schemas/types.yaml#/definitions/phandle-array
+
+required:
+  - compatible
+  - reg
+  - ranges
+  - clocks
+  - clock-names
+  - clock-ranges
+  - "#address-cells"
+  - "#size-cells"
+
+additionalProperties: false
+
+patternProperties:
+  "^sitf@[0-9]+$":
+    type: object
+    description: Serial interface child node
+
+    properties:
+      compatible:
+        enum:
+          - st,stm32mp25-sitf-mdf
+
+      reg:
+        description: Specify the SITF serial interface instance
+        maxItems: 1
+
+      clocks:
+        description: |
+          Serial interface clock (optional depending on interface mode)
+        maxItems: 1
+
+      st,sitf-mode:
+        description: |
+          Select serial interface protocol
+          - spi: SPI mode
+          - lf_spi: low frequency SPI mode for low power applications
+        $ref: /schemas/types.yaml#/definitions/string
+        enum:
+          - spi
+          - lf_spi
+
+    required:
+      - reg
+      - st,sitf-mode
+
+    additionalProperties: false
+
+  "^filter@[0-9]+$":
+    type: object
+    description: Digital filter path child node
+
+    properties:
+      compatible:
+        enum:
+          - st,stm32mp25-mdf-dmic
+          - st,stm32mp25-mdf-adc
+
+      reg:
+        description: Specify the MDF filter instance
+        maxItems: 1
+
+      interrupts:
+        maxItems: 1
+
+      clocks:
+        minItems: 1
+        description: Internal clock used for MDF digital processing and control blocks.
+
+      clock-names:
+        items:
+          - const: ker_ck
+
+      dmas:
+        maxItems: 1
+
+      dma-names:
+        items:
+          - const: rx
+
+      "#io-channel-cells":
+        const: 1
+
+      '#address-cells':
+        const: 1
+
+      '#size-cells':
+        const: 0
+
+      st,cic-mode:
+        description: |
+          Cascaded-integrator-comb (CIC) filter configuration
+          - 0: MCIC & ACIC filters in FastSinc mode
+          - [1-3]: MCIC & ACIC filters in Sinc mode order 1 to 3
+          - [4-5]: Single CIC filter in Sinc mode order 4 to 5
+          For audio purpose it is recommended to use CIC Sinc4 or Sinc5
+          This property is mandatory for filter 0 or filters not used in interleave mode.
+        $ref: /schemas/types.yaml#/definitions/uint32
+        minimum: 0
+        maximum: 5
+
+      st,delay:
+        description: Filter delay in samples
+        $ref: /schemas/types.yaml#/definitions/uint32
+        maximum: 127
+
+      st,rs-filter-bypass:
+        description: Bypass RSFLT reshaping filter.
+        $ref: /schemas/types.yaml#/definitions/flag
+
+      st,hpf-filter-cutoff-bp:
+        description: |
+          High Pass Filter (HPF) cut-off frequency expressed as a fraction of the PCM sampling rate.
+          Cut-off frequency = st,hpf-filter-cutoff-bp x Fpcm / 10000.
+          If this property is not defined the HPF is disabled.
+        enum: [625, 1250, 2500, 9500]
+
+      st,sync:
+        description:
+          Synchronize to another filter.
+          Must contain the phandle of the filter providing the synchronization.
+        allOf:
+          - $ref: /schemas/types.yaml#/definitions/phandle-array
+          - maxItems: 1
+
+      st,sitf:
+        $ref: /schemas/types.yaml#/definitions/phandle-array
+        items:
+          - items:
+              - description: Phandle of the serial interface connected to the digital filter
+              - description: |
+                  The phandle's argument selects the bitstream on the falling or rising edge
+                  of the serial interface clock:
+                  - 0: rising edge
+                  - 1: falling edge
+                enum: [0, 1]
+                default: 0
+        description:
+          Should be phandle/bitstream pair.
+
+    required:
+      - compatible
+      - reg
+      - interrupts
+      - dmas
+      - dma-names
+      - "#io-channel-cells"
+      - "#address-cells"
+      - "#size-cells"
+      - st,sitf
+
+    unevaluatedProperties: false
+
+    patternProperties:
+      "^channel@([0-7])$":
+        type: object
+        $ref: adc.yaml
+        description: Represents the external channel which is connected to the MDF.
+
+        properties:
+          reg:
+            maximum: 7
+
+          io-backends:
+            description:
+              Used to pipe external sigma delta modulator or internal ADC backend to MDF
+              channel.
+            maxItems: 1
+
+        required:
+          - reg
+
+        unevaluatedProperties: false
+
+    allOf:
+      - if:
+          properties:
+            compatible:
+              contains:
+                const: st,stm32mp25-mdf-adc
+
+        then:
+          patternProperties:
+            "^channel@[0-7]$":
+              required:
+                - io-backends
+
+      - if:
+          properties:
+            compatible:
+              contains:
+                const: st,stm32mp25-mdf-dmic
+
+        then:
+          patternProperties:
+            "^mdf-dai+$":
+              type: object
+              description: child node
+
+              properties:
+                compatible:
+                  enum:
+                    - st,stm32mp25-mdf-dai
+
+                "#sound-dai-cells":
+                  const: 0
+
+                io-channels:
+                  description:
+                    From common IIO binding. Used to pipe external sigma delta
+                    modulator or internal ADC output to MDF channel.
+
+                power-domains:
+                  maxItems: 1
+
+                port:
+                  $ref: /schemas/sound/audio-graph-port.yaml#
+                  unevaluatedProperties: false
+
+              required:
+                - compatible
+                - "#sound-dai-cells"
+                - io-channels
+
+              additionalProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/clock/st,stm32mp25-rcc.h>
+    #include <dt-bindings/interrupt-controller/arm-gic.h>
+    mdf1: mdf@504d0000 {
+      compatible = "st,stm32mp25-mdf";
+      ranges = <0 0x504d0000 0x1000>;
+      reg = <0x504d0000 0x8>, <0x504d0ff0 0x10>;
+      #address-cells = <1>;
+      #size-cells = <1>;
+      clocks = <&rcc CK_KER_MDF1>;
+      clock-names = "ker_ck";
+      clock-ranges;
+      #clock-cells = <1>;
+      clock-output-names = "cck0", "cck1";
+      clock-frequency = <2048000>;
+
+      sitf5: sitf@300 {
+        compatible = "st,stm32mp25-sitf-mdf";
+        reg = <0x300 0x4>;
+        st,sitf-mode = "spi";
+        clocks = <&mdf1 0>;
+      };
+
+      filter0: filter@84 {
+        compatible = "st,stm32mp25-mdf-dmic";
+        reg = <0x84 0x70>;
+        #io-channel-cells = <1>;
+        interrupts = <GIC_SPI 184 IRQ_TYPE_LEVEL_HIGH>;
+        dmas = <&hpdma 63 0x63 0x12 0>;
+        dma-names = "rx";
+        st,cic-mode = <5>;
+        st,sitf = <&sitf5 0>;
+        #address-cells = <1>;
+        #size-cells = <0>;
+
+        channel@0 {
+          reg = <0>;
+        };
+
+        asoc_pdm0: mdf-dai {
+          compatible = "st,stm32mp25-mdf-dai";
+          #sound-dai-cells = <0>;
+          io-channels = <&filter0 0>;
+        };
+      };
+
+      filter1: filter@104  {
+        compatible = "st,stm32mp25-mdf-adc";
+        reg = <0x104 0x70>;
+        #io-channel-cells = <1>;
+        interrupts = <GIC_SPI 185 IRQ_TYPE_LEVEL_HIGH>;
+        dmas = <&hpdma 64 0x63 0x12 0>;
+        dma-names = "rx";
+        st,cic-mode = <2>;
+        st,sitf = <&sitf5 1>;
+        #address-cells = <1>;
+        #size-cells = <0>;
+
+        channel@1 {
+          reg = <1>;
+          settling-time-us = <1000>;
+          io-backends = <&sd_adc1>;
+        };
+      };
+    };
+
+...
-- 
2.43.0

Re: [PATCH 1/3] dt-bindings: iio: adc: add bindings for stm32 mdf filter

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Low] dt-bindings: invalid decimal-only regex for sitf and filter unit addresses
- [Low] dt-bindings: faulty regex in mdf-dai and channel patternProperties
--

commit 0433e9502551ab7438d761bd69f15064435b1ccc
Author: Olivier Moysan <olivier.moysan@foss.st.com>

dt-bindings: iio: adc: add bindings for stm32 mdf filter

Add bindings that describes STM32 MDF settings to support
digital filtering for Pulse Density Modulation (PDM) microphones
and analog sigma delta modulators.

> diff --git a/Documentation/devicetree/bindings/iio/adc/st,stm32-mdf-adc.yaml b/Documentation/devicetree/bindings/iio/adc/st,stm32-mdf-adc.yaml
> new file mode 100644
> index 0000000000000..f2fbc3e150e8c
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/adc/st,stm32-mdf-adc.yaml
[ ... ]
> +patternProperties:
> +  "^sitf@[0-9]+$":

[Severity: Low]
Is this regex overly restrictive? Device tree unit addresses commonly contain
hexadecimal characters, so an address like sitf@1a0 would fail to match this
pattern.

Since the top-level schema has additionalProperties: false, valid nodes might
be rejected. Would "^sitf@[0-9a-f]+$" be more appropriate?

> +    type: object
> +    description: Serial interface child node
[ ... ]
> +  "^filter@[0-9]+$":

[Severity: Low]
Similarly, does this restrict filter unit addresses strictly to decimal digits?

A node with a hexadecimal offset, such as filter@1e4, would not match this
pattern and would fail schema validation.

> +    type: object
> +    description: Digital filter path child node
[ ... ]
> +    patternProperties:
> +      "^channel@([0-7])$":

[Severity: Low]
Does this capture group differ from the allOf constraint key? The allOf section
later in the file uses "^channel@[0-7]$".

Mismatches in literal keys can sometimes interfere with schema aggregation
tools that rely on exact string matching to properly merge subschemas.

> +        type: object
> +        $ref: adc.yaml
[ ... ]
> +        then:
> +          patternProperties:
> +            "^mdf-dai+$":

[Severity: Low]
Could this regex pattern be a typo? The '+' quantifier applies to the character
'i' rather than matching multiple child nodes or strictly matching the string.

If it is meant to match exactly one string, would "^mdf-dai$" be intended?

> +              type: object
> +              description: child node

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261001145702.2628429-1-olivier.moysan@foss.st.com?part=1

Re: [PATCH 1/3] dt-bindings: iio: adc: add bindings for stm32 mdf filter

[Rob Herring (Arm)]

On Thu, 01 Oct 2026 16:56:45 +0200, Olivier Moysan wrote:
> Add bindings that describes STM32 MDF settings to support
> digital filtering for Pulse Density Modulation (PDM) microphones
> and analog sigma delta modulators.
> 
> Signed-off-by: Olivier Moysan <olivier.moysan@foss.st.com>
> ---
>  .../bindings/iio/adc/st,stm32-mdf-adc.yaml    | 383 ++++++++++++++++++
>  1 file changed, 383 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/iio/adc/st,stm32-mdf-adc.yaml
> 

My bot found errors running 'make dt_binding_check' on your patch:

yamllint warnings/errors:

dtschema/dtc warnings/errors:
./Documentation/devicetree/bindings/iio/adc/st,stm32-mdf-adc.yaml:363: example 0 [redundant-whitespace] extra whitespace before {

doc reference errors (make refcheckdocs):

See https://patchwork.kernel.org/project/devicetree/patch/20261001145702.2628429-2-olivier.moysan@foss.st.com

The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.

If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:

pip3 install dtschema --upgrade

Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.

Re: [PATCH 1/3] dt-bindings: iio: adc: add bindings for stm32 mdf filter

[Conor Dooley]

[-- Attachment #1: Type: text/plain, Size: 12687 bytes --]

On Thu, Oct 01, 2026 at 04:56:45PM +0200, Olivier Moysan wrote:
> Add bindings that describes STM32 MDF settings to support
> digital filtering for Pulse Density Modulation (PDM) microphones
> and analog sigma delta modulators.
> 
> Signed-off-by: Olivier Moysan <olivier.moysan@foss.st.com>
> ---
>  .../bindings/iio/adc/st,stm32-mdf-adc.yaml    | 383 ++++++++++++++++++
>  1 file changed, 383 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/iio/adc/st,stm32-mdf-adc.yaml
> 
> diff --git a/Documentation/devicetree/bindings/iio/adc/st,stm32-mdf-adc.yaml b/Documentation/devicetree/bindings/iio/adc/st,stm32-mdf-adc.yaml
> new file mode 100644
> index 000000000000..f2fbc3e150e8
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/adc/st,stm32-mdf-adc.yaml
> @@ -0,0 +1,383 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/iio/adc/st,stm32-mdf-adc.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: STMicroelectronics STM32 Multi-function Digital Filter (MDF) ADC
> +
> +maintainers:
> +  - Olivier Moysan <olivier.moysan@foss.st.com>
> +
> +description: |
> +  STM32 MDF ADC is a sigma delta analog-to-digital converter dedicated to
> +  interface external sigma delta modulators to STM32 micro controllers.
> +
> +properties:
> +  compatible:
> +    enum:
> +      - st,stm32mp25-mdf
> +      - st,stm32mp23-mdf
> +
> +  reg:
> +    minItems: 1
> +    maxItems: 2

This needs an items list here. The size of the regions seems like crap
to begin with...

> +
> +  clocks:
> +    maxItems: 1
> +
> +  clock-names:
> +    description: Internal clock used for MDF digital processing.
> +    items:
> +      - const: ker_ck

This is pointless when you only have one.

> +
> +  "#clock-cells":
> +    enum: [0, 1]

Why is this not fixed? Also why are parts of your own device consuming
the clocks?

> +
> +  clock-output-names:
> +    description: |
> +      CCK0 and CCK1 are optional output clocks, which share the same clock frequency,
> +      but can be gated independently to save power.
> +    minItems: 1
> +    maxItems: 2
> +    oneOf:
> +      - items:
> +          - const: cck0
> +      - items:
> +          - const: cck1
> +      - items:
> +          - const: cck0
> +          - const: cck1
> +
> +  clock-frequency:
> +    description: |
> +      Common clock frequency (Hz) for CCK0 and CCK1 output clocks.
> +      The frequency must be a multiple of the "ker_ck" clock frequency.
> +    maximum: 25000000

Should not be needed, the consumers request what they need.

> +
> +  "#address-cells":
> +    const: 1
> +
> +  "#size-cells":
> +    const: 1
> +
> +  ranges: true
> +
> +  clock-ranges: true
> +
> +  resets:
> +    maxItems: 1
> +
> +  reset-names:
> +    items:
> +      - const: mdf
> +
> +  access-controllers:
> +    $ref: /schemas/types.yaml#/definitions/phandle-array
> +    description: |
> +      Phandle to the rifsc device to check access right.
> +
> +  power-domains:
> +    maxItems: 1
> +
> +  st,interleave:
> +    description: |
> +      List of phandles of interleaved filters. The indexes of interleaved filters must be
> +      consecutives starting from 0 (i.e in range [0..N]). The samples from interleaved filters
> +      are muxed in a single channel and retrieved through the device associated to the filter 0.
> +      The filters 1..N have to be enabled, but inherit their configuration from filter 0.
> +    $ref: /schemas/types.yaml#/definitions/phandle-array

No idea what these even are, but this is probably not the right way to
represent the relationship between devices. They're apparently ADCs, but
this is also an ADC so I'm not sure what's going on here at all.

> +
> +required:
> +  - compatible
> +  - reg
> +  - ranges
> +  - clocks
> +  - clock-names
> +  - clock-ranges
> +  - "#address-cells"
> +  - "#size-cells"
> +
> +additionalProperties: false
> +
> +patternProperties:
> +  "^sitf@[0-9]+$":
> +    type: object
> +    description: Serial interface child node

Why is this a child node at all?
 
Probably not worth reviewing more without a link to the docs for this
device so I can figure out what on earth is going on!

Thanks,
Conor.

> +
> +    properties:
> +      compatible:
> +        enum:
> +          - st,stm32mp25-sitf-mdf
> +
> +      reg:
> +        description: Specify the SITF serial interface instance
> +        maxItems: 1
> +
> +      clocks:
> +        description: |
> +          Serial interface clock (optional depending on interface mode)
> +        maxItems: 1
> +
> +      st,sitf-mode:
> +        description: |
> +          Select serial interface protocol
> +          - spi: SPI mode
> +          - lf_spi: low frequency SPI mode for low power applications
> +        $ref: /schemas/types.yaml#/definitions/string
> +        enum:
> +          - spi
> +          - lf_spi
> +
> +    required:
> +      - reg
> +      - st,sitf-mode
> +
> +    additionalProperties: false
> +
> +  "^filter@[0-9]+$":
> +    type: object
> +    description: Digital filter path child node
> +
> +    properties:
> +      compatible:
> +        enum:
> +          - st,stm32mp25-mdf-dmic
> +          - st,stm32mp25-mdf-adc
> +
> +      reg:
> +        description: Specify the MDF filter instance
> +        maxItems: 1
> +
> +      interrupts:
> +        maxItems: 1
> +
> +      clocks:
> +        minItems: 1
> +        description: Internal clock used for MDF digital processing and control blocks.
> +
> +      clock-names:
> +        items:
> +          - const: ker_ck
> +
> +      dmas:
> +        maxItems: 1
> +
> +      dma-names:
> +        items:
> +          - const: rx
> +
> +      "#io-channel-cells":
> +        const: 1
> +
> +      '#address-cells':
> +        const: 1
> +
> +      '#size-cells':
> +        const: 0
> +
> +      st,cic-mode:
> +        description: |
> +          Cascaded-integrator-comb (CIC) filter configuration
> +          - 0: MCIC & ACIC filters in FastSinc mode
> +          - [1-3]: MCIC & ACIC filters in Sinc mode order 1 to 3
> +          - [4-5]: Single CIC filter in Sinc mode order 4 to 5
> +          For audio purpose it is recommended to use CIC Sinc4 or Sinc5
> +          This property is mandatory for filter 0 or filters not used in interleave mode.
> +        $ref: /schemas/types.yaml#/definitions/uint32
> +        minimum: 0
> +        maximum: 5
> +
> +      st,delay:
> +        description: Filter delay in samples
> +        $ref: /schemas/types.yaml#/definitions/uint32
> +        maximum: 127
> +
> +      st,rs-filter-bypass:
> +        description: Bypass RSFLT reshaping filter.
> +        $ref: /schemas/types.yaml#/definitions/flag
> +
> +      st,hpf-filter-cutoff-bp:
> +        description: |
> +          High Pass Filter (HPF) cut-off frequency expressed as a fraction of the PCM sampling rate.
> +          Cut-off frequency = st,hpf-filter-cutoff-bp x Fpcm / 10000.
> +          If this property is not defined the HPF is disabled.
> +        enum: [625, 1250, 2500, 9500]
> +
> +      st,sync:
> +        description:
> +          Synchronize to another filter.
> +          Must contain the phandle of the filter providing the synchronization.
> +        allOf:
> +          - $ref: /schemas/types.yaml#/definitions/phandle-array
> +          - maxItems: 1
> +
> +      st,sitf:
> +        $ref: /schemas/types.yaml#/definitions/phandle-array
> +        items:
> +          - items:
> +              - description: Phandle of the serial interface connected to the digital filter
> +              - description: |
> +                  The phandle's argument selects the bitstream on the falling or rising edge
> +                  of the serial interface clock:
> +                  - 0: rising edge
> +                  - 1: falling edge
> +                enum: [0, 1]
> +                default: 0
> +        description:
> +          Should be phandle/bitstream pair.
> +
> +    required:
> +      - compatible
> +      - reg
> +      - interrupts
> +      - dmas
> +      - dma-names
> +      - "#io-channel-cells"
> +      - "#address-cells"
> +      - "#size-cells"
> +      - st,sitf
> +
> +    unevaluatedProperties: false
> +
> +    patternProperties:
> +      "^channel@([0-7])$":
> +        type: object
> +        $ref: adc.yaml
> +        description: Represents the external channel which is connected to the MDF.
> +
> +        properties:
> +          reg:
> +            maximum: 7
> +
> +          io-backends:
> +            description:
> +              Used to pipe external sigma delta modulator or internal ADC backend to MDF
> +              channel.
> +            maxItems: 1
> +
> +        required:
> +          - reg
> +
> +        unevaluatedProperties: false
> +
> +    allOf:
> +      - if:
> +          properties:
> +            compatible:
> +              contains:
> +                const: st,stm32mp25-mdf-adc
> +
> +        then:
> +          patternProperties:
> +            "^channel@[0-7]$":
> +              required:
> +                - io-backends
> +
> +      - if:
> +          properties:
> +            compatible:
> +              contains:
> +                const: st,stm32mp25-mdf-dmic
> +
> +        then:
> +          patternProperties:
> +            "^mdf-dai+$":
> +              type: object
> +              description: child node
> +
> +              properties:
> +                compatible:
> +                  enum:
> +                    - st,stm32mp25-mdf-dai
> +
> +                "#sound-dai-cells":
> +                  const: 0
> +
> +                io-channels:
> +                  description:
> +                    From common IIO binding. Used to pipe external sigma delta
> +                    modulator or internal ADC output to MDF channel.
> +
> +                power-domains:
> +                  maxItems: 1
> +
> +                port:
> +                  $ref: /schemas/sound/audio-graph-port.yaml#
> +                  unevaluatedProperties: false
> +
> +              required:
> +                - compatible
> +                - "#sound-dai-cells"
> +                - io-channels
> +
> +              additionalProperties: false
> +
> +examples:
> +  - |
> +    #include <dt-bindings/clock/st,stm32mp25-rcc.h>
> +    #include <dt-bindings/interrupt-controller/arm-gic.h>
> +    mdf1: mdf@504d0000 {
> +      compatible = "st,stm32mp25-mdf";
> +      ranges = <0 0x504d0000 0x1000>;
> +      reg = <0x504d0000 0x8>, <0x504d0ff0 0x10>;
> +      #address-cells = <1>;
> +      #size-cells = <1>;
> +      clocks = <&rcc CK_KER_MDF1>;
> +      clock-names = "ker_ck";
> +      clock-ranges;
> +      #clock-cells = <1>;
> +      clock-output-names = "cck0", "cck1";
> +      clock-frequency = <2048000>;
> +
> +      sitf5: sitf@300 {
> +        compatible = "st,stm32mp25-sitf-mdf";
> +        reg = <0x300 0x4>;
> +        st,sitf-mode = "spi";
> +        clocks = <&mdf1 0>;
> +      };
> +
> +      filter0: filter@84 {
> +        compatible = "st,stm32mp25-mdf-dmic";
> +        reg = <0x84 0x70>;
> +        #io-channel-cells = <1>;
> +        interrupts = <GIC_SPI 184 IRQ_TYPE_LEVEL_HIGH>;
> +        dmas = <&hpdma 63 0x63 0x12 0>;
> +        dma-names = "rx";
> +        st,cic-mode = <5>;
> +        st,sitf = <&sitf5 0>;
> +        #address-cells = <1>;
> +        #size-cells = <0>;
> +
> +        channel@0 {
> +          reg = <0>;
> +        };
> +
> +        asoc_pdm0: mdf-dai {
> +          compatible = "st,stm32mp25-mdf-dai";
> +          #sound-dai-cells = <0>;
> +          io-channels = <&filter0 0>;
> +        };
> +      };
> +
> +      filter1: filter@104  {
> +        compatible = "st,stm32mp25-mdf-adc";
> +        reg = <0x104 0x70>;
> +        #io-channel-cells = <1>;
> +        interrupts = <GIC_SPI 185 IRQ_TYPE_LEVEL_HIGH>;
> +        dmas = <&hpdma 64 0x63 0x12 0>;
> +        dma-names = "rx";
> +        st,cic-mode = <2>;
> +        st,sitf = <&sitf5 1>;
> +        #address-cells = <1>;
> +        #size-cells = <0>;
> +
> +        channel@1 {
> +          reg = <1>;
> +          settling-time-us = <1000>;
> +          io-backends = <&sd_adc1>;
> +        };
> +      };
> +    };
> +
> +...
> -- 
> 2.43.0
> 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH 1/3] dt-bindings: iio: adc: add bindings for stm32 mdf filter

[Olivier MOYSAN]

Hi Conor,

Thanks for the review

On 10/1/26 20:32, Conor Dooley wrote:
> On Thu, Oct 01, 2026 at 04:56:45PM +0200, Olivier Moysan wrote:
>> Add bindings that describes STM32 MDF settings to support
>> digital filtering for Pulse Density Modulation (PDM) microphones
>> and analog sigma delta modulators.
>>
>> Signed-off-by: Olivier Moysan <olivier.moysan@foss.st.com>
>> ---
>>   .../bindings/iio/adc/st,stm32-mdf-adc.yaml    | 383 ++++++++++++++++++
>>   1 file changed, 383 insertions(+)
>>   create mode 100644 Documentation/devicetree/bindings/iio/adc/st,stm32-mdf-adc.yaml
>>
>> diff --git a/Documentation/devicetree/bindings/iio/adc/st,stm32-mdf-adc.yaml b/Documentation/devicetree/bindings/iio/adc/st,stm32-mdf-adc.yaml
>> new file mode 100644
>> index 000000000000..f2fbc3e150e8
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/iio/adc/st,stm32-mdf-adc.yaml
>> @@ -0,0 +1,383 @@
>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/iio/adc/st,stm32-mdf-adc.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: STMicroelectronics STM32 Multi-function Digital Filter (MDF) ADC
>> +
>> +maintainers:
>> +  - Olivier Moysan <olivier.moysan@foss.st.com>
>> +
>> +description: |
>> +  STM32 MDF ADC is a sigma delta analog-to-digital converter dedicated to
>> +  interface external sigma delta modulators to STM32 micro controllers.
>> +
>> +properties:
>> +  compatible:
>> +    enum:
>> +      - st,stm32mp25-mdf
>> +      - st,stm32mp23-mdf
>> +
>> +  reg:
>> +    minItems: 1
>> +    maxItems: 2
> 
> This needs an items list here. The size of the regions seems like crap
> to begin with...
> 
>> +
>> +  clocks:
>> +    maxItems: 1
>> +
>> +  clock-names:
>> +    description: Internal clock used for MDF digital processing.
>> +    items:
>> +      - const: ker_ck
> 
> This is pointless when you only have one.
> 

I agree that it could be dropped. However, it is useful for using 
devm_regmap_init_mmio_clk.

>> +
>> +  "#clock-cells":
>> +    enum: [0, 1]
> 
> Why is this not fixed? Also why are parts of your own device consuming
> the clocks?
> 
>> +
>> +  clock-output-names:
>> +    description: |
>> +      CCK0 and CCK1 are optional output clocks, which share the same clock frequency,
>> +      but can be gated independently to save power.
>> +    minItems: 1
>> +    maxItems: 2
>> +    oneOf:
>> +      - items:
>> +          - const: cck0
>> +      - items:
>> +          - const: cck1
>> +      - items:
>> +          - const: cck0
>> +          - const: cck1
>> +
>> +  clock-frequency:
>> +    description: |
>> +      Common clock frequency (Hz) for CCK0 and CCK1 output clocks.
>> +      The frequency must be a multiple of the "ker_ck" clock frequency.
>> +    maximum: 25000000
> 
> Should not be needed, the consumers request what they need.
> 

The CCKx clock frequency depends on the maximum rate supported by the 
sigma delta converters (for instance a digital mic) and the expected 
decimation ratio on the bitstream. Typically this determines the 
frequency on the SPI bus.
This rate is defined statically and shared by the CCKx clocks. So IMHO, 
as this rate is unique, it can look strange to let the consumer define 
it. Moreover, it seems to me that clock-frequency is already used to 
configure the frequency of a provider in some other bindings.
For instance: Documentation/devicetree/bindings/clock/silabs,si570.yaml
So, it's not clear for me, what is the restriction on clock-frequency 
property.
>> +
>> +  ranges: true
>> +
>> +  clock-ranges: true
>> +
>> +  resets:
>> +    maxItems: 1
>> +
>> +  reset-names:
>> +    items:
>> +      - const: mdf
>> +
>> +  access-controllers:
>> +    $ref: /schemas/types.yaml#/definitions/phandle-array
>> +    description: |
>> +      Phandle to the rifsc device to check access right.
>> +
>> +  power-domains:
>> +    maxItems: 1
>> +
>> +  st,interleave:
>> +    description: |
>> +      List of phandles of interleaved filters. The indexes of interleaved filters must be
>> +      consecutives starting from 0 (i.e in range [0..N]). The samples from interleaved filters
>> +      are muxed in a single channel and retrieved through the device associated to the filter 0.
>> +      The filters 1..N have to be enabled, but inherit their configuration from filter 0.
>> +    $ref: /schemas/types.yaml#/definitions/phandle-array
> 
> No idea what these even are, but this is probably not the right way to
> represent the relationship between devices. They're apparently ADCs, but
> this is also an ADC so I'm not sure what's going on here at all.
> 
>> +
>> +required:
>> +  - compatible
>> +  - reg
>> +  - ranges
>> +  - clocks
>> +  - clock-names
>> +  - clock-ranges
>> +  - "#address-cells"
>> +  - "#size-cells"
>> +
>> +additionalProperties: false
>> +
>> +patternProperties:
>> +  "^sitf@[0-9]+$":
>> +    type: object
>> +    description: Serial interface child node
> 
> Why is this a child node at all?
>   
> Probably not worth reviewing more without a link to the docs for this
> device so I can figure out what on earth is going on!
> 

The MDF is a digital filter for sigma-delta bitstreams, rather than the 
analog-to-digital converter itself.

Here is the link to STM32MP25 reference manuel
https://www.st.com/resource/en/reference_manual/rm0457-stm32mp2325xx-advanced-armbased-3264bit-mpus-stmicroelectronics.pdf
Chapter 45: Multi-function digital filter (MDF)

On STMP32MP25 SoC, the MDF provides 8 serial interfaces (SITF) and 8 
digital filters (DFLT) which can be connected through a multiplexer.

Below is a schematic view of typical applications targeted by this 
peripheral


Audio use case:

		mdf
             +-------------------------------------+
+------+    | +------+    +------+    +------+    |
| dmic | -> | | sitf | -> | mux  | -> | dflt | -- | -> audio device
+------+    | +------+    +------+    +------+    |
             +-------------------------------------+

For instance, in an audio use case the serial interface can be 
configured to provide the clock to the digital microphone (cck0, cck1 or 
both) at a common predefined rate, and to retrieve the PDM samples.
The serial interface provides this samples to a digital filter, which 
delivers PCM samples on its output.


Analog use case:

		mdf
               +-------------------------------------+
+--------+    | +------+    +------+    +------+    |
| sd adc | -> | | sitf | -> | mux  | -> | dflt | -- | -> iio device
+--------+    | +------+    +------+    +------+    |
               +-------------------------------------+


Best regards
Olivier

> Thanks,
> Conor.
> 
>> +
>> +    properties:
>> +      compatible:
>> +        enum:
>> +          - st,stm32mp25-sitf-mdf
>> +
>> +      reg:
>> +        description: Specify the SITF serial interface instance
>> +        maxItems: 1
>> +
>> +      clocks:
>> +        description: |
>> +          Serial interface clock (optional depending on interface mode)
>> +        maxItems: 1
>> +
>> +      st,sitf-mode:
>> +        description: |
>> +          Select serial interface protocol
>> +          - spi: SPI mode
>> +          - lf_spi: low frequency SPI mode for low power applications
>> +        $ref: /schemas/types.yaml#/definitions/string
>> +        enum:
>> +          - spi
>> +          - lf_spi
>> +
>> +    required:
>> +      - reg
>> +      - st,sitf-mode
>> +
>> +    additionalProperties: false
>> +
>> +  "^filter@[0-9]+$":
>> +    type: object
>> +    description: Digital filter path child node
>> +
>> +    properties:
>> +      compatible:
>> +        enum:
>> +          - st,stm32mp25-mdf-dmic
>> +          - st,stm32mp25-mdf-adc
>> +
>> +      reg:
>> +        description: Specify the MDF filter instance
>> +        maxItems: 1
>> +
>> +      interrupts:
>> +        maxItems: 1
>> +
>> +      clocks:
>> +        minItems: 1
>> +        description: Internal clock used for MDF digital processing and control blocks.
>> +
>> +      clock-names:
>> +        items:
>> +          - const: ker_ck
>> +
>> +      dmas:
>> +        maxItems: 1
>> +
>> +      dma-names:
>> +        items:
>> +          - const: rx
>> +
>> +      "#io-channel-cells":
>> +        const: 1
>> +
>> +      '#address-cells':
>> +        const: 1
>> +
>> +      '#size-cells':
>> +        const: 0
>> +
>> +      st,cic-mode:
>> +        description: |
>> +          Cascaded-integrator-comb (CIC) filter configuration
>> +          - 0: MCIC & ACIC filters in FastSinc mode
>> +          - [1-3]: MCIC & ACIC filters in Sinc mode order 1 to 3
>> +          - [4-5]: Single CIC filter in Sinc mode order 4 to 5
>> +          For audio purpose it is recommended to use CIC Sinc4 or Sinc5
>> +          This property is mandatory for filter 0 or filters not used in interleave mode.
>> +        $ref: /schemas/types.yaml#/definitions/uint32
>> +        minimum: 0
>> +        maximum: 5
>> +
>> +      st,delay:
>> +        description: Filter delay in samples
>> +        $ref: /schemas/types.yaml#/definitions/uint32
>> +        maximum: 127
>> +
>> +      st,rs-filter-bypass:
>> +        description: Bypass RSFLT reshaping filter.
>> +        $ref: /schemas/types.yaml#/definitions/flag
>> +
>> +      st,hpf-filter-cutoff-bp:
>> +        description: |
>> +          High Pass Filter (HPF) cut-off frequency expressed as a fraction of the PCM sampling rate.
>> +          Cut-off frequency = st,hpf-filter-cutoff-bp x Fpcm / 10000.
>> +          If this property is not defined the HPF is disabled.
>> +        enum: [625, 1250, 2500, 9500]
>> +
>> +      st,sync:
>> +        description:
>> +          Synchronize to another filter.
>> +          Must contain the phandle of the filter providing the synchronization.
>> +        allOf:
>> +          - $ref: /schemas/types.yaml#/definitions/phandle-array
>> +          - maxItems: 1
>> +
>> +      st,sitf:
>> +        $ref: /schemas/types.yaml#/definitions/phandle-array
>> +        items:
>> +          - items:
>> +              - description: Phandle of the serial interface connected to the digital filter
>> +              - description: |
>> +                  The phandle's argument selects the bitstream on the falling or rising edge
>> +                  of the serial interface clock:
>> +                  - 0: rising edge
>> +                  - 1: falling edge
>> +                enum: [0, 1]
>> +                default: 0
>> +        description:
>> +          Should be phandle/bitstream pair.
>> +
>> +    required:
>> +      - compatible
>> +      - reg
>> +      - interrupts
>> +      - dmas
>> +      - dma-names
>> +      - "#io-channel-cells"
>> +      - "#address-cells"
>> +      - "#size-cells"
>> +      - st,sitf
>> +
>> +    unevaluatedProperties: false
>> +
>> +    patternProperties:
>> +      "^channel@([0-7])$":
>> +        type: object
>> +        $ref: adc.yaml
>> +        description: Represents the external channel which is connected to the MDF.
>> +
>> +        properties:
>> +          reg:
>> +            maximum: 7
>> +
>> +          io-backends:
>> +            description:
>> +              Used to pipe external sigma delta modulator or internal ADC backend to MDF
>> +              channel.
>> +            maxItems: 1
>> +
>> +        required:
>> +          - reg
>> +
>> +        unevaluatedProperties: false
>> +
>> +    allOf:
>> +      - if:
>> +          properties:
>> +            compatible:
>> +              contains:
>> +                const: st,stm32mp25-mdf-adc
>> +
>> +        then:
>> +          patternProperties:
>> +            "^channel@[0-7]$":
>> +              required:
>> +                - io-backends
>> +
>> +      - if:
>> +          properties:
>> +            compatible:
>> +              contains:
>> +                const: st,stm32mp25-mdf-dmic
>> +
>> +        then:
>> +          patternProperties:
>> +            "^mdf-dai+$":
>> +              type: object
>> +              description: child node
>> +
>> +              properties:
>> +                compatible:
>> +                  enum:
>> +                    - st,stm32mp25-mdf-dai
>> +
>> +                "#sound-dai-cells":
>> +                  const: 0
>> +
>> +                io-channels:
>> +                  description:
>> +                    From common IIO binding. Used to pipe external sigma delta
>> +                    modulator or internal ADC output to MDF channel.
>> +
>> +                power-domains:
>> +                  maxItems: 1
>> +
>> +                port:
>> +                  $ref: /schemas/sound/audio-graph-port.yaml#
>> +                  unevaluatedProperties: false
>> +
>> +              required:
>> +                - compatible
>> +                - "#sound-dai-cells"
>> +                - io-channels
>> +
>> +              additionalProperties: false
>> +
>> +examples:
>> +  - |
>> +    #include <dt-bindings/clock/st,stm32mp25-rcc.h>
>> +    #include <dt-bindings/interrupt-controller/arm-gic.h>
>> +    mdf1: mdf@504d0000 {
>> +      compatible = "st,stm32mp25-mdf";
>> +      ranges = <0 0x504d0000 0x1000>;
>> +      reg = <0x504d0000 0x8>, <0x504d0ff0 0x10>;
>> +      #address-cells = <1>;
>> +      #size-cells = <1>;
>> +      clocks = <&rcc CK_KER_MDF1>;
>> +      clock-names = "ker_ck";
>> +      clock-ranges;
>> +      #clock-cells = <1>;
>> +      clock-output-names = "cck0", "cck1";
>> +      clock-frequency = <2048000>;
>> +
>> +      sitf5: sitf@300 {
>> +        compatible = "st,stm32mp25-sitf-mdf";
>> +        reg = <0x300 0x4>;
>> +        st,sitf-mode = "spi";
>> +        clocks = <&mdf1 0>;
>> +      };
>> +
>> +      filter0: filter@84 {
>> +        compatible = "st,stm32mp25-mdf-dmic";
>> +        reg = <0x84 0x70>;
>> +        #io-channel-cells = <1>;
>> +        interrupts = <GIC_SPI 184 IRQ_TYPE_LEVEL_HIGH>;
>> +        dmas = <&hpdma 63 0x63 0x12 0>;
>> +        dma-names = "rx";
>> +        st,cic-mode = <5>;
>> +        st,sitf = <&sitf5 0>;
>> +        #address-cells = <1>;
>> +        #size-cells = <0>;
>> +
>> +        channel@0 {
>> +          reg = <0>;
>> +        };
>> +
>> +        asoc_pdm0: mdf-dai {
>> +          compatible = "st,stm32mp25-mdf-dai";
>> +          #sound-dai-cells = <0>;
>> +          io-channels = <&filter0 0>;
>> +        };
>> +      };
>> +
>> +      filter1: filter@104  {
>> +        compatible = "st,stm32mp25-mdf-adc";
>> +        reg = <0x104 0x70>;
>> +        #io-channel-cells = <1>;
>> +        interrupts = <GIC_SPI 185 IRQ_TYPE_LEVEL_HIGH>;
>> +        dmas = <&hpdma 64 0x63 0x12 0>;
>> +        dma-names = "rx";
>> +        st,cic-mode = <2>;
>> +        st,sitf = <&sitf5 1>;
>> +        #address-cells = <1>;
>> +        #size-cells = <0>;
>> +
>> +        channel@1 {
>> +          reg = <1>;
>> +          settling-time-us = <1000>;
>> +          io-backends = <&sd_adc1>;
>> +        };
>> +      };
>> +    };
>> +
>> +...
>> -- 
>> 2.43.0
>>

Re: [PATCH 1/3] dt-bindings: iio: adc: add bindings for stm32 mdf filter

[Rob Herring]

On Wed, Oct 07, 2026 at 11:01:28AM +0200, Olivier MOYSAN wrote:
> Hi Conor,
> 
> Thanks for the review
> 
> On 10/1/26 20:32, Conor Dooley wrote:
> > On Thu, Oct 01, 2026 at 04:56:45PM +0200, Olivier Moysan wrote:
> > > Add bindings that describes STM32 MDF settings to support
> > > digital filtering for Pulse Density Modulation (PDM) microphones
> > > and analog sigma delta modulators.
> > > 
> > > Signed-off-by: Olivier Moysan <olivier.moysan@foss.st.com>
> > > ---
> > >   .../bindings/iio/adc/st,stm32-mdf-adc.yaml    | 383 ++++++++++++++++++
> > >   1 file changed, 383 insertions(+)
> > >   create mode 100644 Documentation/devicetree/bindings/iio/adc/st,stm32-mdf-adc.yaml
> > > 
> > > diff --git a/Documentation/devicetree/bindings/iio/adc/st,stm32-mdf-adc.yaml b/Documentation/devicetree/bindings/iio/adc/st,stm32-mdf-adc.yaml
> > > new file mode 100644
> > > index 000000000000..f2fbc3e150e8
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/iio/adc/st,stm32-mdf-adc.yaml
> > > @@ -0,0 +1,383 @@
> > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > > +%YAML 1.2
> > > +---
> > > +$id: http://devicetree.org/schemas/iio/adc/st,stm32-mdf-adc.yaml#
> > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > +
> > > +title: STMicroelectronics STM32 Multi-function Digital Filter (MDF) ADC
> > > +
> > > +maintainers:
> > > +  - Olivier Moysan <olivier.moysan@foss.st.com>
> > > +
> > > +description: |
> > > +  STM32 MDF ADC is a sigma delta analog-to-digital converter dedicated to
> > > +  interface external sigma delta modulators to STM32 micro controllers.
> > > +
> > > +properties:
> > > +  compatible:
> > > +    enum:
> > > +      - st,stm32mp25-mdf
> > > +      - st,stm32mp23-mdf
> > > +
> > > +  reg:
> > > +    minItems: 1
> > > +    maxItems: 2
> > 
> > This needs an items list here. The size of the regions seems like crap
> > to begin with...
> > 
> > > +
> > > +  clocks:
> > > +    maxItems: 1
> > > +
> > > +  clock-names:
> > > +    description: Internal clock used for MDF digital processing.
> > > +    items:
> > > +      - const: ker_ck
> > 
> > This is pointless when you only have one.
> > 
> 
> I agree that it could be dropped. However, it is useful for using
> devm_regmap_init_mmio_clk.

I don't know what that function is/does, but that's not justification 
for bindings. Maybe you need a helper that handles a single clock. Or 
that function could take a NULL string for single clock? 

> 
> > > +
> > > +  "#clock-cells":
> > > +    enum: [0, 1]
> > 
> > Why is this not fixed? Also why are parts of your own device consuming
> > the clocks?
> > 
> > > +
> > > +  clock-output-names:
> > > +    description: |
> > > +      CCK0 and CCK1 are optional output clocks, which share the same clock frequency,
> > > +      but can be gated independently to save power.
> > > +    minItems: 1
> > > +    maxItems: 2
> > > +    oneOf:
> > > +      - items:
> > > +          - const: cck0
> > > +      - items:
> > > +          - const: cck1
> > > +      - items:
> > > +          - const: cck0
> > > +          - const: cck1
> > > +
> > > +  clock-frequency:
> > > +    description: |
> > > +      Common clock frequency (Hz) for CCK0 and CCK1 output clocks.
> > > +      The frequency must be a multiple of the "ker_ck" clock frequency.
> > > +    maximum: 25000000
> > 
> > Should not be needed, the consumers request what they need.
> > 
> 
> The CCKx clock frequency depends on the maximum rate supported by the sigma
> delta converters (for instance a digital mic) and the expected decimation
> ratio on the bitstream. Typically this determines the frequency on the SPI
> bus.
> This rate is defined statically and shared by the CCKx clocks. So IMHO, as
> this rate is unique, it can look strange to let the consumer define it.
> Moreover, it seems to me that clock-frequency is already used to configure
> the frequency of a provider in some other bindings.
> For instance: Documentation/devicetree/bindings/clock/silabs,si570.yaml
> So, it's not clear for me, what is the restriction on clock-frequency
> property.
> > > +
> > > +  ranges: true
> > > +
> > > +  clock-ranges: true
> > > +
> > > +  resets:
> > > +    maxItems: 1
> > > +
> > > +  reset-names:
> > > +    items:
> > > +      - const: mdf
> > > +
> > > +  access-controllers:
> > > +    $ref: /schemas/types.yaml#/definitions/phandle-array
> > > +    description: |
> > > +      Phandle to the rifsc device to check access right.
> > > +
> > > +  power-domains:
> > > +    maxItems: 1
> > > +
> > > +  st,interleave:
> > > +    description: |
> > > +      List of phandles of interleaved filters. The indexes of interleaved filters must be
> > > +      consecutives starting from 0 (i.e in range [0..N]). The samples from interleaved filters
> > > +      are muxed in a single channel and retrieved through the device associated to the filter 0.
> > > +      The filters 1..N have to be enabled, but inherit their configuration from filter 0.
> > > +    $ref: /schemas/types.yaml#/definitions/phandle-array
> > 
> > No idea what these even are, but this is probably not the right way to
> > represent the relationship between devices. They're apparently ADCs, but
> > this is also an ADC so I'm not sure what's going on here at all.

I don't under it either, but regardless phandle-array needs constraints 
on the items. It's really a matrix with array of phandle+args arrays.

Rob

Re: [PATCH 1/3] dt-bindings: iio: adc: add bindings for stm32 mdf filter

[Olivier MOYSAN]

Hi Rob,

On 10/7/26 15:47, Rob Herring wrote:
> On Wed, Oct 07, 2026 at 11:01:28AM +0200, Olivier MOYSAN wrote:
>> Hi Conor,
>>
>> Thanks for the review
>>
>> On 10/1/26 20:32, Conor Dooley wrote:
>>> On Thu, Oct 01, 2026 at 04:56:45PM +0200, Olivier Moysan wrote:
>>>> Add bindings that describes STM32 MDF settings to support
>>>> digital filtering for Pulse Density Modulation (PDM) microphones
>>>> and analog sigma delta modulators.
>>>>
>>>> Signed-off-by: Olivier Moysan <olivier.moysan@foss.st.com>
>>>> ---
>>>>    .../bindings/iio/adc/st,stm32-mdf-adc.yaml    | 383 ++++++++++++++++++
>>>>    1 file changed, 383 insertions(+)
>>>>    create mode 100644 Documentation/devicetree/bindings/iio/adc/st,stm32-mdf-adc.yaml
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/iio/adc/st,stm32-mdf-adc.yaml b/Documentation/devicetree/bindings/iio/adc/st,stm32-mdf-adc.yaml
>>>> new file mode 100644
>>>> index 000000000000..f2fbc3e150e8
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/iio/adc/st,stm32-mdf-adc.yaml
>>>> @@ -0,0 +1,383 @@
>>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>>>> +%YAML 1.2
>>>> +---
>>>> +$id: http://devicetree.org/schemas/iio/adc/st,stm32-mdf-adc.yaml#
>>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>>>> +
>>>> +title: STMicroelectronics STM32 Multi-function Digital Filter (MDF) ADC
>>>> +
>>>> +maintainers:
>>>> +  - Olivier Moysan <olivier.moysan@foss.st.com>
>>>> +
>>>> +description: |
>>>> +  STM32 MDF ADC is a sigma delta analog-to-digital converter dedicated to
>>>> +  interface external sigma delta modulators to STM32 micro controllers.
>>>> +
>>>> +properties:
>>>> +  compatible:
>>>> +    enum:
>>>> +      - st,stm32mp25-mdf
>>>> +      - st,stm32mp23-mdf
>>>> +
>>>> +  reg:
>>>> +    minItems: 1
>>>> +    maxItems: 2
>>>
>>> This needs an items list here. The size of the regions seems like crap
>>> to begin with...
>>>
>>>> +
>>>> +  clocks:
>>>> +    maxItems: 1
>>>> +
>>>> +  clock-names:
>>>> +    description: Internal clock used for MDF digital processing.
>>>> +    items:
>>>> +      - const: ker_ck
>>>
>>> This is pointless when you only have one.
>>>
>>
>> I agree that it could be dropped. However, it is useful for using
>> devm_regmap_init_mmio_clk.
> 
> I don't know what that function is/does, but that's not justification
> for bindings. Maybe you need a helper that handles a single clock. Or
> that function could take a NULL string for single clock?
> 

Ok. I will drop this clock, and use a helper to replace 
devm_regmap_init_mmio_clk api calls.

>>
>>>> +
>>>> +  "#clock-cells":
>>>> +    enum: [0, 1]
>>>
>>> Why is this not fixed? Also why are parts of your own device consuming
>>> the clocks?
>>>
>>>> +
>>>> +  clock-output-names:
>>>> +    description: |
>>>> +      CCK0 and CCK1 are optional output clocks, which share the same clock frequency,
>>>> +      but can be gated independently to save power.
>>>> +    minItems: 1
>>>> +    maxItems: 2
>>>> +    oneOf:
>>>> +      - items:
>>>> +          - const: cck0
>>>> +      - items:
>>>> +          - const: cck1
>>>> +      - items:
>>>> +          - const: cck0
>>>> +          - const: cck1
>>>> +
>>>> +  clock-frequency:
>>>> +    description: |
>>>> +      Common clock frequency (Hz) for CCK0 and CCK1 output clocks.
>>>> +      The frequency must be a multiple of the "ker_ck" clock frequency.
>>>> +    maximum: 25000000
>>>
>>> Should not be needed, the consumers request what they need.
>>>
>>
>> The CCKx clock frequency depends on the maximum rate supported by the sigma
>> delta converters (for instance a digital mic) and the expected decimation
>> ratio on the bitstream. Typically this determines the frequency on the SPI
>> bus.
>> This rate is defined statically and shared by the CCKx clocks. So IMHO, as
>> this rate is unique, it can look strange to let the consumer define it.
>> Moreover, it seems to me that clock-frequency is already used to configure
>> the frequency of a provider in some other bindings.
>> For instance: Documentation/devicetree/bindings/clock/silabs,si570.yaml
>> So, it's not clear for me, what is the restriction on clock-frequency
>> property.

Would you have any feedback regarding clock-frequency property usage ?

>>>> +
>>>> +  ranges: true
>>>> +
>>>> +  clock-ranges: true
>>>> +
>>>> +  resets:
>>>> +    maxItems: 1
>>>> +
>>>> +  reset-names:
>>>> +    items:
>>>> +      - const: mdf
>>>> +
>>>> +  access-controllers:
>>>> +    $ref: /schemas/types.yaml#/definitions/phandle-array
>>>> +    description: |
>>>> +      Phandle to the rifsc device to check access right.
>>>> +
>>>> +  power-domains:
>>>> +    maxItems: 1
>>>> +
>>>> +  st,interleave:
>>>> +    description: |
>>>> +      List of phandles of interleaved filters. The indexes of interleaved filters must be
>>>> +      consecutives starting from 0 (i.e in range [0..N]). The samples from interleaved filters
>>>> +      are muxed in a single channel and retrieved through the device associated to the filter 0.
>>>> +      The filters 1..N have to be enabled, but inherit their configuration from filter 0.
>>>> +    $ref: /schemas/types.yaml#/definitions/phandle-array
>>>
>>> No idea what these even are, but this is probably not the right way to
>>> represent the relationship between devices. They're apparently ADCs, but
>>> this is also an ADC so I'm not sure what's going on here at all.
> 
> I don't under it either, but regardless phandle-array needs constraints
> on the items. It's really a matrix with array of phandle+args arrays.
> 

What is expected for this property is a list of phandles (from 2 to 8)
For instance: st,interleave = <&filter0 &filter1>;

So, if I just consider the missing constraints, I need to add
     minItems: 2
     maxItems: 8
     items:
       maxItems: 1

Is this correct ?

> Rob

Best regards
Olivier

Re: [PATCH 1/3] dt-bindings: iio: adc: add bindings for stm32 mdf filter

[Conor Dooley]

[-- Attachment #1: Type: text/plain, Size: 20073 bytes --]

On Wed, Oct 07, 2026 at 11:01:28AM +0200, Olivier MOYSAN wrote:
> Hi Conor,
> 
> Thanks for the review
> 
> On 10/1/26 20:32, Conor Dooley wrote:
> > On Thu, Oct 01, 2026 at 04:56:45PM +0200, Olivier Moysan wrote:
> > > Add bindings that describes STM32 MDF settings to support
> > > digital filtering for Pulse Density Modulation (PDM) microphones
> > > and analog sigma delta modulators.
> > > 
> > > Signed-off-by: Olivier Moysan <olivier.moysan@foss.st.com>
> > > ---
> > >   .../bindings/iio/adc/st,stm32-mdf-adc.yaml    | 383 ++++++++++++++++++
> > >   1 file changed, 383 insertions(+)
> > >   create mode 100644 Documentation/devicetree/bindings/iio/adc/st,stm32-mdf-adc.yaml
> > > 
> > > diff --git a/Documentation/devicetree/bindings/iio/adc/st,stm32-mdf-adc.yaml b/Documentation/devicetree/bindings/iio/adc/st,stm32-mdf-adc.yaml
> > > new file mode 100644
> > > index 000000000000..f2fbc3e150e8
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/iio/adc/st,stm32-mdf-adc.yaml
> > > @@ -0,0 +1,383 @@
> > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > > +%YAML 1.2
> > > +---
> > > +$id: http://devicetree.org/schemas/iio/adc/st,stm32-mdf-adc.yaml#
> > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > +
> > > +title: STMicroelectronics STM32 Multi-function Digital Filter (MDF) ADC
> > > +
> > > +maintainers:
> > > +  - Olivier Moysan <olivier.moysan@foss.st.com>
> > > +
> > > +description: |
> > > +  STM32 MDF ADC is a sigma delta analog-to-digital converter dedicated to
> > > +  interface external sigma delta modulators to STM32 micro controllers.
> > > +
> > > +properties:
> > > +  compatible:
> > > +    enum:
> > > +      - st,stm32mp25-mdf
> > > +      - st,stm32mp23-mdf
> > > +
> > > +  reg:
> > > +    minItems: 1
> > > +    maxItems: 2
> > 
> > This needs an items list here. The size of the regions seems like crap
> > to begin with...
> > 
> > > +
> > > +  clocks:
> > > +    maxItems: 1
> > > +
> > > +  clock-names:
> > > +    description: Internal clock used for MDF digital processing.
> > > +    items:
> > > +      - const: ker_ck
> > 
> > This is pointless when you only have one.
> > 
> 
> I agree that it could be dropped. However, it is useful for using
> devm_regmap_init_mmio_clk.

Ah, because that function if you pass NULL to it, it doesn't mean no
string, it means no clock.

> 
> > > +
> > > +  "#clock-cells":
> > > +    enum: [0, 1]
> > 
> > Why is this not fixed? Also why are parts of your own device consuming
> > the clocks?

Reading the docs, this has to be 1, you have two clocks?

Not sure why you skipped this and skipped explaining why you are
consuming your own clocks.

> > > +  clock-output-names:
> > > +    description: |
> > > +      CCK0 and CCK1 are optional output clocks, which share the same clock frequency,
> > > +      but can be gated independently to save power.
> > > +    minItems: 1
> > > +    maxItems: 2
> > > +    oneOf:
> > > +      - items:
> > > +          - const: cck0
> > > +      - items:
> > > +          - const: cck1
> > > +      - items:
> > > +          - const: cck0
> > > +          - const: cck1
> > > +
> > > +  clock-frequency:
> > > +    description: |
> > > +      Common clock frequency (Hz) for CCK0 and CCK1 output clocks.
> > > +      The frequency must be a multiple of the "ker_ck" clock frequency.
> > > +    maximum: 25000000
> > 
> > Should not be needed, the consumers request what they need.
> > 
> 
> The CCKx clock frequency depends on the maximum rate supported by the sigma
> delta converters (for instance a digital mic) and the expected decimation
> ratio on the bitstream. Typically this determines the frequency on the SPI
> bus.
> This rate is defined statically and shared by the CCKx clocks. So IMHO, as
> this rate is unique, it can look strange to let the consumer define it.
> Moreover, it seems to me that clock-frequency is already used to configure
> the frequency of a provider in some other bindings.
> For instance: Documentation/devicetree/bindings/clock/silabs,si570.yaml

This is a binding from the age of antiquity, using it to justify your
use is actually harming your argument rather than helping. Your clock
consumers should be providing the information about what the rate should
be, and if you need to do this in dt you can use assigned-clock-rates.

> So, it's not clear for me, what is the restriction on clock-frequency
> property.
> > > +
> > > +  ranges: true
> > > +
> > > +  clock-ranges: true
> > > +
> > > +  resets:
> > > +    maxItems: 1
> > > +
> > > +  reset-names:
> > > +    items:
> > > +      - const: mdf

Same applies here as to the clock names fwiw.

> > > +
> > > +  access-controllers:
> > > +    $ref: /schemas/types.yaml#/definitions/phandle-array
> > > +    description: |
> > > +      Phandle to the rifsc device to check access right.
> > > +
> > > +  power-domains:
> > > +    maxItems: 1
> > > +
> > > +  st,interleave:
> > > +    description: |
> > > +      List of phandles of interleaved filters. The indexes of interleaved filters must be
> > > +      consecutives starting from 0 (i.e in range [0..N]). The samples from interleaved filters
> > > +      are muxed in a single channel and retrieved through the device associated to the filter 0.
> > > +      The filters 1..N have to be enabled, but inherit their configuration from filter 0.
> > > +    $ref: /schemas/types.yaml#/definitions/phandle-array
> > 
> > No idea what these even are, but this is probably not the right way to
> > represent the relationship between devices. They're apparently ADCs, but
> > this is also an ADC so I'm not sure what's going on here at all.

Yeah, after more thought this should not be done like this at all,
especially if these filters the phandle point to are part of this device
itself, which I suspect they are. If that's the case, you don't need
phandles to even do this, you just need an int that says what N is.

> > 
> > > +
> > > +required:
> > > +  - compatible
> > > +  - reg
> > > +  - ranges
> > > +  - clocks
> > > +  - clock-names
> > > +  - clock-ranges
> > > +  - "#address-cells"
> > > +  - "#size-cells"
> > > +
> > > +additionalProperties: false
> > > +
> > > +patternProperties:
> > > +  "^sitf@[0-9]+$":
> > > +    type: object
> > > +    description: Serial interface child node
> > 
> > Why is this a child node at all?
> > Probably not worth reviewing more without a link to the docs for this
> > device so I can figure out what on earth is going on!
> > 
> 
> The MDF is a digital filter for sigma-delta bitstreams, rather than the
> analog-to-digital converter itself.
> 
> Here is the link to STM32MP25 reference manuel
> https://www.st.com/resource/en/reference_manual/rm0457-stm32mp2325xx-advanced-armbased-3264bit-mpus-stmicroelectronics.pdf
> Chapter 45: Multi-function digital filter (MDF)
> 
> On STMP32MP25 SoC, the MDF provides 8 serial interfaces (SITF) and 8 digital
> filters (DFLT) which can be connected through a multiplexer.
> 
> Below is a schematic view of typical applications targeted by this
> peripheral
> 
> 
> Audio use case:
> 
> 		mdf
>             +-------------------------------------+
> +------+    | +------+    +------+    +------+    |
> | dmic | -> | | sitf | -> | mux  | -> | dflt | -- | -> audio device
> +------+    | +------+    +------+    +------+    |
>             +-------------------------------------+
> 
> For instance, in an audio use case the serial interface can be configured to
> provide the clock to the digital microphone (cck0, cck1 or both) at a common
> predefined rate, and to retrieve the PDM samples.
> The serial interface provides this samples to a digital filter, which
> delivers PCM samples on its output.
> 
> 
> Analog use case:
> 
> 		mdf
>               +-------------------------------------+
> +--------+    | +------+    +------+    +------+    |
> | sd adc | -> | | sitf | -> | mux  | -> | dflt | -- | -> iio device
> +--------+    | +------+    +------+    +------+    |
>               +-------------------------------------+


So, looking at the docs and a brief chat with Jonathan about this
device, I believe you've got things backwards and this is actually the backend,
and the adc should be the one populating the io-backends property
pointing to this device. You should have io-backend-cells, and I assume
that there should be a cell for the adc to select which dlft it is connected
to.

I think all of these child nodes should just get deleted - all your
devices here seem completely fake, since you've got stuff that's only a
single word wide. With that, you could also throw away these mickey
mouse nodes with sound-dai-cels of 0, and use 1 instead, with that cell
again determining which dlft is in use.

The only child node I can really thing of any justification for here is
channels - albeit not adc channels since this is not an adc - so that
you can individually configure a dlft using those channel nodes.

These serial inputs, what is the source for the data that is ever
actually sent there? I am assuming it's effectively another IIO device,
just not the onboard adc? Are the outputs exposed on pins on the
package?

I would encourage you to remodel this system, where this device is the
backend and also try to get rid of as much of the consuming your own
clock as possible. Certainly consuming ker_clk should never be required.
It's hard to reason about what should happen with the serial interface
clocks, when I have no idea what the input/data source device actually
is in those cases. Being a clock controller does make sense, because the
device exposes CCK0/1 to the outside world, it's the internal routing to
the SITF blocks that I am not sure how to deal with. A ouroboros device
that is consuming a clock it provides is not really a done thing,
hopefully the IIO guys can tell you how these kinds of things are
typically done here, since I'm sure there's plenty of other devices
that have some sort of ability to change the clock source for a channel.

Probably you need to add two optional input clocks to this device, since
mdf_cck0/1 can be inputs too?

Let me know if any of this feedback is intractable stuff, and maybe hang
on for someone like David or Jonathan to provide some review before
going about a significant rework. It's worth bearing in mind that I am a
binding reviewer and not a domain expert in ADCs etc.

Thanks,
Conor.

> > > +
> > > +    properties:
> > > +      compatible:
> > > +        enum:
> > > +          - st,stm32mp25-sitf-mdf
> > > +
> > > +      reg:
> > > +        description: Specify the SITF serial interface instance
> > > +        maxItems: 1
> > > +
> > > +      clocks:
> > > +        description: |
> > > +          Serial interface clock (optional depending on interface mode)
> > > +        maxItems: 1
> > > +
> > > +      st,sitf-mode:
> > > +        description: |
> > > +          Select serial interface protocol
> > > +          - spi: SPI mode
> > > +          - lf_spi: low frequency SPI mode for low power applications
> > > +        $ref: /schemas/types.yaml#/definitions/string
> > > +        enum:
> > > +          - spi
> > > +          - lf_spi
> > > +
> > > +    required:
> > > +      - reg
> > > +      - st,sitf-mode
> > > +
> > > +    additionalProperties: false
> > > +
> > > +  "^filter@[0-9]+$":
> > > +    type: object
> > > +    description: Digital filter path child node
> > > +
> > > +    properties:
> > > +      compatible:
> > > +        enum:
> > > +          - st,stm32mp25-mdf-dmic
> > > +          - st,stm32mp25-mdf-adc
> > > +
> > > +      reg:
> > > +        description: Specify the MDF filter instance
> > > +        maxItems: 1
> > > +
> > > +      interrupts:
> > > +        maxItems: 1
> > > +
> > > +      clocks:
> > > +        minItems: 1
> > > +        description: Internal clock used for MDF digital processing and control blocks.
> > > +
> > > +      clock-names:
> > > +        items:
> > > +          - const: ker_ck
> > > +
> > > +      dmas:
> > > +        maxItems: 1
> > > +
> > > +      dma-names:
> > > +        items:
> > > +          - const: rx
> > > +
> > > +      "#io-channel-cells":
> > > +        const: 1
> > > +
> > > +      '#address-cells':
> > > +        const: 1
> > > +
> > > +      '#size-cells':
> > > +        const: 0
> > > +
> > > +      st,cic-mode:
> > > +        description: |
> > > +          Cascaded-integrator-comb (CIC) filter configuration
> > > +          - 0: MCIC & ACIC filters in FastSinc mode
> > > +          - [1-3]: MCIC & ACIC filters in Sinc mode order 1 to 3
> > > +          - [4-5]: Single CIC filter in Sinc mode order 4 to 5
> > > +          For audio purpose it is recommended to use CIC Sinc4 or Sinc5
> > > +          This property is mandatory for filter 0 or filters not used in interleave mode.
> > > +        $ref: /schemas/types.yaml#/definitions/uint32
> > > +        minimum: 0
> > > +        maximum: 5
> > > +
> > > +      st,delay:
> > > +        description: Filter delay in samples
> > > +        $ref: /schemas/types.yaml#/definitions/uint32
> > > +        maximum: 127
> > > +
> > > +      st,rs-filter-bypass:
> > > +        description: Bypass RSFLT reshaping filter.
> > > +        $ref: /schemas/types.yaml#/definitions/flag
> > > +
> > > +      st,hpf-filter-cutoff-bp:
> > > +        description: |
> > > +          High Pass Filter (HPF) cut-off frequency expressed as a fraction of the PCM sampling rate.
> > > +          Cut-off frequency = st,hpf-filter-cutoff-bp x Fpcm / 10000.
> > > +          If this property is not defined the HPF is disabled.
> > > +        enum: [625, 1250, 2500, 9500]
> > > +
> > > +      st,sync:
> > > +        description:
> > > +          Synchronize to another filter.
> > > +          Must contain the phandle of the filter providing the synchronization.
> > > +        allOf:
> > > +          - $ref: /schemas/types.yaml#/definitions/phandle-array
> > > +          - maxItems: 1
> > > +
> > > +      st,sitf:
> > > +        $ref: /schemas/types.yaml#/definitions/phandle-array
> > > +        items:
> > > +          - items:
> > > +              - description: Phandle of the serial interface connected to the digital filter
> > > +              - description: |
> > > +                  The phandle's argument selects the bitstream on the falling or rising edge
> > > +                  of the serial interface clock:
> > > +                  - 0: rising edge
> > > +                  - 1: falling edge
> > > +                enum: [0, 1]
> > > +                default: 0
> > > +        description:
> > > +          Should be phandle/bitstream pair.
> > > +
> > > +    required:
> > > +      - compatible
> > > +      - reg
> > > +      - interrupts
> > > +      - dmas
> > > +      - dma-names
> > > +      - "#io-channel-cells"
> > > +      - "#address-cells"
> > > +      - "#size-cells"
> > > +      - st,sitf
> > > +
> > > +    unevaluatedProperties: false
> > > +
> > > +    patternProperties:
> > > +      "^channel@([0-7])$":
> > > +        type: object
> > > +        $ref: adc.yaml
> > > +        description: Represents the external channel which is connected to the MDF.
> > > +
> > > +        properties:
> > > +          reg:
> > > +            maximum: 7
> > > +
> > > +          io-backends:
> > > +            description:
> > > +              Used to pipe external sigma delta modulator or internal ADC backend to MDF
> > > +              channel.
> > > +            maxItems: 1

> > > +
> > > +        required:
> > > +          - reg
> > > +
> > > +        unevaluatedProperties: false
> > > +
> > > +    allOf:
> > > +      - if:
> > > +          properties:
> > > +            compatible:
> > > +              contains:
> > > +                const: st,stm32mp25-mdf-adc
> > > +
> > > +        then:
> > > +          patternProperties:
> > > +            "^channel@[0-7]$":
> > > +              required:
> > > +                - io-backends
> > > +
> > > +      - if:
> > > +          properties:
> > > +            compatible:
> > > +              contains:
> > > +                const: st,stm32mp25-mdf-dmic
> > > +
> > > +        then:
> > > +          patternProperties:
> > > +            "^mdf-dai+$":
> > > +              type: object
> > > +              description: child node
> > > +
> > > +              properties:
> > > +                compatible:
> > > +                  enum:
> > > +                    - st,stm32mp25-mdf-dai
> > > +
> > > +                "#sound-dai-cells":
> > > +                  const: 0
> > > +
> > > +                io-channels:
> > > +                  description:
> > > +                    From common IIO binding. Used to pipe external sigma delta
> > > +                    modulator or internal ADC output to MDF channel.
> > > +
> > > +                power-domains:
> > > +                  maxItems: 1
> > > +
> > > +                port:
> > > +                  $ref: /schemas/sound/audio-graph-port.yaml#
> > > +                  unevaluatedProperties: false
> > > +
> > > +              required:
> > > +                - compatible
> > > +                - "#sound-dai-cells"
> > > +                - io-channels
> > > +
> > > +              additionalProperties: false
> > > +
> > > +examples:
> > > +  - |
> > > +    #include <dt-bindings/clock/st,stm32mp25-rcc.h>
> > > +    #include <dt-bindings/interrupt-controller/arm-gic.h>
> > > +    mdf1: mdf@504d0000 {
> > > +      compatible = "st,stm32mp25-mdf";
> > > +      ranges = <0 0x504d0000 0x1000>;
> > > +      reg = <0x504d0000 0x8>, <0x504d0ff0 0x10>;
> > > +      #address-cells = <1>;
> > > +      #size-cells = <1>;
> > > +      clocks = <&rcc CK_KER_MDF1>;
> > > +      clock-names = "ker_ck";
> > > +      clock-ranges;
> > > +      #clock-cells = <1>;
> > > +      clock-output-names = "cck0", "cck1";
> > > +      clock-frequency = <2048000>;
> > > +
> > > +      sitf5: sitf@300 {
> > > +        compatible = "st,stm32mp25-sitf-mdf";
> > > +        reg = <0x300 0x4>;
> > > +        st,sitf-mode = "spi";
> > > +        clocks = <&mdf1 0>;
> > > +      };
> > > +
> > > +      filter0: filter@84 {
> > > +        compatible = "st,stm32mp25-mdf-dmic";
> > > +        reg = <0x84 0x70>;
> > > +        #io-channel-cells = <1>;
> > > +        interrupts = <GIC_SPI 184 IRQ_TYPE_LEVEL_HIGH>;
> > > +        dmas = <&hpdma 63 0x63 0x12 0>;
> > > +        dma-names = "rx";
> > > +        st,cic-mode = <5>;
> > > +        st,sitf = <&sitf5 0>;
> > > +        #address-cells = <1>;
> > > +        #size-cells = <0>;
> > > +
> > > +        channel@0 {
> > > +          reg = <0>;
> > > +        };
> > > +
> > > +        asoc_pdm0: mdf-dai {
> > > +          compatible = "st,stm32mp25-mdf-dai";
> > > +          #sound-dai-cells = <0>;
> > > +          io-channels = <&filter0 0>;
> > > +        };
> > > +      };
> > > +
> > > +      filter1: filter@104  {
> > > +        compatible = "st,stm32mp25-mdf-adc";
> > > +        reg = <0x104 0x70>;
> > > +        #io-channel-cells = <1>;
> > > +        interrupts = <GIC_SPI 185 IRQ_TYPE_LEVEL_HIGH>;
> > > +        dmas = <&hpdma 64 0x63 0x12 0>;
> > > +        dma-names = "rx";
> > > +        st,cic-mode = <2>;
> > > +        st,sitf = <&sitf5 1>;
> > > +        #address-cells = <1>;
> > > +        #size-cells = <0>;
> > > +
> > > +        channel@1 {
> > > +          reg = <1>;
> > > +          settling-time-us = <1000>;
> > > +          io-backends = <&sd_adc1>;
> > > +        };
> > > +      };
> > > +    };
> > > +
> > > +...
> > > -- 
> > > 2.43.0
> > > 
> 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH 1/3] dt-bindings: iio: adc: add bindings for stm32 mdf filter

[Olivier MOYSAN]

Hi Conor,

On 10/8/26 12:11, Conor Dooley wrote:
> On Wed, Oct 07, 2026 at 11:01:28AM +0200, Olivier MOYSAN wrote:
>> Hi Conor,
>>
>> Thanks for the review
>>
>> On 10/1/26 20:32, Conor Dooley wrote:
>>> On Thu, Oct 01, 2026 at 04:56:45PM +0200, Olivier Moysan wrote:
>>>> Add bindings that describes STM32 MDF settings to support
>>>> digital filtering for Pulse Density Modulation (PDM) microphones
>>>> and analog sigma delta modulators.
>>>>
>>>> Signed-off-by: Olivier Moysan <olivier.moysan@foss.st.com>
>>>> ---
>>>>    .../bindings/iio/adc/st,stm32-mdf-adc.yaml    | 383 ++++++++++++++++++
>>>>    1 file changed, 383 insertions(+)
>>>>    create mode 100644 Documentation/devicetree/bindings/iio/adc/st,stm32-mdf-adc.yaml
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/iio/adc/st,stm32-mdf-adc.yaml b/Documentation/devicetree/bindings/iio/adc/st,stm32-mdf-adc.yaml
>>>> new file mode 100644
>>>> index 000000000000..f2fbc3e150e8
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/iio/adc/st,stm32-mdf-adc.yaml
>>>> @@ -0,0 +1,383 @@
>>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>>>> +%YAML 1.2
>>>> +---
>>>> +$id: http://devicetree.org/schemas/iio/adc/st,stm32-mdf-adc.yaml#
>>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>>>> +
>>>> +title: STMicroelectronics STM32 Multi-function Digital Filter (MDF) ADC
>>>> +
>>>> +maintainers:
>>>> +  - Olivier Moysan <olivier.moysan@foss.st.com>
>>>> +
>>>> +description: |
>>>> +  STM32 MDF ADC is a sigma delta analog-to-digital converter dedicated to
>>>> +  interface external sigma delta modulators to STM32 micro controllers.
>>>> +
>>>> +properties:
>>>> +  compatible:
>>>> +    enum:
>>>> +      - st,stm32mp25-mdf
>>>> +      - st,stm32mp23-mdf
>>>> +
>>>> +  reg:
>>>> +    minItems: 1
>>>> +    maxItems: 2
>>>
>>> This needs an items list here. The size of the regions seems like crap
>>> to begin with...
>>>
>>>> +
>>>> +  clocks:
>>>> +    maxItems: 1
>>>> +
>>>> +  clock-names:
>>>> +    description: Internal clock used for MDF digital processing.
>>>> +    items:
>>>> +      - const: ker_ck
>>>
>>> This is pointless when you only have one.
>>>
>>
>> I agree that it could be dropped. However, it is useful for using
>> devm_regmap_init_mmio_clk.
> 
> Ah, because that function if you pass NULL to it, it doesn't mean no
> string, it means no clock.
> 

The MDF has two clocks (AHB clock for register accesses and ker_ck for 
peripheral processing). However, these two clocks share the same gate. 
So, only the ker_ck clock is exposed in the driver.
The regmap api is a convenient way to manage registers and gate the AHB 
clock only on register accesses. Removing clock-names no longer allows 
you to benefit from clock management handled by the regmap framework, 
and means that this must be managed explicitly, partially or entirely, 
in the driver.

>>
>>>> +
>>>> +  "#clock-cells":
>>>> +    enum: [0, 1]
>>>
>>> Why is this not fixed? Also why are parts of your own device consuming
>>> the clocks?
> 
> Reading the docs, this has to be 1, you have two clocks?
> 
> Not sure why you skipped this and skipped explaining why you are
> consuming your own clocks.
> 

Yes, we can have two clocks gated independently but sharing the same rate.

Using the clock framework apis seemed to me the right way to manage cck1 
and cck0 gating and divider computing. I think I would have to introduce 
proprietary properties and have to implement code in the driver, that 
would be handled natively by the framework otherwise.

>>>> +  clock-output-names:
>>>> +    description: |
>>>> +      CCK0 and CCK1 are optional output clocks, which share the same clock frequency,
>>>> +      but can be gated independently to save power.
>>>> +    minItems: 1
>>>> +    maxItems: 2
>>>> +    oneOf:
>>>> +      - items:
>>>> +          - const: cck0
>>>> +      - items:
>>>> +          - const: cck1
>>>> +      - items:
>>>> +          - const: cck0
>>>> +          - const: cck1
>>>> +
>>>> +  clock-frequency:
>>>> +    description: |
>>>> +      Common clock frequency (Hz) for CCK0 and CCK1 output clocks.
>>>> +      The frequency must be a multiple of the "ker_ck" clock frequency.
>>>> +    maximum: 25000000
>>>
>>> Should not be needed, the consumers request what they need.
>>>
>>
>> The CCKx clock frequency depends on the maximum rate supported by the sigma
>> delta converters (for instance a digital mic) and the expected decimation
>> ratio on the bitstream. Typically this determines the frequency on the SPI
>> bus.
>> This rate is defined statically and shared by the CCKx clocks. So IMHO, as
>> this rate is unique, it can look strange to let the consumer define it.
>> Moreover, it seems to me that clock-frequency is already used to configure
>> the frequency of a provider in some other bindings.
>> For instance: Documentation/devicetree/bindings/clock/silabs,si570.yaml
> 
> This is a binding from the age of antiquity, using it to justify your
> use is actually harming your argument rather than helping. Your clock
> consumers should be providing the information about what the rate should
> be, and if you need to do this in dt you can use assigned-clock-rates.
> 

ok, I will move this to clock consumer with assigned-clock properties.

>> So, it's not clear for me, what is the restriction on clock-frequency
>> property.
>>>> +
>>>> +  ranges: true
>>>> +
>>>> +  clock-ranges: true
>>>> +
>>>> +  resets:
>>>> +    maxItems: 1
>>>> +
>>>> +  reset-names:
>>>> +    items:
>>>> +      - const: mdf
> 
> Same applies here as to the clock names fwiw.
> 

Yes, I removed this.

>>>> +
>>>> +  access-controllers:
>>>> +    $ref: /schemas/types.yaml#/definitions/phandle-array
>>>> +    description: |
>>>> +      Phandle to the rifsc device to check access right.
>>>> +
>>>> +  power-domains:
>>>> +    maxItems: 1
>>>> +
>>>> +  st,interleave:
>>>> +    description: |
>>>> +      List of phandles of interleaved filters. The indexes of interleaved filters must be
>>>> +      consecutives starting from 0 (i.e in range [0..N]). The samples from interleaved filters
>>>> +      are muxed in a single channel and retrieved through the device associated to the filter 0.
>>>> +      The filters 1..N have to be enabled, but inherit their configuration from filter 0.
>>>> +    $ref: /schemas/types.yaml#/definitions/phandle-array
>>>
>>> No idea what these even are, but this is probably not the right way to
>>> represent the relationship between devices. They're apparently ADCs, but
>>> this is also an ADC so I'm not sure what's going on here at all.
> 
> Yeah, after more thought this should not be done like this at all,
> especially if these filters the phandle point to are part of this device
> itself, which I suspect they are. If that's the case, you don't need
> phandles to even do this, you just need an int that says what N is.
> 

Yes, can be an index as it is an internal reference. I will change this.

>>>
>>>> +
>>>> +required:
>>>> +  - compatible
>>>> +  - reg
>>>> +  - ranges
>>>> +  - clocks
>>>> +  - clock-names
>>>> +  - clock-ranges
>>>> +  - "#address-cells"
>>>> +  - "#size-cells"
>>>> +
>>>> +additionalProperties: false
>>>> +
>>>> +patternProperties:
>>>> +  "^sitf@[0-9]+$":
>>>> +    type: object
>>>> +    description: Serial interface child node
>>>
>>> Why is this a child node at all?
>>> Probably not worth reviewing more without a link to the docs for this
>>> device so I can figure out what on earth is going on!
>>>
>>
>> The MDF is a digital filter for sigma-delta bitstreams, rather than the
>> analog-to-digital converter itself.
>>
>> Here is the link to STM32MP25 reference manuel
>> https://www.st.com/resource/en/reference_manual/rm0457-stm32mp2325xx-advanced-armbased-3264bit-mpus-stmicroelectronics.pdf
>> Chapter 45: Multi-function digital filter (MDF)
>>
>> On STMP32MP25 SoC, the MDF provides 8 serial interfaces (SITF) and 8 digital
>> filters (DFLT) which can be connected through a multiplexer.
>>
>> Below is a schematic view of typical applications targeted by this
>> peripheral
>>
>>
>> Audio use case:
>>
>> 		mdf
>>              +-------------------------------------+
>> +------+    | +------+    +------+    +------+    |
>> | dmic | -> | | sitf | -> | mux  | -> | dflt | -- | -> audio device
>> +------+    | +------+    +------+    +------+    |
>>              +-------------------------------------+
>>
>> For instance, in an audio use case the serial interface can be configured to
>> provide the clock to the digital microphone (cck0, cck1 or both) at a common
>> predefined rate, and to retrieve the PDM samples.
>> The serial interface provides this samples to a digital filter, which
>> delivers PCM samples on its output.
>>
>>
>> Analog use case:
>>
>> 		mdf
>>                +-------------------------------------+
>> +--------+    | +------+    +------+    +------+    |
>> | sd adc | -> | | sitf | -> | mux  | -> | dflt | -- | -> iio device
>> +--------+    | +------+    +------+    +------+    |
>>                +-------------------------------------+
> 
> 
> So, looking at the docs and a brief chat with Jonathan about this
> device, I believe you've got things backwards and this is actually the backend,
> and the adc should be the one populating the io-backends property
> pointing to this device. You should have io-backend-cells, and I assume
> that there should be a cell for the adc to select which dlft it is connected
> to.
> 

There have already been lengthy discussions in the past about a DFSDM 
peripheral on STM32MP1, which has features similar to those of the MDF 
and similar implementation constraints. For the DFSDM, a solution based 
on an IIO backend had been upstreamed. The MDF follows the same 
architecture. I need to take a little time to dive back into this issue.

DFSDM sources:
drivers/iio/adc/stm32-dfsdm-adc.c
drivers/iio/adc/stm32-dfsdm-core.c

Here is a sample of DFSDM DT

sd_adc0: simple-sd-adc0 {
	compatible = "sd-modulator";
	#io-backend-cells = <0>;
	vref-supply = <&v3v3>;
};

dfsdm0 {
	compatible = "st,stm32-dfsdm-adc";
	...

	channel@0 {
		reg = <0>;
		label = "in0";
		...
		io-backends = <&sd_adc0>;
	};		
};

> I think all of these child nodes should just get deleted - all your
> devices here seem completely fake, since you've got stuff that's only a
> single word wide. With that, you could also throw away these mickey
> mouse nodes with sound-dai-cels of 0, and use 1 instead, with that cell
> again determining which dlft is in use.
> 
> The only child node I can really thing of any justification for here is
> channels - albeit not adc channels since this is not an adc - so that
> you can individually configure a dlft using those channel nodes.
> 
> These serial inputs, what is the source for the data that is ever
> actually sent there? I am assuming it's effectively another IIO device,
> just not the onboard adc? Are the outputs exposed on pins on the
> package?
> 
> I would encourage you to remodel this system, where this device is the
> backend and also try to get rid of as much of the consuming your own
> clock as possible. Certainly consuming ker_clk should never be required.
> It's hard to reason about what should happen with the serial interface
> clocks, when I have no idea what the input/data source device actually
> is in those cases. Being a clock controller does make sense, because the
> device exposes CCK0/1 to the outside world, it's the internal routing to
> the SITF blocks that I am not sure how to deal with. A ouroboros device
> that is consuming a clock it provides is not really a done thing,
> hopefully the IIO guys can tell you how these kinds of things are
> typically done here, since I'm sure there's plenty of other devices
> that have some sort of ability to change the clock source for a channel.
> 
> Probably you need to add two optional input clocks to this device, since
> mdf_cck0/1 can be inputs too?
> 
> Let me know if any of this feedback is intractable stuff, and maybe hang
> on for someone like David or Jonathan to provide some review before
> going about a significant rework. It's worth bearing in mind that I am a
> binding reviewer and not a domain expert in ADCs etc.
> 
> Thanks,
> Conor.
> 

Best regards
Olivier

>>>> +
>>>> +    properties:
>>>> +      compatible:
>>>> +        enum:
>>>> +          - st,stm32mp25-sitf-mdf
>>>> +
>>>> +      reg:
>>>> +        description: Specify the SITF serial interface instance
>>>> +        maxItems: 1
>>>> +
>>>> +      clocks:
>>>> +        description: |
>>>> +          Serial interface clock (optional depending on interface mode)
>>>> +        maxItems: 1
>>>> +
>>>> +      st,sitf-mode:
>>>> +        description: |
>>>> +          Select serial interface protocol
>>>> +          - spi: SPI mode
>>>> +          - lf_spi: low frequency SPI mode for low power applications
>>>> +        $ref: /schemas/types.yaml#/definitions/string
>>>> +        enum:
>>>> +          - spi
>>>> +          - lf_spi
>>>> +
>>>> +    required:
>>>> +      - reg
>>>> +      - st,sitf-mode
>>>> +
>>>> +    additionalProperties: false
>>>> +
>>>> +  "^filter@[0-9]+$":
>>>> +    type: object
>>>> +    description: Digital filter path child node
>>>> +
>>>> +    properties:
>>>> +      compatible:
>>>> +        enum:
>>>> +          - st,stm32mp25-mdf-dmic
>>>> +          - st,stm32mp25-mdf-adc
>>>> +
>>>> +      reg:
>>>> +        description: Specify the MDF filter instance
>>>> +        maxItems: 1
>>>> +
>>>> +      interrupts:
>>>> +        maxItems: 1
>>>> +
>>>> +      clocks:
>>>> +        minItems: 1
>>>> +        description: Internal clock used for MDF digital processing and control blocks.
>>>> +
>>>> +      clock-names:
>>>> +        items:
>>>> +          - const: ker_ck
>>>> +
>>>> +      dmas:
>>>> +        maxItems: 1
>>>> +
>>>> +      dma-names:
>>>> +        items:
>>>> +          - const: rx
>>>> +
>>>> +      "#io-channel-cells":
>>>> +        const: 1
>>>> +
>>>> +      '#address-cells':
>>>> +        const: 1
>>>> +
>>>> +      '#size-cells':
>>>> +        const: 0
>>>> +
>>>> +      st,cic-mode:
>>>> +        description: |
>>>> +          Cascaded-integrator-comb (CIC) filter configuration
>>>> +          - 0: MCIC & ACIC filters in FastSinc mode
>>>> +          - [1-3]: MCIC & ACIC filters in Sinc mode order 1 to 3
>>>> +          - [4-5]: Single CIC filter in Sinc mode order 4 to 5
>>>> +          For audio purpose it is recommended to use CIC Sinc4 or Sinc5
>>>> +          This property is mandatory for filter 0 or filters not used in interleave mode.
>>>> +        $ref: /schemas/types.yaml#/definitions/uint32
>>>> +        minimum: 0
>>>> +        maximum: 5
>>>> +
>>>> +      st,delay:
>>>> +        description: Filter delay in samples
>>>> +        $ref: /schemas/types.yaml#/definitions/uint32
>>>> +        maximum: 127
>>>> +
>>>> +      st,rs-filter-bypass:
>>>> +        description: Bypass RSFLT reshaping filter.
>>>> +        $ref: /schemas/types.yaml#/definitions/flag
>>>> +
>>>> +      st,hpf-filter-cutoff-bp:
>>>> +        description: |
>>>> +          High Pass Filter (HPF) cut-off frequency expressed as a fraction of the PCM sampling rate.
>>>> +          Cut-off frequency = st,hpf-filter-cutoff-bp x Fpcm / 10000.
>>>> +          If this property is not defined the HPF is disabled.
>>>> +        enum: [625, 1250, 2500, 9500]
>>>> +
>>>> +      st,sync:
>>>> +        description:
>>>> +          Synchronize to another filter.
>>>> +          Must contain the phandle of the filter providing the synchronization.
>>>> +        allOf:
>>>> +          - $ref: /schemas/types.yaml#/definitions/phandle-array
>>>> +          - maxItems: 1
>>>> +
>>>> +      st,sitf:
>>>> +        $ref: /schemas/types.yaml#/definitions/phandle-array
>>>> +        items:
>>>> +          - items:
>>>> +              - description: Phandle of the serial interface connected to the digital filter
>>>> +              - description: |
>>>> +                  The phandle's argument selects the bitstream on the falling or rising edge
>>>> +                  of the serial interface clock:
>>>> +                  - 0: rising edge
>>>> +                  - 1: falling edge
>>>> +                enum: [0, 1]
>>>> +                default: 0
>>>> +        description:
>>>> +          Should be phandle/bitstream pair.
>>>> +
>>>> +    required:
>>>> +      - compatible
>>>> +      - reg
>>>> +      - interrupts
>>>> +      - dmas
>>>> +      - dma-names
>>>> +      - "#io-channel-cells"
>>>> +      - "#address-cells"
>>>> +      - "#size-cells"
>>>> +      - st,sitf
>>>> +
>>>> +    unevaluatedProperties: false
>>>> +
>>>> +    patternProperties:
>>>> +      "^channel@([0-7])$":
>>>> +        type: object
>>>> +        $ref: adc.yaml
>>>> +        description: Represents the external channel which is connected to the MDF.
>>>> +
>>>> +        properties:
>>>> +          reg:
>>>> +            maximum: 7
>>>> +
>>>> +          io-backends:
>>>> +            description:
>>>> +              Used to pipe external sigma delta modulator or internal ADC backend to MDF
>>>> +              channel.
>>>> +            maxItems: 1
> 
>>>> +
>>>> +        required:
>>>> +          - reg
>>>> +
>>>> +        unevaluatedProperties: false
>>>> +
>>>> +    allOf:
>>>> +      - if:
>>>> +          properties:
>>>> +            compatible:
>>>> +              contains:
>>>> +                const: st,stm32mp25-mdf-adc
>>>> +
>>>> +        then:
>>>> +          patternProperties:
>>>> +            "^channel@[0-7]$":
>>>> +              required:
>>>> +                - io-backends
>>>> +
>>>> +      - if:
>>>> +          properties:
>>>> +            compatible:
>>>> +              contains:
>>>> +                const: st,stm32mp25-mdf-dmic
>>>> +
>>>> +        then:
>>>> +          patternProperties:
>>>> +            "^mdf-dai+$":
>>>> +              type: object
>>>> +              description: child node
>>>> +
>>>> +              properties:
>>>> +                compatible:
>>>> +                  enum:
>>>> +                    - st,stm32mp25-mdf-dai
>>>> +
>>>> +                "#sound-dai-cells":
>>>> +                  const: 0
>>>> +
>>>> +                io-channels:
>>>> +                  description:
>>>> +                    From common IIO binding. Used to pipe external sigma delta
>>>> +                    modulator or internal ADC output to MDF channel.
>>>> +
>>>> +                power-domains:
>>>> +                  maxItems: 1
>>>> +
>>>> +                port:
>>>> +                  $ref: /schemas/sound/audio-graph-port.yaml#
>>>> +                  unevaluatedProperties: false
>>>> +
>>>> +              required:
>>>> +                - compatible
>>>> +                - "#sound-dai-cells"
>>>> +                - io-channels
>>>> +
>>>> +              additionalProperties: false
>>>> +
>>>> +examples:
>>>> +  - |
>>>> +    #include <dt-bindings/clock/st,stm32mp25-rcc.h>
>>>> +    #include <dt-bindings/interrupt-controller/arm-gic.h>
>>>> +    mdf1: mdf@504d0000 {
>>>> +      compatible = "st,stm32mp25-mdf";
>>>> +      ranges = <0 0x504d0000 0x1000>;
>>>> +      reg = <0x504d0000 0x8>, <0x504d0ff0 0x10>;
>>>> +      #address-cells = <1>;
>>>> +      #size-cells = <1>;
>>>> +      clocks = <&rcc CK_KER_MDF1>;
>>>> +      clock-names = "ker_ck";
>>>> +      clock-ranges;
>>>> +      #clock-cells = <1>;
>>>> +      clock-output-names = "cck0", "cck1";
>>>> +      clock-frequency = <2048000>;
>>>> +
>>>> +      sitf5: sitf@300 {
>>>> +        compatible = "st,stm32mp25-sitf-mdf";
>>>> +        reg = <0x300 0x4>;
>>>> +        st,sitf-mode = "spi";
>>>> +        clocks = <&mdf1 0>;
>>>> +      };
>>>> +
>>>> +      filter0: filter@84 {
>>>> +        compatible = "st,stm32mp25-mdf-dmic";
>>>> +        reg = <0x84 0x70>;
>>>> +        #io-channel-cells = <1>;
>>>> +        interrupts = <GIC_SPI 184 IRQ_TYPE_LEVEL_HIGH>;
>>>> +        dmas = <&hpdma 63 0x63 0x12 0>;
>>>> +        dma-names = "rx";
>>>> +        st,cic-mode = <5>;
>>>> +        st,sitf = <&sitf5 0>;
>>>> +        #address-cells = <1>;
>>>> +        #size-cells = <0>;
>>>> +
>>>> +        channel@0 {
>>>> +          reg = <0>;
>>>> +        };
>>>> +
>>>> +        asoc_pdm0: mdf-dai {
>>>> +          compatible = "st,stm32mp25-mdf-dai";
>>>> +          #sound-dai-cells = <0>;
>>>> +          io-channels = <&filter0 0>;
>>>> +        };
>>>> +      };
>>>> +
>>>> +      filter1: filter@104  {
>>>> +        compatible = "st,stm32mp25-mdf-adc";
>>>> +        reg = <0x104 0x70>;
>>>> +        #io-channel-cells = <1>;
>>>> +        interrupts = <GIC_SPI 185 IRQ_TYPE_LEVEL_HIGH>;
>>>> +        dmas = <&hpdma 64 0x63 0x12 0>;
>>>> +        dma-names = "rx";
>>>> +        st,cic-mode = <2>;
>>>> +        st,sitf = <&sitf5 1>;
>>>> +        #address-cells = <1>;
>>>> +        #size-cells = <0>;
>>>> +
>>>> +        channel@1 {
>>>> +          reg = <1>;
>>>> +          settling-time-us = <1000>;
>>>> +          io-backends = <&sd_adc1>;
>>>> +        };
>>>> +      };
>>>> +    };
>>>> +
>>>> +...
>>>> -- 
>>>> 2.43.0
>>>>
>>

Re: [PATCH 1/3] dt-bindings: iio: adc: add bindings for stm32 mdf filter

[Conor Dooley]

[-- Attachment #1: Type: text/plain, Size: 25463 bytes --]

On Thu, Oct 08, 2026 at 06:37:26PM +0200, Olivier MOYSAN wrote:
> Hi Conor,
> 
> On 10/8/26 12:11, Conor Dooley wrote:
> > On Wed, Oct 07, 2026 at 11:01:28AM +0200, Olivier MOYSAN wrote:
> > > Hi Conor,
> > > 
> > > Thanks for the review
> > > 
> > > On 10/1/26 20:32, Conor Dooley wrote:
> > > > On Thu, Oct 01, 2026 at 04:56:45PM +0200, Olivier Moysan wrote:
> > > > > Add bindings that describes STM32 MDF settings to support
> > > > > digital filtering for Pulse Density Modulation (PDM) microphones
> > > > > and analog sigma delta modulators.
> > > > > 
> > > > > Signed-off-by: Olivier Moysan <olivier.moysan@foss.st.com>
> > > > > ---
> > > > >    .../bindings/iio/adc/st,stm32-mdf-adc.yaml    | 383 ++++++++++++++++++
> > > > >    1 file changed, 383 insertions(+)
> > > > >    create mode 100644 Documentation/devicetree/bindings/iio/adc/st,stm32-mdf-adc.yaml
> > > > > 
> > > > > diff --git a/Documentation/devicetree/bindings/iio/adc/st,stm32-mdf-adc.yaml b/Documentation/devicetree/bindings/iio/adc/st,stm32-mdf-adc.yaml
> > > > > new file mode 100644
> > > > > index 000000000000..f2fbc3e150e8
> > > > > --- /dev/null
> > > > > +++ b/Documentation/devicetree/bindings/iio/adc/st,stm32-mdf-adc.yaml
> > > > > @@ -0,0 +1,383 @@
> > > > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > > > > +%YAML 1.2
> > > > > +---
> > > > > +$id: http://devicetree.org/schemas/iio/adc/st,stm32-mdf-adc.yaml#
> > > > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > > > +
> > > > > +title: STMicroelectronics STM32 Multi-function Digital Filter (MDF) ADC
> > > > > +
> > > > > +maintainers:
> > > > > +  - Olivier Moysan <olivier.moysan@foss.st.com>
> > > > > +
> > > > > +description: |
> > > > > +  STM32 MDF ADC is a sigma delta analog-to-digital converter dedicated to
> > > > > +  interface external sigma delta modulators to STM32 micro controllers.
> > > > > +
> > > > > +properties:
> > > > > +  compatible:
> > > > > +    enum:
> > > > > +      - st,stm32mp25-mdf
> > > > > +      - st,stm32mp23-mdf
> > > > > +
> > > > > +  reg:
> > > > > +    minItems: 1
> > > > > +    maxItems: 2
> > > > 
> > > > This needs an items list here. The size of the regions seems like crap
> > > > to begin with...
> > > > 
> > > > > +
> > > > > +  clocks:
> > > > > +    maxItems: 1
> > > > > +
> > > > > +  clock-names:
> > > > > +    description: Internal clock used for MDF digital processing.
> > > > > +    items:
> > > > > +      - const: ker_ck
> > > > 
> > > > This is pointless when you only have one.
> > > > 
> > > 
> > > I agree that it could be dropped. However, it is useful for using
> > > devm_regmap_init_mmio_clk.
> > 
> > Ah, because that function if you pass NULL to it, it doesn't mean no
> > string, it means no clock.
> > 
> 
> The MDF has two clocks (AHB clock for register accesses and ker_ck for
> peripheral processing). However, these two clocks share the same gate. So,
> only the ker_ck clock is exposed in the driver.

That's incorrect, you should have two clocks in DT if the block has two
even if they have a shared gate.

> The regmap api is a convenient way to manage registers and gate the AHB
> clock only on register accesses. Removing clock-names no longer allows you
> to benefit from clock management handled by the regmap framework, and means
> that this must be managed explicitly, partially or entirely, in the driver.
> 
> > > 
> > > > > +
> > > > > +  "#clock-cells":
> > > > > +    enum: [0, 1]
> > > > 
> > > > Why is this not fixed? Also why are parts of your own device consuming
> > > > the clocks?
> > 
> > Reading the docs, this has to be 1, you have two clocks?
> > 
> > Not sure why you skipped this and skipped explaining why you are
> > consuming your own clocks.
> > 
> 
> Yes, we can have two clocks gated independently but sharing the same rate.
> 
> Using the clock framework apis seemed to me the right way to manage cck1 and
> cck0 gating and divider computing. I think I would have to introduce
> proprietary properties and have to implement code in the driver, that would
> be handled natively by the framework otherwise.

The CCF is still the right way to do it, especially since CCK0/1 can be
exported to other devices. I don't believe you need to actually have a
reference in DT to do this though, plenty of "real" clock controllers
have only one input clock and hang a whole tree with multiple layers off
that.
Down below I mentioned this under "ouroboros devices", I think this kind
of ability to chose which clock a channel uses is a fairly normal thing
to do in IIO land, I just dunno what the preferred mechanism is - I just
know that it is not referencing yourself (probably it's some sort of
property that you put in a channel node that says 'blah-clock = "cck0"',
but better that the IIO folks answer.

> > > > > +  clock-output-names:
> > > > > +    description: |
> > > > > +      CCK0 and CCK1 are optional output clocks, which share the same clock frequency,
> > > > > +      but can be gated independently to save power.
> > > > > +    minItems: 1
> > > > > +    maxItems: 2
> > > > > +    oneOf:
> > > > > +      - items:
> > > > > +          - const: cck0
> > > > > +      - items:
> > > > > +          - const: cck1
> > > > > +      - items:
> > > > > +          - const: cck0
> > > > > +          - const: cck1
> > > > > +
> > > > > +  clock-frequency:
> > > > > +    description: |
> > > > > +      Common clock frequency (Hz) for CCK0 and CCK1 output clocks.
> > > > > +      The frequency must be a multiple of the "ker_ck" clock frequency.
> > > > > +    maximum: 25000000
> > > > 
> > > > Should not be needed, the consumers request what they need.
> > > > 
> > > 
> > > The CCKx clock frequency depends on the maximum rate supported by the sigma
> > > delta converters (for instance a digital mic) and the expected decimation
> > > ratio on the bitstream. Typically this determines the frequency on the SPI
> > > bus.
> > > This rate is defined statically and shared by the CCKx clocks. So IMHO, as
> > > this rate is unique, it can look strange to let the consumer define it.
> > > Moreover, it seems to me that clock-frequency is already used to configure
> > > the frequency of a provider in some other bindings.
> > > For instance: Documentation/devicetree/bindings/clock/silabs,si570.yaml
> > 
> > This is a binding from the age of antiquity, using it to justify your
> > use is actually harming your argument rather than helping. Your clock
> > consumers should be providing the information about what the rate should
> > be, and if you need to do this in dt you can use assigned-clock-rates.
> > 
> 
> ok, I will move this to clock consumer with assigned-clock properties.
> 
> > > So, it's not clear for me, what is the restriction on clock-frequency
> > > property.
> > > > > +
> > > > > +  ranges: true
> > > > > +
> > > > > +  clock-ranges: true
> > > > > +
> > > > > +  resets:
> > > > > +    maxItems: 1
> > > > > +
> > > > > +  reset-names:
> > > > > +    items:
> > > > > +      - const: mdf
> > 
> > Same applies here as to the clock names fwiw.
> > 
> 
> Yes, I removed this.
> 
> > > > > +
> > > > > +  access-controllers:
> > > > > +    $ref: /schemas/types.yaml#/definitions/phandle-array
> > > > > +    description: |
> > > > > +      Phandle to the rifsc device to check access right.
> > > > > +
> > > > > +  power-domains:
> > > > > +    maxItems: 1
> > > > > +
> > > > > +  st,interleave:
> > > > > +    description: |
> > > > > +      List of phandles of interleaved filters. The indexes of interleaved filters must be
> > > > > +      consecutives starting from 0 (i.e in range [0..N]). The samples from interleaved filters
> > > > > +      are muxed in a single channel and retrieved through the device associated to the filter 0.
> > > > > +      The filters 1..N have to be enabled, but inherit their configuration from filter 0.
> > > > > +    $ref: /schemas/types.yaml#/definitions/phandle-array
> > > > 
> > > > No idea what these even are, but this is probably not the right way to
> > > > represent the relationship between devices. They're apparently ADCs, but
> > > > this is also an ADC so I'm not sure what's going on here at all.
> > 
> > Yeah, after more thought this should not be done like this at all,
> > especially if these filters the phandle point to are part of this device
> > itself, which I suspect they are. If that's the case, you don't need
> > phandles to even do this, you just need an int that says what N is.
> > 
> 
> Yes, can be an index as it is an internal reference. I will change this.
> 
> > > > 
> > > > > +
> > > > > +required:
> > > > > +  - compatible
> > > > > +  - reg
> > > > > +  - ranges
> > > > > +  - clocks
> > > > > +  - clock-names
> > > > > +  - clock-ranges
> > > > > +  - "#address-cells"
> > > > > +  - "#size-cells"
> > > > > +
> > > > > +additionalProperties: false
> > > > > +
> > > > > +patternProperties:
> > > > > +  "^sitf@[0-9]+$":
> > > > > +    type: object
> > > > > +    description: Serial interface child node
> > > > 
> > > > Why is this a child node at all?
> > > > Probably not worth reviewing more without a link to the docs for this
> > > > device so I can figure out what on earth is going on!
> > > > 
> > > 
> > > The MDF is a digital filter for sigma-delta bitstreams, rather than the
> > > analog-to-digital converter itself.
> > > 
> > > Here is the link to STM32MP25 reference manuel
> > > https://www.st.com/resource/en/reference_manual/rm0457-stm32mp2325xx-advanced-armbased-3264bit-mpus-stmicroelectronics.pdf
> > > Chapter 45: Multi-function digital filter (MDF)
> > > 
> > > On STMP32MP25 SoC, the MDF provides 8 serial interfaces (SITF) and 8 digital
> > > filters (DFLT) which can be connected through a multiplexer.
> > > 
> > > Below is a schematic view of typical applications targeted by this
> > > peripheral
> > > 
> > > 
> > > Audio use case:
> > > 
> > > 		mdf
> > >              +-------------------------------------+
> > > +------+    | +------+    +------+    +------+    |
> > > | dmic | -> | | sitf | -> | mux  | -> | dflt | -- | -> audio device
> > > +------+    | +------+    +------+    +------+    |
> > >              +-------------------------------------+
> > > 
> > > For instance, in an audio use case the serial interface can be configured to
> > > provide the clock to the digital microphone (cck0, cck1 or both) at a common
> > > predefined rate, and to retrieve the PDM samples.
> > > The serial interface provides this samples to a digital filter, which
> > > delivers PCM samples on its output.
> > > 
> > > 
> > > Analog use case:
> > > 
> > > 		mdf
> > >                +-------------------------------------+
> > > +--------+    | +------+    +------+    +------+    |
> > > | sd adc | -> | | sitf | -> | mux  | -> | dflt | -- | -> iio device
> > > +--------+    | +------+    +------+    +------+    |
> > >                +-------------------------------------+
> > 
> > 
> > So, looking at the docs and a brief chat with Jonathan about this
> > device, I believe you've got things backwards and this is actually the backend,
> > and the adc should be the one populating the io-backends property
> > pointing to this device. You should have io-backend-cells, and I assume
> > that there should be a cell for the adc to select which dlft it is connected
> > to.
> > 
> 
> There have already been lengthy discussions in the past about a DFSDM
> peripheral on STM32MP1, which has features similar to those of the MDF and
> similar implementation constraints. For the DFSDM, a solution based on an
> IIO backend had been upstreamed. The MDF follows the same architecture. I
> need to take a little time to dive back into this issue.

One thing to note there is that you retrofitted the backends onto that
device, and the original design here is much older (it's a text
binding).


> 
> DFSDM sources:
> drivers/iio/adc/stm32-dfsdm-adc.c
> drivers/iio/adc/stm32-dfsdm-core.c
> 
> Here is a sample of DFSDM DT
> 
> sd_adc0: simple-sd-adc0 {
> 	compatible = "sd-modulator";
> 	#io-backend-cells = <0>;
> 	vref-supply = <&v3v3>;

Yeah, pretty sure this is wrong (backwards). The backend is the thing
that gets data from an ADC not the ADC.

Thanks,
Conor.

> };
> 
> dfsdm0 {
> 	compatible = "st,stm32-dfsdm-adc";
> 	...
> 
> 	channel@0 {
> 		reg = <0>;
> 		label = "in0";
> 		...
> 		io-backends = <&sd_adc0>;
> 	};		
> };
> 
> > I think all of these child nodes should just get deleted - all your
> > devices here seem completely fake, since you've got stuff that's only a
> > single word wide. With that, you could also throw away these mickey
> > mouse nodes with sound-dai-cels of 0, and use 1 instead, with that cell
> > again determining which dlft is in use.
> > 
> > The only child node I can really thing of any justification for here is
> > channels - albeit not adc channels since this is not an adc - so that
> > you can individually configure a dlft using those channel nodes.
> > 
> > These serial inputs, what is the source for the data that is ever
> > actually sent there? I am assuming it's effectively another IIO device,
> > just not the onboard adc? Are the outputs exposed on pins on the
> > package?
> > 
> > I would encourage you to remodel this system, where this device is the
> > backend and also try to get rid of as much of the consuming your own
> > clock as possible. Certainly consuming ker_clk should never be required.
> > It's hard to reason about what should happen with the serial interface
> > clocks, when I have no idea what the input/data source device actually
> > is in those cases. Being a clock controller does make sense, because the
> > device exposes CCK0/1 to the outside world, it's the internal routing to
> > the SITF blocks that I am not sure how to deal with. A ouroboros device
> > that is consuming a clock it provides is not really a done thing,
> > hopefully the IIO guys can tell you how these kinds of things are
> > typically done here, since I'm sure there's plenty of other devices
> > that have some sort of ability to change the clock source for a channel.
> > 
> > Probably you need to add two optional input clocks to this device, since
> > mdf_cck0/1 can be inputs too?
> > 
> > Let me know if any of this feedback is intractable stuff, and maybe hang
> > on for someone like David or Jonathan to provide some review before
> > going about a significant rework. It's worth bearing in mind that I am a
> > binding reviewer and not a domain expert in ADCs etc.
> > 
> > Thanks,
> > Conor.
> > 
> 
> Best regards
> Olivier
> 
> > > > > +
> > > > > +    properties:
> > > > > +      compatible:
> > > > > +        enum:
> > > > > +          - st,stm32mp25-sitf-mdf
> > > > > +
> > > > > +      reg:
> > > > > +        description: Specify the SITF serial interface instance
> > > > > +        maxItems: 1
> > > > > +
> > > > > +      clocks:
> > > > > +        description: |
> > > > > +          Serial interface clock (optional depending on interface mode)
> > > > > +        maxItems: 1
> > > > > +
> > > > > +      st,sitf-mode:
> > > > > +        description: |
> > > > > +          Select serial interface protocol
> > > > > +          - spi: SPI mode
> > > > > +          - lf_spi: low frequency SPI mode for low power applications
> > > > > +        $ref: /schemas/types.yaml#/definitions/string
> > > > > +        enum:
> > > > > +          - spi
> > > > > +          - lf_spi
> > > > > +
> > > > > +    required:
> > > > > +      - reg
> > > > > +      - st,sitf-mode
> > > > > +
> > > > > +    additionalProperties: false
> > > > > +
> > > > > +  "^filter@[0-9]+$":
> > > > > +    type: object
> > > > > +    description: Digital filter path child node
> > > > > +
> > > > > +    properties:
> > > > > +      compatible:
> > > > > +        enum:
> > > > > +          - st,stm32mp25-mdf-dmic
> > > > > +          - st,stm32mp25-mdf-adc
> > > > > +
> > > > > +      reg:
> > > > > +        description: Specify the MDF filter instance
> > > > > +        maxItems: 1
> > > > > +
> > > > > +      interrupts:
> > > > > +        maxItems: 1
> > > > > +
> > > > > +      clocks:
> > > > > +        minItems: 1
> > > > > +        description: Internal clock used for MDF digital processing and control blocks.
> > > > > +
> > > > > +      clock-names:
> > > > > +        items:
> > > > > +          - const: ker_ck
> > > > > +
> > > > > +      dmas:
> > > > > +        maxItems: 1
> > > > > +
> > > > > +      dma-names:
> > > > > +        items:
> > > > > +          - const: rx
> > > > > +
> > > > > +      "#io-channel-cells":
> > > > > +        const: 1
> > > > > +
> > > > > +      '#address-cells':
> > > > > +        const: 1
> > > > > +
> > > > > +      '#size-cells':
> > > > > +        const: 0
> > > > > +
> > > > > +      st,cic-mode:
> > > > > +        description: |
> > > > > +          Cascaded-integrator-comb (CIC) filter configuration
> > > > > +          - 0: MCIC & ACIC filters in FastSinc mode
> > > > > +          - [1-3]: MCIC & ACIC filters in Sinc mode order 1 to 3
> > > > > +          - [4-5]: Single CIC filter in Sinc mode order 4 to 5
> > > > > +          For audio purpose it is recommended to use CIC Sinc4 or Sinc5
> > > > > +          This property is mandatory for filter 0 or filters not used in interleave mode.
> > > > > +        $ref: /schemas/types.yaml#/definitions/uint32
> > > > > +        minimum: 0
> > > > > +        maximum: 5
> > > > > +
> > > > > +      st,delay:
> > > > > +        description: Filter delay in samples
> > > > > +        $ref: /schemas/types.yaml#/definitions/uint32
> > > > > +        maximum: 127
> > > > > +
> > > > > +      st,rs-filter-bypass:
> > > > > +        description: Bypass RSFLT reshaping filter.
> > > > > +        $ref: /schemas/types.yaml#/definitions/flag
> > > > > +
> > > > > +      st,hpf-filter-cutoff-bp:
> > > > > +        description: |
> > > > > +          High Pass Filter (HPF) cut-off frequency expressed as a fraction of the PCM sampling rate.
> > > > > +          Cut-off frequency = st,hpf-filter-cutoff-bp x Fpcm / 10000.
> > > > > +          If this property is not defined the HPF is disabled.
> > > > > +        enum: [625, 1250, 2500, 9500]
> > > > > +
> > > > > +      st,sync:
> > > > > +        description:
> > > > > +          Synchronize to another filter.
> > > > > +          Must contain the phandle of the filter providing the synchronization.
> > > > > +        allOf:
> > > > > +          - $ref: /schemas/types.yaml#/definitions/phandle-array
> > > > > +          - maxItems: 1
> > > > > +
> > > > > +      st,sitf:
> > > > > +        $ref: /schemas/types.yaml#/definitions/phandle-array
> > > > > +        items:
> > > > > +          - items:
> > > > > +              - description: Phandle of the serial interface connected to the digital filter
> > > > > +              - description: |
> > > > > +                  The phandle's argument selects the bitstream on the falling or rising edge
> > > > > +                  of the serial interface clock:
> > > > > +                  - 0: rising edge
> > > > > +                  - 1: falling edge
> > > > > +                enum: [0, 1]
> > > > > +                default: 0
> > > > > +        description:
> > > > > +          Should be phandle/bitstream pair.
> > > > > +
> > > > > +    required:
> > > > > +      - compatible
> > > > > +      - reg
> > > > > +      - interrupts
> > > > > +      - dmas
> > > > > +      - dma-names
> > > > > +      - "#io-channel-cells"
> > > > > +      - "#address-cells"
> > > > > +      - "#size-cells"
> > > > > +      - st,sitf
> > > > > +
> > > > > +    unevaluatedProperties: false
> > > > > +
> > > > > +    patternProperties:
> > > > > +      "^channel@([0-7])$":
> > > > > +        type: object
> > > > > +        $ref: adc.yaml
> > > > > +        description: Represents the external channel which is connected to the MDF.
> > > > > +
> > > > > +        properties:
> > > > > +          reg:
> > > > > +            maximum: 7
> > > > > +
> > > > > +          io-backends:
> > > > > +            description:
> > > > > +              Used to pipe external sigma delta modulator or internal ADC backend to MDF
> > > > > +              channel.
> > > > > +            maxItems: 1
> > 
> > > > > +
> > > > > +        required:
> > > > > +          - reg
> > > > > +
> > > > > +        unevaluatedProperties: false
> > > > > +
> > > > > +    allOf:
> > > > > +      - if:
> > > > > +          properties:
> > > > > +            compatible:
> > > > > +              contains:
> > > > > +                const: st,stm32mp25-mdf-adc
> > > > > +
> > > > > +        then:
> > > > > +          patternProperties:
> > > > > +            "^channel@[0-7]$":
> > > > > +              required:
> > > > > +                - io-backends
> > > > > +
> > > > > +      - if:
> > > > > +          properties:
> > > > > +            compatible:
> > > > > +              contains:
> > > > > +                const: st,stm32mp25-mdf-dmic
> > > > > +
> > > > > +        then:
> > > > > +          patternProperties:
> > > > > +            "^mdf-dai+$":
> > > > > +              type: object
> > > > > +              description: child node
> > > > > +
> > > > > +              properties:
> > > > > +                compatible:
> > > > > +                  enum:
> > > > > +                    - st,stm32mp25-mdf-dai
> > > > > +
> > > > > +                "#sound-dai-cells":
> > > > > +                  const: 0
> > > > > +
> > > > > +                io-channels:
> > > > > +                  description:
> > > > > +                    From common IIO binding. Used to pipe external sigma delta
> > > > > +                    modulator or internal ADC output to MDF channel.
> > > > > +
> > > > > +                power-domains:
> > > > > +                  maxItems: 1
> > > > > +
> > > > > +                port:
> > > > > +                  $ref: /schemas/sound/audio-graph-port.yaml#
> > > > > +                  unevaluatedProperties: false
> > > > > +
> > > > > +              required:
> > > > > +                - compatible
> > > > > +                - "#sound-dai-cells"
> > > > > +                - io-channels
> > > > > +
> > > > > +              additionalProperties: false
> > > > > +
> > > > > +examples:
> > > > > +  - |
> > > > > +    #include <dt-bindings/clock/st,stm32mp25-rcc.h>
> > > > > +    #include <dt-bindings/interrupt-controller/arm-gic.h>
> > > > > +    mdf1: mdf@504d0000 {
> > > > > +      compatible = "st,stm32mp25-mdf";
> > > > > +      ranges = <0 0x504d0000 0x1000>;
> > > > > +      reg = <0x504d0000 0x8>, <0x504d0ff0 0x10>;
> > > > > +      #address-cells = <1>;
> > > > > +      #size-cells = <1>;
> > > > > +      clocks = <&rcc CK_KER_MDF1>;
> > > > > +      clock-names = "ker_ck";
> > > > > +      clock-ranges;
> > > > > +      #clock-cells = <1>;
> > > > > +      clock-output-names = "cck0", "cck1";
> > > > > +      clock-frequency = <2048000>;
> > > > > +
> > > > > +      sitf5: sitf@300 {
> > > > > +        compatible = "st,stm32mp25-sitf-mdf";
> > > > > +        reg = <0x300 0x4>;
> > > > > +        st,sitf-mode = "spi";
> > > > > +        clocks = <&mdf1 0>;
> > > > > +      };
> > > > > +
> > > > > +      filter0: filter@84 {
> > > > > +        compatible = "st,stm32mp25-mdf-dmic";
> > > > > +        reg = <0x84 0x70>;
> > > > > +        #io-channel-cells = <1>;
> > > > > +        interrupts = <GIC_SPI 184 IRQ_TYPE_LEVEL_HIGH>;
> > > > > +        dmas = <&hpdma 63 0x63 0x12 0>;
> > > > > +        dma-names = "rx";
> > > > > +        st,cic-mode = <5>;
> > > > > +        st,sitf = <&sitf5 0>;
> > > > > +        #address-cells = <1>;
> > > > > +        #size-cells = <0>;
> > > > > +
> > > > > +        channel@0 {
> > > > > +          reg = <0>;
> > > > > +        };
> > > > > +
> > > > > +        asoc_pdm0: mdf-dai {
> > > > > +          compatible = "st,stm32mp25-mdf-dai";
> > > > > +          #sound-dai-cells = <0>;
> > > > > +          io-channels = <&filter0 0>;
> > > > > +        };
> > > > > +      };
> > > > > +
> > > > > +      filter1: filter@104  {
> > > > > +        compatible = "st,stm32mp25-mdf-adc";
> > > > > +        reg = <0x104 0x70>;
> > > > > +        #io-channel-cells = <1>;
> > > > > +        interrupts = <GIC_SPI 185 IRQ_TYPE_LEVEL_HIGH>;
> > > > > +        dmas = <&hpdma 64 0x63 0x12 0>;
> > > > > +        dma-names = "rx";
> > > > > +        st,cic-mode = <2>;
> > > > > +        st,sitf = <&sitf5 1>;
> > > > > +        #address-cells = <1>;
> > > > > +        #size-cells = <0>;
> > > > > +
> > > > > +        channel@1 {
> > > > > +          reg = <1>;
> > > > > +          settling-time-us = <1000>;
> > > > > +          io-backends = <&sd_adc1>;
> > > > > +        };
> > > > > +      };
> > > > > +    };
> > > > > +
> > > > > +...
> > > > > -- 
> > > > > 2.43.0
> > > > > 
> > > 
> 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH 1/3] dt-bindings: iio: adc: add bindings for stm32 mdf filter

[Olivier MOYSAN]

Hi Conor,

On 10/9/26 21:12, Conor Dooley wrote:
> On Thu, Oct 08, 2026 at 06:37:26PM +0200, Olivier MOYSAN wrote:
>> Hi Conor,
>>
>> On 10/8/26 12:11, Conor Dooley wrote:
>>> On Wed, Oct 07, 2026 at 11:01:28AM +0200, Olivier MOYSAN wrote:
>>>> Hi Conor,
>>>>
>>>> Thanks for the review
>>>>
>>>> On 10/1/26 20:32, Conor Dooley wrote:
>>>>> On Thu, Oct 01, 2026 at 04:56:45PM +0200, Olivier Moysan wrote:
>>>>>> Add bindings that describes STM32 MDF settings to support
>>>>>> digital filtering for Pulse Density Modulation (PDM) microphones
>>>>>> and analog sigma delta modulators.
>>>>>>
>>>>>> Signed-off-by: Olivier Moysan <olivier.moysan@foss.st.com>
>>>>>> ---
>>>>>>     .../bindings/iio/adc/st,stm32-mdf-adc.yaml    | 383 ++++++++++++++++++
>>>>>>     1 file changed, 383 insertions(+)
>>>>>>     create mode 100644 Documentation/devicetree/bindings/iio/adc/st,stm32-mdf-adc.yaml
>>>>>>
>>>>>> diff --git a/Documentation/devicetree/bindings/iio/adc/st,stm32-mdf-adc.yaml b/Documentation/devicetree/bindings/iio/adc/st,stm32-mdf-adc.yaml
>>>>>> new file mode 100644
>>>>>> index 000000000000..f2fbc3e150e8
>>>>>> --- /dev/null
>>>>>> +++ b/Documentation/devicetree/bindings/iio/adc/st,stm32-mdf-adc.yaml
>>>>>> @@ -0,0 +1,383 @@
>>>>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>>>>>> +%YAML 1.2
>>>>>> +---
>>>>>> +$id: http://devicetree.org/schemas/iio/adc/st,stm32-mdf-adc.yaml#
>>>>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>>>>>> +
>>>>>> +title: STMicroelectronics STM32 Multi-function Digital Filter (MDF) ADC
>>>>>> +
>>>>>> +maintainers:
>>>>>> +  - Olivier Moysan <olivier.moysan@foss.st.com>
>>>>>> +
>>>>>> +description: |
>>>>>> +  STM32 MDF ADC is a sigma delta analog-to-digital converter dedicated to
>>>>>> +  interface external sigma delta modulators to STM32 micro controllers.
>>>>>> +
>>>>>> +properties:
>>>>>> +  compatible:
>>>>>> +    enum:
>>>>>> +      - st,stm32mp25-mdf
>>>>>> +      - st,stm32mp23-mdf
>>>>>> +
>>>>>> +  reg:
>>>>>> +    minItems: 1
>>>>>> +    maxItems: 2
>>>>>
>>>>> This needs an items list here. The size of the regions seems like crap
>>>>> to begin with...
>>>>>
>>>>>> +
>>>>>> +  clocks:
>>>>>> +    maxItems: 1
>>>>>> +
>>>>>> +  clock-names:
>>>>>> +    description: Internal clock used for MDF digital processing.
>>>>>> +    items:
>>>>>> +      - const: ker_ck
>>>>>
>>>>> This is pointless when you only have one.
>>>>>
>>>>
>>>> I agree that it could be dropped. However, it is useful for using
>>>> devm_regmap_init_mmio_clk.
>>>
>>> Ah, because that function if you pass NULL to it, it doesn't mean no
>>> string, it means no clock.
>>>
>>
>> The MDF has two clocks (AHB clock for register accesses and ker_ck for
>> peripheral processing). However, these two clocks share the same gate. So,
>> only the ker_ck clock is exposed in the driver.
> 
> That's incorrect, you should have two clocks in DT if the block has two
> even if they have a shared gate.
> 

This would not be consistent with the architectural choice made for the 
STM32MP25. The RCC driver provides an abstraction to manage these two 
clocks as one, since they are controlled by the same gate. The binding 
incorporates this abstraction to manage only a single clock.

A large number of peripherals on STM32MP25 have the same architecture 
and follow this implementation rule. So managing both clocks in the MDF 
driver would create a consistency issue with the other peripherals.

>> The regmap api is a convenient way to manage registers and gate the AHB
>> clock only on register accesses. Removing clock-names no longer allows you
>> to benefit from clock management handled by the regmap framework, and means
>> that this must be managed explicitly, partially or entirely, in the driver.
>>
>>>>
>>>>>> +
>>>>>> +  "#clock-cells":
>>>>>> +    enum: [0, 1]
>>>>>
>>>>> Why is this not fixed? Also why are parts of your own device consuming
>>>>> the clocks?
>>>
>>> Reading the docs, this has to be 1, you have two clocks?
>>>
>>> Not sure why you skipped this and skipped explaining why you are
>>> consuming your own clocks.
>>>
>>
>> Yes, we can have two clocks gated independently but sharing the same rate.
>>
>> Using the clock framework apis seemed to me the right way to manage cck1 and
>> cck0 gating and divider computing. I think I would have to introduce
>> proprietary properties and have to implement code in the driver, that would
>> be handled natively by the framework otherwise.
> 
> The CCF is still the right way to do it, especially since CCK0/1 can be
> exported to other devices. I don't believe you need to actually have a
> reference in DT to do this though, plenty of "real" clock controllers
> have only one input clock and hang a whole tree with multiple layers off
> that.
> Down below I mentioned this under "ouroboros devices", I think this kind
> of ability to chose which clock a channel uses is a fairly normal thing
> to do in IIO land, I just dunno what the preferred mechanism is - I just
> know that it is not referencing yourself (probably it's some sort of
> property that you put in a channel node that says 'blah-clock = "cck0"',
> but better that the IIO folks answer.
> 

The adc.yaml binding do not expose clock properties. But maybe IIO 
experts can answer about this.

>>>>>> +  clock-output-names:
>>>>>> +    description: |
>>>>>> +      CCK0 and CCK1 are optional output clocks, which share the same clock frequency,
>>>>>> +      but can be gated independently to save power.
>>>>>> +    minItems: 1
>>>>>> +    maxItems: 2
>>>>>> +    oneOf:
>>>>>> +      - items:
>>>>>> +          - const: cck0
>>>>>> +      - items:
>>>>>> +          - const: cck1
>>>>>> +      - items:
>>>>>> +          - const: cck0
>>>>>> +          - const: cck1
>>>>>> +
>>>>>> +  clock-frequency:
>>>>>> +    description: |
>>>>>> +      Common clock frequency (Hz) for CCK0 and CCK1 output clocks.
>>>>>> +      The frequency must be a multiple of the "ker_ck" clock frequency.
>>>>>> +    maximum: 25000000
>>>>>
>>>>> Should not be needed, the consumers request what they need.
>>>>>
>>>>
>>>> The CCKx clock frequency depends on the maximum rate supported by the sigma
>>>> delta converters (for instance a digital mic) and the expected decimation
>>>> ratio on the bitstream. Typically this determines the frequency on the SPI
>>>> bus.
>>>> This rate is defined statically and shared by the CCKx clocks. So IMHO, as
>>>> this rate is unique, it can look strange to let the consumer define it.
>>>> Moreover, it seems to me that clock-frequency is already used to configure
>>>> the frequency of a provider in some other bindings.
>>>> For instance: Documentation/devicetree/bindings/clock/silabs,si570.yaml
>>>
>>> This is a binding from the age of antiquity, using it to justify your
>>> use is actually harming your argument rather than helping. Your clock
>>> consumers should be providing the information about what the rate should
>>> be, and if you need to do this in dt you can use assigned-clock-rates.
>>>
>>
>> ok, I will move this to clock consumer with assigned-clock properties.
>>
>>>> So, it's not clear for me, what is the restriction on clock-frequency
>>>> property.
>>>>>> +
>>>>>> +  ranges: true
>>>>>> +
>>>>>> +  clock-ranges: true
>>>>>> +
>>>>>> +  resets:
>>>>>> +    maxItems: 1
>>>>>> +
>>>>>> +  reset-names:
>>>>>> +    items:
>>>>>> +      - const: mdf
>>>
>>> Same applies here as to the clock names fwiw.
>>>
>>
>> Yes, I removed this.
>>
>>>>>> +
>>>>>> +  access-controllers:
>>>>>> +    $ref: /schemas/types.yaml#/definitions/phandle-array
>>>>>> +    description: |
>>>>>> +      Phandle to the rifsc device to check access right.
>>>>>> +
>>>>>> +  power-domains:
>>>>>> +    maxItems: 1
>>>>>> +
>>>>>> +  st,interleave:
>>>>>> +    description: |
>>>>>> +      List of phandles of interleaved filters. The indexes of interleaved filters must be
>>>>>> +      consecutives starting from 0 (i.e in range [0..N]). The samples from interleaved filters
>>>>>> +      are muxed in a single channel and retrieved through the device associated to the filter 0.
>>>>>> +      The filters 1..N have to be enabled, but inherit their configuration from filter 0.
>>>>>> +    $ref: /schemas/types.yaml#/definitions/phandle-array
>>>>>
>>>>> No idea what these even are, but this is probably not the right way to
>>>>> represent the relationship between devices. They're apparently ADCs, but
>>>>> this is also an ADC so I'm not sure what's going on here at all.
>>>
>>> Yeah, after more thought this should not be done like this at all,
>>> especially if these filters the phandle point to are part of this device
>>> itself, which I suspect they are. If that's the case, you don't need
>>> phandles to even do this, you just need an int that says what N is.
>>>
>>
>> Yes, can be an index as it is an internal reference. I will change this.
>>
>>>>>
>>>>>> +
>>>>>> +required:
>>>>>> +  - compatible
>>>>>> +  - reg
>>>>>> +  - ranges
>>>>>> +  - clocks
>>>>>> +  - clock-names
>>>>>> +  - clock-ranges
>>>>>> +  - "#address-cells"
>>>>>> +  - "#size-cells"
>>>>>> +
>>>>>> +additionalProperties: false
>>>>>> +
>>>>>> +patternProperties:
>>>>>> +  "^sitf@[0-9]+$":
>>>>>> +    type: object
>>>>>> +    description: Serial interface child node
>>>>>
>>>>> Why is this a child node at all?
>>>>> Probably not worth reviewing more without a link to the docs for this
>>>>> device so I can figure out what on earth is going on!
>>>>>
>>>>
>>>> The MDF is a digital filter for sigma-delta bitstreams, rather than the
>>>> analog-to-digital converter itself.
>>>>
>>>> Here is the link to STM32MP25 reference manuel
>>>> https://www.st.com/resource/en/reference_manual/rm0457-stm32mp2325xx-advanced-armbased-3264bit-mpus-stmicroelectronics.pdf
>>>> Chapter 45: Multi-function digital filter (MDF)
>>>>
>>>> On STMP32MP25 SoC, the MDF provides 8 serial interfaces (SITF) and 8 digital
>>>> filters (DFLT) which can be connected through a multiplexer.
>>>>
>>>> Below is a schematic view of typical applications targeted by this
>>>> peripheral
>>>>
>>>>
>>>> Audio use case:
>>>>
>>>> 		mdf
>>>>               +-------------------------------------+
>>>> +------+    | +------+    +------+    +------+    |
>>>> | dmic | -> | | sitf | -> | mux  | -> | dflt | -- | -> audio device
>>>> +------+    | +------+    +------+    +------+    |
>>>>               +-------------------------------------+
>>>>
>>>> For instance, in an audio use case the serial interface can be configured to
>>>> provide the clock to the digital microphone (cck0, cck1 or both) at a common
>>>> predefined rate, and to retrieve the PDM samples.
>>>> The serial interface provides this samples to a digital filter, which
>>>> delivers PCM samples on its output.
>>>>
>>>>
>>>> Analog use case:
>>>>
>>>> 		mdf
>>>>                 +-------------------------------------+
>>>> +--------+    | +------+    +------+    +------+    |
>>>> | sd adc | -> | | sitf | -> | mux  | -> | dflt | -- | -> iio device
>>>> +--------+    | +------+    +------+    +------+    |
>>>>                 +-------------------------------------+
>>>
>>>
>>> So, looking at the docs and a brief chat with Jonathan about this
>>> device, I believe you've got things backwards and this is actually the backend,
>>> and the adc should be the one populating the io-backends property
>>> pointing to this device. You should have io-backend-cells, and I assume
>>> that there should be a cell for the adc to select which dlft it is connected
>>> to.
>>>
>>
>> There have already been lengthy discussions in the past about a DFSDM
>> peripheral on STM32MP1, which has features similar to those of the MDF and
>> similar implementation constraints. For the DFSDM, a solution based on an
>> IIO backend had been upstreamed. The MDF follows the same architecture. I
>> need to take a little time to dive back into this issue.
> 
> One thing to note there is that you retrofitted the backends onto that
> device, and the original design here is much older (it's a text
> binding).
> 
> 
>>
>> DFSDM sources:
>> drivers/iio/adc/stm32-dfsdm-adc.c
>> drivers/iio/adc/stm32-dfsdm-core.c
>>
>> Here is a sample of DFSDM DT
>>
>> sd_adc0: simple-sd-adc0 {
>> 	compatible = "sd-modulator";
>> 	#io-backend-cells = <0>;
>> 	vref-supply = <&v3v3>;
> 
> Yeah, pretty sure this is wrong (backwards). The backend is the thing
> that gets data from an ADC not the ADC.
> 

The backend framework was introduced to implement complex IIO aggregate 
devices. The hardwares that were driving this need were analog device 
ad9467 and ST DFSDM.

https://lore.kernel.org/linux-iio/20231204144925.4fe9922f@jic23-huawei/T/#m222f5175273b81dbfe40b7f0daffcdc67d6cb8ff

 From drivers/iio/industrialio-backend.c:

"The typical architecture is to have one device as the frontend device 
which can be "linked" against one or multiple backend devices. All the 
IIO and userspace interface is expected to be registers/managed by the 
frontend device which will callback into the backends when needed (to 
get/set some configuration that it does not directly control)."

  *                                    ---------------------
  * ------------------                 | ------------
  * |     ADC        |-----------------| | ADC CORE |
  * | (Frontend/IIO) | Serial Data (eg | |(backend) |-------
  * |                |-----------------| ------------
  * ------------------                 ---------------------

The MDF (or DFSDM) use case, follows this topology:
- The SD modulator (ADC core) registers in backend framework
- The MDF registers in IIO framework and exposes the IIO devices
   It also get configuration (ref voltage) from SD modulator, to compute 
   scaling.

I agree that if we consider the terms frontend and backend, the elements 
in the data flow do not have the roles that we would naturally expect. 
However, if we consider the expected role of the elements using the 
iio-backend framework, the usage seems coherent to me.

Best regards
Olivier

> Thanks,
> Conor.
> 
>> };
>>
>> dfsdm0 {
>> 	compatible = "st,stm32-dfsdm-adc";
>> 	...
>>
>> 	channel@0 {
>> 		reg = <0>;
>> 		label = "in0";
>> 		...
>> 		io-backends = <&sd_adc0>;
>> 	};		
>> };
>>
>>> I think all of these child nodes should just get deleted - all your
>>> devices here seem completely fake, since you've got stuff that's only a
>>> single word wide. With that, you could also throw away these mickey
>>> mouse nodes with sound-dai-cels of 0, and use 1 instead, with that cell
>>> again determining which dlft is in use.
>>>
>>> The only child node I can really thing of any justification for here is
>>> channels - albeit not adc channels since this is not an adc - so that
>>> you can individually configure a dlft using those channel nodes.
>>>
>>> These serial inputs, what is the source for the data that is ever
>>> actually sent there? I am assuming it's effectively another IIO device,
>>> just not the onboard adc? Are the outputs exposed on pins on the
>>> package?
>>>
>>> I would encourage you to remodel this system, where this device is the
>>> backend and also try to get rid of as much of the consuming your own
>>> clock as possible. Certainly consuming ker_clk should never be required.
>>> It's hard to reason about what should happen with the serial interface
>>> clocks, when I have no idea what the input/data source device actually
>>> is in those cases. Being a clock controller does make sense, because the
>>> device exposes CCK0/1 to the outside world, it's the internal routing to
>>> the SITF blocks that I am not sure how to deal with. A ouroboros device
>>> that is consuming a clock it provides is not really a done thing,
>>> hopefully the IIO guys can tell you how these kinds of things are
>>> typically done here, since I'm sure there's plenty of other devices
>>> that have some sort of ability to change the clock source for a channel.
>>>
>>> Probably you need to add two optional input clocks to this device, since
>>> mdf_cck0/1 can be inputs too?
>>>
>>> Let me know if any of this feedback is intractable stuff, and maybe hang
>>> on for someone like David or Jonathan to provide some review before
>>> going about a significant rework. It's worth bearing in mind that I am a
>>> binding reviewer and not a domain expert in ADCs etc.
>>>
>>> Thanks,
>>> Conor.
>>>
>>
>> Best regards
>> Olivier
>>
>>>>>> +
>>>>>> +    properties:
>>>>>> +      compatible:
>>>>>> +        enum:
>>>>>> +          - st,stm32mp25-sitf-mdf
>>>>>> +
>>>>>> +      reg:
>>>>>> +        description: Specify the SITF serial interface instance
>>>>>> +        maxItems: 1
>>>>>> +
>>>>>> +      clocks:
>>>>>> +        description: |
>>>>>> +          Serial interface clock (optional depending on interface mode)
>>>>>> +        maxItems: 1
>>>>>> +
>>>>>> +      st,sitf-mode:
>>>>>> +        description: |
>>>>>> +          Select serial interface protocol
>>>>>> +          - spi: SPI mode
>>>>>> +          - lf_spi: low frequency SPI mode for low power applications
>>>>>> +        $ref: /schemas/types.yaml#/definitions/string
>>>>>> +        enum:
>>>>>> +          - spi
>>>>>> +          - lf_spi
>>>>>> +
>>>>>> +    required:
>>>>>> +      - reg
>>>>>> +      - st,sitf-mode
>>>>>> +
>>>>>> +    additionalProperties: false
>>>>>> +
>>>>>> +  "^filter@[0-9]+$":
>>>>>> +    type: object
>>>>>> +    description: Digital filter path child node
>>>>>> +
>>>>>> +    properties:
>>>>>> +      compatible:
>>>>>> +        enum:
>>>>>> +          - st,stm32mp25-mdf-dmic
>>>>>> +          - st,stm32mp25-mdf-adc
>>>>>> +
>>>>>> +      reg:
>>>>>> +        description: Specify the MDF filter instance
>>>>>> +        maxItems: 1
>>>>>> +
>>>>>> +      interrupts:
>>>>>> +        maxItems: 1
>>>>>> +
>>>>>> +      clocks:
>>>>>> +        minItems: 1
>>>>>> +        description: Internal clock used for MDF digital processing and control blocks.
>>>>>> +
>>>>>> +      clock-names:
>>>>>> +        items:
>>>>>> +          - const: ker_ck
>>>>>> +
>>>>>> +      dmas:
>>>>>> +        maxItems: 1
>>>>>> +
>>>>>> +      dma-names:
>>>>>> +        items:
>>>>>> +          - const: rx
>>>>>> +
>>>>>> +      "#io-channel-cells":
>>>>>> +        const: 1
>>>>>> +
>>>>>> +      '#address-cells':
>>>>>> +        const: 1
>>>>>> +
>>>>>> +      '#size-cells':
>>>>>> +        const: 0
>>>>>> +
>>>>>> +      st,cic-mode:
>>>>>> +        description: |
>>>>>> +          Cascaded-integrator-comb (CIC) filter configuration
>>>>>> +          - 0: MCIC & ACIC filters in FastSinc mode
>>>>>> +          - [1-3]: MCIC & ACIC filters in Sinc mode order 1 to 3
>>>>>> +          - [4-5]: Single CIC filter in Sinc mode order 4 to 5
>>>>>> +          For audio purpose it is recommended to use CIC Sinc4 or Sinc5
>>>>>> +          This property is mandatory for filter 0 or filters not used in interleave mode.
>>>>>> +        $ref: /schemas/types.yaml#/definitions/uint32
>>>>>> +        minimum: 0
>>>>>> +        maximum: 5
>>>>>> +
>>>>>> +      st,delay:
>>>>>> +        description: Filter delay in samples
>>>>>> +        $ref: /schemas/types.yaml#/definitions/uint32
>>>>>> +        maximum: 127
>>>>>> +
>>>>>> +      st,rs-filter-bypass:
>>>>>> +        description: Bypass RSFLT reshaping filter.
>>>>>> +        $ref: /schemas/types.yaml#/definitions/flag
>>>>>> +
>>>>>> +      st,hpf-filter-cutoff-bp:
>>>>>> +        description: |
>>>>>> +          High Pass Filter (HPF) cut-off frequency expressed as a fraction of the PCM sampling rate.
>>>>>> +          Cut-off frequency = st,hpf-filter-cutoff-bp x Fpcm / 10000.
>>>>>> +          If this property is not defined the HPF is disabled.
>>>>>> +        enum: [625, 1250, 2500, 9500]
>>>>>> +
>>>>>> +      st,sync:
>>>>>> +        description:
>>>>>> +          Synchronize to another filter.
>>>>>> +          Must contain the phandle of the filter providing the synchronization.
>>>>>> +        allOf:
>>>>>> +          - $ref: /schemas/types.yaml#/definitions/phandle-array
>>>>>> +          - maxItems: 1
>>>>>> +
>>>>>> +      st,sitf:
>>>>>> +        $ref: /schemas/types.yaml#/definitions/phandle-array
>>>>>> +        items:
>>>>>> +          - items:
>>>>>> +              - description: Phandle of the serial interface connected to the digital filter
>>>>>> +              - description: |
>>>>>> +                  The phandle's argument selects the bitstream on the falling or rising edge
>>>>>> +                  of the serial interface clock:
>>>>>> +                  - 0: rising edge
>>>>>> +                  - 1: falling edge
>>>>>> +                enum: [0, 1]
>>>>>> +                default: 0
>>>>>> +        description:
>>>>>> +          Should be phandle/bitstream pair.
>>>>>> +
>>>>>> +    required:
>>>>>> +      - compatible
>>>>>> +      - reg
>>>>>> +      - interrupts
>>>>>> +      - dmas
>>>>>> +      - dma-names
>>>>>> +      - "#io-channel-cells"
>>>>>> +      - "#address-cells"
>>>>>> +      - "#size-cells"
>>>>>> +      - st,sitf
>>>>>> +
>>>>>> +    unevaluatedProperties: false
>>>>>> +
>>>>>> +    patternProperties:
>>>>>> +      "^channel@([0-7])$":
>>>>>> +        type: object
>>>>>> +        $ref: adc.yaml
>>>>>> +        description: Represents the external channel which is connected to the MDF.
>>>>>> +
>>>>>> +        properties:
>>>>>> +          reg:
>>>>>> +            maximum: 7
>>>>>> +
>>>>>> +          io-backends:
>>>>>> +            description:
>>>>>> +              Used to pipe external sigma delta modulator or internal ADC backend to MDF
>>>>>> +              channel.
>>>>>> +            maxItems: 1
>>>
>>>>>> +
>>>>>> +        required:
>>>>>> +          - reg
>>>>>> +
>>>>>> +        unevaluatedProperties: false
>>>>>> +
>>>>>> +    allOf:
>>>>>> +      - if:
>>>>>> +          properties:
>>>>>> +            compatible:
>>>>>> +              contains:
>>>>>> +                const: st,stm32mp25-mdf-adc
>>>>>> +
>>>>>> +        then:
>>>>>> +          patternProperties:
>>>>>> +            "^channel@[0-7]$":
>>>>>> +              required:
>>>>>> +                - io-backends
>>>>>> +
>>>>>> +      - if:
>>>>>> +          properties:
>>>>>> +            compatible:
>>>>>> +              contains:
>>>>>> +                const: st,stm32mp25-mdf-dmic
>>>>>> +
>>>>>> +        then:
>>>>>> +          patternProperties:
>>>>>> +            "^mdf-dai+$":
>>>>>> +              type: object
>>>>>> +              description: child node
>>>>>> +
>>>>>> +              properties:
>>>>>> +                compatible:
>>>>>> +                  enum:
>>>>>> +                    - st,stm32mp25-mdf-dai
>>>>>> +
>>>>>> +                "#sound-dai-cells":
>>>>>> +                  const: 0
>>>>>> +
>>>>>> +                io-channels:
>>>>>> +                  description:
>>>>>> +                    From common IIO binding. Used to pipe external sigma delta
>>>>>> +                    modulator or internal ADC output to MDF channel.
>>>>>> +
>>>>>> +                power-domains:
>>>>>> +                  maxItems: 1
>>>>>> +
>>>>>> +                port:
>>>>>> +                  $ref: /schemas/sound/audio-graph-port.yaml#
>>>>>> +                  unevaluatedProperties: false
>>>>>> +
>>>>>> +              required:
>>>>>> +                - compatible
>>>>>> +                - "#sound-dai-cells"
>>>>>> +                - io-channels
>>>>>> +
>>>>>> +              additionalProperties: false
>>>>>> +
>>>>>> +examples:
>>>>>> +  - |
>>>>>> +    #include <dt-bindings/clock/st,stm32mp25-rcc.h>
>>>>>> +    #include <dt-bindings/interrupt-controller/arm-gic.h>
>>>>>> +    mdf1: mdf@504d0000 {
>>>>>> +      compatible = "st,stm32mp25-mdf";
>>>>>> +      ranges = <0 0x504d0000 0x1000>;
>>>>>> +      reg = <0x504d0000 0x8>, <0x504d0ff0 0x10>;
>>>>>> +      #address-cells = <1>;
>>>>>> +      #size-cells = <1>;
>>>>>> +      clocks = <&rcc CK_KER_MDF1>;
>>>>>> +      clock-names = "ker_ck";
>>>>>> +      clock-ranges;
>>>>>> +      #clock-cells = <1>;
>>>>>> +      clock-output-names = "cck0", "cck1";
>>>>>> +      clock-frequency = <2048000>;
>>>>>> +
>>>>>> +      sitf5: sitf@300 {
>>>>>> +        compatible = "st,stm32mp25-sitf-mdf";
>>>>>> +        reg = <0x300 0x4>;
>>>>>> +        st,sitf-mode = "spi";
>>>>>> +        clocks = <&mdf1 0>;
>>>>>> +      };
>>>>>> +
>>>>>> +      filter0: filter@84 {
>>>>>> +        compatible = "st,stm32mp25-mdf-dmic";
>>>>>> +        reg = <0x84 0x70>;
>>>>>> +        #io-channel-cells = <1>;
>>>>>> +        interrupts = <GIC_SPI 184 IRQ_TYPE_LEVEL_HIGH>;
>>>>>> +        dmas = <&hpdma 63 0x63 0x12 0>;
>>>>>> +        dma-names = "rx";
>>>>>> +        st,cic-mode = <5>;
>>>>>> +        st,sitf = <&sitf5 0>;
>>>>>> +        #address-cells = <1>;
>>>>>> +        #size-cells = <0>;
>>>>>> +
>>>>>> +        channel@0 {
>>>>>> +          reg = <0>;
>>>>>> +        };
>>>>>> +
>>>>>> +        asoc_pdm0: mdf-dai {
>>>>>> +          compatible = "st,stm32mp25-mdf-dai";
>>>>>> +          #sound-dai-cells = <0>;
>>>>>> +          io-channels = <&filter0 0>;
>>>>>> +        };
>>>>>> +      };
>>>>>> +
>>>>>> +      filter1: filter@104  {
>>>>>> +        compatible = "st,stm32mp25-mdf-adc";
>>>>>> +        reg = <0x104 0x70>;
>>>>>> +        #io-channel-cells = <1>;
>>>>>> +        interrupts = <GIC_SPI 185 IRQ_TYPE_LEVEL_HIGH>;
>>>>>> +        dmas = <&hpdma 64 0x63 0x12 0>;
>>>>>> +        dma-names = "rx";
>>>>>> +        st,cic-mode = <2>;
>>>>>> +        st,sitf = <&sitf5 1>;
>>>>>> +        #address-cells = <1>;
>>>>>> +        #size-cells = <0>;
>>>>>> +
>>>>>> +        channel@1 {
>>>>>> +          reg = <1>;
>>>>>> +          settling-time-us = <1000>;
>>>>>> +          io-backends = <&sd_adc1>;
>>>>>> +        };
>>>>>> +      };
>>>>>> +    };
>>>>>> +
>>>>>> +...
>>>>>> -- 
>>>>>> 2.43.0
>>>>>>
>>>>
>>

Re: [PATCH 1/3] dt-bindings: iio: adc: add bindings for stm32 mdf filter

[Conor Dooley]

[-- Attachment #1: Type: text/plain, Size: 16944 bytes --]

On Mon, Oct 12, 2026 at 02:56:04PM +0200, Olivier MOYSAN wrote:
> Hi Conor,
> 
> On 10/9/26 21:12, Conor Dooley wrote:
> > On Thu, Oct 08, 2026 at 06:37:26PM +0200, Olivier MOYSAN wrote:
> > > Hi Conor,
> > > 
> > > On 10/8/26 12:11, Conor Dooley wrote:
> > > > On Wed, Oct 07, 2026 at 11:01:28AM +0200, Olivier MOYSAN wrote:
> > > > > Hi Conor,
> > > > > 
> > > > > Thanks for the review
> > > > > 
> > > > > On 10/1/26 20:32, Conor Dooley wrote:
> > > > > > On Thu, Oct 01, 2026 at 04:56:45PM +0200, Olivier Moysan wrote:
> > > > > > > Add bindings that describes STM32 MDF settings to support
> > > > > > > digital filtering for Pulse Density Modulation (PDM) microphones
> > > > > > > and analog sigma delta modulators.
> > > > > > > 
> > > > > > > Signed-off-by: Olivier Moysan <olivier.moysan@foss.st.com>
> > > > > > > ---
> > > > > > >     .../bindings/iio/adc/st,stm32-mdf-adc.yaml    | 383 ++++++++++++++++++
> > > > > > >     1 file changed, 383 insertions(+)
> > > > > > >     create mode 100644 Documentation/devicetree/bindings/iio/adc/st,stm32-mdf-adc.yaml
> > > > > > > 
> > > > > > > diff --git a/Documentation/devicetree/bindings/iio/adc/st,stm32-mdf-adc.yaml b/Documentation/devicetree/bindings/iio/adc/st,stm32-mdf-adc.yaml
> > > > > > > new file mode 100644
> > > > > > > index 000000000000..f2fbc3e150e8
> > > > > > > --- /dev/null
> > > > > > > +++ b/Documentation/devicetree/bindings/iio/adc/st,stm32-mdf-adc.yaml
> > > > > > > @@ -0,0 +1,383 @@
> > > > > > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > > > > > > +%YAML 1.2
> > > > > > > +---
> > > > > > > +$id: http://devicetree.org/schemas/iio/adc/st,stm32-mdf-adc.yaml#
> > > > > > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > > > > > +
> > > > > > > +title: STMicroelectronics STM32 Multi-function Digital Filter (MDF) ADC
> > > > > > > +
> > > > > > > +maintainers:
> > > > > > > +  - Olivier Moysan <olivier.moysan@foss.st.com>
> > > > > > > +
> > > > > > > +description: |
> > > > > > > +  STM32 MDF ADC is a sigma delta analog-to-digital converter dedicated to
> > > > > > > +  interface external sigma delta modulators to STM32 micro controllers.
> > > > > > > +
> > > > > > > +properties:
> > > > > > > +  compatible:
> > > > > > > +    enum:
> > > > > > > +      - st,stm32mp25-mdf
> > > > > > > +      - st,stm32mp23-mdf
> > > > > > > +
> > > > > > > +  reg:
> > > > > > > +    minItems: 1
> > > > > > > +    maxItems: 2
> > > > > > 
> > > > > > This needs an items list here. The size of the regions seems like crap
> > > > > > to begin with...
> > > > > > 
> > > > > > > +
> > > > > > > +  clocks:
> > > > > > > +    maxItems: 1
> > > > > > > +
> > > > > > > +  clock-names:
> > > > > > > +    description: Internal clock used for MDF digital processing.
> > > > > > > +    items:
> > > > > > > +      - const: ker_ck
> > > > > > 
> > > > > > This is pointless when you only have one.
> > > > > > 
> > > > > 
> > > > > I agree that it could be dropped. However, it is useful for using
> > > > > devm_regmap_init_mmio_clk.
> > > > 
> > > > Ah, because that function if you pass NULL to it, it doesn't mean no
> > > > string, it means no clock.
> > > > 
> > > 
> > > The MDF has two clocks (AHB clock for register accesses and ker_ck for
> > > peripheral processing). However, these two clocks share the same gate. So,
> > > only the ker_ck clock is exposed in the driver.
> > 
> > That's incorrect, you should have two clocks in DT if the block has two
> > even if they have a shared gate.
> > 
> 
> This would not be consistent with the architectural choice made for the
> STM32MP25. The RCC driver provides an abstraction to manage these two clocks
> as one, since they are controlled by the same gate. The binding incorporates
> this abstraction to manage only a single clock.
> 
> A large number of peripherals on STM32MP25 have the same architecture and
> follow this implementation rule. So managing both clocks in the MDF driver
> would create a consistency issue with the other peripherals.

Doesn't really matter how you've modelled the clock controller, cos you
can just have the same clock be both inputs, and retain a correct model
of this hardware?

> 
> > > The regmap api is a convenient way to manage registers and gate the AHB
> > > clock only on register accesses. Removing clock-names no longer allows you
> > > to benefit from clock management handled by the regmap framework, and means
> > > that this must be managed explicitly, partially or entirely, in the driver.
> > > 
> > > > > 
> > > > > > > +
> > > > > > > +  "#clock-cells":
> > > > > > > +    enum: [0, 1]
> > > > > > 
> > > > > > Why is this not fixed? Also why are parts of your own device consuming
> > > > > > the clocks?
> > > > 
> > > > Reading the docs, this has to be 1, you have two clocks?
> > > > 
> > > > Not sure why you skipped this and skipped explaining why you are
> > > > consuming your own clocks.
> > > > 
> > > 
> > > Yes, we can have two clocks gated independently but sharing the same rate.
> > > 
> > > Using the clock framework apis seemed to me the right way to manage cck1 and
> > > cck0 gating and divider computing. I think I would have to introduce
> > > proprietary properties and have to implement code in the driver, that would
> > > be handled natively by the framework otherwise.
> > 
> > The CCF is still the right way to do it, especially since CCK0/1 can be
> > exported to other devices. I don't believe you need to actually have a
> > reference in DT to do this though, plenty of "real" clock controllers
> > have only one input clock and hang a whole tree with multiple layers off
> > that.
> > Down below I mentioned this under "ouroboros devices", I think this kind
> > of ability to chose which clock a channel uses is a fairly normal thing
> > to do in IIO land, I just dunno what the preferred mechanism is - I just
> > know that it is not referencing yourself (probably it's some sort of
> > property that you put in a channel node that says 'blah-clock = "cck0"',
> > but better that the IIO folks answer.
> > 
> 
> The adc.yaml binding do not expose clock properties. But maybe IIO experts
> can answer about this.
> 
> > > > > > > +  clock-output-names:
> > > > > > > +    description: |
> > > > > > > +      CCK0 and CCK1 are optional output clocks, which share the same clock frequency,
> > > > > > > +      but can be gated independently to save power.
> > > > > > > +    minItems: 1
> > > > > > > +    maxItems: 2
> > > > > > > +    oneOf:
> > > > > > > +      - items:
> > > > > > > +          - const: cck0
> > > > > > > +      - items:
> > > > > > > +          - const: cck1
> > > > > > > +      - items:
> > > > > > > +          - const: cck0
> > > > > > > +          - const: cck1
> > > > > > > +
> > > > > > > +  clock-frequency:
> > > > > > > +    description: |
> > > > > > > +      Common clock frequency (Hz) for CCK0 and CCK1 output clocks.
> > > > > > > +      The frequency must be a multiple of the "ker_ck" clock frequency.
> > > > > > > +    maximum: 25000000
> > > > > > 
> > > > > > Should not be needed, the consumers request what they need.
> > > > > > 
> > > > > 
> > > > > The CCKx clock frequency depends on the maximum rate supported by the sigma
> > > > > delta converters (for instance a digital mic) and the expected decimation
> > > > > ratio on the bitstream. Typically this determines the frequency on the SPI
> > > > > bus.
> > > > > This rate is defined statically and shared by the CCKx clocks. So IMHO, as
> > > > > this rate is unique, it can look strange to let the consumer define it.
> > > > > Moreover, it seems to me that clock-frequency is already used to configure
> > > > > the frequency of a provider in some other bindings.
> > > > > For instance: Documentation/devicetree/bindings/clock/silabs,si570.yaml
> > > > 
> > > > This is a binding from the age of antiquity, using it to justify your
> > > > use is actually harming your argument rather than helping. Your clock
> > > > consumers should be providing the information about what the rate should
> > > > be, and if you need to do this in dt you can use assigned-clock-rates.
> > > > 
> > > 
> > > ok, I will move this to clock consumer with assigned-clock properties.
> > > 
> > > > > So, it's not clear for me, what is the restriction on clock-frequency
> > > > > property.
> > > > > > > +
> > > > > > > +  ranges: true
> > > > > > > +
> > > > > > > +  clock-ranges: true
> > > > > > > +
> > > > > > > +  resets:
> > > > > > > +    maxItems: 1
> > > > > > > +
> > > > > > > +  reset-names:
> > > > > > > +    items:
> > > > > > > +      - const: mdf
> > > > 
> > > > Same applies here as to the clock names fwiw.
> > > > 
> > > 
> > > Yes, I removed this.
> > > 
> > > > > > > +
> > > > > > > +  access-controllers:
> > > > > > > +    $ref: /schemas/types.yaml#/definitions/phandle-array
> > > > > > > +    description: |
> > > > > > > +      Phandle to the rifsc device to check access right.
> > > > > > > +
> > > > > > > +  power-domains:
> > > > > > > +    maxItems: 1
> > > > > > > +
> > > > > > > +  st,interleave:
> > > > > > > +    description: |
> > > > > > > +      List of phandles of interleaved filters. The indexes of interleaved filters must be
> > > > > > > +      consecutives starting from 0 (i.e in range [0..N]). The samples from interleaved filters
> > > > > > > +      are muxed in a single channel and retrieved through the device associated to the filter 0.
> > > > > > > +      The filters 1..N have to be enabled, but inherit their configuration from filter 0.
> > > > > > > +    $ref: /schemas/types.yaml#/definitions/phandle-array
> > > > > > 
> > > > > > No idea what these even are, but this is probably not the right way to
> > > > > > represent the relationship between devices. They're apparently ADCs, but
> > > > > > this is also an ADC so I'm not sure what's going on here at all.
> > > > 
> > > > Yeah, after more thought this should not be done like this at all,
> > > > especially if these filters the phandle point to are part of this device
> > > > itself, which I suspect they are. If that's the case, you don't need
> > > > phandles to even do this, you just need an int that says what N is.
> > > > 
> > > 
> > > Yes, can be an index as it is an internal reference. I will change this.
> > > 
> > > > > > 
> > > > > > > +
> > > > > > > +required:
> > > > > > > +  - compatible
> > > > > > > +  - reg
> > > > > > > +  - ranges
> > > > > > > +  - clocks
> > > > > > > +  - clock-names
> > > > > > > +  - clock-ranges
> > > > > > > +  - "#address-cells"
> > > > > > > +  - "#size-cells"
> > > > > > > +
> > > > > > > +additionalProperties: false
> > > > > > > +
> > > > > > > +patternProperties:
> > > > > > > +  "^sitf@[0-9]+$":
> > > > > > > +    type: object
> > > > > > > +    description: Serial interface child node
> > > > > > 
> > > > > > Why is this a child node at all?
> > > > > > Probably not worth reviewing more without a link to the docs for this
> > > > > > device so I can figure out what on earth is going on!
> > > > > > 
> > > > > 
> > > > > The MDF is a digital filter for sigma-delta bitstreams, rather than the
> > > > > analog-to-digital converter itself.
> > > > > 
> > > > > Here is the link to STM32MP25 reference manuel
> > > > > https://www.st.com/resource/en/reference_manual/rm0457-stm32mp2325xx-advanced-armbased-3264bit-mpus-stmicroelectronics.pdf
> > > > > Chapter 45: Multi-function digital filter (MDF)
> > > > > 
> > > > > On STMP32MP25 SoC, the MDF provides 8 serial interfaces (SITF) and 8 digital
> > > > > filters (DFLT) which can be connected through a multiplexer.
> > > > > 
> > > > > Below is a schematic view of typical applications targeted by this
> > > > > peripheral
> > > > > 
> > > > > 
> > > > > Audio use case:
> > > > > 
> > > > > 		mdf
> > > > >               +-------------------------------------+
> > > > > +------+    | +------+    +------+    +------+    |
> > > > > | dmic | -> | | sitf | -> | mux  | -> | dflt | -- | -> audio device
> > > > > +------+    | +------+    +------+    +------+    |
> > > > >               +-------------------------------------+
> > > > > 
> > > > > For instance, in an audio use case the serial interface can be configured to
> > > > > provide the clock to the digital microphone (cck0, cck1 or both) at a common
> > > > > predefined rate, and to retrieve the PDM samples.
> > > > > The serial interface provides this samples to a digital filter, which
> > > > > delivers PCM samples on its output.
> > > > > 
> > > > > 
> > > > > Analog use case:
> > > > > 
> > > > > 		mdf
> > > > >                 +-------------------------------------+
> > > > > +--------+    | +------+    +------+    +------+    |
> > > > > | sd adc | -> | | sitf | -> | mux  | -> | dflt | -- | -> iio device
> > > > > +--------+    | +------+    +------+    +------+    |
> > > > >                 +-------------------------------------+
> > > > 
> > > > 
> > > > So, looking at the docs and a brief chat with Jonathan about this
> > > > device, I believe you've got things backwards and this is actually the backend,
> > > > and the adc should be the one populating the io-backends property
> > > > pointing to this device. You should have io-backend-cells, and I assume
> > > > that there should be a cell for the adc to select which dlft it is connected
> > > > to.
> > > > 
> > > 
> > > There have already been lengthy discussions in the past about a DFSDM
> > > peripheral on STM32MP1, which has features similar to those of the MDF and
> > > similar implementation constraints. For the DFSDM, a solution based on an
> > > IIO backend had been upstreamed. The MDF follows the same architecture. I
> > > need to take a little time to dive back into this issue.
> > 
> > One thing to note there is that you retrofitted the backends onto that
> > device, and the original design here is much older (it's a text
> > binding).
> > 
> > 
> > > 
> > > DFSDM sources:
> > > drivers/iio/adc/stm32-dfsdm-adc.c
> > > drivers/iio/adc/stm32-dfsdm-core.c
> > > 
> > > Here is a sample of DFSDM DT
> > > 
> > > sd_adc0: simple-sd-adc0 {
> > > 	compatible = "sd-modulator";
> > > 	#io-backend-cells = <0>;
> > > 	vref-supply = <&v3v3>;
> > 
> > Yeah, pretty sure this is wrong (backwards). The backend is the thing
> > that gets data from an ADC not the ADC.
> > 
> 
> The backend framework was introduced to implement complex IIO aggregate
> devices. The hardwares that were driving this need were analog device ad9467
> and ST DFSDM.
> 
> https://lore.kernel.org/linux-iio/20231204144925.4fe9922f@jic23-huawei/T/#m222f5175273b81dbfe40b7f0daffcdc67d6cb8ff
> 
> From drivers/iio/industrialio-backend.c:
> 
> "The typical architecture is to have one device as the frontend device which
> can be "linked" against one or multiple backend devices. All the IIO and
> userspace interface is expected to be registers/managed by the frontend
> device which will callback into the backends when needed (to get/set some
> configuration that it does not directly control)."
> 
>  *                                    ---------------------
>  * ------------------                 | ------------
>  * |     ADC        |-----------------| | ADC CORE |
>  * | (Frontend/IIO) | Serial Data (eg | |(backend) |-------
>  * |                |-----------------| ------------
>  * ------------------                 ---------------------
> 
> The MDF (or DFSDM) use case, follows this topology:
> - The SD modulator (ADC core) registers in backend framework
> - The MDF registers in IIO framework and exposes the IIO devices
>   It also get configuration (ref voltage) from SD modulator, to compute
> scaling.
> 
> I agree that if we consider the terms frontend and backend, the elements in
> the data flow do not have the roles that we would naturally expect. However,
> if we consider the expected role of the elements using the iio-backend
> framework, the usage seems coherent to me.

I didn't even get as far as sd modulators or whatever, if I understand
correctly the ADC inputs on this device are fed by the onboard ADC?
(https://lore.kernel.org/linux-iio/20261006-adc-stm32mp25-v1-v4-0-d31ec75aecf3@foss.st.com/)
In that case, I can't really see how it makes sense for the primary iio
device to change when data is fed back through the mdf or taken
directly from the ADC itself, particularly given how that would affect
the userspace interface.

The "serial" side of this seems in a similar vein to the adi,axi-adc
stuff, which when considered with the ADC inputs, really does give me
the impression this is backwards.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH 1/3] dt-bindings: iio: adc: add bindings for stm32 mdf filter

[Olivier MOYSAN]

On 10/14/26 17:15, Conor Dooley wrote:
> On Mon, Oct 12, 2026 at 02:56:04PM +0200, Olivier MOYSAN wrote:
>> Hi Conor,
>>
>> On 10/9/26 21:12, Conor Dooley wrote:
>>> On Thu, Oct 08, 2026 at 06:37:26PM +0200, Olivier MOYSAN wrote:
>>>> Hi Conor,
>>>>
>>>> On 10/8/26 12:11, Conor Dooley wrote:
>>>>> On Wed, Oct 07, 2026 at 11:01:28AM +0200, Olivier MOYSAN wrote:
>>>>>> Hi Conor,
>>>>>>
>>>>>> Thanks for the review
>>>>>>
>>>>>> On 10/1/26 20:32, Conor Dooley wrote:
>>>>>>> On Thu, Oct 01, 2026 at 04:56:45PM +0200, Olivier Moysan wrote:
>>>>>>>> Add bindings that describes STM32 MDF settings to support
>>>>>>>> digital filtering for Pulse Density Modulation (PDM) microphones
>>>>>>>> and analog sigma delta modulators.
>>>>>>>>
>>>>>>>> Signed-off-by: Olivier Moysan <olivier.moysan@foss.st.com>
>>>>>>>> ---
>>>>>>>>      .../bindings/iio/adc/st,stm32-mdf-adc.yaml    | 383 ++++++++++++++++++
>>>>>>>>      1 file changed, 383 insertions(+)
>>>>>>>>      create mode 100644 Documentation/devicetree/bindings/iio/adc/st,stm32-mdf-adc.yaml
>>>>>>>>
>>>>>>>> diff --git a/Documentation/devicetree/bindings/iio/adc/st,stm32-mdf-adc.yaml b/Documentation/devicetree/bindings/iio/adc/st,stm32-mdf-adc.yaml
>>>>>>>> new file mode 100644
>>>>>>>> index 000000000000..f2fbc3e150e8
>>>>>>>> --- /dev/null
>>>>>>>> +++ b/Documentation/devicetree/bindings/iio/adc/st,stm32-mdf-adc.yaml
>>>>>>>> @@ -0,0 +1,383 @@
>>>>>>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>>>>>>>> +%YAML 1.2
>>>>>>>> +---
>>>>>>>> +$id: http://devicetree.org/schemas/iio/adc/st,stm32-mdf-adc.yaml#
>>>>>>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>>>>>>>> +
>>>>>>>> +title: STMicroelectronics STM32 Multi-function Digital Filter (MDF) ADC
>>>>>>>> +
>>>>>>>> +maintainers:
>>>>>>>> +  - Olivier Moysan <olivier.moysan@foss.st.com>
>>>>>>>> +
>>>>>>>> +description: |
>>>>>>>> +  STM32 MDF ADC is a sigma delta analog-to-digital converter dedicated to
>>>>>>>> +  interface external sigma delta modulators to STM32 micro controllers.
>>>>>>>> +
>>>>>>>> +properties:
>>>>>>>> +  compatible:
>>>>>>>> +    enum:
>>>>>>>> +      - st,stm32mp25-mdf
>>>>>>>> +      - st,stm32mp23-mdf
>>>>>>>> +
>>>>>>>> +  reg:
>>>>>>>> +    minItems: 1
>>>>>>>> +    maxItems: 2
>>>>>>>
>>>>>>> This needs an items list here. The size of the regions seems like crap
>>>>>>> to begin with...
>>>>>>>
>>>>>>>> +
>>>>>>>> +  clocks:
>>>>>>>> +    maxItems: 1
>>>>>>>> +
>>>>>>>> +  clock-names:
>>>>>>>> +    description: Internal clock used for MDF digital processing.
>>>>>>>> +    items:
>>>>>>>> +      - const: ker_ck
>>>>>>>
>>>>>>> This is pointless when you only have one.
>>>>>>>
>>>>>>
>>>>>> I agree that it could be dropped. However, it is useful for using
>>>>>> devm_regmap_init_mmio_clk.
>>>>>
>>>>> Ah, because that function if you pass NULL to it, it doesn't mean no
>>>>> string, it means no clock.
>>>>>
>>>>
>>>> The MDF has two clocks (AHB clock for register accesses and ker_ck for
>>>> peripheral processing). However, these two clocks share the same gate. So,
>>>> only the ker_ck clock is exposed in the driver.
>>>
>>> That's incorrect, you should have two clocks in DT if the block has two
>>> even if they have a shared gate.
>>>
>>
>> This would not be consistent with the architectural choice made for the
>> STM32MP25. The RCC driver provides an abstraction to manage these two clocks
>> as one, since they are controlled by the same gate. The binding incorporates
>> this abstraction to manage only a single clock.
>>
>> A large number of peripherals on STM32MP25 have the same architecture and
>> follow this implementation rule. So managing both clocks in the MDF driver
>> would create a consistency issue with the other peripherals.
> 
> Doesn't really matter how you've modelled the clock controller, cos you
> can just have the same clock be both inputs, and retain a correct model
> of this hardware?
> 
>>
>>>> The regmap api is a convenient way to manage registers and gate the AHB
>>>> clock only on register accesses. Removing clock-names no longer allows you
>>>> to benefit from clock management handled by the regmap framework, and means
>>>> that this must be managed explicitly, partially or entirely, in the driver.
>>>>
>>>>>>
>>>>>>>> +
>>>>>>>> +  "#clock-cells":
>>>>>>>> +    enum: [0, 1]
>>>>>>>
>>>>>>> Why is this not fixed? Also why are parts of your own device consuming
>>>>>>> the clocks?
>>>>>
>>>>> Reading the docs, this has to be 1, you have two clocks?
>>>>>
>>>>> Not sure why you skipped this and skipped explaining why you are
>>>>> consuming your own clocks.
>>>>>
>>>>
>>>> Yes, we can have two clocks gated independently but sharing the same rate.
>>>>
>>>> Using the clock framework apis seemed to me the right way to manage cck1 and
>>>> cck0 gating and divider computing. I think I would have to introduce
>>>> proprietary properties and have to implement code in the driver, that would
>>>> be handled natively by the framework otherwise.
>>>
>>> The CCF is still the right way to do it, especially since CCK0/1 can be
>>> exported to other devices. I don't believe you need to actually have a
>>> reference in DT to do this though, plenty of "real" clock controllers
>>> have only one input clock and hang a whole tree with multiple layers off
>>> that.
>>> Down below I mentioned this under "ouroboros devices", I think this kind
>>> of ability to chose which clock a channel uses is a fairly normal thing
>>> to do in IIO land, I just dunno what the preferred mechanism is - I just
>>> know that it is not referencing yourself (probably it's some sort of
>>> property that you put in a channel node that says 'blah-clock = "cck0"',
>>> but better that the IIO folks answer.
>>>
>>
>> The adc.yaml binding do not expose clock properties. But maybe IIO experts
>> can answer about this.
>>
>>>>>>>> +  clock-output-names:
>>>>>>>> +    description: |
>>>>>>>> +      CCK0 and CCK1 are optional output clocks, which share the same clock frequency,
>>>>>>>> +      but can be gated independently to save power.
>>>>>>>> +    minItems: 1
>>>>>>>> +    maxItems: 2
>>>>>>>> +    oneOf:
>>>>>>>> +      - items:
>>>>>>>> +          - const: cck0
>>>>>>>> +      - items:
>>>>>>>> +          - const: cck1
>>>>>>>> +      - items:
>>>>>>>> +          - const: cck0
>>>>>>>> +          - const: cck1
>>>>>>>> +
>>>>>>>> +  clock-frequency:
>>>>>>>> +    description: |
>>>>>>>> +      Common clock frequency (Hz) for CCK0 and CCK1 output clocks.
>>>>>>>> +      The frequency must be a multiple of the "ker_ck" clock frequency.
>>>>>>>> +    maximum: 25000000
>>>>>>>
>>>>>>> Should not be needed, the consumers request what they need.
>>>>>>>
>>>>>>
>>>>>> The CCKx clock frequency depends on the maximum rate supported by the sigma
>>>>>> delta converters (for instance a digital mic) and the expected decimation
>>>>>> ratio on the bitstream. Typically this determines the frequency on the SPI
>>>>>> bus.
>>>>>> This rate is defined statically and shared by the CCKx clocks. So IMHO, as
>>>>>> this rate is unique, it can look strange to let the consumer define it.
>>>>>> Moreover, it seems to me that clock-frequency is already used to configure
>>>>>> the frequency of a provider in some other bindings.
>>>>>> For instance: Documentation/devicetree/bindings/clock/silabs,si570.yaml
>>>>>
>>>>> This is a binding from the age of antiquity, using it to justify your
>>>>> use is actually harming your argument rather than helping. Your clock
>>>>> consumers should be providing the information about what the rate should
>>>>> be, and if you need to do this in dt you can use assigned-clock-rates.
>>>>>
>>>>
>>>> ok, I will move this to clock consumer with assigned-clock properties.
>>>>
>>>>>> So, it's not clear for me, what is the restriction on clock-frequency
>>>>>> property.
>>>>>>>> +
>>>>>>>> +  ranges: true
>>>>>>>> +
>>>>>>>> +  clock-ranges: true
>>>>>>>> +
>>>>>>>> +  resets:
>>>>>>>> +    maxItems: 1
>>>>>>>> +
>>>>>>>> +  reset-names:
>>>>>>>> +    items:
>>>>>>>> +      - const: mdf
>>>>>
>>>>> Same applies here as to the clock names fwiw.
>>>>>
>>>>
>>>> Yes, I removed this.
>>>>
>>>>>>>> +
>>>>>>>> +  access-controllers:
>>>>>>>> +    $ref: /schemas/types.yaml#/definitions/phandle-array
>>>>>>>> +    description: |
>>>>>>>> +      Phandle to the rifsc device to check access right.
>>>>>>>> +
>>>>>>>> +  power-domains:
>>>>>>>> +    maxItems: 1
>>>>>>>> +
>>>>>>>> +  st,interleave:
>>>>>>>> +    description: |
>>>>>>>> +      List of phandles of interleaved filters. The indexes of interleaved filters must be
>>>>>>>> +      consecutives starting from 0 (i.e in range [0..N]). The samples from interleaved filters
>>>>>>>> +      are muxed in a single channel and retrieved through the device associated to the filter 0.
>>>>>>>> +      The filters 1..N have to be enabled, but inherit their configuration from filter 0.
>>>>>>>> +    $ref: /schemas/types.yaml#/definitions/phandle-array
>>>>>>>
>>>>>>> No idea what these even are, but this is probably not the right way to
>>>>>>> represent the relationship between devices. They're apparently ADCs, but
>>>>>>> this is also an ADC so I'm not sure what's going on here at all.
>>>>>
>>>>> Yeah, after more thought this should not be done like this at all,
>>>>> especially if these filters the phandle point to are part of this device
>>>>> itself, which I suspect they are. If that's the case, you don't need
>>>>> phandles to even do this, you just need an int that says what N is.
>>>>>
>>>>
>>>> Yes, can be an index as it is an internal reference. I will change this.
>>>>
>>>>>>>
>>>>>>>> +
>>>>>>>> +required:
>>>>>>>> +  - compatible
>>>>>>>> +  - reg
>>>>>>>> +  - ranges
>>>>>>>> +  - clocks
>>>>>>>> +  - clock-names
>>>>>>>> +  - clock-ranges
>>>>>>>> +  - "#address-cells"
>>>>>>>> +  - "#size-cells"
>>>>>>>> +
>>>>>>>> +additionalProperties: false
>>>>>>>> +
>>>>>>>> +patternProperties:
>>>>>>>> +  "^sitf@[0-9]+$":
>>>>>>>> +    type: object
>>>>>>>> +    description: Serial interface child node
>>>>>>>
>>>>>>> Why is this a child node at all?
>>>>>>> Probably not worth reviewing more without a link to the docs for this
>>>>>>> device so I can figure out what on earth is going on!
>>>>>>>
>>>>>>
>>>>>> The MDF is a digital filter for sigma-delta bitstreams, rather than the
>>>>>> analog-to-digital converter itself.
>>>>>>
>>>>>> Here is the link to STM32MP25 reference manuel
>>>>>> https://www.st.com/resource/en/reference_manual/rm0457-stm32mp2325xx-advanced-armbased-3264bit-mpus-stmicroelectronics.pdf
>>>>>> Chapter 45: Multi-function digital filter (MDF)
>>>>>>
>>>>>> On STMP32MP25 SoC, the MDF provides 8 serial interfaces (SITF) and 8 digital
>>>>>> filters (DFLT) which can be connected through a multiplexer.
>>>>>>
>>>>>> Below is a schematic view of typical applications targeted by this
>>>>>> peripheral
>>>>>>
>>>>>>
>>>>>> Audio use case:
>>>>>>
>>>>>> 		mdf
>>>>>>                +-------------------------------------+
>>>>>> +------+    | +------+    +------+    +------+    |
>>>>>> | dmic | -> | | sitf | -> | mux  | -> | dflt | -- | -> audio device
>>>>>> +------+    | +------+    +------+    +------+    |
>>>>>>                +-------------------------------------+
>>>>>>
>>>>>> For instance, in an audio use case the serial interface can be configured to
>>>>>> provide the clock to the digital microphone (cck0, cck1 or both) at a common
>>>>>> predefined rate, and to retrieve the PDM samples.
>>>>>> The serial interface provides this samples to a digital filter, which
>>>>>> delivers PCM samples on its output.
>>>>>>
>>>>>>
>>>>>> Analog use case:
>>>>>>
>>>>>> 		mdf
>>>>>>                  +-------------------------------------+
>>>>>> +--------+    | +------+    +------+    +------+    |
>>>>>> | sd adc | -> | | sitf | -> | mux  | -> | dflt | -- | -> iio device
>>>>>> +--------+    | +------+    +------+    +------+    |
>>>>>>                  +-------------------------------------+
>>>>>
>>>>>
>>>>> So, looking at the docs and a brief chat with Jonathan about this
>>>>> device, I believe you've got things backwards and this is actually the backend,
>>>>> and the adc should be the one populating the io-backends property
>>>>> pointing to this device. You should have io-backend-cells, and I assume
>>>>> that there should be a cell for the adc to select which dlft it is connected
>>>>> to.
>>>>>
>>>>
>>>> There have already been lengthy discussions in the past about a DFSDM
>>>> peripheral on STM32MP1, which has features similar to those of the MDF and
>>>> similar implementation constraints. For the DFSDM, a solution based on an
>>>> IIO backend had been upstreamed. The MDF follows the same architecture. I
>>>> need to take a little time to dive back into this issue.
>>>
>>> One thing to note there is that you retrofitted the backends onto that
>>> device, and the original design here is much older (it's a text
>>> binding).
>>>
>>>
>>>>
>>>> DFSDM sources:
>>>> drivers/iio/adc/stm32-dfsdm-adc.c
>>>> drivers/iio/adc/stm32-dfsdm-core.c
>>>>
>>>> Here is a sample of DFSDM DT
>>>>
>>>> sd_adc0: simple-sd-adc0 {
>>>> 	compatible = "sd-modulator";
>>>> 	#io-backend-cells = <0>;
>>>> 	vref-supply = <&v3v3>;
>>>
>>> Yeah, pretty sure this is wrong (backwards). The backend is the thing
>>> that gets data from an ADC not the ADC.
>>>
>>
>> The backend framework was introduced to implement complex IIO aggregate
>> devices. The hardwares that were driving this need were analog device ad9467
>> and ST DFSDM.
>>
>> https://lore.kernel.org/linux-iio/20231204144925.4fe9922f@jic23-huawei/T/#m222f5175273b81dbfe40b7f0daffcdc67d6cb8ff
>>
>>  From drivers/iio/industrialio-backend.c:
>>
>> "The typical architecture is to have one device as the frontend device which
>> can be "linked" against one or multiple backend devices. All the IIO and
>> userspace interface is expected to be registers/managed by the frontend
>> device which will callback into the backends when needed (to get/set some
>> configuration that it does not directly control)."
>>
>>   *                                    ---------------------
>>   * ------------------                 | ------------
>>   * |     ADC        |-----------------| | ADC CORE |
>>   * | (Frontend/IIO) | Serial Data (eg | |(backend) |-------
>>   * |                |-----------------| ------------
>>   * ------------------                 ---------------------
>>
>> The MDF (or DFSDM) use case, follows this topology:
>> - The SD modulator (ADC core) registers in backend framework
>> - The MDF registers in IIO framework and exposes the IIO devices
>>    It also get configuration (ref voltage) from SD modulator, to compute
>> scaling.
>>
>> I agree that if we consider the terms frontend and backend, the elements in
>> the data flow do not have the roles that we would naturally expect. However,
>> if we consider the expected role of the elements using the iio-backend
>> framework, the usage seems coherent to me.
> 
> I didn't even get as far as sd modulators or whatever, if I understand
> correctly the ADC inputs on this device are fed by the onboard ADC?
> (https://lore.kernel.org/linux-iio/20261006-adc-stm32mp25-v1-v4-0-d31ec75aecf3@foss.st.com/)
> In that case, I can't really see how it makes sense for the primary iio
> device to change when data is fed back through the mdf or taken
> directly from the ADC itself, particularly given how that would affect
> the userspace interface.
> 
> The "serial" side of this seems in a similar vein to the adi,axi-adc
> stuff, which when considered with the ADC inputs, really does give me
> the impression this is backwards.

Some clarifications about the STM32MP25. This SoC does indeed provide 
ADCs, and these can be connected to the MDF via a dedicated interface. 
(but not the serial interface).

However, this use case is not supported by the driver. Only sigma-delta 
modulators, external to the SoC and connected via the serial interface, 
are supported. On ST boards, the only available SD modulators are 
digital microphones.

Anyway, if the internal ADC to MDF use case was supported, the issue 
would be the same. The whole ADC + MDF set would be presented at the 
interface as an aggregated device, and the ADC data would not be 
directly accessible to the user.

BRs
Olivier

Re: [PATCH 1/3] dt-bindings: iio: adc: add bindings for stm32 mdf filter

[Conor Dooley]

[-- Attachment #1: Type: text/plain, Size: 9728 bytes --]

On Wed, Oct 14, 2026 at 06:51:45PM +0200, Olivier MOYSAN wrote:
> On 10/14/26 17:15, Conor Dooley wrote:
> > On Mon, Oct 12, 2026 at 02:56:04PM +0200, Olivier MOYSAN wrote:
> > > On 10/9/26 21:12, Conor Dooley wrote:
> > > > On Thu, Oct 08, 2026 at 06:37:26PM +0200, Olivier MOYSAN wrote:
> > > > > On 10/8/26 12:11, Conor Dooley wrote:
> > > > > > On Wed, Oct 07, 2026 at 11:01:28AM +0200, Olivier MOYSAN wrote:
> > > > > > > On 10/1/26 20:32, Conor Dooley wrote:
> > > > > > > > 
> > > > > > > > > +
> > > > > > > > > +required:
> > > > > > > > > +  - compatible
> > > > > > > > > +  - reg
> > > > > > > > > +  - ranges
> > > > > > > > > +  - clocks
> > > > > > > > > +  - clock-names
> > > > > > > > > +  - clock-ranges
> > > > > > > > > +  - "#address-cells"
> > > > > > > > > +  - "#size-cells"
> > > > > > > > > +
> > > > > > > > > +additionalProperties: false
> > > > > > > > > +
> > > > > > > > > +patternProperties:
> > > > > > > > > +  "^sitf@[0-9]+$":
> > > > > > > > > +    type: object
> > > > > > > > > +    description: Serial interface child node
> > > > > > > > 
> > > > > > > > Why is this a child node at all?
> > > > > > > > Probably not worth reviewing more without a link to the docs for this
> > > > > > > > device so I can figure out what on earth is going on!
> > > > > > > > 
> > > > > > > 
> > > > > > > The MDF is a digital filter for sigma-delta bitstreams, rather than the
> > > > > > > analog-to-digital converter itself.
> > > > > > > 
> > > > > > > Here is the link to STM32MP25 reference manuel
> > > > > > > https://www.st.com/resource/en/reference_manual/rm0457-stm32mp2325xx-advanced-armbased-3264bit-mpus-stmicroelectronics.pdf
> > > > > > > Chapter 45: Multi-function digital filter (MDF)
> > > > > > > 
> > > > > > > On STMP32MP25 SoC, the MDF provides 8 serial interfaces (SITF) and 8 digital
> > > > > > > filters (DFLT) which can be connected through a multiplexer.
> > > > > > > 
> > > > > > > Below is a schematic view of typical applications targeted by this
> > > > > > > peripheral
> > > > > > > 
> > > > > > > 
> > > > > > > Audio use case:
> > > > > > > 
> > > > > > > 		mdf
> > > > > > >                +-------------------------------------+
> > > > > > > +------+    | +------+    +------+    +------+    |
> > > > > > > | dmic | -> | | sitf | -> | mux  | -> | dflt | -- | -> audio device
> > > > > > > +------+    | +------+    +------+    +------+    |
> > > > > > >                +-------------------------------------+
> > > > > > > 
> > > > > > > For instance, in an audio use case the serial interface can be configured to
> > > > > > > provide the clock to the digital microphone (cck0, cck1 or both) at a common
> > > > > > > predefined rate, and to retrieve the PDM samples.
> > > > > > > The serial interface provides this samples to a digital filter, which
> > > > > > > delivers PCM samples on its output.
> > > > > > > 
> > > > > > > 
> > > > > > > Analog use case:
> > > > > > > 
> > > > > > > 		mdf
> > > > > > >                  +-------------------------------------+
> > > > > > > +--------+    | +------+    +------+    +------+    |
> > > > > > > | sd adc | -> | | sitf | -> | mux  | -> | dflt | -- | -> iio device
> > > > > > > +--------+    | +------+    +------+    +------+    |
> > > > > > >                  +-------------------------------------+
> > > > > > 
> > > > > > 
> > > > > > So, looking at the docs and a brief chat with Jonathan about this
> > > > > > device, I believe you've got things backwards and this is actually the backend,
> > > > > > and the adc should be the one populating the io-backends property
> > > > > > pointing to this device. You should have io-backend-cells, and I assume
> > > > > > that there should be a cell for the adc to select which dlft it is connected
> > > > > > to.
> > > > > > 
> > > > > 
> > > > > There have already been lengthy discussions in the past about a DFSDM
> > > > > peripheral on STM32MP1, which has features similar to those of the MDF and
> > > > > similar implementation constraints. For the DFSDM, a solution based on an
> > > > > IIO backend had been upstreamed. The MDF follows the same architecture. I
> > > > > need to take a little time to dive back into this issue.
> > > > 
> > > > One thing to note there is that you retrofitted the backends onto that
> > > > device, and the original design here is much older (it's a text
> > > > binding).
> > > > 
> > > > 
> > > > > 
> > > > > DFSDM sources:
> > > > > drivers/iio/adc/stm32-dfsdm-adc.c
> > > > > drivers/iio/adc/stm32-dfsdm-core.c
> > > > > 
> > > > > Here is a sample of DFSDM DT
> > > > > 
> > > > > sd_adc0: simple-sd-adc0 {
> > > > > 	compatible = "sd-modulator";
> > > > > 	#io-backend-cells = <0>;
> > > > > 	vref-supply = <&v3v3>;
> > > > 
> > > > Yeah, pretty sure this is wrong (backwards). The backend is the thing
> > > > that gets data from an ADC not the ADC.
> > > > 
> > > 
> > > The backend framework was introduced to implement complex IIO aggregate
> > > devices. The hardwares that were driving this need were analog device ad9467
> > > and ST DFSDM.
> > > 
> > > https://lore.kernel.org/linux-iio/20231204144925.4fe9922f@jic23-huawei/T/#m222f5175273b81dbfe40b7f0daffcdc67d6cb8ff
> > > 
> > >  From drivers/iio/industrialio-backend.c:
> > > 
> > > "The typical architecture is to have one device as the frontend device which
> > > can be "linked" against one or multiple backend devices. All the IIO and
> > > userspace interface is expected to be registers/managed by the frontend
> > > device which will callback into the backends when needed (to get/set some
> > > configuration that it does not directly control)."
> > > 
> > >   *                                    ---------------------
> > >   * ------------------                 | ------------
> > >   * |     ADC        |-----------------| | ADC CORE |
> > >   * | (Frontend/IIO) | Serial Data (eg | |(backend) |-------
> > >   * |                |-----------------| ------------
> > >   * ------------------                 ---------------------
> > > 
> > > The MDF (or DFSDM) use case, follows this topology:
> > > - The SD modulator (ADC core) registers in backend framework
> > > - The MDF registers in IIO framework and exposes the IIO devices
> > >    It also get configuration (ref voltage) from SD modulator, to compute
> > > scaling.
> > > 
> > > I agree that if we consider the terms frontend and backend, the elements in
> > > the data flow do not have the roles that we would naturally expect. However,
> > > if we consider the expected role of the elements using the iio-backend
> > > framework, the usage seems coherent to me.
> > 
> > I didn't even get as far as sd modulators or whatever, if I understand
> > correctly the ADC inputs on this device are fed by the onboard ADC?
> > (https://lore.kernel.org/linux-iio/20261006-adc-stm32mp25-v1-v4-0-d31ec75aecf3@foss.st.com/)
> > In that case, I can't really see how it makes sense for the primary iio
> > device to change when data is fed back through the mdf or taken
> > directly from the ADC itself, particularly given how that would affect
> > the userspace interface.
> > 
> > The "serial" side of this seems in a similar vein to the adi,axi-adc
> > stuff, which when considered with the ADC inputs, really does give me
> > the impression this is backwards.
> 
> Some clarifications about the STM32MP25. This SoC does indeed provide ADCs,
> and these can be connected to the MDF via a dedicated interface. (but not
> the serial interface).
> 
> However, this use case is not supported by the driver. Only sigma-delta
> modulators, external to the SoC and connected via the serial interface, are
> supported. On ST boards, the only available SD modulators are digital
> microphones.

Quite frankly, I don't care what you are choosing to implement in the
driver or what your first-party boards support. The binding must
represent the capabilities of the device, not what subset you deem
relevant at this point in time. I'm not going to ack anything that does
not consider all use cases for the device, especially since I the more I
look the more I am convinced that this is the wrong way to model the
relationship between devices and therefore intentionally ignoring a use case
is likely to be problematic when someone does decide that they want to use
that feature.

> Anyway, if the internal ADC to MDF use case was supported, the issue would
> be the same. The whole ADC + MDF set would be presented at the interface as
> an aggregated device, and the ADC data would not be directly accessible to
> the user.

Of course, that's what I was talking about when I said:
| In that case, I can't really see how it makes sense for the primary iio
| device to change when data is fed back through the mdf or taken
| directly from the ADC itself, particularly given how that would affect
| the userspace interface.

To me, in that ADC to MDF use case, the frontend portion of the aggregate
device presented to userspace needs to be the ADC and the MDF needs to be
the backend, since otherwise the ADC will simultaneously be frontend and
backend, depending on which channel is considered. That makes no sense to me
when the MDF can always be the backend, for all use cases and avoid that
sort of problem entirely.
I've heard no argument as to why the MDF cannot be a backend, just that you
don't want to because the previous device didn't, but copying what was
done before isn't a justification that bears weight if how it was done
before isn't the way it should be done.

Thanks,
Conor.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH 1/3] dt-bindings: iio: adc: add bindings for stm32 mdf filter

[Olivier MOYSAN]

Hi Conor,

On 10/15/26 00:49, Conor Dooley wrote:
> On Wed, Oct 14, 2026 at 06:51:45PM +0200, Olivier MOYSAN wrote:
>> On 10/14/26 17:15, Conor Dooley wrote:
>>> On Mon, Oct 12, 2026 at 02:56:04PM +0200, Olivier MOYSAN wrote:
>>>> On 10/9/26 21:12, Conor Dooley wrote:
>>>>> On Thu, Oct 08, 2026 at 06:37:26PM +0200, Olivier MOYSAN wrote:
>>>>>> On 10/8/26 12:11, Conor Dooley wrote:
>>>>>>> On Wed, Oct 07, 2026 at 11:01:28AM +0200, Olivier MOYSAN wrote:
>>>>>>>> On 10/1/26 20:32, Conor Dooley wrote:
>>>>>>>>>
>>>>>>>>>> +
>>>>>>>>>> +required:
>>>>>>>>>> +  - compatible
>>>>>>>>>> +  - reg
>>>>>>>>>> +  - ranges
>>>>>>>>>> +  - clocks
>>>>>>>>>> +  - clock-names
>>>>>>>>>> +  - clock-ranges
>>>>>>>>>> +  - "#address-cells"
>>>>>>>>>> +  - "#size-cells"
>>>>>>>>>> +
>>>>>>>>>> +additionalProperties: false
>>>>>>>>>> +
>>>>>>>>>> +patternProperties:
>>>>>>>>>> +  "^sitf@[0-9]+$":
>>>>>>>>>> +    type: object
>>>>>>>>>> +    description: Serial interface child node
>>>>>>>>>
>>>>>>>>> Why is this a child node at all?
>>>>>>>>> Probably not worth reviewing more without a link to the docs for this
>>>>>>>>> device so I can figure out what on earth is going on!
>>>>>>>>>
>>>>>>>>
>>>>>>>> The MDF is a digital filter for sigma-delta bitstreams, rather than the
>>>>>>>> analog-to-digital converter itself.
>>>>>>>>
>>>>>>>> Here is the link to STM32MP25 reference manuel
>>>>>>>> https://www.st.com/resource/en/reference_manual/rm0457-stm32mp2325xx-advanced-armbased-3264bit-mpus-stmicroelectronics.pdf
>>>>>>>> Chapter 45: Multi-function digital filter (MDF)
>>>>>>>>
>>>>>>>> On STMP32MP25 SoC, the MDF provides 8 serial interfaces (SITF) and 8 digital
>>>>>>>> filters (DFLT) which can be connected through a multiplexer.
>>>>>>>>
>>>>>>>> Below is a schematic view of typical applications targeted by this
>>>>>>>> peripheral
>>>>>>>>
>>>>>>>>
>>>>>>>> Audio use case:
>>>>>>>>
>>>>>>>> 		mdf
>>>>>>>>                 +-------------------------------------+
>>>>>>>> +------+    | +------+    +------+    +------+    |
>>>>>>>> | dmic | -> | | sitf | -> | mux  | -> | dflt | -- | -> audio device
>>>>>>>> +------+    | +------+    +------+    +------+    |
>>>>>>>>                 +-------------------------------------+
>>>>>>>>
>>>>>>>> For instance, in an audio use case the serial interface can be configured to
>>>>>>>> provide the clock to the digital microphone (cck0, cck1 or both) at a common
>>>>>>>> predefined rate, and to retrieve the PDM samples.
>>>>>>>> The serial interface provides this samples to a digital filter, which
>>>>>>>> delivers PCM samples on its output.
>>>>>>>>
>>>>>>>>
>>>>>>>> Analog use case:
>>>>>>>>
>>>>>>>> 		mdf
>>>>>>>>                   +-------------------------------------+
>>>>>>>> +--------+    | +------+    +------+    +------+    |
>>>>>>>> | sd adc | -> | | sitf | -> | mux  | -> | dflt | -- | -> iio device
>>>>>>>> +--------+    | +------+    +------+    +------+    |
>>>>>>>>                   +-------------------------------------+
>>>>>>>
>>>>>>>
>>>>>>> So, looking at the docs and a brief chat with Jonathan about this
>>>>>>> device, I believe you've got things backwards and this is actually the backend,
>>>>>>> and the adc should be the one populating the io-backends property
>>>>>>> pointing to this device. You should have io-backend-cells, and I assume
>>>>>>> that there should be a cell for the adc to select which dlft it is connected
>>>>>>> to.
>>>>>>>
>>>>>>
>>>>>> There have already been lengthy discussions in the past about a DFSDM
>>>>>> peripheral on STM32MP1, which has features similar to those of the MDF and
>>>>>> similar implementation constraints. For the DFSDM, a solution based on an
>>>>>> IIO backend had been upstreamed. The MDF follows the same architecture. I
>>>>>> need to take a little time to dive back into this issue.
>>>>>
>>>>> One thing to note there is that you retrofitted the backends onto that
>>>>> device, and the original design here is much older (it's a text
>>>>> binding).
>>>>>
>>>>>
>>>>>>
>>>>>> DFSDM sources:
>>>>>> drivers/iio/adc/stm32-dfsdm-adc.c
>>>>>> drivers/iio/adc/stm32-dfsdm-core.c
>>>>>>
>>>>>> Here is a sample of DFSDM DT
>>>>>>
>>>>>> sd_adc0: simple-sd-adc0 {
>>>>>> 	compatible = "sd-modulator";
>>>>>> 	#io-backend-cells = <0>;
>>>>>> 	vref-supply = <&v3v3>;
>>>>>
>>>>> Yeah, pretty sure this is wrong (backwards). The backend is the thing
>>>>> that gets data from an ADC not the ADC.
>>>>>
>>>>
>>>> The backend framework was introduced to implement complex IIO aggregate
>>>> devices. The hardwares that were driving this need were analog device ad9467
>>>> and ST DFSDM.
>>>>
>>>> https://lore.kernel.org/linux-iio/20231204144925.4fe9922f@jic23-huawei/T/#m222f5175273b81dbfe40b7f0daffcdc67d6cb8ff
>>>>
>>>>   From drivers/iio/industrialio-backend.c:
>>>>
>>>> "The typical architecture is to have one device as the frontend device which
>>>> can be "linked" against one or multiple backend devices. All the IIO and
>>>> userspace interface is expected to be registers/managed by the frontend
>>>> device which will callback into the backends when needed (to get/set some
>>>> configuration that it does not directly control)."
>>>>
>>>>    *                                    ---------------------
>>>>    * ------------------                 | ------------
>>>>    * |     ADC        |-----------------| | ADC CORE |
>>>>    * | (Frontend/IIO) | Serial Data (eg | |(backend) |-------
>>>>    * |                |-----------------| ------------
>>>>    * ------------------                 ---------------------
>>>>
>>>> The MDF (or DFSDM) use case, follows this topology:
>>>> - The SD modulator (ADC core) registers in backend framework
>>>> - The MDF registers in IIO framework and exposes the IIO devices
>>>>     It also get configuration (ref voltage) from SD modulator, to compute
>>>> scaling.
>>>>
>>>> I agree that if we consider the terms frontend and backend, the elements in
>>>> the data flow do not have the roles that we would naturally expect. However,
>>>> if we consider the expected role of the elements using the iio-backend
>>>> framework, the usage seems coherent to me.
>>>
>>> I didn't even get as far as sd modulators or whatever, if I understand
>>> correctly the ADC inputs on this device are fed by the onboard ADC?
>>> (https://lore.kernel.org/linux-iio/20261006-adc-stm32mp25-v1-v4-0-d31ec75aecf3@foss.st.com/)
>>> In that case, I can't really see how it makes sense for the primary iio
>>> device to change when data is fed back through the mdf or taken
>>> directly from the ADC itself, particularly given how that would affect
>>> the userspace interface.
>>>
>>> The "serial" side of this seems in a similar vein to the adi,axi-adc
>>> stuff, which when considered with the ADC inputs, really does give me
>>> the impression this is backwards.
>>
>> Some clarifications about the STM32MP25. This SoC does indeed provide ADCs,
>> and these can be connected to the MDF via a dedicated interface. (but not
>> the serial interface).
>>
>> However, this use case is not supported by the driver. Only sigma-delta
>> modulators, external to the SoC and connected via the serial interface, are
>> supported. On ST boards, the only available SD modulators are digital
>> microphones.
> 
> Quite frankly, I don't care what you are choosing to implement in the
> driver or what your first-party boards support. The binding must
> represent the capabilities of the device, not what subset you deem
> relevant at this point in time. I'm not going to ack anything that does
> not consider all use cases for the device, especially since I the more I
> look the more I am convinced that this is the wrong way to model the
> relationship between devices and therefore intentionally ignoring a use case
> is likely to be problematic when someone does decide that they want to use
> that feature.
> 
>> Anyway, if the internal ADC to MDF use case was supported, the issue would
>> be the same. The whole ADC + MDF set would be presented at the interface as
>> an aggregated device, and the ADC data would not be directly accessible to
>> the user.
> 
> Of course, that's what I was talking about when I said:
> | In that case, I can't really see how it makes sense for the primary iio
> | device to change when data is fed back through the mdf or taken
> | directly from the ADC itself, particularly given how that would affect
> | the userspace interface.
> 
> To me, in that ADC to MDF use case, the frontend portion of the aggregate
> device presented to userspace needs to be the ADC and the MDF needs to be
> the backend, since otherwise the ADC will simultaneously be frontend and
> backend, depending on which channel is considered. That makes no sense to me
> when the MDF can always be the backend, for all use cases and avoid that
> sort of problem entirely.
> I've heard no argument as to why the MDF cannot be a backend, just that you
> don't want to because the previous device didn't, but copying what was
> done before isn't a justification that bears weight if how it was done
> before isn't the way it should be done.
> 

These topology problems were discussed at length in the case of DFSDM.
The main blocking point being support for interleaved channels (scan 
mode), a problematic issue that is still found with MDF.
The constraints that led to this approach are in the following thread:
https://lore.kernel.org/all/20210919191414.09270f4e@jic23-huawei/

FYI: An implementation attempt had been made also via the "concverter 
framework" proposal, but this approach has been abandoned in favor of 
the backend framework.
https://marc.info/?l=linux-iio&m=169347396021802&w=2

BRs
Olivier

> Thanks,
> Conor.

Re: [PATCH 1/3] dt-bindings: iio: adc: add bindings for stm32 mdf filter

[Conor Dooley]

[-- Attachment #1: Type: text/plain, Size: 12250 bytes --]

On Thu, Oct 15, 2026 at 11:19:19AM +0200, Olivier MOYSAN wrote:
> Hi Conor,
> 
> On 10/15/26 00:49, Conor Dooley wrote:
> > On Wed, Oct 14, 2026 at 06:51:45PM +0200, Olivier MOYSAN wrote:
> > > On 10/14/26 17:15, Conor Dooley wrote:
> > > > On Mon, Oct 12, 2026 at 02:56:04PM +0200, Olivier MOYSAN wrote:
> > > > > On 10/9/26 21:12, Conor Dooley wrote:
> > > > > > On Thu, Oct 08, 2026 at 06:37:26PM +0200, Olivier MOYSAN wrote:
> > > > > > > On 10/8/26 12:11, Conor Dooley wrote:
> > > > > > > > On Wed, Oct 07, 2026 at 11:01:28AM +0200, Olivier MOYSAN wrote:
> > > > > > > > > On 10/1/26 20:32, Conor Dooley wrote:
> > > > > > > > > > 
> > > > > > > > > > > +
> > > > > > > > > > > +required:
> > > > > > > > > > > +  - compatible
> > > > > > > > > > > +  - reg
> > > > > > > > > > > +  - ranges
> > > > > > > > > > > +  - clocks
> > > > > > > > > > > +  - clock-names
> > > > > > > > > > > +  - clock-ranges
> > > > > > > > > > > +  - "#address-cells"
> > > > > > > > > > > +  - "#size-cells"
> > > > > > > > > > > +
> > > > > > > > > > > +additionalProperties: false
> > > > > > > > > > > +
> > > > > > > > > > > +patternProperties:
> > > > > > > > > > > +  "^sitf@[0-9]+$":
> > > > > > > > > > > +    type: object
> > > > > > > > > > > +    description: Serial interface child node
> > > > > > > > > > 
> > > > > > > > > > Why is this a child node at all?
> > > > > > > > > > Probably not worth reviewing more without a link to the docs for this
> > > > > > > > > > device so I can figure out what on earth is going on!
> > > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > The MDF is a digital filter for sigma-delta bitstreams, rather than the
> > > > > > > > > analog-to-digital converter itself.
> > > > > > > > > 
> > > > > > > > > Here is the link to STM32MP25 reference manuel
> > > > > > > > > https://www.st.com/resource/en/reference_manual/rm0457-stm32mp2325xx-advanced-armbased-3264bit-mpus-stmicroelectronics.pdf
> > > > > > > > > Chapter 45: Multi-function digital filter (MDF)
> > > > > > > > > 
> > > > > > > > > On STMP32MP25 SoC, the MDF provides 8 serial interfaces (SITF) and 8 digital
> > > > > > > > > filters (DFLT) which can be connected through a multiplexer.
> > > > > > > > > 
> > > > > > > > > Below is a schematic view of typical applications targeted by this
> > > > > > > > > peripheral
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > Audio use case:
> > > > > > > > > 
> > > > > > > > > 		mdf
> > > > > > > > >                 +-------------------------------------+
> > > > > > > > > +------+    | +------+    +------+    +------+    |
> > > > > > > > > | dmic | -> | | sitf | -> | mux  | -> | dflt | -- | -> audio device
> > > > > > > > > +------+    | +------+    +------+    +------+    |
> > > > > > > > >                 +-------------------------------------+
> > > > > > > > > 
> > > > > > > > > For instance, in an audio use case the serial interface can be configured to
> > > > > > > > > provide the clock to the digital microphone (cck0, cck1 or both) at a common
> > > > > > > > > predefined rate, and to retrieve the PDM samples.
> > > > > > > > > The serial interface provides this samples to a digital filter, which
> > > > > > > > > delivers PCM samples on its output.
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > Analog use case:
> > > > > > > > > 
> > > > > > > > > 		mdf
> > > > > > > > >                   +-------------------------------------+
> > > > > > > > > +--------+    | +------+    +------+    +------+    |
> > > > > > > > > | sd adc | -> | | sitf | -> | mux  | -> | dflt | -- | -> iio device
> > > > > > > > > +--------+    | +------+    +------+    +------+    |
> > > > > > > > >                   +-------------------------------------+
> > > > > > > > 
> > > > > > > > 
> > > > > > > > So, looking at the docs and a brief chat with Jonathan about this
> > > > > > > > device, I believe you've got things backwards and this is actually the backend,
> > > > > > > > and the adc should be the one populating the io-backends property
> > > > > > > > pointing to this device. You should have io-backend-cells, and I assume
> > > > > > > > that there should be a cell for the adc to select which dlft it is connected
> > > > > > > > to.
> > > > > > > > 
> > > > > > > 
> > > > > > > There have already been lengthy discussions in the past about a DFSDM
> > > > > > > peripheral on STM32MP1, which has features similar to those of the MDF and
> > > > > > > similar implementation constraints. For the DFSDM, a solution based on an
> > > > > > > IIO backend had been upstreamed. The MDF follows the same architecture. I
> > > > > > > need to take a little time to dive back into this issue.
> > > > > > 
> > > > > > One thing to note there is that you retrofitted the backends onto that
> > > > > > device, and the original design here is much older (it's a text
> > > > > > binding).
> > > > > > 
> > > > > > 
> > > > > > > 
> > > > > > > DFSDM sources:
> > > > > > > drivers/iio/adc/stm32-dfsdm-adc.c
> > > > > > > drivers/iio/adc/stm32-dfsdm-core.c
> > > > > > > 
> > > > > > > Here is a sample of DFSDM DT
> > > > > > > 
> > > > > > > sd_adc0: simple-sd-adc0 {
> > > > > > > 	compatible = "sd-modulator";
> > > > > > > 	#io-backend-cells = <0>;
> > > > > > > 	vref-supply = <&v3v3>;
> > > > > > 
> > > > > > Yeah, pretty sure this is wrong (backwards). The backend is the thing
> > > > > > that gets data from an ADC not the ADC.
> > > > > > 
> > > > > 
> > > > > The backend framework was introduced to implement complex IIO aggregate
> > > > > devices. The hardwares that were driving this need were analog device ad9467
> > > > > and ST DFSDM.
> > > > > 
> > > > > https://lore.kernel.org/linux-iio/20231204144925.4fe9922f@jic23-huawei/T/#m222f5175273b81dbfe40b7f0daffcdc67d6cb8ff
> > > > > 
> > > > >   From drivers/iio/industrialio-backend.c:
> > > > > 
> > > > > "The typical architecture is to have one device as the frontend device which
> > > > > can be "linked" against one or multiple backend devices. All the IIO and
> > > > > userspace interface is expected to be registers/managed by the frontend
> > > > > device which will callback into the backends when needed (to get/set some
> > > > > configuration that it does not directly control)."
> > > > > 
> > > > >    *                                    ---------------------
> > > > >    * ------------------                 | ------------
> > > > >    * |     ADC        |-----------------| | ADC CORE |
> > > > >    * | (Frontend/IIO) | Serial Data (eg | |(backend) |-------
> > > > >    * |                |-----------------| ------------
> > > > >    * ------------------                 ---------------------
> > > > > 
> > > > > The MDF (or DFSDM) use case, follows this topology:
> > > > > - The SD modulator (ADC core) registers in backend framework
> > > > > - The MDF registers in IIO framework and exposes the IIO devices
> > > > >     It also get configuration (ref voltage) from SD modulator, to compute
> > > > > scaling.
> > > > > 
> > > > > I agree that if we consider the terms frontend and backend, the elements in
> > > > > the data flow do not have the roles that we would naturally expect. However,
> > > > > if we consider the expected role of the elements using the iio-backend
> > > > > framework, the usage seems coherent to me.
> > > > 
> > > > I didn't even get as far as sd modulators or whatever, if I understand
> > > > correctly the ADC inputs on this device are fed by the onboard ADC?
> > > > (https://lore.kernel.org/linux-iio/20261006-adc-stm32mp25-v1-v4-0-d31ec75aecf3@foss.st.com/)
> > > > In that case, I can't really see how it makes sense for the primary iio
> > > > device to change when data is fed back through the mdf or taken
> > > > directly from the ADC itself, particularly given how that would affect
> > > > the userspace interface.
> > > > 
> > > > The "serial" side of this seems in a similar vein to the adi,axi-adc
> > > > stuff, which when considered with the ADC inputs, really does give me
> > > > the impression this is backwards.
> > > 
> > > Some clarifications about the STM32MP25. This SoC does indeed provide ADCs,
> > > and these can be connected to the MDF via a dedicated interface. (but not
> > > the serial interface).
> > > 
> > > However, this use case is not supported by the driver. Only sigma-delta
> > > modulators, external to the SoC and connected via the serial interface, are
> > > supported. On ST boards, the only available SD modulators are digital
> > > microphones.
> > 
> > Quite frankly, I don't care what you are choosing to implement in the
> > driver or what your first-party boards support. The binding must
> > represent the capabilities of the device, not what subset you deem
> > relevant at this point in time. I'm not going to ack anything that does
> > not consider all use cases for the device, especially since I the more I
> > look the more I am convinced that this is the wrong way to model the
> > relationship between devices and therefore intentionally ignoring a use case
> > is likely to be problematic when someone does decide that they want to use
> > that feature.
> > 
> > > Anyway, if the internal ADC to MDF use case was supported, the issue would
> > > be the same. The whole ADC + MDF set would be presented at the interface as
> > > an aggregated device, and the ADC data would not be directly accessible to
> > > the user.
> > 
> > Of course, that's what I was talking about when I said:
> > | In that case, I can't really see how it makes sense for the primary iio
> > | device to change when data is fed back through the mdf or taken
> > | directly from the ADC itself, particularly given how that would affect
> > | the userspace interface.
> > 
> > To me, in that ADC to MDF use case, the frontend portion of the aggregate
> > device presented to userspace needs to be the ADC and the MDF needs to be
> > the backend, since otherwise the ADC will simultaneously be frontend and
> > backend, depending on which channel is considered. That makes no sense to me
> > when the MDF can always be the backend, for all use cases and avoid that
> > sort of problem entirely.
> > I've heard no argument as to why the MDF cannot be a backend, just that you
> > don't want to because the previous device didn't, but copying what was
> > done before isn't a justification that bears weight if how it was done
> > before isn't the way it should be done.
> > 
> 
> These topology problems were discussed at length in the case of DFSDM.
> The main blocking point being support for interleaved channels (scan mode),
> a problematic issue that is still found with MDF.

If I am not mistaken, you're talking about what's described in the
section labelled "Interleaved-transfer mode" of the document you
provided previously?

> The constraints that led to this approach are in the following thread:
> https://lore.kernel.org/all/20210919191414.09270f4e@jic23-huawei/

That to me seemed like a discussion about why the MDF/interleaver needs
to be represented as a separate device, I don't see anything that
explains why the MDF cannot be a backend.

Reading the document, "Interleaved-transfer mode" doesn't trash the
association between data and which fifo, and thereby which sensor or
ADC, it came from. Using #io-backend-cells = <1> in the MDF, the
sensor/ADC can provide the channel to which it is linked, and the data
association restored. You already know what the set of interleaved channels
is from the st,interleave property so there's no extra properties required
for this I think.

The problem here must be that you want to access the interleaved data? That
could be handled by having a cell value that represents the interleaved
data (e.g. -1), rather than a channel (1-N)? That'd support systems that
want interleaved data (like an array of identical sensors?) and systems
using the mode for the stated aim of it in documentation of optimising
DMA request resources who have disparate devices where interleaved data
itself is not useful?

Thanks,
Conor.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH 1/3] dt-bindings: iio: adc: add bindings for stm32 mdf filter

[Krzysztof Kozlowski]

On Thu, Oct 01, 2026 at 04:56:45PM +0200, Olivier Moysan wrote:
> Add bindings that describes STM32 MDF settings to support
> digital filtering for Pulse Density Modulation (PDM) microphones
> and analog sigma delta modulators.

You already received review, so a few things on top to spare you one
more cycle:

A nit, subject: drop second/last, redundant "bindings for". The
"dt-bindings" prefix is already stating that these are bindings.
See also:
https://elixir.bootlin.com/linux/v7.1-rc7/source/Documentation/devicetree/bindings/submitting-patches.rst#L23

> 
> Signed-off-by: Olivier Moysan <olivier.moysan@foss.st.com>
> ---
>  .../bindings/iio/adc/st,stm32-mdf-adc.yaml    | 383 ++++++++++++++++++
>  1 file changed, 383 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/iio/adc/st,stm32-mdf-adc.yaml
> 
> diff --git a/Documentation/devicetree/bindings/iio/adc/st,stm32-mdf-adc.yaml b/Documentation/devicetree/bindings/iio/adc/st,stm32-mdf-adc.yaml
> new file mode 100644
> index 000000000000..f2fbc3e150e8
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/adc/st,stm32-mdf-adc.yaml

Filename follows compatible, so st,stm32mp23-mdf

> @@ -0,0 +1,383 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/iio/adc/st,stm32-mdf-adc.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: STMicroelectronics STM32 Multi-function Digital Filter (MDF) ADC
> +
> +maintainers:
> +  - Olivier Moysan <olivier.moysan@foss.st.com>
> +
> +description: |
> +  STM32 MDF ADC is a sigma delta analog-to-digital converter dedicated to
> +  interface external sigma delta modulators to STM32 micro controllers.
> +
> +properties:
> +  compatible:
> +    enum:
> +      - st,stm32mp25-mdf
> +      - st,stm32mp23-mdf

Why reversed order?

> +  ranges: true
> +
> +  clock-ranges: true

Do you need it here?

> +
> +  resets:
> +    maxItems: 1
> +
> +  reset-names:
> +    items:
> +      - const: mdf

Drop

> +
> +  access-controllers:
> +    $ref: /schemas/types.yaml#/definitions/phandle-array
> +    description: |
> +      Phandle to the rifsc device to check access right.

Look at other code how this is done. Don't come with own stuff.

> +
> +  power-domains:
> +    maxItems: 1
> +
> +  st,interleave:
> +    description: |
> +      List of phandles of interleaved filters. The indexes of interleaved filters must be
> +      consecutives starting from 0 (i.e in range [0..N]). The samples from interleaved filters
> +      are muxed in a single channel and retrieved through the device associated to the filter 0.
> +      The filters 1..N have to be enabled, but inherit their configuration from filter 0.
> +    $ref: /schemas/types.yaml#/definitions/phandle-array
> +
> +required:
> +  - compatible
> +  - reg
> +  - ranges
> +  - clocks
> +  - clock-names
> +  - clock-ranges
> +  - "#address-cells"
> +  - "#size-cells"
> +
> +additionalProperties: false
> +
> +patternProperties:

And this has odd order. Please look at example-schema.

> +  "^sitf@[0-9]+$":
> +    type: object
> +    description: Serial interface child node
> +
> +    properties:
> +      compatible:
> +        enum:
> +          - st,stm32mp25-sitf-mdf
> +
> +      reg:
> +        description: Specify the SITF serial interface instance
> +        maxItems: 1
> +
> +      clocks:
> +        description: |
> +          Serial interface clock (optional depending on interface mode)
> +        maxItems: 1
> +
> +      st,sitf-mode:
> +        description: |
> +          Select serial interface protocol
> +          - spi: SPI mode
> +          - lf_spi: low frequency SPI mode for low power applications
> +        $ref: /schemas/types.yaml#/definitions/string
> +        enum:
> +          - spi
> +          - lf_spi
> +
> +    required:
> +      - reg
> +      - st,sitf-mode
> +
> +    additionalProperties: false
> +
> +  "^filter@[0-9]+$":
> +    type: object
> +    description: Digital filter path child node
> +
> +    properties:
> +      compatible:
> +        enum:
> +          - st,stm32mp25-mdf-dmic
> +          - st,stm32mp25-mdf-adc
> +
> +      reg:
> +        description: Specify the MDF filter instance
> +        maxItems: 1
> +
> +      interrupts:
> +        maxItems: 1
> +
> +      clocks:
> +        minItems: 1

Heh? so here min? Is there any logic in your choices of code style?

> +        description: Internal clock used for MDF digital processing and control blocks.
> +
> +      clock-names:
> +        items:
> +          - const: ker_ck
> +
> +      dmas:
> +        maxItems: 1
> +
> +      dma-names:
> +        items:
> +          - const: rx
> +
> +      "#io-channel-cells":
> +        const: 1
> +
> +      '#address-cells':
> +        const: 1
> +
> +      '#size-cells':
> +        const: 0
> +
> +      st,cic-mode:
> +        description: |
> +          Cascaded-integrator-comb (CIC) filter configuration
> +          - 0: MCIC & ACIC filters in FastSinc mode
> +          - [1-3]: MCIC & ACIC filters in Sinc mode order 1 to 3
> +          - [4-5]: Single CIC filter in Sinc mode order 4 to 5
> +          For audio purpose it is recommended to use CIC Sinc4 or Sinc5
> +          This property is mandatory for filter 0 or filters not used in interleave mode.
> +        $ref: /schemas/types.yaml#/definitions/uint32
> +        minimum: 0
> +        maximum: 5
> +
> +      st,delay:
> +        description: Filter delay in samples
> +        $ref: /schemas/types.yaml#/definitions/uint32
> +        maximum: 127
> +
> +      st,rs-filter-bypass:
> +        description: Bypass RSFLT reshaping filter.
> +        $ref: /schemas/types.yaml#/definitions/flag
> +
> +      st,hpf-filter-cutoff-bp:
> +        description: |
> +          High Pass Filter (HPF) cut-off frequency expressed as a fraction of the PCM sampling rate.
> +          Cut-off frequency = st,hpf-filter-cutoff-bp x Fpcm / 10000.
> +          If this property is not defined the HPF is disabled.
> +        enum: [625, 1250, 2500, 9500]
> +
> +      st,sync:
> +        description:
> +          Synchronize to another filter.
> +          Must contain the phandle of the filter providing the synchronization.
> +        allOf:
> +          - $ref: /schemas/types.yaml#/definitions/phandle-array
> +          - maxItems: 1
> +
> +      st,sitf:
> +        $ref: /schemas/types.yaml#/definitions/phandle-array
> +        items:
> +          - items:
> +              - description: Phandle of the serial interface connected to the digital filter
> +              - description: |
> +                  The phandle's argument selects the bitstream on the falling or rising edge
> +                  of the serial interface clock:
> +                  - 0: rising edge
> +                  - 1: falling edge
> +                enum: [0, 1]
> +                default: 0
> +        description:
> +          Should be phandle/bitstream pair.
> +
> +    required:
> +      - compatible
> +      - reg
> +      - interrupts
> +      - dmas
> +      - dma-names
> +      - "#io-channel-cells"
> +      - "#address-cells"
> +      - "#size-cells"
> +      - st,sitf
> +
> +    unevaluatedProperties: false
> +
> +    patternProperties:
> +      "^channel@([0-7])$":
> +        type: object
> +        $ref: adc.yaml
> +        description: Represents the external channel which is connected to the MDF.
> +
> +        properties:
> +          reg:
> +            maximum: 7
> +
> +          io-backends:
> +            description:
> +              Used to pipe external sigma delta modulator or internal ADC backend to MDF
> +              channel.
> +            maxItems: 1
> +
> +        required:
> +          - reg
> +
> +        unevaluatedProperties: false
> +
> +    allOf:
> +      - if:
> +          properties:
> +            compatible:
> +              contains:
> +                const: st,stm32mp25-mdf-adc
> +
> +        then:
> +          patternProperties:
> +            "^channel@[0-7]$":
> +              required:
> +                - io-backends
> +
> +      - if:
> +          properties:
> +            compatible:
> +              contains:
> +                const: st,stm32mp25-mdf-dmic
> +
> +        then:
> +          patternProperties:
> +            "^mdf-dai+$":

This makes no sense. Why is this a pattern and why mdf-daiiiii is
correct name?

Not mentioning that your are not supposed to define properties in if
block (do you see any code like that?). Mixing addressable and
non-addressable children is another odd thing.

This entire schema is quite chaotic and overcomplicated.

> +              type: object
> +              description: child node
> +
> +              properties:
> +                compatible:
> +                  enum:
> +                    - st,stm32mp25-mdf-dai
> +
> +                "#sound-dai-cells":
> +                  const: 0
> +
> +                io-channels:
> +                  description:
> +                    From common IIO binding. Used to pipe external sigma delta
> +                    modulator or internal ADC output to MDF channel.
> +
> +                power-domains:
> +                  maxItems: 1
> +
> +                port:
> +                  $ref: /schemas/sound/audio-graph-port.yaml#
> +                  unevaluatedProperties: false
> +
> +              required:
> +                - compatible
> +                - "#sound-dai-cells"
> +                - io-channels
> +
> +              additionalProperties: false
> +
> +examples:
> +  - |
> +    #include <dt-bindings/clock/st,stm32mp25-rcc.h>
> +    #include <dt-bindings/interrupt-controller/arm-gic.h>
> +    mdf1: mdf@504d0000 {

Node names should be generic. See also an explanation and list of
examples (not exhaustive) in DT specification:
https://devicetree-specification.readthedocs.io/en/latest/chapter2-devicetree-basics.html#generic-names-recommendation
If you cannot find a name matching your device, please check in kernel
sources for similar cases or you can grow the spec (via pull request to
DT spec repo).

And drop unused labels.

> +      compatible = "st,stm32mp25-mdf";
> +      ranges = <0 0x504d0000 0x1000>;
> +      reg = <0x504d0000 0x8>, <0x504d0ff0 0x10>;

Address ranges of 2 and 4 words?

Best regards,
Krzysztof

Re: [PATCH 1/3] dt-bindings: iio: adc: add bindings for stm32 mdf filter

[Olivier MOYSAN]

Hi Krzysztof,

Thank you for the review.

On 10/2/26 11:22, Krzysztof Kozlowski wrote:
> On Thu, Oct 01, 2026 at 04:56:45PM +0200, Olivier Moysan wrote:
>> Add bindings that describes STM32 MDF settings to support
>> digital filtering for Pulse Density Modulation (PDM) microphones
>> and analog sigma delta modulators.
> 
> You already received review, so a few things on top to spare you one
> more cycle:
> 
> A nit, subject: drop second/last, redundant "bindings for". The
> "dt-bindings" prefix is already stating that these are bindings.
> See also:
> https://elixir.bootlin.com/linux/v7.1-rc7/source/Documentation/devicetree/bindings/submitting-patches.rst#L23
> 

Done

>>
>> Signed-off-by: Olivier Moysan <olivier.moysan@foss.st.com>
>> ---
>>   .../bindings/iio/adc/st,stm32-mdf-adc.yaml    | 383 ++++++++++++++++++
>>   1 file changed, 383 insertions(+)
>>   create mode 100644 Documentation/devicetree/bindings/iio/adc/st,stm32-mdf-adc.yaml
>>
>> diff --git a/Documentation/devicetree/bindings/iio/adc/st,stm32-mdf-adc.yaml b/Documentation/devicetree/bindings/iio/adc/st,stm32-mdf-adc.yaml
>> new file mode 100644
>> index 000000000000..f2fbc3e150e8
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/iio/adc/st,stm32-mdf-adc.yaml
> 
> Filename follows compatible, so st,stm32mp23-mdf
> 

stmp32mp25 is the main SoC, while stm32mp23 is a variant.
file renamed st,stm32mp25-mdf.yaml

>> @@ -0,0 +1,383 @@
>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/iio/adc/st,stm32-mdf-adc.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: STMicroelectronics STM32 Multi-function Digital Filter (MDF) ADC
>> +
>> +maintainers:
>> +  - Olivier Moysan <olivier.moysan@foss.st.com>
>> +
>> +description: |
>> +  STM32 MDF ADC is a sigma delta analog-to-digital converter dedicated to
>> +  interface external sigma delta modulators to STM32 micro controllers.
>> +
>> +properties:
>> +  compatible:
>> +    enum:
>> +      - st,stm32mp25-mdf
>> +      - st,stm32mp23-mdf
> 
> Why reversed order?
> 

Ok. Reordered alphabetically

>> +  ranges: true
>> +
>> +  clock-ranges: true
> 
> Do you need it here?

clock-ranges property is used to allow the filter child nodes to inherit 
the MDF kernel clock from the parent node.

> 
>> +
>> +  resets:
>> +    maxItems: 1
>> +
>> +  reset-names:
>> +    items:
>> +      - const: mdf
> 
> Drop
> 

reset-names removed.

>> +
>> +  access-controllers:
>> +    $ref: /schemas/types.yaml#/definitions/phandle-array
>> +    description: |
>> +      Phandle to the rifsc device to check access right.
> 
> Look at other code how this is done. Don't come with own stuff.
> 

Replaced by:
   access-controllers:
     maxItems: 1

>> +
>> +  power-domains:
>> +    maxItems: 1
>> +
>> +  st,interleave:
>> +    description: |
>> +      List of phandles of interleaved filters. The indexes of interleaved filters must be
>> +      consecutives starting from 0 (i.e in range [0..N]). The samples from interleaved filters
>> +      are muxed in a single channel and retrieved through the device associated to the filter 0.
>> +      The filters 1..N have to be enabled, but inherit their configuration from filter 0.
>> +    $ref: /schemas/types.yaml#/definitions/phandle-array
>> +
>> +required:
>> +  - compatible
>> +  - reg
>> +  - ranges
>> +  - clocks
>> +  - clock-names
>> +  - clock-ranges
>> +  - "#address-cells"
>> +  - "#size-cells"
>> +
>> +additionalProperties: false
>> +
>> +patternProperties:
> 
> And this has odd order. Please look at example-schema.
> 

ok. Reordered.

>> +  "^sitf@[0-9]+$":
>> +    type: object
>> +    description: Serial interface child node
>> +
>> +    properties:
>> +      compatible:
>> +        enum:
>> +          - st,stm32mp25-sitf-mdf
>> +
>> +      reg:
>> +        description: Specify the SITF serial interface instance
>> +        maxItems: 1
>> +
>> +      clocks:
>> +        description: |
>> +          Serial interface clock (optional depending on interface mode)
>> +        maxItems: 1
>> +
>> +      st,sitf-mode:
>> +        description: |
>> +          Select serial interface protocol
>> +          - spi: SPI mode
>> +          - lf_spi: low frequency SPI mode for low power applications
>> +        $ref: /schemas/types.yaml#/definitions/string
>> +        enum:
>> +          - spi
>> +          - lf_spi
>> +
>> +    required:
>> +      - reg
>> +      - st,sitf-mode
>> +
>> +    additionalProperties: false
>> +
>> +  "^filter@[0-9]+$":
>> +    type: object
>> +    description: Digital filter path child node
>> +
>> +    properties:
>> +      compatible:
>> +        enum:
>> +          - st,stm32mp25-mdf-dmic
>> +          - st,stm32mp25-mdf-adc
>> +
>> +      reg:
>> +        description: Specify the MDF filter instance
>> +        maxItems: 1
>> +
>> +      interrupts:
>> +        maxItems: 1
>> +
>> +      clocks:
>> +        minItems: 1
> 
> Heh? so here min? Is there any logic in your choices of code style?
> 

As the filter node always use the kernel clock from parent node we can 
remove "clocks" item. "clocks" is not relevant here as the filter is not 
supposed to use another reference.
clocks & clock-names removed

>> +        description: Internal clock used for MDF digital processing and control blocks.
>> +
>> +      clock-names:
>> +        items:
>> +          - const: ker_ck
>> +
>> +      dmas:
>> +        maxItems: 1
>> +
>> +      dma-names:
>> +        items:
>> +          - const: rx
>> +
>> +      "#io-channel-cells":
>> +        const: 1
>> +
>> +      '#address-cells':
>> +        const: 1
>> +
>> +      '#size-cells':
>> +        const: 0
>> +
>> +      st,cic-mode:
>> +        description: |
>> +          Cascaded-integrator-comb (CIC) filter configuration
>> +          - 0: MCIC & ACIC filters in FastSinc mode
>> +          - [1-3]: MCIC & ACIC filters in Sinc mode order 1 to 3
>> +          - [4-5]: Single CIC filter in Sinc mode order 4 to 5
>> +          For audio purpose it is recommended to use CIC Sinc4 or Sinc5
>> +          This property is mandatory for filter 0 or filters not used in interleave mode.
>> +        $ref: /schemas/types.yaml#/definitions/uint32
>> +        minimum: 0
>> +        maximum: 5
>> +
>> +      st,delay:
>> +        description: Filter delay in samples
>> +        $ref: /schemas/types.yaml#/definitions/uint32
>> +        maximum: 127
>> +
>> +      st,rs-filter-bypass:
>> +        description: Bypass RSFLT reshaping filter.
>> +        $ref: /schemas/types.yaml#/definitions/flag
>> +
>> +      st,hpf-filter-cutoff-bp:
>> +        description: |
>> +          High Pass Filter (HPF) cut-off frequency expressed as a fraction of the PCM sampling rate.
>> +          Cut-off frequency = st,hpf-filter-cutoff-bp x Fpcm / 10000.
>> +          If this property is not defined the HPF is disabled.
>> +        enum: [625, 1250, 2500, 9500]
>> +
>> +      st,sync:
>> +        description:
>> +          Synchronize to another filter.
>> +          Must contain the phandle of the filter providing the synchronization.
>> +        allOf:
>> +          - $ref: /schemas/types.yaml#/definitions/phandle-array
>> +          - maxItems: 1
>> +
>> +      st,sitf:
>> +        $ref: /schemas/types.yaml#/definitions/phandle-array
>> +        items:
>> +          - items:
>> +              - description: Phandle of the serial interface connected to the digital filter
>> +              - description: |
>> +                  The phandle's argument selects the bitstream on the falling or rising edge
>> +                  of the serial interface clock:
>> +                  - 0: rising edge
>> +                  - 1: falling edge
>> +                enum: [0, 1]
>> +                default: 0
>> +        description:
>> +          Should be phandle/bitstream pair.
>> +
>> +    required:
>> +      - compatible
>> +      - reg
>> +      - interrupts
>> +      - dmas
>> +      - dma-names
>> +      - "#io-channel-cells"
>> +      - "#address-cells"
>> +      - "#size-cells"
>> +      - st,sitf
>> +
>> +    unevaluatedProperties: false
>> +
>> +    patternProperties:
>> +      "^channel@([0-7])$":
>> +        type: object
>> +        $ref: adc.yaml
>> +        description: Represents the external channel which is connected to the MDF.
>> +
>> +        properties:
>> +          reg:
>> +            maximum: 7
>> +
>> +          io-backends:
>> +            description:
>> +              Used to pipe external sigma delta modulator or internal ADC backend to MDF
>> +              channel.
>> +            maxItems: 1
>> +
>> +        required:
>> +          - reg
>> +
>> +        unevaluatedProperties: false
>> +
>> +    allOf:
>> +      - if:
>> +          properties:
>> +            compatible:
>> +              contains:
>> +                const: st,stm32mp25-mdf-adc
>> +
>> +        then:
>> +          patternProperties:
>> +            "^channel@[0-7]$":
>> +              required:
>> +                - io-backends
>> +
>> +      - if:
>> +          properties:
>> +            compatible:
>> +              contains:
>> +                const: st,stm32mp25-mdf-dmic
>> +
>> +        then:
>> +          patternProperties:
>> +            "^mdf-dai+$":
> 
> This makes no sense. Why is this a pattern and why mdf-daiiiii is
> correct name?
> 

"^mdf-dai$" is intended here

> Not mentioning that your are not supposed to define properties in if
> block (do you see any code like that?). Mixing addressable and
> non-addressable children is another odd thing.
> 

This binding is inspired by the one already adopted for the DFSDM
https://www.kernel.org/doc/Documentation/devicetree/bindings/iio/adc/st,stm32-dfsdm-adc.yaml

I assume can move the mdf-dai node definition outside the conditional 
branch easily.
However, it seems to me more complicated to avoid mixing addressable and 
non-addressable nodes here. Can we keep this binding aligned with the 
DFSDM model? Or would you have another suggestion?

> This entire schema is quite chaotic and overcomplicated.
> 
>> +              type: object
>> +              description: child node
>> +
>> +              properties:
>> +                compatible:
>> +                  enum:
>> +                    - st,stm32mp25-mdf-dai
>> +
>> +                "#sound-dai-cells":
>> +                  const: 0
>> +
>> +                io-channels:
>> +                  description:
>> +                    From common IIO binding. Used to pipe external sigma delta
>> +                    modulator or internal ADC output to MDF channel.
>> +
>> +                power-domains:
>> +                  maxItems: 1
>> +
>> +                port:
>> +                  $ref: /schemas/sound/audio-graph-port.yaml#
>> +                  unevaluatedProperties: false
>> +
>> +              required:
>> +                - compatible
>> +                - "#sound-dai-cells"
>> +                - io-channels
>> +
>> +              additionalProperties: false
>> +
>> +examples:
>> +  - |
>> +    #include <dt-bindings/clock/st,stm32mp25-rcc.h>
>> +    #include <dt-bindings/interrupt-controller/arm-gic.h>
>> +    mdf1: mdf@504d0000 {
> 
> Node names should be generic. See also an explanation and list of
> examples (not exhaustive) in DT specification:
> https://devicetree-specification.readthedocs.io/en/latest/chapter2-devicetree-basics.html#generic-names-recommendation
> If you cannot find a name matching your device, please check in kernel
> sources for similar cases or you can grow the spec (via pull request to
> DT spec repo).
> 
> And drop unused labels.
> 

The MDF is a digital filter for sigma-delta bitstreams, rather than the 
analog-to-digital converter itself. So "adc" would not be adapted. I did 
not find "filter", that probably would be the more relevant generic name.
The closest similar case is the DFSDM peripheral, which already uses a 
specific naming:
     dfsdm: dfsdm@4400d000 { ...
https://www.kernel.org/doc/Documentation/devicetree/bindings/iio/adc/st,stm32-dfsdm-adc.yaml

What is your recommendation: keep the naming "mdf" or make a pull 
request to add "filter" or another more appropriate name ?

>> +      compatible = "st,stm32mp25-mdf";
>> +      ranges = <0 0x504d0000 0x1000>;
>> +      reg = <0x504d0000 0x8>, <0x504d0ff0 0x10>;
> 
> Address ranges of 2 and 4 words?
> 

These two sections correspond to MDF common registers managed by the core
- Control registers: 2 x 32 bits registers
- Identification registers: 4 x 32 bits registers
The other registers are managed by filter and serial interface driver

> Best regards,
> Krzysztof
> 

Best regards
Olivier

Re: [PATCH 1/3] dt-bindings: iio: adc: add bindings for stm32 mdf filter

[Krzysztof Kozlowski]

On 06/10/2026 17:48, Olivier MOYSAN wrote:
>>>
>>> diff --git a/Documentation/devicetree/bindings/iio/adc/st,stm32-mdf-adc.yaml b/Documentation/devicetree/bindings/iio/adc/st,stm32-mdf-adc.yaml
>>> new file mode 100644
>>> index 000000000000..f2fbc3e150e8
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/iio/adc/st,stm32-mdf-adc.yaml
>>
>> Filename follows compatible, so st,stm32mp23-mdf
>>
> 
> stmp32mp25 is the main SoC, while stm32mp23 is a variant.
> file renamed st,stm32mp25-mdf.yaml

Sure, that's fine.

> 
>>> @@ -0,0 +1,383 @@
>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>>> +%YAML 1.2
>>> +---
>>> +$id: http://devicetree.org/schemas/iio/adc/st,stm32-mdf-adc.yaml#
>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>>> +
>>> +title: STMicroelectronics STM32 Multi-function Digital Filter (MDF) ADC
>>> +
>>> +maintainers:
>>> +  - Olivier Moysan <olivier.moysan@foss.st.com>
>>> +
>>> +description: |
>>> +  STM32 MDF ADC is a sigma delta analog-to-digital converter dedicated to
>>> +  interface external sigma delta modulators to STM32 micro controllers.
>>> +
>>> +properties:
>>> +  compatible:
>>> +    enum:
>>> +      - st,stm32mp25-mdf
>>> +      - st,stm32mp23-mdf
>>
>> Why reversed order?
>>
> 
> Ok. Reordered alphabetically
> 
>>> +  ranges: true
>>> +
>>> +  clock-ranges: true
>>
>> Do you need it here?
> 
> clock-ranges property is used to allow the filter child nodes to inherit 
> the MDF kernel clock from the parent node.

You answered why you need it in DTS. I question why do you need it in
the binding? Do you see a warning?

> 
>>
>>> +
>>> +  resets:
>>> +    maxItems: 1
>>> +
>>> +  reset-names:
>>> +    items:
>>> +      - const: mdf


>>> +        then:
>>> +          patternProperties:
>>> +            "^channel@[0-7]$":
>>> +              required:
>>> +                - io-backends
>>> +
>>> +      - if:
>>> +          properties:
>>> +            compatible:
>>> +              contains:
>>> +                const: st,stm32mp25-mdf-dmic
>>> +
>>> +        then:
>>> +          patternProperties:
>>> +            "^mdf-dai+$":
>>
>> This makes no sense. Why is this a pattern and why mdf-daiiiii is
>> correct name?
>>
> 
> "^mdf-dai$" is intended here
> 
>> Not mentioning that your are not supposed to define properties in if
>> block (do you see any code like that?). Mixing addressable and
>> non-addressable children is another odd thing.
>>
> 
> This binding is inspired by the one already adopted for the DFSDM
> https://www.kernel.org/doc/Documentation/devicetree/bindings/iio/adc/st,stm32-dfsdm-adc.yaml
> 
> I assume can move the mdf-dai node definition outside the conditional 
> branch easily.
> However, it seems to me more complicated to avoid mixing addressable and 
> non-addressable nodes here. Can we keep this binding aligned with the 
> DFSDM model? Or would you have another suggestion?

Why was this model chosen in that dfsdm? The child has no resources, so
it should never been made a separate node.


> 
>> This entire schema is quite chaotic and overcomplicated.
>>
>>> +              type: object
>>> +              description: child node
>>> +
>>> +              properties:
>>> +                compatible:
>>> +                  enum:
>>> +                    - st,stm32mp25-mdf-dai
>>> +
>>> +                "#sound-dai-cells":
>>> +                  const: 0
>>> +
>>> +                io-channels:
>>> +                  description:
>>> +                    From common IIO binding. Used to pipe external sigma delta
>>> +                    modulator or internal ADC output to MDF channel.
>>> +
>>> +                power-domains:
>>> +                  maxItems: 1
>>> +
>>> +                port:
>>> +                  $ref: /schemas/sound/audio-graph-port.yaml#
>>> +                  unevaluatedProperties: false
>>> +
>>> +              required:
>>> +                - compatible
>>> +                - "#sound-dai-cells"
>>> +                - io-channels
>>> +
>>> +              additionalProperties: false
>>> +
>>> +examples:
>>> +  - |
>>> +    #include <dt-bindings/clock/st,stm32mp25-rcc.h>
>>> +    #include <dt-bindings/interrupt-controller/arm-gic.h>
>>> +    mdf1: mdf@504d0000 {
>>
>> Node names should be generic. See also an explanation and list of
>> examples (not exhaustive) in DT specification:
>> https://devicetree-specification.readthedocs.io/en/latest/chapter2-devicetree-basics.html#generic-names-recommendation
>> If you cannot find a name matching your device, please check in kernel
>> sources for similar cases or you can grow the spec (via pull request to
>> DT spec repo).
>>
>> And drop unused labels.
>>
> 
> The MDF is a digital filter for sigma-delta bitstreams, rather than the 
> analog-to-digital converter itself. So "adc" would not be adapted. I did 
> not find "filter", that probably would be the more relevant generic name.
> The closest similar case is the DFSDM peripheral, which already uses a 
> specific naming:
>      dfsdm: dfsdm@4400d000 { ...
> https://www.kernel.org/doc/Documentation/devicetree/bindings/iio/adc/st,stm32-dfsdm-adc.yaml
> 
> What is your recommendation: keep the naming "mdf" or make a pull 
> request to add "filter" or another more appropriate name ?
> 
>>> +      compatible = "st,stm32mp25-mdf";
>>> +      ranges = <0 0x504d0000 0x1000>;
>>> +      reg = <0x504d0000 0x8>, <0x504d0ff0 0x10>;
>>
>> Address ranges of 2 and 4 words?
>>
> 
> These two sections correspond to MDF common registers managed by the core
> - Control registers: 2 x 32 bits registers
> - Identification registers: 4 x 32 bits registers
> The other registers are managed by filter and serial interface driver
> 


Unfortunately this leaves impression of incomplete DT or too granular
split of devices to match your driver model.

Best regards,
Krzysztof

Re: [PATCH 1/3] dt-bindings: iio: adc: add bindings for stm32 mdf filter

[Krzysztof Kozlowski]

On Thu, Oct 01, 2026 at 04:56:45PM +0200, Olivier Moysan wrote:
> +  clock-output-names:
> +    description: |
> +      CCK0 and CCK1 are optional output clocks, which share the same clock frequency,
> +      but can be gated independently to save power.
> +    minItems: 1
> +    maxItems: 2
> +    oneOf:
> +      - items:
> +          - const: cck0
> +      - items:
> +          - const: cck1
> +      - items:
> +          - const: cck0
> +          - const: cck1

Use simpler notation:
minItems: 1
items:
  - enum
  - const

> +
> +  clock-frequency:
> +    description: |

Drop | when not needed.

> +      Common clock frequency (Hz) for CCK0 and CCK1 output clocks.
> +      The frequency must be a multiple of the "ker_ck" clock frequency.
> +    maximum: 25000000

So here is the clock-frequency. No, these are output clocks as written
above, so consumer sets it, not the provider. Or use existing assigned
properties. This is even mentioned on DTS101 slides, really...

Best regards,
Krzysztof

Re: [PATCH 1/3] dt-bindings: iio: adc: add bindings for stm32 mdf filter

[Olivier MOYSAN]

Hi Krzysztof,

On 10/2/26 11:34, Krzysztof Kozlowski wrote:
> On Thu, Oct 01, 2026 at 04:56:45PM +0200, Olivier Moysan wrote:
>> +  clock-output-names:
>> +    description: |
>> +      CCK0 and CCK1 are optional output clocks, which share the same clock frequency,
>> +      but can be gated independently to save power.
>> +    minItems: 1
>> +    maxItems: 2
>> +    oneOf:
>> +      - items:
>> +          - const: cck0
>> +      - items:
>> +          - const: cck1
>> +      - items:
>> +          - const: cck0
>> +          - const: cck1
> 
> Use simpler notation:
> minItems: 1
> items:
>    - enum
>    - const
> 
>> +
>> +  clock-frequency:
>> +    description: |
> 
> Drop | when not needed.
> 
>> +      Common clock frequency (Hz) for CCK0 and CCK1 output clocks.
>> +      The frequency must be a multiple of the "ker_ck" clock frequency.
>> +    maximum: 25000000
> 
> So here is the clock-frequency. No, these are output clocks as written
> above, so consumer sets it, not the provider. Or use existing assigned
> properties. This is even mentioned on DTS101 slides, really...
> 

We expect the clock frequency to be defined statically for a given board 
So, using assigned-clocks properties looks the right choice.
What bothers me about this solution, is that the frequency will be 
defined in each consumer, whereas a single rate can be defined for the 
provider. This may looks a bit strange, but I will implement it this way 
if there is no other mean to set the provider frequency.


> Best regards,
> Krzysztof
> 

Best regards
Olivier