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 <dig...@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 <dig...@gmail.com>
>>>> + - Jon Hunter <jonath...@nvidia.com>
>>>> + - Thierry Reding <thierry.red...@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 = <®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.
