Re: [PATCH 1/3] dt-bindings: iio: adc: add bindings for stm32 mdf filter
From: Olivier MOYSAN
Date: Thu Oct 15 2026 - 05:25:59 EST
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@xxxxxxxxxxx/)
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.