diff mbox

[PATCHv7,07/12] ARM: OMAP4: PM: put all domains to OSWR during suspend

Message ID 1342704392-23657-8-git-send-email-t-kristo@ti.com (mailing list archive)
State New, archived
Headers show

Commit Message

Tero Kristo July 19, 2012, 1:26 p.m. UTC
Signed-off-by: Tero Kristo <t-kristo@ti.com>
---
 arch/arm/mach-omap2/pm44xx.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

Comments

Paul Walmsley July 19, 2012, 2:44 p.m. UTC | #1
On Thu, 19 Jul 2012, Tero Kristo wrote:

> Signed-off-by: Tero Kristo <t-kristo@ti.com>

This one needs at least some short description for the changelog.  Maybe 
just a brief explanation that OSWR saves more energy that CSWR, but has 
higher resume latency, and since resume from system suspend is considered 
to be a high-latency operation, OSWR is appropriate here.


- Paul
Tero Kristo July 19, 2012, 3:31 p.m. UTC | #2
On Thu, 2012-07-19 at 08:44 -0600, Paul Walmsley wrote:
> On Thu, 19 Jul 2012, Tero Kristo wrote:
> 
> > Signed-off-by: Tero Kristo <t-kristo@ti.com>
> 
> This one needs at least some short description for the changelog.  Maybe 
> just a brief explanation that OSWR saves more energy that CSWR, but has 
> higher resume latency, and since resume from system suspend is considered 
> to be a high-latency operation, OSWR is appropriate here.

Yea, I can add one. How about this:

Subject: [PATCHv7 07/12] ARM: OMAP4: PM: put all domains to OSWR during
suspend

Currently OMAP4 suspend puts all power domains to CSWR. OSWR is a deeper
state that saves more power, but has higher latencies also. As suspend
is considered a high-latency operation, OSWR is appropriate here.

Signed-off-by: Tero Kristo <t-kristo@ti.com>
---

I'll update this to next rev if one is requested.

(Kind of hoping this set would be reaching maturity already.)

-Tero
Paul Walmsley July 19, 2012, 11:30 p.m. UTC | #3
Hi

On Thu, 19 Jul 2012, Tero Kristo wrote:

> Subject: [PATCHv7 07/12] ARM: OMAP4: PM: put all domains to OSWR during
> suspend
> 
> Currently OMAP4 suspend puts all power domains to CSWR. OSWR is a deeper
> state that saves more power, but has higher latencies also. As suspend
> is considered a high-latency operation, OSWR is appropriate here.
> 
> Signed-off-by: Tero Kristo <t-kristo@ti.com>
> ---
> 
> I'll update this to next rev if one is requested.

No need, I'll add it in the local copy here.

> (Kind of hoping this set would be reaching maturity already.)

It kind of looks to me like there are two or three separate sets within 
the series.  My feeling is that Kevin should take the first two, then I 
should take the rest other than 6 and 7.  Then once those are queued, 
we can pull in 6 and 7.  Does that make sense to you?


- Paul
Tero Kristo July 20, 2012, 8:37 a.m. UTC | #4
On Thu, 2012-07-19 at 17:30 -0600, Paul Walmsley wrote:
> Hi
> 
> On Thu, 19 Jul 2012, Tero Kristo wrote:
> 
> > Subject: [PATCHv7 07/12] ARM: OMAP4: PM: put all domains to OSWR during
> > suspend
> > 
> > Currently OMAP4 suspend puts all power domains to CSWR. OSWR is a deeper
> > state that saves more power, but has higher latencies also. As suspend
> > is considered a high-latency operation, OSWR is appropriate here.
> > 
> > Signed-off-by: Tero Kristo <t-kristo@ti.com>
> > ---
> > 
> > I'll update this to next rev if one is requested.
> 
> No need, I'll add it in the local copy here.

Thanks, thats what I thought. :)

> 
> > (Kind of hoping this set would be reaching maturity already.)
> 
> It kind of looks to me like there are two or three separate sets within 
> the series.  My feeling is that Kevin should take the first two, then I 
> should take the rest other than 6 and 7.  Then once those are queued, 
> we can pull in 6 and 7.  Does that make sense to you?

Yea, that looks good to me. Patches up from 6+ should only be pulled
once the pre-reqs for this set are in also (io-chain + Jean's func pwrst
stuff.) I haven't actually tried these patches without the pre-reqs
lately, but I think they should be fine.

-Tero
Kevin Hilman Sept. 12, 2012, 11:11 p.m. UTC | #5
Paul Walmsley <paul@pwsan.com> writes:

[...]

>
> It kind of looks to me like there are two or three separate sets within 
> the series.  My feeling is that Kevin should take the first two, then I 
> should take the rest other than 6 and 7.  Then once those are queued, 
> we can pull in 6 and 7.  Does that make sense to you?
>

Looks like 1, 2 & 7 are needed for OSWR, and the rest can go now via
Paul.

Tero, can create a new OSWR series including 1, 2 & 7?  Can you also
refresh it against Jean's latest functional power state series (v6)?

Thanks,

Kevin
Tero Kristo Sept. 13, 2012, 7:40 a.m. UTC | #6
On Wed, 2012-09-12 at 16:11 -0700, Kevin Hilman wrote:
> Paul Walmsley <paul@pwsan.com> writes:
> 
> [...]
> 
> >
> > It kind of looks to me like there are two or three separate sets within 
> > the series.  My feeling is that Kevin should take the first two, then I 
> > should take the rest other than 6 and 7.  Then once those are queued, 
> > we can pull in 6 and 7.  Does that make sense to you?
> >
> 
> Looks like 1, 2 & 7 are needed for OSWR, and the rest can go now via
> Paul.
> 
> Tero, can create a new OSWR series including 1, 2 & 7?  Can you also
> refresh it against Jean's latest functional power state series (v6)?

Yes, I already have these patches locally available. I'll just refresh
them against Paul's minor tweaks on rest of the patches and re-post.

-Tero
diff mbox

Patch

diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm44xx.c
index 1e845e8..eb3e073 100644
--- a/arch/arm/mach-omap2/pm44xx.c
+++ b/arch/arm/mach-omap2/pm44xx.c
@@ -105,7 +105,7 @@  static int __init pwrdms_setup(struct powerdomain *pwrdm, void *unused)
 	pwrst->pwrdm = pwrdm;
 	pwrst->next_state = pwrdm_get_achievable_func_pwrst(
 						pwrdm,
-						PWRDM_FUNC_PWRST_CSWR);
+						PWRDM_FUNC_PWRST_OSWR);
 	list_add(&pwrst->node, &pwrst_list);
 
 	return omap_set_pwrdm_state(pwrst->pwrdm, pwrst->next_state);