Add support for the Google gs101 version of the Exynos power domains. A
new compatible is needed because register fields have changed and
because power domain operations involve interfacing with the TrustZone
protection control on newer Exynos SoCs.
Power domains can also have a power supply linked to them, so add
optional support for that, too. It is believed that all (existing)
platforms could benefit from this, hence it's not being limited to
gs101-pd.
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: André Draszik <andre.draszik@linaro.org>
---
v5:
- add domain-supply and update commit message
v4:
- add new vendor property samsung,dtzpc
- drop previous tags due to that
---
.../devicetree/bindings/power/pd-samsung.yaml | 33 ++++++++++++++++++++--
1 file changed, 30 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/power/pd-samsung.yaml b/Documentation/devicetree/bindings/power/pd-samsung.yaml
index 9c2c51133457..3f1a2dc17862 100644
--- a/Documentation/devicetree/bindings/power/pd-samsung.yaml
+++ b/Documentation/devicetree/bindings/power/pd-samsung.yaml
@@ -13,12 +13,10 @@ description: |+
Exynos processors include support for multiple power domains which are used
to gate power to one or more peripherals on the processor.
-allOf:
- - $ref: power-domain.yaml#
-
properties:
compatible:
enum:
+ - google,gs101-pd
- samsung,exynos4210-pd
- samsung,exynos5433-pd
@@ -33,6 +31,9 @@ properties:
deprecated: true
maxItems: 1
+ domain-supply:
+ description: domain regulator supply.
+
label:
description:
Human readable string with domain name. Will be visible in userspace
@@ -44,11 +45,28 @@ properties:
power-domains:
maxItems: 1
+ samsung,dtzpc:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description:
+ Distributed TrustZone Protection Control (DTZPC) node.
+
required:
- compatible
- "#power-domain-cells"
- reg
+allOf:
+ - $ref: power-domain.yaml#
+ - if:
+ not:
+ properties:
+ compatible:
+ contains:
+ const: google,gs101-pd
+ then:
+ properties:
+ samsung,dtzpc: false
+
unevaluatedProperties: false
examples:
@@ -66,3 +84,12 @@ examples:
#power-domain-cells = <0>;
label = "MFC";
};
+
+ power-domain@2080 {
+ compatible = "google,gs101-pd";
+ reg = <0x2080 0x80>;
+ #power-domain-cells = <0>;
+ label = "hsi0";
+ domain-supply = <&ldo7m>;
+ samsung,dtzpc = <&dtzpc_hsi0>;
+ };
--
2.53.0.851.ga537e3e6e9-goog
On Wed, 18 Mar 2026 15:27:47 +0000, André Draszik <andre.draszik@linaro.org> wrote: > diff --git a/Documentation/devicetree/bindings/power/pd-samsung.yaml b/Documentation/devicetree/bindings/power/pd-samsung.yaml > index 9c2c51133457..3f1a2dc17862 100644 > --- a/Documentation/devicetree/bindings/power/pd-samsung.yaml > +++ b/Documentation/devicetree/bindings/power/pd-samsung.yaml > @@ -44,11 +45,28 @@ properties: > power-domains: > maxItems: 1 > > + samsung,dtzpc: > + $ref: /schemas/types.yaml#/definitions/phandle > + description: > + Distributed TrustZone Protection Control (DTZPC) node. For what purpose? Your patchset is organized in odd way - first patch for me, then not for me, then again two patches for me. Please keep it consistent. Or better, decouple since there are no dependencies according to cover letter. Best regards, Krzysztof -- Krzysztof Kozlowski <krzk@kernel.org>
Hi Krzysztof, On Sat, 2026-03-21 at 14:16 +0100, Krzysztof Kozlowski wrote: > On Wed, 18 Mar 2026 15:27:47 +0000, André Draszik <andre.draszik@linaro.org> wrote: > > diff --git a/Documentation/devicetree/bindings/power/pd-samsung.yaml b/Documentation/devicetree/bindings/power/pd-samsung.yaml > > index 9c2c51133457..3f1a2dc17862 100644 > > --- a/Documentation/devicetree/bindings/power/pd-samsung.yaml > > +++ b/Documentation/devicetree/bindings/power/pd-samsung.yaml > > @@ -44,11 +45,28 @@ properties: > > power-domains: > > maxItems: 1 > > > > + samsung,dtzpc: > > + $ref: /schemas/types.yaml#/definitions/phandle > > + description: > > + Distributed TrustZone Protection Control (DTZPC) node. > > For what purpose? It is part of the domain. Furthermore, TZ configuration is lost as part of power-domain power cycle, so this allows a driver to take necessary actions (inform the EL3 firmware). I believe this handle to be similar to e.g. the existing samsung,sysreg > Your patchset is organized in odd way - first patch for me, then not for > me, then again two patches for me. Please keep it consistent. Or better, > decouple since there are no dependencies according to cover letter. I'll update the cover letter to describe the dependencies. 4 depends on 2, and 2 depends on 1, hence the ordering. Cheers, Andre
On 30/03/2026 12:52, André Draszik wrote: >> Your patchset is organized in odd way - first patch for me, then not for >> me, then again two patches for me. Please keep it consistent. Or better, >> decouple since there are no dependencies according to cover letter. > > I'll update the cover letter to describe the dependencies. 4 depends on 2, How 4 (soc) patch depends on 2 (pm domains)? What is exactly the dependency? Best regards, Krzysztof
On Mon, 2026-03-30 at 12:55 +0200, Krzysztof Kozlowski wrote: > On 30/03/2026 12:52, André Draszik wrote: > > > Your patchset is organized in odd way - first patch for me, then not for > > > me, then again two patches for me. Please keep it consistent. Or better, > > > decouple since there are no dependencies according to cover letter. > > > > I'll update the cover letter to describe the dependencies. 4 depends on 2, > > > How 4 (soc) patch depends on 2 (pm domains)? What is exactly the dependency? 4 updates the soc-level pmu binding of gs101 to have gs101-power-domain child-nodes, which are introduced in 2 A.
On 30/03/2026 12:59, André Draszik wrote: > On Mon, 2026-03-30 at 12:55 +0200, Krzysztof Kozlowski wrote: >> On 30/03/2026 12:52, André Draszik wrote: >>>> Your patchset is organized in odd way - first patch for me, then not for >>>> me, then again two patches for me. Please keep it consistent. Or better, >>>> decouple since there are no dependencies according to cover letter. >>> >>> I'll update the cover letter to describe the dependencies. 4 depends on 2, >> >> >> How 4 (soc) patch depends on 2 (pm domains)? What is exactly the dependency? > > 4 updates the soc-level pmu binding of gs101 to have gs101-power-domain > child-nodes, which are introduced in 2 > You described what the patch is doing, but that was not my question. What is the dependency exactly. This is ping pong, so I finish discussions here, but to be clear - entire patchset cannot be merged. Best regards, Krzysztof
© 2016 - 2026 Red Hat, Inc.