[PATCH v3 1/4] dt-bindings: clock: google,gs101-clock: add samsung,sysreg property as required

Peter Griffin posted 4 patches 3 months, 1 week ago
There is a newer version of this series
[PATCH v3 1/4] dt-bindings: clock: google,gs101-clock: add samsung,sysreg property as required
Posted by Peter Griffin 3 months, 1 week ago
Each CMU (with the exception of cmu_top) has a corresponding sysreg bank
that contains the BUSCOMPONENT_DRCG_EN and MEMCLK registers.

If present these registers need to be initialised in the clock driver.
Update the bindings documentation so that all CMUs (with the exception of
gs101-cmu-top) have samsung,sysreg as a required property.

Additionally update the DT example to included the correct CMU size as
registers in that region are used for auto clock mode.

Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
---
Changes in v2:
- Update commit description as to why the sysreg is required (Krzysztof)
- Update commit description regarding updated example (Andre)
---
 .../bindings/clock/google,gs101-clock.yaml         | 23 +++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/clock/google,gs101-clock.yaml b/Documentation/devicetree/bindings/clock/google,gs101-clock.yaml
index 31e106ef913dead9a038b3b6d8b43b950587f6aa..5ce5ba523110af3a2a7740b8ba28e2271c76bddb 100644
--- a/Documentation/devicetree/bindings/clock/google,gs101-clock.yaml
+++ b/Documentation/devicetree/bindings/clock/google,gs101-clock.yaml
@@ -52,6 +52,11 @@ properties:
   reg:
     maxItems: 1
 
+  samsung,sysreg:
+    $ref: /schemas/types.yaml#/definitions/phandle
+    description:
+      Phandle to system registers interface.
+
 required:
   - compatible
   - "#clock-cells"
@@ -166,6 +171,22 @@ allOf:
             - const: bus
             - const: ip
 
+  - if:
+      properties:
+        compatible:
+          contains:
+            enum:
+              - google,gs101-cmu-apm
+              - google,gs101-cmu-misc
+              - google,gs101-hsi0
+              - google,gs101-cmu-hsi2
+              - google,gs101-cmu-peric0
+              - google,gs101-cmu-peric1
+
+    then:
+      required:
+        - samsung,sysreg
+
 additionalProperties: false
 
 examples:
@@ -175,7 +196,7 @@ examples:
 
     cmu_top: clock-controller@1e080000 {
         compatible = "google,gs101-cmu-top";
-        reg = <0x1e080000 0x8000>;
+        reg = <0x1e080000 0x10000>;
         #clock-cells = <1>;
         clocks = <&ext_24_5m>;
         clock-names = "oscclk";

-- 
2.51.1.930.gacf6e81ea2-goog
Re: [PATCH v3 1/4] dt-bindings: clock: google,gs101-clock: add samsung,sysreg property as required
Posted by Krzysztof Kozlowski 3 months, 1 week ago
On Sun, Nov 02, 2025 at 08:27:14PM +0000, Peter Griffin wrote:
> Each CMU (with the exception of cmu_top) has a corresponding sysreg bank
> that contains the BUSCOMPONENT_DRCG_EN and MEMCLK registers.
> 
> If present these registers need to be initialised 


... for what exactly? What would happen if this was not initialized?
What is the exact justification for ABI break - wasn't this working
before? Or new feature will not work (thus no ABI break allowed)?

You need to provide rationale and "driver needs to do something" is not
enough, because everything could be justified that way.

> in the clock driver.
> Update the bindings documentation so that all CMUs (with the exception of
> gs101-cmu-top) have samsung,sysreg as a required property.
> 
> Additionally update the DT example to included the correct CMU size as
> registers in that region are used for auto clock mode.

Best regards,
Krzysztof
Re: [PATCH v3 1/4] dt-bindings: clock: google,gs101-clock: add samsung,sysreg property as required
Posted by Peter Griffin 3 months, 1 week ago
Hi Krzysztof,

Thanks for the review feedback!

On Mon, 3 Nov 2025 at 09:41, Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
> On Sun, Nov 02, 2025 at 08:27:14PM +0000, Peter Griffin wrote:
> > Each CMU (with the exception of cmu_top) has a corresponding sysreg bank
> > that contains the BUSCOMPONENT_DRCG_EN and MEMCLK registers.
> >
> > If present these registers need to be initialised
>
>
> ... for what exactly? What would happen if this was not initialized?

The BUSCOMPONENT_DRCG_EN register enables dynamic root clock gating of
bus components. So it is related to the automatic clock gating feature
that is being enabled in this series. Things still work without
initializing this register, but the bus components won't be
automatically clock gated leading to increased dynamic power
consumption. Similarly the memclk register enables/disables sram clock
gate. Up until now we've not been initializing the registers as
everything from Linux PoV has been in manual clock gating mode and
until starting to implement this I wasn't aware there were some clock
related registers in the corresponding sysreg. Additionally with
Andre's work enabling power domains it has become clear we should be
saving/restoring these two sysreg clock registers when the power
domain is turned off and on.

> What is the exact justification for ABI break - wasn't this working
> before? Or new feature will not work (thus no ABI break allowed)?

No, automatic clocks and dynamic root clock gating were not working
prior to this series. Currently power domains and system wide
suspend/resume aren't enabled upstream either. As we work on enabling
these features we are finding some things that in an ideal world we
would have known about earlier. Unfortunately it's not so obvious just
from studying the downstream code either as they rely heavily on
CAL-IF layer that has peeks/pokes all over the memory map especially
for power/clock related functionality.

Whilst it is technically an ABI break, I've tried to implement it in a
backwards compatible way (i.e. an old DT without the samsung,sysreg
phandle specified) will just fallback to the current behavior of not
initializing these registers. Things will still work to the extent
they did prior to this series. With a new DT the registers will be
initialized, and dynamic power consumption will be better.

>
> You need to provide rationale and "driver needs to do something" is not
> enough, because everything could be justified that way.

Apologies for not being more verbose in the commit message on the
technical details, hopefully the above helps explain it better.

regards,

Peter
Re: [PATCH v3 1/4] dt-bindings: clock: google,gs101-clock: add samsung,sysreg property as required
Posted by Krzysztof Kozlowski 3 months ago
On Mon, Nov 03, 2025 at 01:49:53PM +0000, Peter Griffin wrote:
> Hi Krzysztof,
> 
> Thanks for the review feedback!
> 
> On Mon, 3 Nov 2025 at 09:41, Krzysztof Kozlowski <krzk@kernel.org> wrote:
> >
> > On Sun, Nov 02, 2025 at 08:27:14PM +0000, Peter Griffin wrote:
> > > Each CMU (with the exception of cmu_top) has a corresponding sysreg bank
> > > that contains the BUSCOMPONENT_DRCG_EN and MEMCLK registers.
> > >
> > > If present these registers need to be initialised
> >
> >
> > ... for what exactly? What would happen if this was not initialized?
> 
> The BUSCOMPONENT_DRCG_EN register enables dynamic root clock gating of
> bus components. So it is related to the automatic clock gating feature
> that is being enabled in this series. Things still work without
> initializing this register, but the bus components won't be
> automatically clock gated leading to increased dynamic power
> consumption. Similarly the memclk register enables/disables sram clock
> gate. Up until now we've not been initializing the registers as
> everything from Linux PoV has been in manual clock gating mode and
> until starting to implement this I wasn't aware there were some clock
> related registers in the corresponding sysreg. Additionally with
> Andre's work enabling power domains it has become clear we should be
> saving/restoring these two sysreg clock registers when the power
> domain is turned off and on.
> 
> > What is the exact justification for ABI break - wasn't this working
> > before? Or new feature will not work (thus no ABI break allowed)?
> 
> No, automatic clocks and dynamic root clock gating were not working
> prior to this series. Currently power domains and system wide
> suspend/resume aren't enabled upstream either. As we work on enabling
> these features we are finding some things that in an ideal world we
> would have known about earlier. Unfortunately it's not so obvious just
> from studying the downstream code either as they rely heavily on
> CAL-IF layer that has peeks/pokes all over the memory map especially
> for power/clock related functionality.
> 
> Whilst it is technically an ABI break, I've tried to implement it in a
> backwards compatible way (i.e. an old DT without the samsung,sysreg
> phandle specified) will just fallback to the current behavior of not
> initializing these registers. Things will still work to the extent
> they did prior to this series. With a new DT the registers will be
> initialized, and dynamic power consumption will be better.

So explain that this is needed for proper and complete power management
solution on this SoC, however that is not an ABI break because Linux
driver will be stil backwards compatible.


Best regards,
Krzysztof
Re: [PATCH v3 1/4] dt-bindings: clock: google,gs101-clock: add samsung,sysreg property as required
Posted by Peter Griffin 3 months ago
Hi Krzysztof,

On Tue, 4 Nov 2025 at 08:11, Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
> On Mon, Nov 03, 2025 at 01:49:53PM +0000, Peter Griffin wrote:
> > Hi Krzysztof,
> >
> > Thanks for the review feedback!
> >
> > On Mon, 3 Nov 2025 at 09:41, Krzysztof Kozlowski <krzk@kernel.org> wrote:
> > >
> > > On Sun, Nov 02, 2025 at 08:27:14PM +0000, Peter Griffin wrote:
> > > > Each CMU (with the exception of cmu_top) has a corresponding sysreg bank
> > > > that contains the BUSCOMPONENT_DRCG_EN and MEMCLK registers.
> > > >
> > > > If present these registers need to be initialised
> > >
> > >
> > > ... for what exactly? What would happen if this was not initialized?
> >
> > The BUSCOMPONENT_DRCG_EN register enables dynamic root clock gating of
> > bus components. So it is related to the automatic clock gating feature
> > that is being enabled in this series. Things still work without
> > initializing this register, but the bus components won't be
> > automatically clock gated leading to increased dynamic power
> > consumption. Similarly the memclk register enables/disables sram clock
> > gate. Up until now we've not been initializing the registers as
> > everything from Linux PoV has been in manual clock gating mode and
> > until starting to implement this I wasn't aware there were some clock
> > related registers in the corresponding sysreg. Additionally with
> > Andre's work enabling power domains it has become clear we should be
> > saving/restoring these two sysreg clock registers when the power
> > domain is turned off and on.
> >
> > > What is the exact justification for ABI break - wasn't this working
> > > before? Or new feature will not work (thus no ABI break allowed)?
> >
> > No, automatic clocks and dynamic root clock gating were not working
> > prior to this series. Currently power domains and system wide
> > suspend/resume aren't enabled upstream either. As we work on enabling
> > these features we are finding some things that in an ideal world we
> > would have known about earlier. Unfortunately it's not so obvious just
> > from studying the downstream code either as they rely heavily on
> > CAL-IF layer that has peeks/pokes all over the memory map especially
> > for power/clock related functionality.
> >
> > Whilst it is technically an ABI break, I've tried to implement it in a
> > backwards compatible way (i.e. an old DT without the samsung,sysreg
> > phandle specified) will just fallback to the current behavior of not
> > initializing these registers. Things will still work to the extent
> > they did prior to this series. With a new DT the registers will be
> > initialized, and dynamic power consumption will be better.
>
> So explain that this is needed for proper and complete power management
> solution on this SoC, however that is not an ABI break because Linux
> driver will be stil backwards compatible.

I'll send a new version shortly with an updated commit message like you suggest.

Thanks,

Peter.