Re: [PATCH 2/2] dt-bindings: Add clock guard DT description
From: Vyacheslav Yurkov
Date: Fri Mar 27 2026 - 22:59:05 EST
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