All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stephen Warren <swarren@wwwdotorg.org>
To: Jon Hunter <jonathanh@nvidia.com>, Rob Herring <robh@kernel.org>
Cc: Thierry Reding <thierry.reding@gmail.com>,
	Alexandre Courbot <gnurou@gmail.com>,
	Pawel Moll <pawel.moll@arm.com>,
	Mark Rutland <mark.rutland@arm.com>,
	Ian Campbell <ijc+devicetree@hellion.org.uk>,
	Kumar Gala <galak@codeaurora.org>,
	"Rafael J. Wysocki" <rjw@rjwysocki.net>,
	Kevin Hilman <khilman@kernel.org>,
	Ulf Hansson <ulf.hansson@linaro.org>,
	linux-tegra@vger.kernel.org, devicetree@vger.kernel.org,
	linux-pm@vger.kernel.org
Subject: Re: [PATCH V7 2/4] Documentation: DT: bindings: Add power domain info for NVIDIA PMC
Date: Mon, 7 Mar 2016 13:29:44 -0700	[thread overview]
Message-ID: <56DDE4B8.6000408@wwwdotorg.org> (raw)
In-Reply-To: <56DDD794.8090207@nvidia.com>

On 03/07/2016 12:33 PM, Jon Hunter wrote:
>
> On 07/03/16 17:47, Stephen Warren wrote:
>> On 03/07/2016 03:00 AM, Jon Hunter wrote:
>>>
>>> On 05/03/16 04:31, Rob Herring wrote:
>>>> On Fri, Mar 04, 2016 at 12:23:04PM +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      | 80
>>>>> ++++++++++++++++++++++
>>>>>    1 file changed, 80 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..7d52bbe99709 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,11 @@ 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. See
>>>>> "Powergate
>>>>> +           Nodes" below.
>>>>> +
>>>>>    Example:
>>>>>
>>>>>    / SoC dts including file
>>>>> @@ -115,3 +122,76 @@ pmc@7000f400 {
>>>>>        };
>>>>>        ...
>>>>>    };
>>>>> +
>>>>> +
>>>>> +== Powergate Nodes ==
>>>>> +
>>>>> +Each of the powergate nodes represent a power-domain on the Tegra SoC
>>>>> +that can be power-gated by the Tegra PMC. The name of the powergate
>>>>> node
>>>>> +should be one of the below. Note that not every powergate is
>>>>> applicable
>>>>> +to all Tegra devices and the following list shows which powergates are
>>>>> +applicable to which devices. Please refer to the Tegra TRM for more
>>>>> +details on the various powergates.
>>>>> +
>>>>> + Name        Description            Devices Applicable
>>>>> + 3d        3D Graphics            Tegra20/114/124/210
>>>>> + 3d0        3D Graphics 0            Tegra30
>>>>> + 3d1        3D Graphics 1            Tegra30
>>>>> + aud        Audio                Tegra210
>>>>> + dfd        Debug                Tegra210
>>>>> + dis        Display A            Tegra114/124/210
>>>>> + disb        Display B            Tegra114/124/210
>>>>> + heg        2D Graphics            Tegra30/114/124/210
>>>>> + iram        Internal RAM            Tegra124/210
>>>>> + mpe        MPEG Encode            All
>>>>> + nvdec        NVIDIA Video Decode Engine    Tegra210
>>>>> + nvjpg        NVIDIA JPEG Engine        Tegra210
>>>>> + pcie        PCIE                Tegra20/30/124/210
>>>>> + sata        SATA                Tegra30/124/210
>>>>> + sor        Display interfaces        Tegra124/210
>>>>> + ve2        Video Encode Engine 2        Tegra210
>>>>> + venc        Video Encode Engine        All
>>>>> + vdec        Video Decode Engine        Tegra20/30/114/124
>>>>> + vic        Video Imaging Compositor    Tegra124/210
>>>>> + xusba        USB Partition A            Tegra114/124/210
>>>>> + xusbb        USB Partition B         Tegra114/124/210
>>>>> + xusbc        USB Partition C            Tegra114/124/210
>>>>> +
>>>>> +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.
>>>>> +  - #power-domain-cells: Must be 0.
>>>>> +
>>>>> +Example:
>>>>> +
>>>>> +    pmc: pmc@0,7000e400 {
>>>>
>>>> Just pmc@7000e400. We were erronously using commas for 64-bit addresses
>>>> briefly, but the correct usage is when there are distinct fields in reg
>>>> like PCI bus,dev,func.
>>>
>>> Ok. Looks like we use this style quite widely across all Tegra 32-bit
>>> and 64-bit devices for all peripheral devices.
>>>
>>> Thierry, Stephen,
>>>
>>> Do we need to correct this for existing devices?
>>
>> I don't think so; my understanding is that where reg has multiple
>> address cells, they all get represented in the unit address. Otherwise,
>> the node names couldn't be guaranteed unique.
>
> OK, but I am a bit confused as that does not sound exactly the same as
> what Rob is saying?

Consider a SoC with two I2C ports at address 1_00000000 and 2_00000000 
physical. The top 32-bits (2nd cell) of the address must be represented 
in the unit address, or the nodes won't have a unique name.

Perhaps Rob is simply saying that multi-cell values should be treated as 
a single large integer, rather than comma-separating each cell value? I 
perhaps mistakenly took his comment to mean that only a single address 
cell should be used in the unit address.

> Also, I see that starting with tegra124 we have #address-cells = <2> and
> #size-cells = <2>, which I also don't understand either. Are the bus
> addresses really 64-bit for tegra124?

T124 has a >32-bit bus since it supports >2GB RAM (via LPAE) (although 
not a full 64-bit bus I would imagine). That alone means we need two 
cells in DT to represent large RAM layouts.

  reply	other threads:[~2016-03-07 20:29 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-04 12:23 [PATCH V7 0/4] Add generic PM domain support for Tegra Jon Hunter
2016-03-04 12:23 ` [PATCH V7 2/4] Documentation: DT: bindings: Add power domain info for NVIDIA PMC Jon Hunter
2016-03-05  4:31   ` Rob Herring
2016-03-07 10:00     ` Jon Hunter
     [not found]       ` <56DD515A.4020207-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2016-03-07 10:28         ` Thierry Reding
2016-03-07 17:47       ` Stephen Warren
     [not found]         ` <56DDBEC6.7080102-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2016-03-07 19:33           ` Jon Hunter
2016-03-07 20:29             ` Stephen Warren [this message]
     [not found] ` <1457094186-15786-1-git-send-email-jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2016-03-04 12:23   ` [PATCH V7 1/4] ARM64: tegra: Remove unused #power-domain-cells property Jon Hunter
2016-03-04 14:13     ` Thierry Reding
2016-03-04 14:19       ` Jon Hunter
2016-03-04 12:23   ` [PATCH V7 3/4] soc: tegra: pmc: Add generic PM domain support Jon Hunter
2016-03-08 21:28     ` Ulf Hansson
     [not found]       ` <CAPDyKFooBRk4Od=pgEnK8Uvq6Y+5O9uK5Ej9Z4gJn1W=imPvdw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2016-03-09 10:22         ` Jon Hunter
2016-03-04 12:23   ` [PATCH V7 4/4] 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=56DDE4B8.6000408@wwwdotorg.org \
    --to=swarren@wwwdotorg.org \
    --cc=devicetree@vger.kernel.org \
    --cc=galak@codeaurora.org \
    --cc=gnurou@gmail.com \
    --cc=ijc+devicetree@hellion.org.uk \
    --cc=jonathanh@nvidia.com \
    --cc=khilman@kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=linux-tegra@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=pawel.moll@arm.com \
    --cc=rjw@rjwysocki.net \
    --cc=robh@kernel.org \
    --cc=thierry.reding@gmail.com \
    --cc=ulf.hansson@linaro.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.