public inbox for linux-arm-kernel@lists.infradead.org 
 help / color / mirror / Atom feed
From: jonathanh@nvidia•com (Jon Hunter)
To: linux-arm-kernel@lists•infradead.org
Subject: [PATCH V5 10/14] Documentation: DT: bindings: Add power domain info for NVIDIA PMC
Date: Wed, 10 Feb 2016 10:57:11 +0000	[thread overview]
Message-ID: <56BB1787.4050801@nvidia.com> (raw)
In-Reply-To: <CAL_JsqLcoKW2znNNvM=sYLmZ6O6ZWqn7+aXspkXoONw6-O1ygg@mail.gmail.com>


On 03/02/16 15:48, Rob Herring wrote:
> On Wed, Feb 3, 2016 at 5:02 AM, Jon Hunter <jonathanh@nvidia•com> wrote:
>>
>> On 29/01/16 16:06, Rob Herring wrote:
>>> On Thu, Jan 28, 2016 at 04:33:48PM +0000, Jon Hunter wrote:
>>>> Add power-domain binding documentation for the NVIDIA PMC driver in
>>>> order to support generic power-domains.
>>>>
>>>> Signed-off-by: Jon Hunter <jonathanh@nvidia•com>
>>>> ---
>>>>  .../bindings/arm/tegra/nvidia,tegra20-pmc.txt      | 55 ++++++++++++++++++++++
>>>>  1 file changed, 55 insertions(+)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-pmc.txt b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-pmc.txt
>>>> index 53aa5496c5cf..3c77373aa826 100644
>>>> --- a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-pmc.txt
>>>> +++ b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-pmc.txt
>>>> @@ -1,5 +1,7 @@
>>>>  NVIDIA Tegra Power Management Controller (PMC)
>>>>
>>>> +== Power Management Controller Node ==
>>>> +
>>>>  The PMC block interacts with an external Power Management Unit. The PMC
>>>>  mostly controls the entry and exit of the system from different sleep
>>>>  modes. It provides power-gating controllers for SoC and CPU power-islands.
>>>> @@ -70,6 +72,10 @@ Optional properties for hardware-triggered thermal reset (inside 'i2c-thermtrip'
>>>>                       Defaults to 0. Valid values are described in section 12.5.2
>>>>                       "Pinmux Support" of the Tegra4 Technical Reference Manual.
>>>>
>>>> +Optional nodes:
>>>> +- powergates : This node contains a hierarchy of power domain nodes, which
>>>> +           should match the powergates on the Tegra SoC.
>>>> +
>>>>  Example:
>>>>
>>>>  / SoC dts including file
>>>> @@ -115,3 +121,52 @@ pmc at 7000f400 {
>>>>      };
>>>>      ...
>>>>  };
>>>> +
>>>> +
>>>> +== PM Domain Nodes ==
>>>> +
>>>> +Each of the PM domain nodes represents a power-domain on the Tegra SoC
>>>> +that can be power-gated by the PMC and should be named appropriately.
>>>> +
>>>> +Required properties:
>>>> +  - clocks: Must contain an entry for each clock required by the PMC for
>>>> +    controlling a power-gate. See ../clocks/clock-bindings.txt for details.
>>>> +  - resets: Must contain an entry for each reset required by the PMC for
>>>> +    controlling a power-gate. See ../reset/reset.txt for details.
>>>> +  - nvidia,powergate: Integer cell that contains an identifier for the PMC
>>>> +    power-gate that is associated with the power-domain. Please refer to
>>>> +    the Tegra TRM for more details.
>>>
>>> Why not make this value be the power-domain cell for consumers and the
>>> pmc be the phandle.
>>
>> Is there anything wrong with using a label for the consumers? Seems
>> simpler, if you can just say ...
>>
>>         adma: adma at 702e2000 {
>>                 ...
>>                 power-domains = <&pd_audio>;
>>                 ...
>>         };
> 
> Only that is a bit unusual. It would only really matter if we had some
> common parsing that we wanted to share. I'd look at other examples and
> try to align. If there's no clear pattern, then it is fine.

So I have been having a look at this and it appears to be mixed across
the various SoCs. It seems that those SoCs that define the generic PM
domains statically in the machine/soc code use a phandle plus a argument
to identify the power domain. However, for those that describe the
power-domain in the DT (listing clocks, resets, etc), they just use a
phandle to the power-domain itself (like I have above). It looks like if
you are describing the power domain in DT, then it is much simplier to
do this.

Given that I wish to keep the description of the power-domain in DT, it
is much easier to stick with the same conventions that the other SoCs
are using.

Cheers
Jon

  reply	other threads:[~2016-02-10 10:57 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-28 16:33 [PATCH V5 00/14] Add generic PM domain support for Tegra Jon Hunter
2016-01-28 16:33 ` [PATCH V5 01/14] soc: tegra: pmc: Restore base address on probe failure Jon Hunter
2016-01-28 16:33 ` [PATCH V5 02/14] soc: tegra: pmc: Protect public functions from potential race conditions Jon Hunter
2016-01-29 16:20   ` Mathieu Poirier
2016-02-01 13:42     ` Jon Hunter
2016-01-28 16:33 ` [PATCH V5 03/14] soc: tegra: pmc: Change powergate and rail IDs to be an unsigned type Jon Hunter
2016-01-28 16:33 ` [PATCH V5 04/14] soc: tegra: pmc: Fix testing of powergate state Jon Hunter
2016-01-28 16:33 ` [PATCH V5 05/14] soc: tegra: pmc: Wait for powergate state to change Jon Hunter
2016-01-29 16:58   ` Mathieu Poirier
2016-02-01 13:44     ` Jon Hunter
2016-02-03  9:20       ` Jon Hunter
2016-02-03 15:58         ` Mathieu Poirier
2016-01-28 16:33 ` [PATCH V5 06/14] soc: tegra: pmc: Fix checking of valid partitions Jon Hunter
2016-01-29 17:08   ` Mathieu Poirier
2016-02-01 13:45     ` Jon Hunter
2016-01-28 16:33 ` [PATCH V5 07/14] soc: tegra: pmc: Ensure partitions can be toggled on/off by PMC Jon Hunter
2016-01-28 16:33 ` [PATCH V5 08/14] PM / Domains: Add function to remove a pm-domain Jon Hunter
2016-02-02 15:35   ` Ulf Hansson
2016-02-03 10:51     ` Jon Hunter
2016-01-28 16:33 ` [PATCH V5 09/14] Documentation: DT: bindings: Update NVIDIA PMC for Tegra Jon Hunter
2016-01-29 16:08   ` Rob Herring
2016-01-28 16:33 ` [PATCH V5 10/14] Documentation: DT: bindings: Add power domain info for NVIDIA PMC Jon Hunter
2016-01-29 16:06   ` Rob Herring
2016-02-03 11:02     ` Jon Hunter
2016-02-03 15:48       ` Rob Herring
2016-02-10 10:57         ` Jon Hunter [this message]
2016-02-10 14:06           ` Rob Herring
2016-01-28 16:33 ` [PATCH V5 11/14] soc: tegra: pmc: Add generic PM domain support Jon Hunter
2016-02-04 15:44   ` Ulf Hansson
2016-02-10 18:01     ` Jon Hunter
2016-02-10 18:25       ` Ulf Hansson
2016-02-11  9:13         ` Jon Hunter
2016-02-11  9:57           ` Ulf Hansson
2016-02-11 10:13             ` Jon Hunter
2016-02-11 10:26               ` Jon Hunter
2016-02-11 10:37                 ` Ulf Hansson
2016-02-11 10:52                   ` Jon Hunter
2016-02-11 10:28               ` Ulf Hansson
2016-02-11 16:38                 ` Jon Hunter
2016-02-18 15:06                   ` Ulf Hansson
2016-02-12 23:14     ` Kevin Hilman
2016-02-15 11:27       ` Jon Hunter
2016-02-18 16:00         ` Ulf Hansson
2016-02-18 16:31           ` Jon Hunter
2016-02-24  0:03             ` Kevin Hilman
2016-01-28 16:33 ` [PATCH V5 12/14] clk: tegra210: Add the APB2APE audio clock Jon Hunter
2016-02-02 14:37   ` Thierry Reding
2016-01-28 16:33 ` [PATCH V5 13/14] ARM64: tegra: Add audio PM domain device node for Tegra210 Jon Hunter
2016-01-28 16:33 ` [PATCH V5 14/14] ARM64: tegra: select PM_GENERIC_DOMAINS Jon Hunter

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=56BB1787.4050801@nvidia.com \
    --to=jonathanh@nvidia$(echo .)com \
    --cc=linux-arm-kernel@lists$(echo .)infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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