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

[Olivier MOYSAN <olivier.moysan@foss.st.com>]

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.