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@xxxxxxxxx> >>>> --- >>>> .../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@xxxxxxxxx> >>>> + - Jon Hunter <jonathanh@xxxxxxxxxx> >>>> + - Thierry Reding <thierry.reding@xxxxxxxxx> >>>> + >>>> +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 = <®ulator>; >>>> + #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.
