On 22-06-29 20:04:43, Krzysztof Kozlowski wrote:
> On 29/06/2022 18:44, Viorel Suman (OSS) wrote:
> > From: Viorel Suman <viorel.suman@xxxxxxx>
> >
> > "clocks" and "clock-names" are not used the driver, so
> > remove them in order to match the yaml definition.
>
> So this explains the unexpected change in the bindings... but actually
> it does not explain whether it is correct or not. Just because driver
> does not use it, is not a proof that clocks are not there. In different
> OS/implementation this DTS might break stuff, so basically it is ABI
> break. DTS should describe the hardware fully, so if the clocks are
> there, should be in DTS regardless of the driver.
Hi Krzysztof,
Both XTAL clocks - 24MHz and 32kHz - are still defined in DTSI files, see for instance in
arch/arm64/boot/dts/freescale/imx8qxp.dtsi :
---------------
xtal32k: clock-xtal32k {
compatible = "fixed-clock";
#clock-cells = <0>;
clock-frequency = <32768>;
clock-output-names = "xtal_32KHz";
};
xtal24m: clock-xtal24m {
compatible = "fixed-clock";
#clock-cells = <0>;
clock-frequency = <24000000>;
clock-output-names = "xtal_24MHz";
};
---------------
Both can be seen in /sys/kernel/debug/clk/clk_summary once boot is complete, both can be referenced
in any DTS node, so there is no ABI break.
"DTS should describe the hardware fully" - this is true in case the OS is supposed to controll the
hardware fully. i.MX8 System Controller Unit concept implies resources being allocated and managed
by SCU, there is no direct OS access to some hardware. SCU actually defines the hardware environment
the OS is being able to see and run within. SCU is able to define several such isolated hardware
environments, each having its own OS running. So, in this particular case - i.MX8 SCU concept -
DTS should describe the hardware from the perspective of the hardware environment exposed by SCU to
OS.
Best regards,
Viorel
