Re: [PATCH 2/2] dt-bindings: Add clock guard DT description

[Conor Dooley]

On Sat, Mar 28, 2026 at 03:58:47AM +0100, Vyacheslav Yurkov wrote:
> On 26.03.2026 19:32, Conor Dooley wrote:
> 
> > > I was not sure how to provide a diagram in the mailing list, so I posted in
> > > on Github https://github.com/OSS-Keepers/clock-controller-guard/issues/1
> > > 
> > > It is a driver which models dependencies for other drivers. These are soft
> > > or "indirect" dependencies, because we cannot access the FPGA unless the
> > > FPGA_PLL_locked, and GPIO is telling us we are good to go.
> > > 
> > > Conor, I think this should answer your question as well.
> > 
> > Not really, but it gets part of the way there. I want to know what this
> > provider actually is. I now know it is a PLL, not an off-chip
> > oscillator, but I know nothing about the interface that you have to it
> > (or if you have one at all). What compatible string/kernel driver does
> > it use?
> > 
> > Because SoC-FPGAs can route GPIOs from the SoC part to the FPGA fabric
> > and use them as if interacting with something off-chip, I'm not sure if
> > we are dealing with an separate FPGA or a SoC-FPGA. Which is it?
> > Effectively I want to understand why you cannot just read the lock bit
> > from the PLL directly. In my experience with *SoC*-FPGAs, things like
> > PLLs that must lock for the fabric to be usable have a register
> > interface from which the lock bit can be read, that is of course not
> > clocked by the PLL output clock and therefore accessible before the
> > PLL has locked.
> > 
> > I think more info is needed here to guide you on where such a "helper
> > driver" should be located and what the dt represetation should be.
> 
> I really appreciate your feedback on this. Here's an attempt to provide a
> better exlanation.
> 
> We have various use cases. Most of the time it's a PLL in the FPGA but it
> can also be some signal from a custom FPGA IP used to indicate if some
> preconditions are met and the IP is ready to be used (some kind of inverted
> reset but exposed by the IP). For a PLL we typically get the signal
> connected either to a GPIO IP block (altr,pio-1.0) OR to a bit in a custom
> IP register.
> In addition, some of the IPs in our design do not have a proper split
> between registers and IP core, which means that if an external clock and/or
> PLL lock is missing and we access the registers we won’t ever get an answer
> and thus stall the CPU.
> 
> We are using a SoC-FPGA and use some GPIO IP within the FPGA (altr,pio-1.0
> for example).
> 
> The PLL itself doesn't have any registers but the signal indicating that it
> is locked is available and routed to such a GPIO.
> 
> The point is that we will have several IPs/drivers that will depend on the
> same preconditions (clk, gpios being high or low) and we want to use this
> clk_guard driver as an aggregator for those pre-conditions. Define once,
> reuse a lot.

Apologies for the delay responding, been sick the last week.
I think what you have here is not unreasonable, but may never have users
other than yourself! It's effectively gated-fixed-clock but the gpio
direction is inverted. I'm not keen on the "guarded" wording, but I
think I would want you to become a fixed-clock variant w/ a prefix that
indicates what's different. Then you get locked-gpios instead of
enable-gpios that gated-fixed-clock has.

Or maybe you're a gpio-gate-clock variant instead, and represent the PLL
as a fixed-clock (but I think being a fixed-clock variant makes more
sense).

Attachment: signature.asc
Description: PGP signature