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

[Conor Dooley <conor@kernel.org>]

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

On Mon, Oct 19, 2026 at 02:30:37AM +0100, Jonathan Cameron wrote:
> 
> > >> 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.
> 
> Hmm.. For an 'conventional' ADC channel a clock is a novel thing to have
> on a per channel basis. What does it mean for an analog signal?

tbh, I don't think this has anything to do with adc.yaml or ADC
channels, the channel that I was talking about here was the channel on
the backend since in Figure 349 the serial interfaces can select between
the two clocks but also select to be clocked by the MDF_CKIx input. We
definitely have some properties about that are used by devices to change
between clock sources - I just dunno if any of them have that capability
on a per-channel basis.

> I think these are signals between the front end (which here typically
> has one channel only) and the backend. They are useful because they
> end up indicating (I think) whether we want to interleave or not?

If it was just about interleaving, I don't think you'd need two of them,
since only one set of interleaved channels is possible? There's also the
option I mentioned of having the MDF_CKIx be the clock. Maybe being a
clock controller is actually the right thing to do, just with the
frontend sdmodulator or w/e connected to the SITFx being the consumer?
In that case, you'd need to do something to actually represent the clock
mux in dt, one mux per SITFx, leaving us with N output clocks from
CLK_SITF0 to CLK_SITFx rather than two because we're thinking in terms
of programming model not physical outputs. Additionally, the number of
input clocks grows by N since MDF_CKIx are all parents of the muxes.
You'd then use assigned-clock-parents from the frontend node to set the
parent of the mux (I think anyway). I'd be a little afraid of creating a
loop there though, that needs to be broken, if the MDF_CKIx provider is
the sd-modulator - but idk if that's possible and cyclic dependencies
like that can always be dealt with anyway.

That's probably the most natural way to go about things from a DT point
of view, and makes some sense to me if the clock is being used to drive
communication with the sd-modulator - although it seems a little forced.
It's still better IMO than the MDF referencing itself as things are done
now.

> 
> Anyhow, right now I don't have this clear enough in my head to
> give a firm answer.
> 
> Jonathan

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