diff mbox series

[v6,10/14] arm64: dts: freescale: imx8qxp: Remove unnecessary clock related entries

Message ID 20220629164414.301813-11-viorel.suman@oss.nxp.com
State Superseded
Headers show
Series dt-bindings: arm: freescale: Switch fsl,scu from txt to yaml | expand

Commit Message

Viorel Suman (OSS) June 29, 2022, 4:44 p.m. UTC
From: Viorel Suman <viorel.suman@nxp.com>

"clocks" and "clock-names" are not used the driver, so
remove them in order to match the yaml definition.

Signed-off-by: Viorel Suman <viorel.suman@nxp.com>
---
 arch/arm64/boot/dts/freescale/imx8qxp.dtsi | 2 --
 1 file changed, 2 deletions(-)

Comments

Krzysztof Kozlowski June 29, 2022, 6:04 p.m. UTC | #1
On 29/06/2022 18:44, Viorel Suman (OSS) wrote:
> From: Viorel Suman <viorel.suman@nxp.com>
> 
> "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.


Best regards,
Krzysztof
Viorel Suman June 30, 2022, 8:36 a.m. UTC | #2
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@nxp.com>
> > 
> > "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
Krzysztof Kozlowski June 30, 2022, 6:01 p.m. UTC | #3
On 30/06/2022 10:36, Viorel Suman wrote:
> 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@nxp.com>
>>>
>>> "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.

ABI break is not relevant to the fixed clocks being or not being defined
in the DTS. You have a device which was taking the clock inputs, so the
clocks stayed enabled.

Now, you don't take these inputs, so for example the clocks are getting
disabled as not used.

> 
> "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.

OK, that sounds good, but the question about these clocks remain - are
they inputs to the SCU or not.

Regardless whether they are actual input or not, you used not
appropriate argument here - that Linux OS implementation does not use
them. The proper argument is - whether the hardware environment has them
connected or not.

Best regards,
Krzysztof
Viorel Suman (OSS) June 30, 2022, 7:48 p.m. UTC | #4
On 22-06-30 20:01:31, Krzysztof Kozlowski wrote:
> On 30/06/2022 10:36, Viorel Suman wrote:
> > 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@nxp.com>
> >>>
> >>> "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.
> 
> ABI break is not relevant to the fixed clocks being or not being defined
> in the DTS. You have a device which was taking the clock inputs, so the
> clocks stayed enabled.
> 
> Now, you don't take these inputs, so for example the clocks are getting
> disabled as not used.

Ok, thanks for the explanation.

> > 
> > "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.
> 
> OK, that sounds good, but the question about these clocks remain - are
> they inputs to the SCU or not.

The question context looks a bit shifted. The "clocks" and "clock-names"
attributes are removed from a clock provider device.

The OS clock provider in this case is a client which uses some protocol
to communicate with SCU via a messaging unit. There is no
access to xtal clocks via the existing OS<->SCU communication protocol.

> 
> Regardless whether they are actual input or not, you used not
> appropriate argument here - that Linux OS implementation does not use
> them. The proper argument is - whether the hardware environment has them
> connected or not.

Right, agreed.

Regards,
Viorel
diff mbox series

Patch

diff --git a/arch/arm64/boot/dts/freescale/imx8qxp.dtsi b/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
index 483996a1f2d5..878c2aa663f1 100644
--- a/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
@@ -218,8 +218,6 @@  pd: imx8qx-pd {
 		clk: clock-controller {
 			compatible = "fsl,imx8qxp-clk";
 			#clock-cells = <2>;
-			clocks = <&xtal32k &xtal24m>;
-			clock-names = "xtal_32KHz", "xtal_24Mhz";
 		};
 
 		iomuxc: pinctrl {