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

[Conor Dooley <conor@kernel.org>]

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

On Thu, Mar 26, 2026 at 02:39:22PM +0100, Vyacheslav Yurkov wrote:
> On 26.03.2026 11:08, Krzysztof Kozlowski wrote:
> 
> > > 
> > > DTS example:
> > >     clock_guard: clock_controller_guard {
> > >       compatible = "clock-controller-guard";
> > >       #clock-cells = <1>;
> > >       clocks = <&h2f_clk 0>, <&clk_fgpa_rx 0>, <clk_fpga_tx 0>;
> > >       clock-names = "h2f_clk0", "clk_fpga_rx", "clk_fpga_tx";
> > >       gpios = <&fpga_ip 0 GPIO_ACTIVE_HIGH>, <&fpga_ip 1 GPIO_ACTIVE_HIGH>;
> > >       gpio-names = "gpio-input0", "gpio-input1";
> > >       clock-output-names = "clkctrl-guard";
> > >     };
> > > 
> > >     custom_device {
> > >       compatible = "...";
> > >       ...
> > >       #clock-cells = <1>;
> > >       clocks = <&clock_guard 0>;
> > >       clock-names = "clock-guard";
> > >     };
> > 
> > So a pure SW construct? Device has specific clock inputs but you do not
> > model them and instead replace with one fake-guard-input.
> > 
> > I don't see how this represents the hardware at all.
> > 
> > Maybe some diagrams would help, assuming we still talk about hardware.
> > 
> > Best regards,
> > Krzysztof
> 
> Techincally that's correct, it's a software construct. If this is not a

Is it a software construct?
I assume that the PLL status is going to be some lock bit in a register,
and you're got some "hardware" in your FPGA fabric that reads that bit
and sets a GPIO when it gets locked? Or maybe it's even simpler, and
your GPIO just gets set once your custom HDL comes out of reset, which
happens when the PLL locks?
If that's an approximation of what you have, that's not a software
construct.

> right place to submit such a helper driver, I'd appreciate a hint what
> subsystem is the right one.
> 
> 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.


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