I really don't like this but I'm not familiar with how TI fdt sutff works.
The part I don't like is drivers calling ti_sysc function out of the blue (but that was already the case before) and always with the argument "fck" as the clock name, why ?

In D60206#1381950, @manu wrote:

I really don't like this but I'm not familiar with how TI fdt sutff works.
The part I don't like is drivers calling ti_sysc function out of the blue (but that was already the case before) and always with the argument "fck" as the clock name, why ?

Yeah, a brief description of the background for ti_sysc can be found here https://cgit.freebsd.org/src/tree/sys/contrib/device-tree/Bindings/bus/ti-sysc.yaml
For example the gpio controller can use the "dbclk" for debounce functionality but today there is no support for configure the debounce of the input pin that is why I only enable the functional clock ("fck")
https://cgit.freebsd.org/src/tree/sys/contrib/device-tree/src/arm/ti/omap/am33xx-l4.dtsi#n137

I can't give you a good explanation as to why TI placed the clock references in the parent node instead of directly in the GPIO controller node itself.
If you have any suggestions for a cleaner way to access resources located in the parent node, I could give it a try.
One obvious solution would be for the GPIO driver (and others) to query the parent node's clocks during its attach() call and create the clock references itself?

In D60206#1382194, @oh wrote:

In D60206#1381950, @manu wrote:

I really don't like this but I'm not familiar with how TI fdt sutff works.
The part I don't like is drivers calling ti_sysc function out of the blue (but that was already the case before) and always with the argument "fck" as the clock name, why ?

Yeah, a brief description of the background for ti_sysc can be found here https://cgit.freebsd.org/src/tree/sys/contrib/device-tree/Bindings/bus/ti-sysc.yaml
For example the gpio controller can use the "dbclk" for debounce functionality but today there is no support for configure the debounce of the input pin that is why I only enable the functional clock ("fck")
https://cgit.freebsd.org/src/tree/sys/contrib/device-tree/src/arm/ti/omap/am33xx-l4.dtsi#n137

Ok I see.

I can't give you a good explanation as to why TI placed the clock references in the parent node instead of directly in the GPIO controller node itself.

One explanation is that TI linux devs are crazy because it wasn't like that before and it was ok.

If you have any suggestions for a cleaner way to access resources located in the parent node, I could give it a try.
One obvious solution would be for the GPIO driver (and others) to query the parent node's clocks during its attach() call and create the clock references itself?

No I don't think that this is a good solution, in fact I think that the current one is the correct approach but it could be cleaner, like making a proper ti,sysc interface with methods to enable clocks and others. But that could be done later.

The clock property is located in the parent node/driver because the parent node provides this clock for all its children. The children have no individual gate functionality, meaning the parent driver must enable the clock for them.

Of course, this assumes that clocks are implemented properly using the clock framework. However, this is also a hard prerequisite for returning TI to the universe build or introducing arm64 SoCs.