Re: [PATCH 07/13] OMAP PM: early init of the pwrdms states
Todd, On Tue, Aug 2, 2011 at 10:57 AM, Jean Pihet wrote: > Todd, > > On Fri, Jul 29, 2011 at 10:50 AM, Jean Pihet > wrote: >> On Fri, Jul 29, 2011 at 10:08 AM, Todd Poynor wrote: >>> On Thu, Jul 28, 2011 at 10:30:14AM +0200, jean.pi...@newoldbits.com wrote: > ... > diff --git a/arch/arm/mach-omap2/powerdomain.c b/arch/arm/mach-omap2/powerdomain.c index 9af0847..63c3e7a 100644 --- a/arch/arm/mach-omap2/powerdomain.c +++ b/arch/arm/mach-omap2/powerdomain.c @@ -108,6 +108,9 @@ static int _pwrdm_register(struct powerdomain *pwrdm) pwrdm->state = pwrdm_read_pwrst(pwrdm); pwrdm->state_counter[pwrdm->state] = 1; + /* Early init of the next power state */ + pwrdm_set_next_pwrst(pwrdm, PWRDM_POWER_RET); + >>> >>> Wanted to check that it's OK to initialize the next state of a power >>> domain to RETENTION early in the boot sequence. I believe patches >>> have been previously discussed that set the state to ON to ensure the >>> domain doesn't go to a lower state, and possibly lose context, before >>> the PM subsystem is setup to handle it? Not sure, thought maybe worth >>> a doublecheck. >> Indeed I need to check the behavior for OMAP3 & 4 which seem to >> initialize the pwrdm states differently. >> BTW the patch that inits all pwrdms to ON is not yet in l-o master >> that is why I (lazily) submitted this one for now. > > Ok I will update the patch to make it compliant with [1]. v4 will > include this change. > > Thanks, > Jean > > [1] http://marc.info/?l=linux-arm-kernel&m=131052762623823&w=2 After more thinking I now realize there is a problem with the PM early init, PM late init and the constraints framework which all setup the power domains next states in a non-coherent way. Definitely this needs to be revisited. More to come on this! There is a comment about that in [00/15] of the v4 patch set. Regards, Jean > >> >>> >>> >>> Todd > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 07/13] OMAP PM: early init of the pwrdms states
Todd, On Fri, Jul 29, 2011 at 10:50 AM, Jean Pihet wrote: > On Fri, Jul 29, 2011 at 10:08 AM, Todd Poynor wrote: >> On Thu, Jul 28, 2011 at 10:30:14AM +0200, jean.pi...@newoldbits.com wrote: ... >>> diff --git a/arch/arm/mach-omap2/powerdomain.c >>> b/arch/arm/mach-omap2/powerdomain.c >>> index 9af0847..63c3e7a 100644 >>> --- a/arch/arm/mach-omap2/powerdomain.c >>> +++ b/arch/arm/mach-omap2/powerdomain.c >>> @@ -108,6 +108,9 @@ static int _pwrdm_register(struct powerdomain *pwrdm) >>> pwrdm->state = pwrdm_read_pwrst(pwrdm); >>> pwrdm->state_counter[pwrdm->state] = 1; >>> >>> + /* Early init of the next power state */ >>> + pwrdm_set_next_pwrst(pwrdm, PWRDM_POWER_RET); >>> + >> >> Wanted to check that it's OK to initialize the next state of a power >> domain to RETENTION early in the boot sequence. I believe patches >> have been previously discussed that set the state to ON to ensure the >> domain doesn't go to a lower state, and possibly lose context, before >> the PM subsystem is setup to handle it? Not sure, thought maybe worth >> a doublecheck. > Indeed I need to check the behavior for OMAP3 & 4 which seem to > initialize the pwrdm states differently. > BTW the patch that inits all pwrdms to ON is not yet in l-o master > that is why I (lazily) submitted this one for now. Ok I will update the patch to make it compliant with [1]. v4 will include this change. Thanks, Jean [1] http://marc.info/?l=linux-arm-kernel&m=131052762623823&w=2 > >> >> >> Todd -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 07/13] OMAP PM: early init of the pwrdms states
On Fri, Jul 29, 2011 at 10:08 AM, Todd Poynor wrote: > On Thu, Jul 28, 2011 at 10:30:14AM +0200, jean.pi...@newoldbits.com wrote: >> From: Jean Pihet >> >> The powerdomains next states are initialized in pwrdms_setup as a >> late_initcall. Because the PM QoS devices constraint can be requested >> early in the boot sequence, the power domains next states can be >> overwritten by pwrdms_setup. >> >> This patch fixes it by initializing the power domains next states >> early at boot, so that the constraints can be applied. >> Later in the pwrdms_setup function the currently programmed >> next states are re-used as next state values. >> >> Applies to OMAP3 and OMAP4. >> >> Tested on OMAP3 Beagleboard and OMAP4 Pandaboard in RET/OFF using >> wake-up latency constraints on MPU, CORE and PER. >> >> Signed-off-by: Jean Pihet >> --- > ... >> diff --git a/arch/arm/mach-omap2/powerdomain.c >> b/arch/arm/mach-omap2/powerdomain.c >> index 9af0847..63c3e7a 100644 >> --- a/arch/arm/mach-omap2/powerdomain.c >> +++ b/arch/arm/mach-omap2/powerdomain.c >> @@ -108,6 +108,9 @@ static int _pwrdm_register(struct powerdomain *pwrdm) >> pwrdm->state = pwrdm_read_pwrst(pwrdm); >> pwrdm->state_counter[pwrdm->state] = 1; >> >> + /* Early init of the next power state */ >> + pwrdm_set_next_pwrst(pwrdm, PWRDM_POWER_RET); >> + > > Wanted to check that it's OK to initialize the next state of a power > domain to RETENTION early in the boot sequence. I believe patches > have been previously discussed that set the state to ON to ensure the > domain doesn't go to a lower state, and possibly lose context, before > the PM subsystem is setup to handle it? Not sure, thought maybe worth > a doublecheck. Indeed I need to check the behavior for OMAP3 & 4 which seem to initialize the pwrdm states differently. BTW the patch that inits all pwrdms to ON is not yet in l-o master that is why I (lazily) submitted this one for now. > > > Todd > > Jean -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 07/13] OMAP PM: early init of the pwrdms states
On Thu, Jul 28, 2011 at 10:30:14AM +0200, jean.pi...@newoldbits.com wrote: > From: Jean Pihet > > The powerdomains next states are initialized in pwrdms_setup as a > late_initcall. Because the PM QoS devices constraint can be requested > early in the boot sequence, the power domains next states can be > overwritten by pwrdms_setup. > > This patch fixes it by initializing the power domains next states > early at boot, so that the constraints can be applied. > Later in the pwrdms_setup function the currently programmed > next states are re-used as next state values. > > Applies to OMAP3 and OMAP4. > > Tested on OMAP3 Beagleboard and OMAP4 Pandaboard in RET/OFF using > wake-up latency constraints on MPU, CORE and PER. > > Signed-off-by: Jean Pihet > --- ... > diff --git a/arch/arm/mach-omap2/powerdomain.c > b/arch/arm/mach-omap2/powerdomain.c > index 9af0847..63c3e7a 100644 > --- a/arch/arm/mach-omap2/powerdomain.c > +++ b/arch/arm/mach-omap2/powerdomain.c > @@ -108,6 +108,9 @@ static int _pwrdm_register(struct powerdomain *pwrdm) > pwrdm->state = pwrdm_read_pwrst(pwrdm); > pwrdm->state_counter[pwrdm->state] = 1; > > + /* Early init of the next power state */ > + pwrdm_set_next_pwrst(pwrdm, PWRDM_POWER_RET); > + Wanted to check that it's OK to initialize the next state of a power domain to RETENTION early in the boot sequence. I believe patches have been previously discussed that set the state to ON to ensure the domain doesn't go to a lower state, and possibly lose context, before the PM subsystem is setup to handle it? Not sure, thought maybe worth a doublecheck. Todd -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 07/13] OMAP PM: early init of the pwrdms states
From: Jean Pihet
The powerdomains next states are initialized in pwrdms_setup as a
late_initcall. Because the PM QoS devices constraint can be requested
early in the boot sequence, the power domains next states can be
overwritten by pwrdms_setup.
This patch fixes it by initializing the power domains next states
early at boot, so that the constraints can be applied.
Later in the pwrdms_setup function the currently programmed
next states are re-used as next state values.
Applies to OMAP3 and OMAP4.
Tested on OMAP3 Beagleboard and OMAP4 Pandaboard in RET/OFF using
wake-up latency constraints on MPU, CORE and PER.
Signed-off-by: Jean Pihet
---
arch/arm/mach-omap2/pm34xx.c |2 +-
arch/arm/mach-omap2/pm44xx.c |2 +-
arch/arm/mach-omap2/powerdomain.c |3 +++
3 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 96a7624..af626ac 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -822,7 +822,7 @@ static int __init pwrdms_setup(struct powerdomain *pwrdm,
void *unused)
if (!pwrst)
return -ENOMEM;
pwrst->pwrdm = pwrdm;
- pwrst->next_state = PWRDM_POWER_RET;
+ pwrst->next_state = pwrdm_read_next_pwrst(pwrdm);
list_add(&pwrst->node, &pwrst_list);
if (pwrdm_has_hdwr_sar(pwrdm))
diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm44xx.c
index 59a870b..91ede72 100644
--- a/arch/arm/mach-omap2/pm44xx.c
+++ b/arch/arm/mach-omap2/pm44xx.c
@@ -84,7 +84,7 @@ static int __init pwrdms_setup(struct powerdomain *pwrdm,
void *unused)
if (!pwrst)
return -ENOMEM;
pwrst->pwrdm = pwrdm;
- pwrst->next_state = PWRDM_POWER_ON;
+ pwrst->next_state = pwrdm_read_next_pwrst(pwrdm);
list_add(&pwrst->node, &pwrst_list);
return pwrdm_set_next_pwrst(pwrst->pwrdm, pwrst->next_state);
diff --git a/arch/arm/mach-omap2/powerdomain.c
b/arch/arm/mach-omap2/powerdomain.c
index 9af0847..63c3e7a 100644
--- a/arch/arm/mach-omap2/powerdomain.c
+++ b/arch/arm/mach-omap2/powerdomain.c
@@ -108,6 +108,9 @@ static int _pwrdm_register(struct powerdomain *pwrdm)
pwrdm->state = pwrdm_read_pwrst(pwrdm);
pwrdm->state_counter[pwrdm->state] = 1;
+ /* Early init of the next power state */
+ pwrdm_set_next_pwrst(pwrdm, PWRDM_POWER_RET);
+
pr_debug("powerdomain: registered %s\n", pwrdm->name);
return 0;
--
1.7.2.5
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
