Re: [PATCH v4 1/2] dt-bindings: Add GPIO-locked fixed clock

[Vyacheslav Yurkov]

On 27.08.2026 18:55, Conor Dooley wrote:

> > It is n input clocks and 1 output clock. It is kind of a mux, but the CPU
> > doesn't control the clocks or GPIO signals. The whole idea is that
> > peripherals check the output clock, when it's locked that means _all_ the
> > clocks are locked and GPIOs are in expected state. That's why the selection
> > operation is not really implemented.
> >
> > Actually the number of input clocks don't have to correspond to the number
> > of the GPIOs, because the GPIO signals indicate the locked state of the
> > clocks that are not accessible to the CPU.
>
> I'm not entirely sure what you mean by this, but it is starting to sound
> like you're only having one output because that's the minimum you need to do
> to ensure that this driver has probed before the peripheral(s) using the
> N input clocks.

That's exactly the idea. How else I would ensure in peripheral's probe 
driver that clocks are locked?

> Requiring other input clocks to be stable before
> declaring the input that's actually connected to the output stable
> appears to be a shortcut/hack rather than an accurate description of the
> hardware. If that's the case, I'd be much happier with this if this was
> implemented as either a) N inputs with N gpios and N outputs, or b) 1 input,
> M gpios (if multiple represent the stability of that input) and 1 output,
> with N instances, one for each clock.

How having N outputs would help? It looks like it would just move the 
job I do here into each peripheral driver instead.

> On the other hand, if this is genuinely a mux, then the binding should
> reflect that, rather than only describe a subset of what you can do and
> the driver should only check the actual parent out the output, rather
> than the N-1 other inputs.
>
> Thanks,
> Conor.


Slava