All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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: link
Be 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.