From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jon Hunter Subject: Re: [PATCH V4 12/16] Documentation: DT: bindings: Add power domain info for NVIDIA PMC Date: Wed, 9 Dec 2015 12:23:47 +0000 Message-ID: <56681D53.9090600@nvidia.com> References: <1449241037-22193-1-git-send-email-jonathanh@nvidia.com> <1449241037-22193-13-git-send-email-jonathanh@nvidia.com> <7h4mfslpyd.fsf@deeprootsystems.com> Mime-Version: 1.0 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <7h4mfslpyd.fsf-1D3HCaltpLuhEniVeURVKkEOCMrvLtNR@public.gmane.org> Sender: linux-tegra-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Kevin Hilman Cc: Philipp Zabel , Stephen Warren , Thierry Reding , Alexandre Courbot , Rafael Wysocki , Ulf Hansson , Rob Herring , Pawel Moll , Mark Rutland , Ian Campbell , Kumar Gala , Vince Hsu , devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-pm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-Id: linux-tegra@vger.kernel.org On 08/12/15 19:07, Kevin Hilman wrote: > Jon Hunter writes: > >> Add power-domain binding documentation for the NVIDIA PMC driver in >> order to support generic power-domains. >> >> Signed-off-by: Jon Hunter >> >> --- >> >> Please note that I have been debating whether I add this >> "nvidia,powergate-clock-disable" property or just leave the clocks >> disabled by default. Some downstream kernels leave the clocks enabled >> for the audio power-domain because the clocks required for powering up >> the power-domain are needed by all modules within the power-domain. >> However are the same time there are other power-domains that may need >> to be on, but not always clocked and so having the ability to specify if >> the clocks should be disabled seems useful. However, I can also remove >> this and just have the appropriate devices turn on the clocks as well. >> --- >> .../bindings/arm/tegra/nvidia,tegra20-pmc.txt | 61 ++++++++++++++++++++++ >> 1 file changed, 61 insertions(+) >> >> diff --git a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-pmc.txt b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-pmc.txt >> index 838e1a69ec0a..8e4641db51a9 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. >> @@ -69,6 +71,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: >> +- pm-domains : This node contains a hierarchy of PM domain nodes, which should >> + match the power-domains on the Tegra SoC. >> + >> Example: >> >> / SoC dts including file >> @@ -114,3 +120,58 @@ pmc@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. > > We've had this discussiona for a couple of other SoCs, so I need to > ask... > > Presumably these are not device clocks that a runtime PM enabled driver > should be managing for a device, right? IOW, We want to make sure that the > PM domain isn't managing clocks for drivers that should be doing it. > > I understand there are legitimate reasons for the PM domain to manage > clocks in addition to device drivers (e.g. for synchronous reset), but > just want to be sure it's not a shortcut for having a proper driver. So some clocks may also be used by devices, but they are needed as part of the power ungating/gating sequence. The general power-up sequence for tegra is ... 1. Enable the power-domain 2. Enable the clock(s) 3. Remove signal clamps 4. De-assert reset(s) 5. Disable clocks (optional) You may say we should only handle #1 above for the powering up sequence, but we can't do this. The reason is that there is one bit for each power-domain that controls the signaling clamps and so we need to turn on all the clocks specified in the TRM before we do this. Once we have done this and released the reset(s), we can then disable the clocks again (shown above an optional as it is not mandatory from a design perspective) and then the devices in the power-domain should enable the clocks they need as and when they want them. Please note that I 100% agree that all clocks required by a device are handled by the device and we do not implement any short-cuts here. The only question I had was if there are clocks that may be bus clocks in the power-domain that are required by all device in the power-domain. However, may be this should be represented as a bus driver and all the devices are children of it? Hope that helps. Cheers Jon From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754033AbbLIMX4 (ORCPT ); Wed, 9 Dec 2015 07:23:56 -0500 Received: from hqemgate16.nvidia.com ([216.228.121.65]:9293 "EHLO hqemgate16.nvidia.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751521AbbLIMXy (ORCPT ); Wed, 9 Dec 2015 07:23:54 -0500 X-PGP-Universal: processed; by hqnvupgp07.nvidia.com on Wed, 09 Dec 2015 04:10:03 -0800 Subject: Re: [PATCH V4 12/16] Documentation: DT: bindings: Add power domain info for NVIDIA PMC To: Kevin Hilman References: <1449241037-22193-1-git-send-email-jonathanh@nvidia.com> <1449241037-22193-13-git-send-email-jonathanh@nvidia.com> <7h4mfslpyd.fsf@deeprootsystems.com> CC: Philipp Zabel , Stephen Warren , Thierry Reding , "Alexandre Courbot" , Rafael Wysocki , Ulf Hansson , Rob Herring , Pawel Moll , Mark Rutland , Ian Campbell , Kumar Gala , Vince Hsu , , , , From: Jon Hunter Message-ID: <56681D53.9090600@nvidia.com> Date: Wed, 9 Dec 2015 12:23:47 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <7h4mfslpyd.fsf@deeprootsystems.com> X-Originating-IP: [10.21.132.159] X-ClientProxiedBy: UKMAIL101.nvidia.com (10.26.138.13) To UKMAIL101.nvidia.com (10.26.138.13) Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 08/12/15 19:07, Kevin Hilman wrote: > Jon Hunter writes: > >> Add power-domain binding documentation for the NVIDIA PMC driver in >> order to support generic power-domains. >> >> Signed-off-by: Jon Hunter >> >> --- >> >> Please note that I have been debating whether I add this >> "nvidia,powergate-clock-disable" property or just leave the clocks >> disabled by default. Some downstream kernels leave the clocks enabled >> for the audio power-domain because the clocks required for powering up >> the power-domain are needed by all modules within the power-domain. >> However are the same time there are other power-domains that may need >> to be on, but not always clocked and so having the ability to specify if >> the clocks should be disabled seems useful. However, I can also remove >> this and just have the appropriate devices turn on the clocks as well. >> --- >> .../bindings/arm/tegra/nvidia,tegra20-pmc.txt | 61 ++++++++++++++++++++++ >> 1 file changed, 61 insertions(+) >> >> diff --git a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-pmc.txt b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-pmc.txt >> index 838e1a69ec0a..8e4641db51a9 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. >> @@ -69,6 +71,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: >> +- pm-domains : This node contains a hierarchy of PM domain nodes, which should >> + match the power-domains on the Tegra SoC. >> + >> Example: >> >> / SoC dts including file >> @@ -114,3 +120,58 @@ pmc@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. > > We've had this discussiona for a couple of other SoCs, so I need to > ask... > > Presumably these are not device clocks that a runtime PM enabled driver > should be managing for a device, right? IOW, We want to make sure that the > PM domain isn't managing clocks for drivers that should be doing it. > > I understand there are legitimate reasons for the PM domain to manage > clocks in addition to device drivers (e.g. for synchronous reset), but > just want to be sure it's not a shortcut for having a proper driver. So some clocks may also be used by devices, but they are needed as part of the power ungating/gating sequence. The general power-up sequence for tegra is ... 1. Enable the power-domain 2. Enable the clock(s) 3. Remove signal clamps 4. De-assert reset(s) 5. Disable clocks (optional) You may say we should only handle #1 above for the powering up sequence, but we can't do this. The reason is that there is one bit for each power-domain that controls the signaling clamps and so we need to turn on all the clocks specified in the TRM before we do this. Once we have done this and released the reset(s), we can then disable the clocks again (shown above an optional as it is not mandatory from a design perspective) and then the devices in the power-domain should enable the clocks they need as and when they want them. Please note that I 100% agree that all clocks required by a device are handled by the device and we do not implement any short-cuts here. The only question I had was if there are clocks that may be bus clocks in the power-domain that are required by all device in the power-domain. However, may be this should be represented as a bus driver and all the devices are children of it? Hope that helps. Cheers Jon