linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dmitry Osipenko <digetx@gmail.com>
To: Thierry Reding <thierry.reding@gmail.com>
Cc: "Rob Herring" <robh@kernel.org>,
	"Jonathan Hunter" <jonathanh@nvidia.com>,
	"Mark Brown" <broonie@kernel.org>,
	"Paul Fertser" <fercerpav@gmail.com>,
	"Matt Merhar" <mattmerhar@protonmail.com>,
	"Peter Geis" <pgwipeout@gmail.com>,
	"Nicolas Chauvet" <kwizart@gmail.com>,
	"Viresh Kumar" <vireshk@kernel.org>,
	"Stephen Boyd" <sboyd@kernel.org>,
	"Michał Mirosław" <mirq-linux@rere.qmqm.pl>,
	"Krzysztof Kozlowski" <krzk@kernel.org>,
	devicetree@vger.kernel.org, linux-tegra@vger.kernel.org,
	linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4 3/6] dt-bindings: power: tegra: Add binding for core power domain
Date: Thu, 25 Mar 2021 20:38:16 +0300	[thread overview]
Message-ID: <80410199-3b5f-13b7-25b7-3fbd009c31e7@gmail.com> (raw)
In-Reply-To: <YFyjDNYAkbTQU5G0@orome.fritz.box>

25.03.2021 17:49, Thierry Reding пишет:
> On Wed, Mar 24, 2021 at 02:01:29AM +0300, Dmitry Osipenko wrote:
>> 24.03.2021 01:48, Rob Herring пишет:
>>> On Sun, Mar 14, 2021 at 07:48:07PM +0300, Dmitry Osipenko wrote:
>>>> All NVIDIA Tegra SoCs have a core power domain where majority of hardware
>>>> blocks reside. Add binding for the core power domain.
>>>>
>>>> Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
>>>> ---
>>>>  .../power/nvidia,tegra20-core-domain.yaml     | 51 +++++++++++++++++++
>>>>  1 file changed, 51 insertions(+)
>>>>  create mode 100644 Documentation/devicetree/bindings/power/nvidia,tegra20-core-domain.yaml
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/power/nvidia,tegra20-core-domain.yaml b/Documentation/devicetree/bindings/power/nvidia,tegra20-core-domain.yaml
>>>> new file mode 100644
>>>> index 000000000000..4692489d780a
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/power/nvidia,tegra20-core-domain.yaml
>>>> @@ -0,0 +1,51 @@
>>>> +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
>>>> +%YAML 1.2
>>>> +---
>>>> +$id: http://devicetree.org/schemas/power/nvidia,tegra20-core-domain.yaml#
>>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>>>> +
>>>> +title: NVIDIA Tegra Core Power Domain
>>>> +
>>>> +maintainers:
>>>> +  - Dmitry Osipenko <digetx@gmail.com>
>>>> +  - Jon Hunter <jonathanh@nvidia.com>
>>>> +  - Thierry Reding <thierry.reding@gmail.com>
>>>> +
>>>> +allOf:
>>>> +  - $ref: power-domain.yaml#
>>>> +
>>>> +properties:
>>>> +  compatible:
>>>> +    enum:
>>>> +      - nvidia,tegra20-core-domain
>>>> +      - nvidia,tegra30-core-domain
>>>> +
>>>> +  operating-points-v2:
>>>> +    description:
>>>> +      Should contain level, voltages and opp-supported-hw property.
>>>> +      The supported-hw is a bitfield indicating SoC speedo or process
>>>> +      ID mask.
>>>> +
>>>> +  "#power-domain-cells":
>>>> +    const: 0
>>>> +
>>>> +  power-supply:
>>>> +    description:
>>>> +      Phandle to voltage regulator connected to the SoC Core power rail.
>>>> +
>>>> +required:
>>>> +  - compatible
>>>> +  - operating-points-v2
>>>> +  - "#power-domain-cells"
>>>> +  - power-supply
>>>> +
>>>> +additionalProperties: false
>>>> +
>>>> +examples:
>>>> +  - |
>>>> +    power-domain {
>>>> +        compatible = "nvidia,tegra20-core-domain";
>>>> +        operating-points-v2 = <&opp_table>;
>>>> +        power-supply = <&regulator>;
>>>> +        #power-domain-cells = <0>;
>>>
>>> AFAICT, there's no way to access this 'hardware'?
>> correct
> 
> To avoid exposing this "virtual" device in device tree, could this
> instead be modelled as a child node of the PMC node? We already expose a
> couple of generic power domains that way on Tegra210 and later, so
> perhaps some of that infrastructure can be reused? I suppose given that
> this is different from the standard powergate domains that we expose so
> far, this may need a different implementation, but from a device tree
> bindings point of view it could fit in with that.

At a quick glance this should be too troublesome because OPP and regulator frameworks require a proper/real backing device.

Perhaps we could either turn the whole PMC into a core-domain or add a virtual device as a child of PMC, like this:

diff --git a/arch/arm/boot/dts/tegra20.dtsi b/arch/arm/boot/dts/tegra20.dtsi
index 79364cdafeab..717273048caf 100644
--- a/arch/arm/boot/dts/tegra20.dtsi
+++ b/arch/arm/boot/dts/tegra20.dtsi
@@ -850,6 +850,12 @@ pd_mpe: mpe {
 				#power-domain-cells = <0>;
 			};
 		};
+
+		pd_core: core-domain {
+			compatible = "nvidia,tegra20-core-domain";
+			operating-points-v2 = <&core_opp_table>;
+			#power-domain-cells = <0>;
+		};
 	};
 
 	mc: memory-controller@7000f000 {

but then this is still a virtual device, although in a bit nicer way.

It feels like yours suggestion might result in a hardware description that is closer to reality since PMC controls fan out of all power rails within SoC.

  reply	other threads:[~2021-03-25 17:39 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-14 16:48 [PATCH v4 0/6] NVIDIA Tegra core power domain driver and OPP helper Dmitry Osipenko
2021-03-14 16:48 ` [PATCH v4 1/6] soc/tegra: Add devm_tegra_core_dev_init_opp_table() Dmitry Osipenko
2021-03-18 10:27   ` Dmitry Osipenko
2021-03-18 10:32     ` Viresh Kumar
2021-03-18 10:37       ` Dmitry Osipenko
2021-03-31 15:45         ` Dmitry Osipenko
2021-03-14 16:48 ` [PATCH v4 2/6] soc/tegra: Add CONFIG_SOC_TEGRA_COMMON and select PM_OPP by default Dmitry Osipenko
2021-03-14 16:48 ` [PATCH v4 3/6] dt-bindings: power: tegra: Add binding for core power domain Dmitry Osipenko
2021-03-23 22:48   ` Rob Herring
2021-03-23 23:01     ` Dmitry Osipenko
2021-03-25 14:49       ` Thierry Reding
2021-03-25 17:38         ` Dmitry Osipenko [this message]
2021-03-14 16:48 ` [PATCH v4 4/6] soc/tegra: Introduce core power domain driver Dmitry Osipenko
2021-03-14 16:48 ` [PATCH v4 5/6] soc/tegra: regulators: Support Core domain state syncing Dmitry Osipenko
2021-03-14 16:48 ` [PATCH v4 6/6] soc/tegra: pmc: Link children power domains to the parent domain Dmitry Osipenko

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=80410199-3b5f-13b7-25b7-3fbd009c31e7@gmail.com \
    --to=digetx@gmail.com \
    --cc=broonie@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=fercerpav@gmail.com \
    --cc=jonathanh@nvidia.com \
    --cc=krzk@kernel.org \
    --cc=kwizart@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=linux-tegra@vger.kernel.org \
    --cc=mattmerhar@protonmail.com \
    --cc=mirq-linux@rere.qmqm.pl \
    --cc=pgwipeout@gmail.com \
    --cc=robh@kernel.org \
    --cc=sboyd@kernel.org \
    --cc=thierry.reding@gmail.com \
    --cc=vireshk@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).