All of lore.kernel.org
 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 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.