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

[Vyacheslav Yurkov <uvv.mail@gmail.com>]

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.

Slava