From: Rob Herring <robh+dt@kernel.org> To: Hector Martin <marcan@marcan.st> Cc: linux-arm-kernel <linux-arm-kernel@lists.infradead.org>, Marc Zyngier <maz@kernel.org>, Arnd Bergmann <arnd@kernel.org>, Linus Walleij <linus.walleij@linaro.org>, Alyssa Rosenzweig <alyssa@rosenzweig.io>, Krzysztof Kozlowski <krzk@kernel.org>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Mark Kettenis <mark.kettenis@xs4all.nl>, Philipp Zabel <p.zabel@pengutronix.de>, "Rafael J. Wysocki" <rafael@kernel.org>, devicetree@vger.kernel.org, "open list:THERMAL" <linux-pm@vger.kernel.org>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, linux-samsung-soc <linux-samsung-soc@vger.kernel.org>, "open list:SERIAL DRIVERS" <linux-serial@vger.kernel.org> Subject: Re: [PATCH 2/7] dt-bindings: power: Add apple,pmgr-pwrstate binding Date: Tue, 5 Oct 2021 19:58:24 -0500 [thread overview] Message-ID: <CAL_JsqJenHAOw4gApzGpuj-8nZjkYhmBg0qBj-DV+CEJ7zXuVw@mail.gmail.com> (raw) In-Reply-To: <20211005155923.173399-3-marcan@marcan.st> On Tue, Oct 5, 2021 at 10:59 AM Hector Martin <marcan@marcan.st> wrote: > > This syscon child node represents a single SoC device controlled by the > PMGR block. This layout allows us to declare all device power state > controls (power/clock gating and reset) in the device tree, including > dependencies, instead of hardcoding it into the driver. The register > layout is uniform. > > Each pmgr-pwrstate node provides genpd and reset features, to be > consumed by downstream device nodes. > > Future SoCs are expected to use backwards compatible registers, and the > "apple,pmgr-pwrstate" represents any such interfaces (possibly with > additional features gated by the more specific compatible), allowing > them to be bound without driver updates. If a backwards incompatible > change is introduced in future SoCs, it will require a new compatible, > such as "apple,pmgr-pwrstate-v2". Is that because past SoCs used the same registers? I don't see how else you have any insight to what future SoCs will do. Normally we don't do 1 node per register type bindings, so I'm a bit leery about doing 1 node per domain. > > Signed-off-by: Hector Martin <marcan@marcan.st> > --- > .../bindings/power/apple,pmgr-pwrstate.yaml | 117 ++++++++++++++++++ > MAINTAINERS | 1 + > 2 files changed, 118 insertions(+) > create mode 100644 Documentation/devicetree/bindings/power/apple,pmgr-pwrstate.yaml > > diff --git a/Documentation/devicetree/bindings/power/apple,pmgr-pwrstate.yaml b/Documentation/devicetree/bindings/power/apple,pmgr-pwrstate.yaml > new file mode 100644 > index 000000000000..a14bf5f30ff0 > --- /dev/null > +++ b/Documentation/devicetree/bindings/power/apple,pmgr-pwrstate.yaml > @@ -0,0 +1,117 @@ > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/power/apple,pmgr-pwrstate.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Apple SoC PMGR Power States > + > +maintainers: > + - Hector Martin <marcan@marcan.st> > + > +allOf: > + - $ref: "power-domain.yaml#" > + > +description: | > + Apple SoCs include a PMGR block responsible for power management, > + which can control various clocks, resets, power states, and > + performance features. This binding describes the device power > + state registers, which control power states and resets. > + > + Each instance of a power controller within the PMGR syscon node > + represents a generic power domain provider, as documented in > + Documentation/devicetree/bindings/power/power-domain.yaml. > + The provider controls a single SoC block. The power hierarchy is > + represented via power-domains relationships between these nodes. > + > + See Documentation/devicetree/bindings/arm/apple/apple,pmgr.yaml > + for the top-level PMGR node documentation. > + > + IP cores belonging to a power domain should contain a > + "power-domains" property that is a phandle for the > + power domain node representing the domain. > + > +properties: > + $nodename: > + pattern: "^power-controller@[0-9a-f]+$" Drop this and define this node in the syscon schema with a $ref to this schema. > + > + compatible: > + items: > + - enum: > + - apple,t8103-pmgr-pwrstate > + - const: apple,pmgr-pwrstate > + > + reg: > + maxItems: 1 > + > + "#power-domain-cells": > + const: 0 > + > + "#reset-cells": > + const: 0 > + > + power-domains: > + description: > + Reference to parent power domains. A domain may have multiple parents, > + and all will be powered up when it is powered. > + > + apple,domain-name: > + description: | > + Specifies the name of the SoC device being controlled. This is used to > + name the power/reset domains. > + $ref: /schemas/types.yaml#/definitions/string No other power domain binding needs this, why do you? > + > + apple,always-on: > + description: | > + Forces this power domain to always be powered up. > + type: boolean > + > +required: > + - compatible > + - reg > + - "#power-domain-cells" > + - "#reset-cells" > + - "apple,domain-name" > + > +additionalProperties: false > + > +examples: I prefer 1 complete example in the MFD schema rather than piecemeal examples. > + - | > + soc { > + #address-cells = <2>; > + #size-cells = <2>; > + > + power-management@23b700000 { > + compatible = "apple,t8103-pmgr", "apple,pmgr", "syscon", "simple-mfd"; > + #address-cells = <1>; > + #size-cells = <0>; As the child nodes are memory mapped devices, size should be 1. Then address translation works (though Linux doesn't care (currently)). > + reg = <0x2 0x3b700000 0x0 0x14000>; > + > + ps_sio: power-controller@1c0 { > + compatible = "apple,t8103-pmgr-pwrstate", "apple,pmgr-pwrstate"; > + reg = <0x1c0>; > + #power-domain-cells = <0>; > + #reset-cells = <0>; > + apple,domain-name = "sio"; > + apple,always-on; > + }; > + > + ps_uart_p: power-controller@220 { > + compatible = "apple,t8103-pmgr-pwrstate", "apple,pmgr-pwrstate"; > + reg = <0x220>; > + #power-domain-cells = <0>; > + #reset-cells = <0>; > + apple,domain-name = "uart_p"; > + power-domains = <&ps_sio>; > + }; > + > + ps_uart0: power-controller@270 { > + compatible = "apple,t8103-pmgr-pwrstate", "apple,pmgr-pwrstate"; > + reg = <0x270>; > + #power-domain-cells = <0>; > + #reset-cells = <0>; > + apple,domain-name = "uart0"; > + power-domains = <&ps_uart_p>; > + }; > + }; > + }; > diff --git a/MAINTAINERS b/MAINTAINERS > index d25598842d15..5fe53d9a2956 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -1722,6 +1722,7 @@ F: Documentation/devicetree/bindings/arm/apple.yaml > F: Documentation/devicetree/bindings/arm/apple/* > F: Documentation/devicetree/bindings/interrupt-controller/apple,aic.yaml > F: Documentation/devicetree/bindings/pinctrl/apple,pinctrl.yaml > +F: Documentation/devicetree/bindings/power/apple* > F: arch/arm64/boot/dts/apple/ > F: drivers/irqchip/irq-apple-aic.c > F: include/dt-bindings/interrupt-controller/apple-aic.h > -- > 2.33.0 >
WARNING: multiple messages have this Message-ID (diff)
From: Rob Herring <robh+dt@kernel.org> To: Hector Martin <marcan@marcan.st> Cc: linux-arm-kernel <linux-arm-kernel@lists.infradead.org>, Marc Zyngier <maz@kernel.org>, Arnd Bergmann <arnd@kernel.org>, Linus Walleij <linus.walleij@linaro.org>, Alyssa Rosenzweig <alyssa@rosenzweig.io>, Krzysztof Kozlowski <krzk@kernel.org>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Mark Kettenis <mark.kettenis@xs4all.nl>, Philipp Zabel <p.zabel@pengutronix.de>, "Rafael J. Wysocki" <rafael@kernel.org>, devicetree@vger.kernel.org, "open list:THERMAL" <linux-pm@vger.kernel.org>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, linux-samsung-soc <linux-samsung-soc@vger.kernel.org>, "open list:SERIAL DRIVERS" <linux-serial@vger.kernel.org> Subject: Re: [PATCH 2/7] dt-bindings: power: Add apple,pmgr-pwrstate binding Date: Tue, 5 Oct 2021 19:58:24 -0500 [thread overview] Message-ID: <CAL_JsqJenHAOw4gApzGpuj-8nZjkYhmBg0qBj-DV+CEJ7zXuVw@mail.gmail.com> (raw) In-Reply-To: <20211005155923.173399-3-marcan@marcan.st> On Tue, Oct 5, 2021 at 10:59 AM Hector Martin <marcan@marcan.st> wrote: > > This syscon child node represents a single SoC device controlled by the > PMGR block. This layout allows us to declare all device power state > controls (power/clock gating and reset) in the device tree, including > dependencies, instead of hardcoding it into the driver. The register > layout is uniform. > > Each pmgr-pwrstate node provides genpd and reset features, to be > consumed by downstream device nodes. > > Future SoCs are expected to use backwards compatible registers, and the > "apple,pmgr-pwrstate" represents any such interfaces (possibly with > additional features gated by the more specific compatible), allowing > them to be bound without driver updates. If a backwards incompatible > change is introduced in future SoCs, it will require a new compatible, > such as "apple,pmgr-pwrstate-v2". Is that because past SoCs used the same registers? I don't see how else you have any insight to what future SoCs will do. Normally we don't do 1 node per register type bindings, so I'm a bit leery about doing 1 node per domain. > > Signed-off-by: Hector Martin <marcan@marcan.st> > --- > .../bindings/power/apple,pmgr-pwrstate.yaml | 117 ++++++++++++++++++ > MAINTAINERS | 1 + > 2 files changed, 118 insertions(+) > create mode 100644 Documentation/devicetree/bindings/power/apple,pmgr-pwrstate.yaml > > diff --git a/Documentation/devicetree/bindings/power/apple,pmgr-pwrstate.yaml b/Documentation/devicetree/bindings/power/apple,pmgr-pwrstate.yaml > new file mode 100644 > index 000000000000..a14bf5f30ff0 > --- /dev/null > +++ b/Documentation/devicetree/bindings/power/apple,pmgr-pwrstate.yaml > @@ -0,0 +1,117 @@ > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/power/apple,pmgr-pwrstate.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Apple SoC PMGR Power States > + > +maintainers: > + - Hector Martin <marcan@marcan.st> > + > +allOf: > + - $ref: "power-domain.yaml#" > + > +description: | > + Apple SoCs include a PMGR block responsible for power management, > + which can control various clocks, resets, power states, and > + performance features. This binding describes the device power > + state registers, which control power states and resets. > + > + Each instance of a power controller within the PMGR syscon node > + represents a generic power domain provider, as documented in > + Documentation/devicetree/bindings/power/power-domain.yaml. > + The provider controls a single SoC block. The power hierarchy is > + represented via power-domains relationships between these nodes. > + > + See Documentation/devicetree/bindings/arm/apple/apple,pmgr.yaml > + for the top-level PMGR node documentation. > + > + IP cores belonging to a power domain should contain a > + "power-domains" property that is a phandle for the > + power domain node representing the domain. > + > +properties: > + $nodename: > + pattern: "^power-controller@[0-9a-f]+$" Drop this and define this node in the syscon schema with a $ref to this schema. > + > + compatible: > + items: > + - enum: > + - apple,t8103-pmgr-pwrstate > + - const: apple,pmgr-pwrstate > + > + reg: > + maxItems: 1 > + > + "#power-domain-cells": > + const: 0 > + > + "#reset-cells": > + const: 0 > + > + power-domains: > + description: > + Reference to parent power domains. A domain may have multiple parents, > + and all will be powered up when it is powered. > + > + apple,domain-name: > + description: | > + Specifies the name of the SoC device being controlled. This is used to > + name the power/reset domains. > + $ref: /schemas/types.yaml#/definitions/string No other power domain binding needs this, why do you? > + > + apple,always-on: > + description: | > + Forces this power domain to always be powered up. > + type: boolean > + > +required: > + - compatible > + - reg > + - "#power-domain-cells" > + - "#reset-cells" > + - "apple,domain-name" > + > +additionalProperties: false > + > +examples: I prefer 1 complete example in the MFD schema rather than piecemeal examples. > + - | > + soc { > + #address-cells = <2>; > + #size-cells = <2>; > + > + power-management@23b700000 { > + compatible = "apple,t8103-pmgr", "apple,pmgr", "syscon", "simple-mfd"; > + #address-cells = <1>; > + #size-cells = <0>; As the child nodes are memory mapped devices, size should be 1. Then address translation works (though Linux doesn't care (currently)). > + reg = <0x2 0x3b700000 0x0 0x14000>; > + > + ps_sio: power-controller@1c0 { > + compatible = "apple,t8103-pmgr-pwrstate", "apple,pmgr-pwrstate"; > + reg = <0x1c0>; > + #power-domain-cells = <0>; > + #reset-cells = <0>; > + apple,domain-name = "sio"; > + apple,always-on; > + }; > + > + ps_uart_p: power-controller@220 { > + compatible = "apple,t8103-pmgr-pwrstate", "apple,pmgr-pwrstate"; > + reg = <0x220>; > + #power-domain-cells = <0>; > + #reset-cells = <0>; > + apple,domain-name = "uart_p"; > + power-domains = <&ps_sio>; > + }; > + > + ps_uart0: power-controller@270 { > + compatible = "apple,t8103-pmgr-pwrstate", "apple,pmgr-pwrstate"; > + reg = <0x270>; > + #power-domain-cells = <0>; > + #reset-cells = <0>; > + apple,domain-name = "uart0"; > + power-domains = <&ps_uart_p>; > + }; > + }; > + }; > diff --git a/MAINTAINERS b/MAINTAINERS > index d25598842d15..5fe53d9a2956 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -1722,6 +1722,7 @@ F: Documentation/devicetree/bindings/arm/apple.yaml > F: Documentation/devicetree/bindings/arm/apple/* > F: Documentation/devicetree/bindings/interrupt-controller/apple,aic.yaml > F: Documentation/devicetree/bindings/pinctrl/apple,pinctrl.yaml > +F: Documentation/devicetree/bindings/power/apple* > F: arch/arm64/boot/dts/apple/ > F: drivers/irqchip/irq-apple-aic.c > F: include/dt-bindings/interrupt-controller/apple-aic.h > -- > 2.33.0 > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2021-10-06 0:59 UTC|newest] Thread overview: 90+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-10-05 15:59 [PATCH 0/7] Apple SoC PMGR device power states driver Hector Martin 2021-10-05 15:59 ` Hector Martin 2021-10-05 15:59 ` [PATCH 1/7] dt-bindings: arm: apple: Add apple,pmgr binding Hector Martin 2021-10-05 15:59 ` Hector Martin 2021-10-05 20:09 ` Mark Kettenis 2021-10-05 20:09 ` Mark Kettenis 2021-10-05 22:45 ` Rob Herring 2021-10-05 22:45 ` Rob Herring 2021-10-06 15:17 ` Hector Martin 2021-10-06 15:17 ` Hector Martin 2021-10-06 6:56 ` Krzysztof Kozlowski 2021-10-06 6:56 ` Krzysztof Kozlowski 2021-10-06 7:30 ` Krzysztof Kozlowski 2021-10-06 7:30 ` Krzysztof Kozlowski 2021-10-06 15:21 ` Hector Martin 2021-10-06 15:21 ` Hector Martin 2021-10-06 15:26 ` Hector Martin 2021-10-06 15:26 ` Hector Martin 2021-10-07 13:10 ` Krzysztof Kozlowski 2021-10-07 13:10 ` Krzysztof Kozlowski 2021-10-05 15:59 ` [PATCH 2/7] dt-bindings: power: Add apple,pmgr-pwrstate binding Hector Martin 2021-10-05 15:59 ` Hector Martin 2021-10-05 20:16 ` Mark Kettenis 2021-10-05 20:16 ` Mark Kettenis 2021-10-06 15:27 ` Hector Martin 2021-10-06 15:27 ` Hector Martin 2021-10-06 0:58 ` Rob Herring [this message] 2021-10-06 0:58 ` Rob Herring 2021-10-06 15:52 ` Hector Martin 2021-10-06 15:52 ` Hector Martin 2021-10-06 15:55 ` Hector Martin 2021-10-06 15:55 ` Hector Martin 2021-10-08 7:50 ` Krzysztof Kozlowski 2021-10-08 7:50 ` Krzysztof Kozlowski 2021-10-11 5:17 ` Hector Martin 2021-10-11 5:17 ` Hector Martin 2021-10-06 7:05 ` Krzysztof Kozlowski 2021-10-06 7:05 ` Krzysztof Kozlowski 2021-10-06 15:59 ` Hector Martin 2021-10-06 15:59 ` Hector Martin 2021-10-07 13:12 ` Krzysztof Kozlowski 2021-10-07 13:12 ` Krzysztof Kozlowski 2021-10-11 4:42 ` Hector Martin 2021-10-11 4:42 ` Hector Martin 2021-10-05 15:59 ` [PATCH 3/7] soc: apple: Add driver for Apple PMGR power state controls Hector Martin 2021-10-05 15:59 ` Hector Martin 2021-10-05 16:08 ` Linus Walleij 2021-10-05 16:08 ` Linus Walleij 2021-10-05 16:15 ` Hector Martin 2021-10-05 16:15 ` Hector Martin 2021-10-05 19:49 ` Linus Walleij 2021-10-05 19:49 ` Linus Walleij 2021-10-05 20:21 ` Mark Kettenis 2021-10-05 20:21 ` Mark Kettenis 2021-10-06 16:00 ` Hector Martin 2021-10-06 16:00 ` Hector Martin 2021-10-06 7:28 ` Krzysztof Kozlowski 2021-10-06 7:28 ` Krzysztof Kozlowski 2021-10-06 16:08 ` Hector Martin 2021-10-06 16:08 ` Hector Martin 2021-10-06 9:24 ` Philipp Zabel 2021-10-06 9:24 ` Philipp Zabel 2021-10-06 16:11 ` Hector Martin 2021-10-06 16:11 ` Hector Martin 2021-10-05 15:59 ` [PATCH 4/7] arm64: dts: apple: t8103: Rename clk24 to clkref Hector Martin 2021-10-05 15:59 ` Hector Martin 2021-10-05 20:22 ` Mark Kettenis 2021-10-05 20:22 ` Mark Kettenis 2021-10-05 15:59 ` [PATCH 5/7] arm64: dts: apple: t8103: Add the UART PMGR tree Hector Martin 2021-10-05 15:59 ` Hector Martin 2021-10-05 20:25 ` Mark Kettenis 2021-10-05 20:25 ` Mark Kettenis 2021-10-05 15:59 ` [PATCH 6/7] tty: serial: samsung_tty: Support runtime PM Hector Martin 2021-10-05 15:59 ` Hector Martin 2021-10-06 7:43 ` Krzysztof Kozlowski 2021-10-06 7:43 ` Krzysztof Kozlowski 2021-10-06 13:25 ` Rafael J. Wysocki 2021-10-06 13:25 ` Rafael J. Wysocki 2021-10-06 13:29 ` Krzysztof Kozlowski 2021-10-06 13:29 ` Krzysztof Kozlowski 2021-10-11 5:32 ` Hector Martin 2021-10-11 5:32 ` Hector Martin 2021-10-11 6:48 ` Krzysztof Kozlowski 2021-10-11 6:48 ` Krzysztof Kozlowski 2021-10-11 8:27 ` Johan Hovold 2021-10-11 8:27 ` Johan Hovold 2021-10-05 15:59 ` [PATCH 7/7] arm64: dts: apple: t8103: Add UART2 Hector Martin 2021-10-05 15:59 ` Hector Martin 2021-10-05 20:26 ` Mark Kettenis 2021-10-05 20:26 ` Mark Kettenis
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=CAL_JsqJenHAOw4gApzGpuj-8nZjkYhmBg0qBj-DV+CEJ7zXuVw@mail.gmail.com \ --to=robh+dt@kernel.org \ --cc=alyssa@rosenzweig.io \ --cc=arnd@kernel.org \ --cc=devicetree@vger.kernel.org \ --cc=gregkh@linuxfoundation.org \ --cc=krzk@kernel.org \ --cc=linus.walleij@linaro.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-pm@vger.kernel.org \ --cc=linux-samsung-soc@vger.kernel.org \ --cc=linux-serial@vger.kernel.org \ --cc=marcan@marcan.st \ --cc=mark.kettenis@xs4all.nl \ --cc=maz@kernel.org \ --cc=p.zabel@pengutronix.de \ --cc=rafael@kernel.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.