Re: [PATCH V7 2/4] Documentation: DT: bindings: Add power domain info for NVIDIA PMC

Stephen Warren
2016-03-07T20:29:44Z

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.