diff mbox

[V5,9/9] ARM: dts: tegra: add the PM configurations of PMC

Message ID 1364901613-25080-10-git-send-email-josephl@nvidia.com (mailing list archive)
State New, archived
Headers show

Commit Message

Joseph Lo April 2, 2013, 11:20 a.m. UTC
Adding the PM configuration of PMC when the platform support suspend
function.

Signed-off-by: Joseph Lo <josephl@nvidia.com>
---
V5:
* no change
V4:
* no change
V3:
* fix the configuration for paz00 board
V2:
* no change
---
 arch/arm/boot/dts/tegra20-harmony.dts   | 6 ++++++
 arch/arm/boot/dts/tegra20-paz00.dts     | 6 ++++++
 arch/arm/boot/dts/tegra20-seaboard.dts  | 6 ++++++
 arch/arm/boot/dts/tegra20-trimslice.dts | 9 +++++++++
 arch/arm/boot/dts/tegra20-ventana.dts   | 6 ++++++
 arch/arm/boot/dts/tegra20-whistler.dts  | 8 ++++++++
 arch/arm/boot/dts/tegra30-beaver.dts    | 7 +++++++
 arch/arm/boot/dts/tegra30-cardhu.dtsi   | 7 +++++++
 8 files changed, 55 insertions(+)

Comments

Stephen Warren April 2, 2013, 8 p.m. UTC | #1
On 04/02/2013 05:20 AM, Joseph Lo wrote:
> Adding the PM configuration of PMC when the platform support suspend
> function.

For this patch, some more boards could be supported, but I think we'll
have to rely on other people (Lucas, Thierry) to send patches for them,
since they know the details of the board. It's fine to leave suspend
disabled on those boards until later.

Aside from the 1 other comment I made on this series, I think it's good
to go once your previous 3-long series is fixed and reposted per my
comments on it.
Thierry Reding April 3, 2013, 5:59 a.m. UTC | #2
On Tue, Apr 02, 2013 at 02:00:55PM -0600, Stephen Warren wrote:
> On 04/02/2013 05:20 AM, Joseph Lo wrote:
> > Adding the PM configuration of PMC when the platform support suspend
> > function.
> 
> For this patch, some more boards could be supported, but I think we'll
> have to rely on other people (Lucas, Thierry) to send patches for them,
> since they know the details of the board. It's fine to leave suspend
> disabled on those boards until later.

I'm not sure what would be the best way to get the Tamonten devices out
of suspend again. For Plutux and TEC we have a power button that could
possibly be reused. There's a WAKEUP pin on the Tamonten connector which
goes to GPIO PV2, but the mechanism to trigger it is carrier-board
dependent.

For the Medcom-Wide we don't have a power button, but it could possibly
use the WAKEUP pin if that's connected. It seems like in all designs it
goes to the CPLD, but I need to check with engineering if there's a way
to manipulate it.

So yes, I think for now we can leave suspend disabled on Tamonten and I
can send patches to enable it once I've clarified with engineering.

Thierry
Joseph Lo April 3, 2013, 6:34 a.m. UTC | #3
On Wed, 2013-04-03 at 13:59 +0800, Thierry Reding wrote:
> * PGP Signed by an unknown key
> 
> On Tue, Apr 02, 2013 at 02:00:55PM -0600, Stephen Warren wrote:
> > On 04/02/2013 05:20 AM, Joseph Lo wrote:
> > > Adding the PM configuration of PMC when the platform support suspend
> > > function.
> > 
> > For this patch, some more boards could be supported, but I think we'll
> > have to rely on other people (Lucas, Thierry) to send patches for them,
> > since they know the details of the board. It's fine to leave suspend
> > disabled on those boards until later.
> 
> I'm not sure what would be the best way to get the Tamonten devices out
> of suspend again. For Plutux and TEC we have a power button that could
> possibly be reused. There's a WAKEUP pin on the Tamonten connector which
> goes to GPIO PV2, but the mechanism to trigger it is carrier-board
> dependent.
> 
> For the Medcom-Wide we don't have a power button, but it could possibly
> use the WAKEUP pin if that's connected. It seems like in all designs it
> goes to the CPLD, but I need to check with engineering if there's a way
> to manipulate it.
> 
> So yes, I think for now we can leave suspend disabled on Tamonten and I
> can send patches to enable it once I've clarified with engineering.
> 
Hi Thierry,

I just recall I still need at least "nvidia,cpu-pwr-good-time" and
"nvidia,cpu-pwr-off-time" two properties to make CPU idle power-down
mode (same with LP2) work normally after this series.

So can you provide me that or point me out where is your downstream
kernel source? There data would be come from DT after this series.

Thanks,
Joseph
Thierry Reding April 3, 2013, 7:04 a.m. UTC | #4
On Wed, Apr 03, 2013 at 02:34:25PM +0800, Joseph Lo wrote:
> On Wed, 2013-04-03 at 13:59 +0800, Thierry Reding wrote:
> > * PGP Signed by an unknown key
> > 
> > On Tue, Apr 02, 2013 at 02:00:55PM -0600, Stephen Warren wrote:
> > > On 04/02/2013 05:20 AM, Joseph Lo wrote:
> > > > Adding the PM configuration of PMC when the platform support suspend
> > > > function.
> > > 
> > > For this patch, some more boards could be supported, but I think we'll
> > > have to rely on other people (Lucas, Thierry) to send patches for them,
> > > since they know the details of the board. It's fine to leave suspend
> > > disabled on those boards until later.
> > 
> > I'm not sure what would be the best way to get the Tamonten devices out
> > of suspend again. For Plutux and TEC we have a power button that could
> > possibly be reused. There's a WAKEUP pin on the Tamonten connector which
> > goes to GPIO PV2, but the mechanism to trigger it is carrier-board
> > dependent.
> > 
> > For the Medcom-Wide we don't have a power button, but it could possibly
> > use the WAKEUP pin if that's connected. It seems like in all designs it
> > goes to the CPLD, but I need to check with engineering if there's a way
> > to manipulate it.
> > 
> > So yes, I think for now we can leave suspend disabled on Tamonten and I
> > can send patches to enable it once I've clarified with engineering.
> > 
> Hi Thierry,
> 
> I just recall I still need at least "nvidia,cpu-pwr-good-time" and
> "nvidia,cpu-pwr-off-time" two properties to make CPU idle power-down
> mode (same with LP2) work normally after this series.
> 
> So can you provide me that or point me out where is your downstream
> kernel source? There data would be come from DT after this series.

We don't have suspend support in downstream kernels either. However
since the Tamonten was derived from the Harmony reference design I
suppose the same values can be reused.

That said, the binding document says that those values are only required
if nvidia,suspend-mode is set. So if we don't add it for the Tamonten
boards why would you need the cpu-pwr-good-time and cpu-pwr-off-time
values. Or maybe the binding document is wrong?

Thierry
Joseph Lo April 3, 2013, 7:11 a.m. UTC | #5
On Wed, 2013-04-03 at 15:04 +0800, Thierry Reding wrote:
> * PGP Signed by an unknown key
> 
> On Wed, Apr 03, 2013 at 02:34:25PM +0800, Joseph Lo wrote:
> > On Wed, 2013-04-03 at 13:59 +0800, Thierry Reding wrote:
> > > > Old Signed by an unknown key
> > > 
> > > On Tue, Apr 02, 2013 at 02:00:55PM -0600, Stephen Warren wrote:
> > > > On 04/02/2013 05:20 AM, Joseph Lo wrote:
> > > > > Adding the PM configuration of PMC when the platform support suspend
> > > > > function.
> > > > 
> > > > For this patch, some more boards could be supported, but I think we'll
> > > > have to rely on other people (Lucas, Thierry) to send patches for them,
> > > > since they know the details of the board. It's fine to leave suspend
> > > > disabled on those boards until later.
> > > 
> > > I'm not sure what would be the best way to get the Tamonten devices out
> > > of suspend again. For Plutux and TEC we have a power button that could
> > > possibly be reused. There's a WAKEUP pin on the Tamonten connector which
> > > goes to GPIO PV2, but the mechanism to trigger it is carrier-board
> > > dependent.
> > > 
> > > For the Medcom-Wide we don't have a power button, but it could possibly
> > > use the WAKEUP pin if that's connected. It seems like in all designs it
> > > goes to the CPLD, but I need to check with engineering if there's a way
> > > to manipulate it.
> > > 
> > > So yes, I think for now we can leave suspend disabled on Tamonten and I
> > > can send patches to enable it once I've clarified with engineering.
> > > 
> > Hi Thierry,
> > 
> > I just recall I still need at least "nvidia,cpu-pwr-good-time" and
> > "nvidia,cpu-pwr-off-time" two properties to make CPU idle power-down
> > mode (same with LP2) work normally after this series.
> > 
> > So can you provide me that or point me out where is your downstream
> > kernel source? There data would be come from DT after this series.
> 
> We don't have suspend support in downstream kernels either. However
> since the Tamonten was derived from the Harmony reference design I
> suppose the same values can be reused.
> 
OK. That's enough.

> That said, the binding document says that those values are only required
> if nvidia,suspend-mode is set. So if we don't add it for the Tamonten
> boards why would you need the cpu-pwr-good-time and cpu-pwr-off-time
> values. Or maybe the binding document is wrong?

Actually, when you support CPU idle power-down mode (LP2), you already
support suspend function (at least LP2 mode). Just no wake up source
define in DT for your boards.

May I add these properties to your boards (same as Harmony)? Then you
can figure out your wake up source later, at least the RTC can wake up
your device I believe.

Thanks,
Joseph
Thierry Reding April 3, 2013, 7:19 a.m. UTC | #6
On Wed, Apr 03, 2013 at 03:11:17PM +0800, Joseph Lo wrote:
> On Wed, 2013-04-03 at 15:04 +0800, Thierry Reding wrote:
> > * PGP Signed by an unknown key
> > 
> > On Wed, Apr 03, 2013 at 02:34:25PM +0800, Joseph Lo wrote:
> > > On Wed, 2013-04-03 at 13:59 +0800, Thierry Reding wrote:
> > > > > Old Signed by an unknown key
> > > > 
> > > > On Tue, Apr 02, 2013 at 02:00:55PM -0600, Stephen Warren wrote:
> > > > > On 04/02/2013 05:20 AM, Joseph Lo wrote:
> > > > > > Adding the PM configuration of PMC when the platform support suspend
> > > > > > function.
> > > > > 
> > > > > For this patch, some more boards could be supported, but I think we'll
> > > > > have to rely on other people (Lucas, Thierry) to send patches for them,
> > > > > since they know the details of the board. It's fine to leave suspend
> > > > > disabled on those boards until later.
> > > > 
> > > > I'm not sure what would be the best way to get the Tamonten devices out
> > > > of suspend again. For Plutux and TEC we have a power button that could
> > > > possibly be reused. There's a WAKEUP pin on the Tamonten connector which
> > > > goes to GPIO PV2, but the mechanism to trigger it is carrier-board
> > > > dependent.
> > > > 
> > > > For the Medcom-Wide we don't have a power button, but it could possibly
> > > > use the WAKEUP pin if that's connected. It seems like in all designs it
> > > > goes to the CPLD, but I need to check with engineering if there's a way
> > > > to manipulate it.
> > > > 
> > > > So yes, I think for now we can leave suspend disabled on Tamonten and I
> > > > can send patches to enable it once I've clarified with engineering.
> > > > 
> > > Hi Thierry,
> > > 
> > > I just recall I still need at least "nvidia,cpu-pwr-good-time" and
> > > "nvidia,cpu-pwr-off-time" two properties to make CPU idle power-down
> > > mode (same with LP2) work normally after this series.
> > > 
> > > So can you provide me that or point me out where is your downstream
> > > kernel source? There data would be come from DT after this series.
> > 
> > We don't have suspend support in downstream kernels either. However
> > since the Tamonten was derived from the Harmony reference design I
> > suppose the same values can be reused.
> > 
> OK. That's enough.
> 
> > That said, the binding document says that those values are only required
> > if nvidia,suspend-mode is set. So if we don't add it for the Tamonten
> > boards why would you need the cpu-pwr-good-time and cpu-pwr-off-time
> > values. Or maybe the binding document is wrong?
> 
> Actually, when you support CPU idle power-down mode (LP2), you already
> support suspend function (at least LP2 mode). Just no wake up source
> define in DT for your boards.

Okay, but for CPU idle LP2 we don't need a wakeup source, right? I only
need the wakeup source if I explicitly suspend the device.

> May I add these properties to your boards (same as Harmony)? Then you
> can figure out your wake up source later, at least the RTC can wake up
> your device I believe.

From what I understand there should be no changes in behaviour after
this patch, so it should be fine.

Thierry
Joseph Lo April 3, 2013, 7:33 a.m. UTC | #7
On Wed, 2013-04-03 at 15:19 +0800, Thierry Reding wrote:
> * PGP Signed by an unknown key
> 
> On Wed, Apr 03, 2013 at 03:11:17PM +0800, Joseph Lo wrote:
> > On Wed, 2013-04-03 at 15:04 +0800, Thierry Reding wrote:
> > > > Old Signed by an unknown key
> > > 
> > > On Wed, Apr 03, 2013 at 02:34:25PM +0800, Joseph Lo wrote:
> > > > On Wed, 2013-04-03 at 13:59 +0800, Thierry Reding wrote:
> > > > > > Old Signed by an unknown key
> > > > > 
> > > > > On Tue, Apr 02, 2013 at 02:00:55PM -0600, Stephen Warren wrote:
> > > > > > On 04/02/2013 05:20 AM, Joseph Lo wrote:
> > > > > > > Adding the PM configuration of PMC when the platform support suspend
> > > > > > > function.
> > > > > > 
> > > > > > For this patch, some more boards could be supported, but I think we'll
> > > > > > have to rely on other people (Lucas, Thierry) to send patches for them,
> > > > > > since they know the details of the board. It's fine to leave suspend
> > > > > > disabled on those boards until later.
> > > > > 
> > > > > I'm not sure what would be the best way to get the Tamonten devices out
> > > > > of suspend again. For Plutux and TEC we have a power button that could
> > > > > possibly be reused. There's a WAKEUP pin on the Tamonten connector which
> > > > > goes to GPIO PV2, but the mechanism to trigger it is carrier-board
> > > > > dependent.
> > > > > 
> > > > > For the Medcom-Wide we don't have a power button, but it could possibly
> > > > > use the WAKEUP pin if that's connected. It seems like in all designs it
> > > > > goes to the CPLD, but I need to check with engineering if there's a way
> > > > > to manipulate it.
> > > > > 
> > > > > So yes, I think for now we can leave suspend disabled on Tamonten and I
> > > > > can send patches to enable it once I've clarified with engineering.
> > > > > 
> > > > Hi Thierry,
> > > > 
> > > > I just recall I still need at least "nvidia,cpu-pwr-good-time" and
> > > > "nvidia,cpu-pwr-off-time" two properties to make CPU idle power-down
> > > > mode (same with LP2) work normally after this series.
> > > > 
> > > > So can you provide me that or point me out where is your downstream
> > > > kernel source? There data would be come from DT after this series.
> > > 
> > > We don't have suspend support in downstream kernels either. However
> > > since the Tamonten was derived from the Harmony reference design I
> > > suppose the same values can be reused.
> > > 
> > OK. That's enough.
> > 
> > > That said, the binding document says that those values are only required
> > > if nvidia,suspend-mode is set. So if we don't add it for the Tamonten
> > > boards why would you need the cpu-pwr-good-time and cpu-pwr-off-time
> > > values. Or maybe the binding document is wrong?
> > 
> > Actually, when you support CPU idle power-down mode (LP2), you already
> > support suspend function (at least LP2 mode). Just no wake up source
> > define in DT for your boards.
> 
> Okay, but for CPU idle LP2 we don't need a wakeup source, right? I only
> need the wakeup source if I explicitly suspend the device.
> 
Yes. The difference between CPU idle and suspend LP2 is wake up from any
interrupt or specific interrupt source (wake up source for suspend).

My approach is adding CPU idle LP2 support first and make it support
suspend later. Then reorganize them into PM related code and get the
configurations from DT.

> > May I add these properties to your boards (same as Harmony)? Then you
> > can figure out your wake up source later, at least the RTC can wake up
> > your device I believe.
> 
> From what I understand there should be no changes in behaviour after
> this patch, so it should be fine.
> 
OK, thanks.
diff mbox

Patch

diff --git a/arch/arm/boot/dts/tegra20-harmony.dts b/arch/arm/boot/dts/tegra20-harmony.dts
index 4f08521..7904eb4 100644
--- a/arch/arm/boot/dts/tegra20-harmony.dts
+++ b/arch/arm/boot/dts/tegra20-harmony.dts
@@ -429,6 +429,12 @@ 
 
 	pmc {
 		nvidia,invert-interrupt;
+		nvidia,suspend-mode = <2>;
+		nvidia,cpu-pwr-good-time = <5000>;
+		nvidia,cpu-pwr-off-time = <5000>;
+		nvidia,core-pwr-good-time = <3845 3845>;
+		nvidia,core-pwr-off-time = <3875>;
+		nvidia,sys-clock-req-active-high;
 	};
 
 	usb@c5000000 {
diff --git a/arch/arm/boot/dts/tegra20-paz00.dts b/arch/arm/boot/dts/tegra20-paz00.dts
index c55e062..680eeeb 100644
--- a/arch/arm/boot/dts/tegra20-paz00.dts
+++ b/arch/arm/boot/dts/tegra20-paz00.dts
@@ -428,6 +428,12 @@ 
 
 	pmc {
 		nvidia,invert-interrupt;
+		nvidia,suspend-mode = <2>;
+		nvidia,cpu-pwr-good-time = <2000>;
+		nvidia,cpu-pwr-off-time = <0>;
+		nvidia,core-pwr-good-time = <3845 3845>;
+		nvidia,core-pwr-off-time = <0>;
+		nvidia,sys-clock-req-active-high;
 	};
 
 	usb@c5000000 {
diff --git a/arch/arm/boot/dts/tegra20-seaboard.dts b/arch/arm/boot/dts/tegra20-seaboard.dts
index 5572ee7..2ff92c9 100644
--- a/arch/arm/boot/dts/tegra20-seaboard.dts
+++ b/arch/arm/boot/dts/tegra20-seaboard.dts
@@ -530,6 +530,12 @@ 
 
 	pmc {
 		nvidia,invert-interrupt;
+		nvidia,suspend-mode = <2>;
+		nvidia,cpu-pwr-good-time = <5000>;
+		nvidia,cpu-pwr-off-time = <5000>;
+		nvidia,core-pwr-good-time = <3845 3845>;
+		nvidia,core-pwr-off-time = <3875>;
+		nvidia,sys-clock-req-active-high;
 	};
 
 	memory-controller@7000f400 {
diff --git a/arch/arm/boot/dts/tegra20-trimslice.dts b/arch/arm/boot/dts/tegra20-trimslice.dts
index 8e8d4f6..7760b67 100644
--- a/arch/arm/boot/dts/tegra20-trimslice.dts
+++ b/arch/arm/boot/dts/tegra20-trimslice.dts
@@ -313,6 +313,15 @@ 
 		};
 	};
 
+	pmc {
+		nvidia,suspend-mode = <2>;
+		nvidia,cpu-pwr-good-time = <5000>;
+		nvidia,cpu-pwr-off-time = <5000>;
+		nvidia,core-pwr-good-time = <3845 3845>;
+		nvidia,core-pwr-off-time = <3875>;
+		nvidia,sys-clock-req-active-high;
+	};
+
 	usb@c5000000 {
 		status = "okay";
 		nvidia,vbus-gpio = <&gpio 170 0>; /* gpio PV2 */
diff --git a/arch/arm/boot/dts/tegra20-ventana.dts b/arch/arm/boot/dts/tegra20-ventana.dts
index 4363764..98a1eae 100644
--- a/arch/arm/boot/dts/tegra20-ventana.dts
+++ b/arch/arm/boot/dts/tegra20-ventana.dts
@@ -506,6 +506,12 @@ 
 
 	pmc {
 		nvidia,invert-interrupt;
+		nvidia,suspend-mode = <2>;
+		nvidia,cpu-pwr-good-time = <2000>;
+		nvidia,cpu-pwr-off-time = <100>;
+		nvidia,core-pwr-good-time = <3845 3845>;
+		nvidia,core-pwr-off-time = <458>;
+		nvidia,sys-clock-req-active-high;
 	};
 
 	usb@c5000000 {
diff --git a/arch/arm/boot/dts/tegra20-whistler.dts b/arch/arm/boot/dts/tegra20-whistler.dts
index 878790e..ff74be7 100644
--- a/arch/arm/boot/dts/tegra20-whistler.dts
+++ b/arch/arm/boot/dts/tegra20-whistler.dts
@@ -509,6 +509,14 @@ 
 
 	pmc {
 		nvidia,invert-interrupt;
+		nvidia,suspend-mode = <2>;
+		nvidia,cpu-pwr-good-time = <2000>;
+		nvidia,cpu-pwr-off-time = <1000>;
+		nvidia,core-pwr-good-time = <0 3845>;
+		nvidia,core-pwr-off-time = <93727>;
+		nvidia,core-power-req-active-high;
+		nvidia,sys-clock-req-active-high;
+		nvidia,combined-power-req;
 	};
 
 	usb@c5000000 {
diff --git a/arch/arm/boot/dts/tegra30-beaver.dts b/arch/arm/boot/dts/tegra30-beaver.dts
index 772e6cf..f17deb0 100644
--- a/arch/arm/boot/dts/tegra30-beaver.dts
+++ b/arch/arm/boot/dts/tegra30-beaver.dts
@@ -266,6 +266,13 @@ 
 	pmc {
 		status = "okay";
 		nvidia,invert-interrupt;
+		nvidia,suspend-mode = <2>;
+		nvidia,cpu-pwr-good-time = <2000>;
+		nvidia,cpu-pwr-off-time = <200>;
+		nvidia,core-pwr-good-time = <3845 3845>;
+		nvidia,core-pwr-off-time = <0>;
+		nvidia,core-power-req-active-high;
+		nvidia,sys-clock-req-active-high;
 	};
 
 	sdhci@78000000 {
diff --git a/arch/arm/boot/dts/tegra30-cardhu.dtsi b/arch/arm/boot/dts/tegra30-cardhu.dtsi
index 053913f..9171834 100644
--- a/arch/arm/boot/dts/tegra30-cardhu.dtsi
+++ b/arch/arm/boot/dts/tegra30-cardhu.dtsi
@@ -320,6 +320,13 @@ 
 	pmc {
 		status = "okay";
 		nvidia,invert-interrupt;
+		nvidia,suspend-mode = <2>;
+		nvidia,cpu-pwr-good-time = <2000>;
+		nvidia,cpu-pwr-off-time = <200>;
+		nvidia,core-pwr-good-time = <3845 3845>;
+		nvidia,core-pwr-off-time = <0>;
+		nvidia,core-power-req-active-high;
+		nvidia,sys-clock-req-active-high;
 	};
 
 	sdhci@78000000 {