[PATCH V2 0/9] ARM: tegra: add platform suspend support

[PATCH V2 0/9] ARM: tegra: add platform suspend support

[Joseph Lo]

This series introduces a basic functionality for Tegra to support the
platform suspend and resume.

Note: This series only adds the support for Tegra20 and Tegra30. The
Tegra114 will be supported later.

Verified on Seaboard and Cardhu.

V2:
* re-order the patch sequence to make sure the suspend function can be
  enabled well after the last patch be merged
* squash the patches that defined the PM bindings for PMC and the
  implementation

Joseph Lo (9):
  gpio: tegra: add gpio wakeup source handling
  ARM: tegra: irq: add wake up handling
  ARM: dt: tegra: add bindings of power management configurations for
    PMC
  ARM: tegra: pm: add platform suspend support
  ARM: dts: tegra: add power gpio keys to DT
  ARM: dts: tegra: whistler: add wakeup source for KBC
  ARM: dts: tegra: add non-removable and keep-power-in-suspend property
    for MMC
  ARM: tegra: config: defconfig update
  ARM: dts: tegra: add the PM configurations of PMC

 .../bindings/arm/tegra/nvidia,tegra20-pmc.txt      |  42 ++++++-
 arch/arm/boot/dts/tegra20-harmony.dts              |  17 +++
 arch/arm/boot/dts/tegra20-paz00.dts                |   8 ++
 arch/arm/boot/dts/tegra20-seaboard.dts             |   8 ++
 arch/arm/boot/dts/tegra20-trimslice.dts            |  20 ++++
 arch/arm/boot/dts/tegra20-ventana.dts              |  19 +++
 arch/arm/boot/dts/tegra20-whistler.dts             |  10 ++
 arch/arm/boot/dts/tegra30-beaver.dts               |   8 ++
 arch/arm/boot/dts/tegra30-cardhu-a02.dts           |   1 +
 arch/arm/boot/dts/tegra30-cardhu-a04.dts           |   1 +
 arch/arm/boot/dts/tegra30-cardhu.dtsi              |   8 ++
 arch/arm/configs/tegra_defconfig                   |   1 +
 arch/arm/mach-tegra/common.c                       |   3 +
 arch/arm/mach-tegra/irq.c                          |  95 ++++++++++++++-
 arch/arm/mach-tegra/irq.h                          |   6 +
 arch/arm/mach-tegra/pm.c                           |  65 +++++++++++
 arch/arm/mach-tegra/pm.h                           |   6 +
 arch/arm/mach-tegra/pmc.c                          | 128 +++++++++++++++++++++
 arch/arm/mach-tegra/pmc.h                          |  16 +++
 drivers/gpio/gpio-tegra.c                          |  21 +++-
 20 files changed, 479 insertions(+), 4 deletions(-)

-- 
1.8.1.5

[PATCH V2 0/9] ARM: tegra: add platform suspend support

[Stephen Warren]

On 03/11/2013 10:01 PM, Joseph Lo wrote:
> This series introduces a basic functionality for Tegra to support the
> platform suspend and resume.
> 
> Note: This series only adds the support for Tegra20 and Tegra30. The
> Tegra114 will be supported later.

Aside from the few issues that have already been pointed out, this looks
OK now. I have a couple questions:

1) Please remind me if this series depends on anything. If not, I hope
to apply it mostly directly on top of 3.9-rc1 or so.

2) You mentioned that Tegra114 isn't supported. What is the failure mode
on Tegra114? Is suspend simply not available and hence can't be
requested, or will suspend attempts gracefully return an error, or will
there we crashes, boot failures, etc.?

3) Sorry for asking this again, but since only LP2 is actually
implemented in patch 4, what happens if the user selects LP0 or LP1?
Does the system (a) just use LP2, (b) fail to suspend, and hence
immediately resume, (c) suspend, but can't be resumed, ...?

Thanks.

[PATCH V2 0/9] ARM: tegra: add platform suspend support

[Joseph Lo]

On Wed, 2013-03-13 at 03:32 +0800, Stephen Warren wrote:
> On 03/11/2013 10:01 PM, Joseph Lo wrote:
> > This series introduces a basic functionality for Tegra to support the
> > platform suspend and resume.
> > 
> > Note: This series only adds the support for Tegra20 and Tegra30. The
> > Tegra114 will be supported later.
> 
> Aside from the few issues that have already been pointed out, this looks
> OK now. I have a couple questions:
> 
> 1) Please remind me if this series depends on anything. If not, I hope
> to apply it mostly directly on top of 3.9-rc1 or so.
> 
There is a patch that you just re-post to linux-mmc tree (mmc: tegra:
use mmc_of_parse to get the support of standard MMC DT bindings). This
series need the patch to make sure everything work.

> 2) You mentioned that Tegra114 isn't supported. What is the failure mode
> on Tegra114? Is suspend simply not available and hence can't be
> requested, or will suspend attempts gracefully return an error, or will
> there we crashes, boot failures, etc.?
> 
Because the DT of Tegra114 didn't describe any PMC suspend information.
So the driver will prevent to register any platform suspend ops. The
result will something like below.

Tegra114 > echo mem > /sys/power/state
write error: No such device

> 3) Sorry for asking this again, but since only LP2 is actually
> implemented in patch 4, what happens if the user selects LP0 or LP1?
> Does the system (a) just use LP2, (b) fail to suspend, and hence
> immediately resume, (c) suspend, but can't be resumed, ...?
> 
Ah. I didn't add any protection here. It will be (c) due the LP2 mask. I
will add a protection in next version. Thanks for remind.

BTW, I want to mention one thing about PMC DT bindings. Because I can't
add all of the PMC DT bindings in one time, the PMC is related to too
many devices to work for runtime PM and power domain control. And some
wake up sources control for deep sleep mode (LP0). They are still under
developing for upstream. May I add more bindings for PMC later?

Thanks,
Joseph

[PATCH V2 0/9] ARM: tegra: add platform suspend support

[Stephen Warren]

On 03/13/2013 12:04 AM, Joseph Lo wrote:
...
> BTW, I want to mention one thing about PMC DT bindings. Because I can't
> add all of the PMC DT bindings in one time, the PMC is related to too
> many devices to work for runtime PM and power domain control. And some
> wake up sources control for deep sleep mode (LP0). They are still under
> developing for upstream. May I add more bindings for PMC later?

With DT you are supposed to define the complete DT binding for the HW up
front. There have been some hints that incrementally defining bindings
will start to get push-back. How hard is it in this case to simply
define the entire binding right now?

That said, in practice, you can certainly incrementally define bindings
at the moment. The main issue here is to ensure that when you add the
new properties/..., then:

a) You don't change anything that's already there. The old properties
and content must continue to work without modification.

b) For all nodes/properties that are newly required, either there is a
suitable default if they are missing from the DT (as they would be for
DTs written to the old specification), /or/ the new nodes/properties
only enable new features, so that any old DT continues to work fine with
at least as many features as it always did.

If you satisfy those conditions, I believe we can still get away with
incrementally defining bindings. I don't know how long that will last
though.

[PATCH V2 0/9] ARM: tegra: add platform suspend support

[Joseph Lo]

On Thu, 2013-03-14 at 01:34 +0800, Stephen Warren wrote:
> On 03/13/2013 12:04 AM, Joseph Lo wrote:
> ...
> > BTW, I want to mention one thing about PMC DT bindings. Because I can't
> > add all of the PMC DT bindings in one time, the PMC is related to too
> > many devices to work for runtime PM and power domain control. And some
> > wake up sources control for deep sleep mode (LP0). They are still under
> > developing for upstream. May I add more bindings for PMC later?
> 
> With DT you are supposed to define the complete DT binding for the HW up
> front. There have been some hints that incrementally defining bindings
> will start to get push-back. How hard is it in this case to simply
> define the entire binding right now?
> 
There are still two main features for PMC that we need to define
bindings/properties in DT. One is power main the other wake up source.
But we are not there yet. Because I don't have drivers to verify them is
enough or not. If I add all the bindings right now, I believe it will be
modify later.

> That said, in practice, you can certainly incrementally define bindings
> at the moment. The main issue here is to ensure that when you add the
> new properties/..., then:
> 
> a) You don't change anything that's already there. The old properties
> and content must continue to work without modification.
> 
Yes.
> b) For all nodes/properties that are newly required, either there is a
> suitable default if they are missing from the DT (as they would be for
> DTs written to the old specification), /or/ the new nodes/properties
> only enable new features, so that any old DT continues to work fine with
> at least as many features as it always did.
> 
Yes, it's only for new features.
> If you satisfy those conditions, I believe we can still get away with
> incrementally defining bindings. I don't know how long that will last
> though.

Thanks,
Joseph

[PATCH V2 0/9] ARM: tegra: add platform suspend support

[Stephen Warren]

On 03/13/2013 07:26 PM, Joseph Lo wrote:
> On Thu, 2013-03-14 at 01:34 +0800, Stephen Warren wrote:
>> On 03/13/2013 12:04 AM, Joseph Lo wrote:
>> ...
>>> BTW, I want to mention one thing about PMC DT bindings. Because I can't
>>> add all of the PMC DT bindings in one time, the PMC is related to too
>>> many devices to work for runtime PM and power domain control. And some
>>> wake up sources control for deep sleep mode (LP0). They are still under
>>> developing for upstream. May I add more bindings for PMC later?
>>
>> With DT you are supposed to define the complete DT binding for the HW up
>> front. There have been some hints that incrementally defining bindings
>> will start to get push-back. How hard is it in this case to simply
>> define the entire binding right now?
>>
> There are still two main features for PMC that we need to define
> bindings/properties in DT. One is power main the other wake up source.
> But we are not there yet. Because I don't have drivers to verify them is
> enough or not. If I add all the bindings right now, I believe it will be
> modify later.

Since the DT is supposed to be a representation of the HW, and not a
representation of what a particular driver needs, I'm not sue why you'd
need to be able to test a driver before you could design a DT binding.

[PATCH V2 0/9] ARM: tegra: add platform suspend support

[Joseph Lo]

On Thu, 2013-03-14 at 12:43 +0800, Stephen Warren wrote:
> On 03/13/2013 07:26 PM, Joseph Lo wrote:
> > On Thu, 2013-03-14 at 01:34 +0800, Stephen Warren wrote:
> >> On 03/13/2013 12:04 AM, Joseph Lo wrote:
> >> ...
> >>> BTW, I want to mention one thing about PMC DT bindings. Because I can't
> >>> add all of the PMC DT bindings in one time, the PMC is related to too
> >>> many devices to work for runtime PM and power domain control. And some
> >>> wake up sources control for deep sleep mode (LP0). They are still under
> >>> developing for upstream. May I add more bindings for PMC later?
> >>
> >> With DT you are supposed to define the complete DT binding for the HW up
> >> front. There have been some hints that incrementally defining bindings
> >> will start to get push-back. How hard is it in this case to simply
> >> define the entire binding right now?
> >>
> > There are still two main features for PMC that we need to define
> > bindings/properties in DT. One is power main the other wake up source.
> > But we are not there yet. Because I don't have drivers to verify them is
> > enough or not. If I add all the bindings right now, I believe it will be
> > modify later.
> 
> Since the DT is supposed to be a representation of the HW, and not a
> representation of what a particular driver needs, I'm not sue why you'd
> need to be able to test a driver before you could design a DT binding.
> 
Because some of the power domain has complicated relation, I am still
figuring out how to bind them can make drivers have enough power domain
information to do a power control function.

Joseph