From: Tero Kristo <hidden> Date: 2012-07-13 14:19:37
Hi,
Changes compared to previous version:
- added kerneldoc comments to new API functions
- added autoidle flagging support for omap3 dplls
- modified the clkdm code tweak required to fix omap3 per domain problems
* moved implementation to _clkdm_del_autodeps
* renamed the CLKDM_SKIP_MANUAL_TRANS to CLKDM_NO_AUTODEP_DISABLE
* modified comments accordingly
- ported for 3.5-rc6
- tested with omap3 beagle board, both ret / off + suspend / cpuidle
- functional branch available at:
git://gitorious.org/~kristo/omap-pm/omap-pm-work.git
branch: mainline-3.5-rc6-pwrdm-changes-v4
-Tero
From: Tero Kristo <hidden> Date: 2012-07-13 14:19:38
This works similarly to e.g. pwrdm_for_each(). Needed by enhanced
usecounting debug functionality that will be added to pm-debug.
Signed-off-by: Tero Kristo <redacted>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <redacted>
---
arch/arm/plat-omap/clock.c | 33 +++++++++++++++++++++++++++++++
arch/arm/plat-omap/include/plat/clock.h | 2 +
2 files changed, 35 insertions(+), 0 deletions(-)
From: Tero Kristo <hidden> Date: 2012-07-13 14:19:39
This patch fixes the usecount tracking for omap3+, previously the
usecount numbers were rather bogus and were not really useful for
any purpose. Now usecount numbers track the number of really active
clients on each domain. This patch also adds support for usecount
tracking on powerdomain level and autoidle flag for clocks that
are hardware controlled and should be skipped in usecount
calculations.
Signed-off-by: Tero Kristo <redacted>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <redacted>
---
arch/arm/mach-omap2/clkt_iclk.c | 21 +++++++++++
arch/arm/mach-omap2/clockdomain.c | 59 +++++++++++++++++++++++++++++-
arch/arm/mach-omap2/clockdomain.h | 2 +
arch/arm/mach-omap2/dpll3xxx.c | 19 ++++++++++
arch/arm/mach-omap2/powerdomain.c | 35 ++++++++++++++++++
arch/arm/mach-omap2/powerdomain.h | 5 +++
arch/arm/plat-omap/clock.c | 6 +++
arch/arm/plat-omap/include/plat/clock.h | 2 +
8 files changed, 147 insertions(+), 2 deletions(-)
@@ -34,6 +35,16 @@ void omap2_clkt_iclk_allow_idle(struct clk *clk)v=__raw_readl((__forcevoid__iomem*)r);v|=(1<<clk->enable_bit);__raw_writel(v,(__forcevoid__iomem*)r);++/* Remove this clock from parent clockdomain usecounts */+if(clk->usecount&&clk->clkdm)+clkdm_usecount_dec(clk->clkdm);++/*+*Markasautoidle,sowecontinuetoignorethisclockin+*parentclkdmusecountcalculations+*/+clk->autoidle=true;}/* XXX */
@@ -46,6 +57,16 @@ void omap2_clkt_iclk_deny_idle(struct clk *clk)v=__raw_readl((__forcevoid__iomem*)r);v&=~(1<<clk->enable_bit);__raw_writel(v,(__forcevoid__iomem*)r);++/* Add clock back to parent clockdomain usecount */+if(clk->usecount&&clk->clkdm)+clkdm_usecount_inc(clk->clkdm);++/*+*Disableautoidleflagsofurtherclkdmusecountstakethis+*clockintoaccount+*/+clk->autoidle=false;}/* Public data */
@@ -919,7 +966,7 @@ static int _clkdm_clk_hwmod_enable(struct clockdomain *clkdm)*shouldbecalledforeveryclockinstanceorhwmodthatis*enabled,sotheclkdmcanbeforcewokenup.*/-if((atomic_inc_return(&clkdm->usecount)>1)&&autodeps)+if((clkdm_usecount_inc(clkdm)>1)&&autodeps)return0;spin_lock_irqsave(&clkdm->lock,flags);
@@ -944,7 +991,7 @@ static int _clkdm_clk_hwmod_disable(struct clockdomain *clkdm)return-ERANGE;}-if(atomic_dec_return(&clkdm->usecount)>0)+if(clkdm_usecount_dec(clkdm)>0)return0;spin_lock_irqsave(&clkdm->lock,flags);
@@ -981,6 +1028,10 @@ int clkdm_clk_enable(struct clockdomain *clkdm, struct clk *clk)if(!clk)return-EINVAL;+/* If autoidle clock, do not update clkdm usecounts */+if(clk->autoidle)+return0;+return_clkdm_clk_hwmod_enable(clkdm);}
@@ -1007,6 +1058,10 @@ int clkdm_clk_disable(struct clockdomain *clkdm, struct clk *clk)if(!clk)return-EINVAL;+/* If autoidle clock, do not update clkdm usecounts */+if(clk->autoidle)+return0;+return_clkdm_clk_hwmod_disable(clkdm);}
From: Tero Kristo <hidden> Date: 2012-07-13 14:19:40
These are updated based on powerdomain usecounts. Also added support
for voltdm->sleep and voltdm->wakeup calls that will be invoked once
voltagedomain enters sleep or wakes up based on usecount numbers. These
will be used for controlling voltage scaling functionality.
Signed-off-by: Tero Kristo <redacted>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <redacted>
---
arch/arm/mach-omap2/powerdomain.c | 6 +++-
arch/arm/mach-omap2/voltage.c | 56 +++++++++++++++++++++++++++++++++++++
arch/arm/mach-omap2/voltage.h | 11 +++++++
3 files changed, 72 insertions(+), 1 deletions(-)
From: Tero Kristo <hidden> Date: 2012-07-13 14:19:41
mpu / core powerdomain usecounts are now statically increased
by 1 during MPU activity. This allows the domains to reflect
actual usage, and will allow the usecount to reach 0 just before
all CPUs are ready to idle. Proper powerdomain usecounts are
propageted to voltagedomain level also, and will allow vc
callbacks to be triggered at right point of time.
Signed-off-by: Tero Kristo <redacted>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <redacted>
---
arch/arm/mach-omap2/pm34xx.c | 3 ++
arch/arm/mach-omap2/pm44xx.c | 3 ++
arch/arm/mach-omap2/powerdomain.c | 64 +++++++++++++++++++++++++++++++++++++
arch/arm/mach-omap2/powerdomain.h | 3 ++
4 files changed, 73 insertions(+), 0 deletions(-)
@@ -758,6 +758,9 @@ int __init omap3_pm_init(void)omap_pm_suspend=omap3_pm_suspend;#endif+/* Notify pwrdm usecounters about active CPU */+pwrdm_cpu_wakeup();+arm_pm_idle=omap3_pm_idle;omap3_idle_init();
@@ -206,6 +206,9 @@ int __init omap4_pm_init(void)omap_pm_suspend=omap4_pm_suspend;#endif+/* Notify pwrdm usecounters about active CPU */+pwrdm_cpu_wakeup();+/* Overwrite the default cpu_do_idle() */arm_pm_idle=omap_default_idle;
@@ -1023,11 +1024,15 @@ void pwrdm_clkdm_disable(struct powerdomain *pwrdm)intpwrdm_pre_transition(void){pwrdm_for_each(_pwrdm_pre_transition_cb,NULL);+/* Decrease mpu / core usecounts to indicate we are entering idle */+pwrdm_cpu_idle();return0;}intpwrdm_post_transition(void){+/* Increase mpu / core usecounts to indicate we are leaving idle */+pwrdm_cpu_wakeup();pwrdm_for_each(_pwrdm_post_transition_cb,NULL);return0;}
@@ -1107,3 +1112,62 @@ bool pwrdm_can_ever_lose_context(struct powerdomain *pwrdm)return0;}++/**+*pwrdm_get_idle_cycle_pwrdms-initpwrdmsneededbyidlecycle+*+*MPUandCOREpowerdomainstatesarechangedautomaticallyby+*hardwareduringsuspend/cpuidle.Thus,theusecountsfor+*thesedomainswillbemanuallychangedduringpwrdm_pre_transition+*pwrdm_post_transitioncallbacks.Thecallbackswillneedpointers+*totheMPUandCOREpowerdomains,sothisinitfunctionisused+*togetthoseonceneeded.+*/+staticvoidpwrdm_get_idle_cycle_pwrdms(void)+{+mpu_pwrdm=pwrdm_lookup("mpu_pwrdm");+if(!mpu_pwrdm)+pr_err_once("%s: failed to get mpu_pwrdm\n",__func__);++core_pwrdm=pwrdm_lookup("core_pwrdm");+if(!core_pwrdm)+pr_err_once("%s: failed to get core_pwrdm\n",__func__);+}++/**+*pwrdm_cpu_wakeup-notifypwrdmusecountersaboutactiveCPU+*+*ThisfunctionmustbecalledjustafteraCPUhasbecomeactive.+*SomepowerdomainshavestaticdependencieswithMPUidlecycle,+*namelympu_pwrdmandcore_pwrdm.Thesepowerdomainswillget+*theirusecountsincreased/decreasedeachsleepcyclesothat+*theyreach0justbeforeallCPUshavereachedidle,andwake-up+*rightafterit.Thisallowsthedependentvoltagedomainsto+*followidlecycleproperlyandtriggertheircallbacksfor+*sleep/wakeup,whichinturnwillcontrole.g.autoretention+*feature.+*/+voidpwrdm_cpu_wakeup(void)+{+if(!mpu_pwrdm||!core_pwrdm)+pwrdm_get_idle_cycle_pwrdms();++pwrdm_clkdm_enable(mpu_pwrdm);+pwrdm_clkdm_enable(core_pwrdm);+}++/**+*pwrdm_cpu_idle-notifypwrdmusecountersaboutidlingCPU+*+*ThisfunctionmustbecalledjustbeforeCPUisabouttoidle.+*Similartopwrdm_cpu_wakeup,thisisusedtomakesuretheidle+*cycledependentpowerdomainsfollowthesleepcycleproperly.+*/+voidpwrdm_cpu_idle(void)+{+if(!mpu_pwrdm||!core_pwrdm)+pwrdm_get_idle_cycle_pwrdms();++pwrdm_clkdm_disable(mpu_pwrdm);+pwrdm_clkdm_disable(core_pwrdm);+}
From: Tero Kristo <hidden> Date: 2012-07-13 14:19:42
sdrc_ick doesn't have autoidle flag on HW, but is always automatically
idled. Thus mark the autoidle flag statically as true for it to reflect
hardware behavior. The clock will no longer show as active in usecount
dumps and will allow the voltdm->sleep / wakeup calls to work properly.
Signed-off-by: Tero Kristo <redacted>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <redacted>
---
arch/arm/mach-omap2/clock3xxx_data.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
From: Tero Kristo <hidden> Date: 2012-07-13 14:19:43
Voltdm, pwrdm, clkdm, hwmod and clk usecounts are now separeted to
their own file, 'usecount'. This file shows the usecounts for every
active domain and their children recursively. 'count' file now only
shows power state counts for powerdomains.
This patch also provices a way to do printk dumps from kernel code,
by calling the pm_dbg_dump_X functions. The plan is to call these
functions once an error condition is detected, e.g. failed suspend.
Signed-off-by: Tero Kristo <redacted>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <redacted>
---
arch/arm/mach-omap2/pm-debug.c | 128 ++++++++++++++++++++++++++++++++++------
arch/arm/mach-omap2/pm.h | 6 ++
2 files changed, 115 insertions(+), 19 deletions(-)
From: Tero Kristo <hidden> Date: 2012-07-13 14:19:44
Some clockdomains bug out if their autodeps are deleted before idle.
This happens namely with OMAP3 PER domain, it will bug out if it
doesn't have wakedeps enabled when it enters off-mode. This patch
adds support for new flag 'CLKDM_NO_AUTODEP_DISABLE' which does this.
Signed-off-by: Tero Kristo <redacted>
---
arch/arm/mach-omap2/clockdomain.c | 3 +++
arch/arm/mach-omap2/clockdomain.h | 4 ++++
2 files changed, 7 insertions(+), 0 deletions(-)
From: Tero Kristo <hidden> Date: 2012-07-13 14:19:45
Previously, PER clock domain was always enabled, as the usecounts
for this domain incorrectly always showed positive value. On HW
level though, the domain enters idle as it is set in HW supervised
mode. Now, when the usecounts reflect real values, PER domain
will be put to HWSUP sleep mode, which means its autodeps are deleted.
Removing wakedeps for PER domain will cause multiple problems.
First of all, coming back from idle, PER domain remains idle as the
wakedeps have been disabled for the domain, and this causes a crash
with the GPIO code, as the resume code attempts to access domain
which is not active. Just enabling the interface clocks for the GPIO
does not help, as they are autoidled and don't bring the domain out
of idle. Secondly, there are multiple erratas for omap3, which say
that the wakedeps should be enabled for the PER domain, see e.g.
errata i582 for omap3630.
Signed-off-by: Tero Kristo <redacted>
---
arch/arm/mach-omap2/clockdomains3xxx_data.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
On Friday 13 July 2012 07:49 PM, Tero Kristo wrote:
This works similarly to e.g. pwrdm_for_each(). Needed by enhanced
usecounting debug functionality that will be added to pm-debug.
OMAP clock framework has its own debugfs entry (/debug/clock) to expose
usecounts for clocks, so does the COMMON clock framework (/debug/clk).
Maybe there isn't one which dumps usecounts for the complete tree,
instead there is one per each clock node.
I agree having a complete dump of the clock tree usecounts can be
useful, but can we keep it in /debug/clock for now?
The reason I am saying this is because once we move from OMAP clock to
COMMON clock, something like what 'omap_clk_for_each' does will
not be possible anyway. We might have to add the support for
dumping complete tree usecounts into the COMMON clock core.
On Friday 13 July 2012 07:49 PM, Tero Kristo wrote:
This patch fixes the usecount tracking for omap3+, previously the
usecount numbers were rather bogus and were not really useful for
any purpose. Now usecount numbers track the number of really active
clients on each domain. This patch also adds support for usecount
tracking on powerdomain level and autoidle flag for clocks that
are hardware controlled and should be skipped in usecount
calculations.
Signed-off-by: Tero Kristo<redacted>
Cc: Paul Walmsley<paul@pwsan.com>
Cc: Kevin Hilman<redacted>
list_add(&clk->node,&clocks);
+ /*
+ * If clock has no ops, it is handled by hardware and thus will
+ * idle automatically
+ */
+ if (clk->ops ==&clkops_null)
+ clk->autoidle = true;
I was a little skeptical about this when I first saw it. But I am
sure you would have thought through :)
On Friday 13 July 2012 07:49 PM, Tero Kristo wrote:
These are updated based on powerdomain usecounts. Also added support
for voltdm->sleep and voltdm->wakeup calls that will be invoked once
voltagedomain enters sleep or wakes up based on usecount numbers. These
will be used for controlling voltage scaling functionality.
Signed-off-by: Tero Kristo<redacted>
Cc: Paul Walmsley<paul@pwsan.com>
Cc: Kevin Hilman<redacted>
Reviewed-by: Rajendra Nayak <redacted>
I am working on a series to cleanup CPUidle, on top of this series,
where I add similar callbacks at the pwrdm level too. Something like
pwrdm->power_on and pwrdm->power_down. Helps get rid of a lot of
code stuffed inside idle/suspend.
On Friday 13 July 2012 07:49 PM, Tero Kristo wrote:
quoted hunk
mpu / core powerdomain usecounts are now statically increased
by 1 during MPU activity. This allows the domains to reflect
actual usage, and will allow the usecount to reach 0 just before
all CPUs are ready to idle. Proper powerdomain usecounts are
propageted to voltagedomain level also, and will allow vc
callbacks to be triggered at right point of time.
Signed-off-by: Tero Kristo<redacted>
Cc: Paul Walmsley<paul@pwsan.com>
Cc: Kevin Hilman<redacted>
---
arch/arm/mach-omap2/pm34xx.c | 3 ++
arch/arm/mach-omap2/pm44xx.c | 3 ++
arch/arm/mach-omap2/powerdomain.c | 64 +++++++++++++++++++++++++++++++++++++
arch/arm/mach-omap2/powerdomain.h | 3 ++
4 files changed, 73 insertions(+), 0 deletions(-)
@@ -758,6 +758,9 @@ int __init omap3_pm_init(void)omap_pm_suspend=omap3_pm_suspend;#endif+/* Notify pwrdm usecounters about active CPU */+pwrdm_cpu_wakeup();+
These internally increment/decrement usecount for MPU and CORE
but the name pwrdm_cpu_wakeup/idle seems somewhat misleading.
But I don't know either what would be a better name, so..
Reviewed-by: Rajendra Nayak <redacted>
On Friday 13 July 2012 07:49 PM, Tero Kristo wrote:
sdrc_ick doesn't have autoidle flag on HW, but is always automatically
idled. Thus mark the autoidle flag statically as true for it to reflect
hardware behavior. The clock will no longer show as active in usecount
dumps and will allow the voltdm->sleep / wakeup calls to work properly.
Signed-off-by: Tero Kristo<redacted>
Cc: Paul Walmsley<paul@pwsan.com>
Cc: Kevin Hilman<redacted>
On Friday 13 July 2012 07:49 PM, Tero Kristo wrote:
Voltdm, pwrdm, clkdm, hwmod and clk usecounts are now separeted to
their own file, 'usecount'. This file shows the usecounts for every
active domain and their children recursively. 'count' file now only
shows power state counts for powerdomains.
The only comment I had on this patch was what I also said in response
to PATCH 1/8 about keeping the clock usecounts separate if possible.
voltdm, pwrdm, clkdm and hwmod are OMAP specific frameworks (and so is
clock framework for now) but sooner than later we would move to using
COMMON clock framework and then supporting the clock usecounts in
/debug/pm_debug/usecount would not be possible.
quoted hunk
This patch also provices a way to do printk dumps from kernel code,
by calling the pm_dbg_dump_X functions. The plan is to call these
functions once an error condition is detected, e.g. failed suspend.
Signed-off-by: Tero Kristo<redacted>
Cc: Paul Walmsley<paul@pwsan.com>
Cc: Kevin Hilman<redacted>
---
arch/arm/mach-omap2/pm-debug.c | 128 ++++++++++++++++++++++++++++++++++------
arch/arm/mach-omap2/pm.h | 6 ++
2 files changed, 115 insertions(+), 19 deletions(-)
Hi Tero,
On Friday 13 July 2012 07:49 PM, Tero Kristo wrote:
Some clockdomains bug out if their autodeps are deleted before idle.
This happens namely with OMAP3 PER domain, it will bug out if it
doesn't have wakedeps enabled when it enters off-mode. This patch
adds support for new flag 'CLKDM_NO_AUTODEP_DISABLE' which does this.
I had one more thought on how we could handle this (without adding a new
flag :-))
How about marking OMAP3 PER with a CLKDM_NO_AUTODEPS (already existing
flag) and setting a sleep/wakeup dependency of OMAP3 PER with MPU and
IVA one time sometime during late PM init. Because thats what we intent
to do, which is have a sleep/wakeup dependency set *always* and never
try to remove it, right?
regards,
Rajendra
From: Tero Kristo <hidden> Date: 2012-07-16 11:42:51
On Mon, 2012-07-16 at 15:34 +0530, Rajendra Nayak wrote:
On Friday 13 July 2012 07:49 PM, Tero Kristo wrote:
quoted
This works similarly to e.g. pwrdm_for_each(). Needed by enhanced
usecounting debug functionality that will be added to pm-debug.
OMAP clock framework has its own debugfs entry (/debug/clock) to expose
usecounts for clocks, so does the COMMON clock framework (/debug/clk).
Maybe there isn't one which dumps usecounts for the complete tree,
instead there is one per each clock node.
I agree having a complete dump of the clock tree usecounts can be
useful, but can we keep it in /debug/clock for now?
The reason I am saying this is because once we move from OMAP clock to
COMMON clock, something like what 'omap_clk_for_each' does will
not be possible anyway. We might have to add the support for
dumping complete tree usecounts into the COMMON clock core.
The main idea behind the dump was to allow dumping of whole clocktree
status during failed suspend. It is not that useful as a debugfs feature
(you can do the same with some scripts on userspace), but this is
available as a side effect from the suspend dump.
-Tero
From: Tero Kristo <hidden> Date: 2012-07-16 11:45:56
On Mon, 2012-07-16 at 16:20 +0530, Rajendra Nayak wrote:
On Friday 13 July 2012 07:49 PM, Tero Kristo wrote:
quoted
Voltdm, pwrdm, clkdm, hwmod and clk usecounts are now separeted to
their own file, 'usecount'. This file shows the usecounts for every
active domain and their children recursively. 'count' file now only
shows power state counts for powerdomains.
The only comment I had on this patch was what I also said in response
to PATCH 1/8 about keeping the clock usecounts separate if possible.
voltdm, pwrdm, clkdm and hwmod are OMAP specific frameworks (and so is
clock framework for now) but sooner than later we would move to using
COMMON clock framework and then supporting the clock usecounts in
/debug/pm_debug/usecount would not be possible.
Well, I guess we can move these patches to a separate debug set for now
in that case, and people who want to use them can do that.
quoted
This patch also provices a way to do printk dumps from kernel code,
by calling the pm_dbg_dump_X functions. The plan is to call these
functions once an error condition is detected, e.g. failed suspend.
^
|
This part is the main motivation for this patch imo.
-Tero
On Monday 16 July 2012 05:15 PM, Tero Kristo wrote:
quoted
quoted
quoted
>
> This patch also provices a way to do printk dumps from kernel code,
> by calling the pm_dbg_dump_X functions. The plan is to call these
> functions once an error condition is detected, e.g. failed suspend.
^
|
This part is the main motivation for this patch imo.
From: Tero Kristo <hidden> Date: 2012-07-17 14:56:11
On Mon, 2012-07-16 at 16:30 +0530, Rajendra Nayak wrote:
Hi Tero,
On Friday 13 July 2012 07:49 PM, Tero Kristo wrote:
quoted
Some clockdomains bug out if their autodeps are deleted before idle.
This happens namely with OMAP3 PER domain, it will bug out if it
doesn't have wakedeps enabled when it enters off-mode. This patch
adds support for new flag 'CLKDM_NO_AUTODEP_DISABLE' which does this.
I had one more thought on how we could handle this (without adding a new
flag :-))
How about marking OMAP3 PER with a CLKDM_NO_AUTODEPS (already existing
flag) and setting a sleep/wakeup dependency of OMAP3 PER with MPU and
IVA one time sometime during late PM init. Because thats what we intent
to do, which is have a sleep/wakeup dependency set *always* and never
try to remove it, right?
I did some extra investigation on this, sorry for the delay. What is
enough, is to just add a wakedep from wkup_clkdm to per_clkdm, as the
wakedeps have usecounting so once this is done, the autodep handling
can't remove the wakedep.
Anyway, it also looks like this fix is no longer needed with the latest
kernel, something has changed with the gpio code / or latencies and it
doesn't crash anymore. Thus, it looks like patches 7 & 8 can be dropped
from this set for now. This is the behavior with beagleboard at least,
if someone can verify this with some other omap3 hw that would be nice.
The underlying issue still remains, we have errata i582 which doesn't
have any workarounds in the kernel yet. We should probably resurrect
something like this:
http://www.mail-archive.com/linux-omap at vger.kernel.org/msg38834.html
... or just pull the part which adds the dynamic wakedep add / remove
for the per domain when attempting per OFF.
-Tero
The underlying issue still remains, we have errata i582 which doesn't
have any workarounds in the kernel yet. We should probably resurrect
something like this:
http://www.mail-archive.com/linux-omap at vger.kernel.org/msg38834.html
... or just pull the part which adds the dynamic wakedep add / remove
for the per domain when attempting per OFF.
Yep looks like Kevin had some comments on that patch that no one followed
up on. Guess we need to figure out who will have time to revise and
update it.
A few comments on that patch.
1. Looks to me like the patch needs to be split into several smaller
patches. One patch should deal with the serial changes. Another should
deal with the pm34xx.c changes.
2. Looks like we also need a patch to run the McBSP2/3 sidetone
loopback test. Then the pm34xx.c test code would be something like:
if (omap_uart_test_erratum_i582() || omap_mcbsp_test_erratum_i582()) {
pr_err("%s: erratum i582 encountered; applying workaround\n", __func__);
.. etc.
}
3. When the erratum is encountered, shouldn't the code schedule a CORE OFF
transition to occur at the earliest possible moment, rather than just
emitting a message?
4. The bug is only a problem when the PER serial ports/McBSP sidetone
devices are in use, right? So if those devices aren't in use then we can
defer the device tests until right before one of those devices is brought
into use, no?
5. There needs to be a better way of determining if a device is affected
by this than by testing uart->num. Adding a hwmod dev_attr flag would be
my first inclination.
- Paul
On Tuesday 17 July 2012 08:26 PM, Tero Kristo wrote:
Anyway, it also looks like this fix is no longer needed with the latest
kernel, something has changed with the gpio code / or latencies and it
doesn't crash anymore. Thus, it looks like patches 7& 8 can be dropped
from this set for now. This is the behavior with beagleboard at least,
if someone can verify this with some other omap3 hw that would be nice.
I can test it on a omap3 SDP. What do you want me to test?
From: Tero Kristo <hidden> Date: 2012-07-18 08:05:20
On Wed, 2012-07-18 at 12:45 +0530, Rajendra Nayak wrote:
On Tuesday 17 July 2012 08:26 PM, Tero Kristo wrote:
quoted
Anyway, it also looks like this fix is no longer needed with the latest
kernel, something has changed with the gpio code / or latencies and it
doesn't crash anymore. Thus, it looks like patches 7& 8 can be dropped
from this set for now. This is the behavior with beagleboard at least,
if someone can verify this with some other omap3 hw that would be nice.
I can test it on a omap3 SDP. What do you want me to test?
Just try suspend + cpuidle with and without off-mode enabled and see if
there are any problems. I've usually seen problems with off-mode myself.
-Tero
On Wednesday 18 July 2012 01:35 PM, Tero Kristo wrote:
On Wed, 2012-07-18 at 12:45 +0530, Rajendra Nayak wrote:
quoted
On Tuesday 17 July 2012 08:26 PM, Tero Kristo wrote:
quoted
Anyway, it also looks like this fix is no longer needed with the latest
kernel, something has changed with the gpio code / or latencies and it
doesn't crash anymore. Thus, it looks like patches 7& 8 can be dropped
from this set for now. This is the behavior with beagleboard at least,
if someone can verify this with some other omap3 hw that would be nice.
I can test it on a omap3 SDP. What do you want me to test?
Just try suspend + cpuidle with and without off-mode enabled and see if
there are any problems. I've usually seen problems with off-mode myself.
So I just knocked off the last 2 patches from 'mainline-3.5-rc6-pwrdm-
changes-v4' and tested on my 3430 SDP.
I was able to hit RET and OFF in both suspend and cpuidle. Did not see
any issues.
From: Tero Kristo <hidden> Date: 2012-07-18 09:16:08
On Wed, 2012-07-18 at 14:34 +0530, Rajendra Nayak wrote:
On Wednesday 18 July 2012 01:35 PM, Tero Kristo wrote:
quoted
On Wed, 2012-07-18 at 12:45 +0530, Rajendra Nayak wrote:
quoted
On Tuesday 17 July 2012 08:26 PM, Tero Kristo wrote:
quoted
Anyway, it also looks like this fix is no longer needed with the latest
kernel, something has changed with the gpio code / or latencies and it
doesn't crash anymore. Thus, it looks like patches 7& 8 can be dropped
from this set for now. This is the behavior with beagleboard at least,
if someone can verify this with some other omap3 hw that would be nice.
I can test it on a omap3 SDP. What do you want me to test?
Just try suspend + cpuidle with and without off-mode enabled and see if
there are any problems. I've usually seen problems with off-mode myself.
So I just knocked off the last 2 patches from 'mainline-3.5-rc6-pwrdm-
changes-v4' and tested on my 3430 SDP.
I was able to hit RET and OFF in both suspend and cpuidle. Did not see
any issues.
-----Original Message-----
From: linux-omap-owner at vger.kernel.org [mailto:linux-omap-
owner at vger.kernel.org] On Behalf Of Tero Kristo
Sent: Friday, July 13, 2012 9:20 AM
To: linux-omap at vger.kernel.org; paul at pwsan.com; khilman at ti.com
Cc: linux-arm-kernel at lists.infradead.org
Subject: [PATCHv4 3/8] ARM: OMAP3+: voltage: add support for
voltagedomain usecounts
These are updated based on powerdomain usecounts. Also added support
for voltdm->sleep and voltdm->wakeup calls that will be invoked once
voltagedomain enters sleep or wakes up based on usecount numbers.
These
will be used for controlling voltage scaling functionality.
Signed-off-by: Tero Kristo <redacted>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <redacted>
---
arch/arm/mach-omap2/powerdomain.c | 6 +++-
arch/arm/mach-omap2/voltage.c | 56
+++++++++++++++++++++++++++++++++++++
arch/arm/mach-omap2/voltage.h | 11 +++++++
3 files changed, 72 insertions(+), 1 deletions(-)
@@ -340,6 +341,61 @@ int voltdm_add_pwrdm(struct voltagedomain
*voltdm, struct powerdomain *pwrdm)
}
/**
+ * voltdm_pwrdm_enable - increase usecount for a voltagedomain
+ * @voltdm: struct voltagedomain * to increase count for
+ *
+ * Increases usecount for a given voltagedomain. If the usecount
reaches
+ * 1, the domain is awakened from idle and the function will call
the
+ * voltagedomain->wakeup callback for this domain.
+ */
+void voltdm_pwrdm_enable(struct voltagedomain *voltdm)
+{
+ if (!voltdm)
+ return;
+
+ if (atomic_inc_return(&voltdm->usecount) == 1) {
+ if (voltdm->wakeup)
+ voltdm->wakeup(voltdm);
+ }
+}
I think these usecounting functions are prone to race conditions and need
to be protected using spin_lock or something like that (not just the
usecounter). Otherwise right sequence will not be followed when multiple
modules try to idle and enable simultaneously. You can see this issue when
2 cpus enter idle independently.
Regards
Vishwa
quoted hunk
+
+/**
+ * voltdm_pwrdm_disable - decrease usecount for a voltagedomain
+ * @voltdm: struct voltagedomain * to decrease count for
+ *
+ * Decreases the usecount for a given voltagedomain. If the
usecount
+ * reaches zero, the domain can idle and the function will call the
+ * voltagedomain->sleep callback, and calculate the overall target
+ * state for the voltagedomain.
+ */
+void voltdm_pwrdm_disable(struct voltagedomain *voltdm)
+{
+ u8 target_state = PWRDM_POWER_OFF;
+ int state;
+ struct powerdomain *pwrdm;
+ int val;
+
+ if (!voltdm)
+ return;
+
+ val = atomic_dec_return(&voltdm->usecount);
+
+ BUG_ON(val < 0);
+
+ if (val == 0) {
+ /* Determine target state for voltdm */
+ list_for_each_entry(pwrdm, &voltdm->pwrdm_list,
voltdm_node) {
+ state = pwrdm_read_next_pwrst(pwrdm);
+ if (state > target_state)
+ target_state = state;
+ }
+ voltdm->target_state = target_state;
+ if (voltdm->sleep)
+ voltdm->sleep(voltdm);
+ }
+}
+
+/**
* voltdm_for_each_pwrdm - call function for each pwrdm in a voltdm
* @voltdm: struct voltagedomain * to iterate over
* @fn: callback function *
voltagedomain
* @vc: pointer to VC channel associated with this voltagedomain
* @vp: pointer to VP associated with this voltagedomain
+ * @usecount: number of users for this voltagedomain
+ * @target_state: calculated target state for the children of this
domain
* @read: read a VC/VP register
* @write: write a VC/VP register
* @read: read-modify-write a VC/VP register
* @sys_clk: system clock name/frequency, used for various timing
calculations
+ * @sleep: function to call once the domain enters idle
+ * @wakeup: function to call once the domain wakes up from idle
* @scale: function used to scale the voltage of the voltagedomain
* @nominal_volt: current nominal voltage for this voltage domain
* @volt_data: voltage table having the distinct voltages supported
powerdomain *pwrdm);
+void voltdm_pwrdm_enable(struct voltagedomain *voltdm);
+void voltdm_pwrdm_disable(struct voltagedomain *voltdm);
int voltdm_for_each(int (*fn)(struct voltagedomain *voltdm, void
*user),
void *user);
int voltdm_for_each_pwrdm(struct voltagedomain *voltdm,
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-
omap" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Tero Kristo <hidden> Date: 2012-07-25 08:07:50
On Tue, 2012-07-24 at 15:58 -0500, Vishwanath Sripathy wrote:
Tero,
quoted
-----Original Message-----
From: linux-omap-owner at vger.kernel.org [mailto:linux-omap-
owner at vger.kernel.org] On Behalf Of Tero Kristo
Sent: Friday, July 13, 2012 9:20 AM
To: linux-omap at vger.kernel.org; paul at pwsan.com; khilman at ti.com
Cc: linux-arm-kernel at lists.infradead.org
Subject: [PATCHv4 3/8] ARM: OMAP3+: voltage: add support for
voltagedomain usecounts
These are updated based on powerdomain usecounts. Also added support
for voltdm->sleep and voltdm->wakeup calls that will be invoked once
voltagedomain enters sleep or wakes up based on usecount numbers.
These
will be used for controlling voltage scaling functionality.
Signed-off-by: Tero Kristo <redacted>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <redacted>
---
arch/arm/mach-omap2/powerdomain.c | 6 +++-
arch/arm/mach-omap2/voltage.c | 56
+++++++++++++++++++++++++++++++++++++
arch/arm/mach-omap2/voltage.h | 11 +++++++
3 files changed, 72 insertions(+), 1 deletions(-)
@@ -340,6 +341,61 @@ int voltdm_add_pwrdm(struct voltagedomain
*voltdm, struct powerdomain *pwrdm)
}
/**
+ * voltdm_pwrdm_enable - increase usecount for a voltagedomain
+ * @voltdm: struct voltagedomain * to increase count for
+ *
+ * Increases usecount for a given voltagedomain. If the usecount
reaches
+ * 1, the domain is awakened from idle and the function will call
the
+ * voltagedomain->wakeup callback for this domain.
+ */
+void voltdm_pwrdm_enable(struct voltagedomain *voltdm)
+{
+ if (!voltdm)
+ return;
+
+ if (atomic_inc_return(&voltdm->usecount) == 1) {
+ if (voltdm->wakeup)
+ voltdm->wakeup(voltdm);
+ }
+}
I think these usecounting functions are prone to race conditions and need
to be protected using spin_lock or something like that (not just the
usecounter). Otherwise right sequence will not be followed when multiple
modules try to idle and enable simultaneously. You can see this issue when
2 cpus enter idle independently.
Yes, you are right... something like this needs to be added for SMP once
individual cpuidle is in place. I'll add this kind of fix for the next
version.
-Tero
Hi Tero,
just looking at the usecounting series to see what is mergeable and
noticed this:
On Fri, 13 Jul 2012, Tero Kristo wrote:
Secondly, there are multiple erratas for omap3, which say that the
wakedeps should be enabled for the PER domain, see e.g. errata i582 for
omap3630.
Erratum i582 mentions that a wakeup dependency needs to exist between PER
and WKUP such that PER will wake when CORE_L3 does. Our autodeps would
not add this dependency; they just would attempt to add a wakeup
dependency between PER and MPU/IVA2. So we need a different mechanism.
What do you think about the following patch to handle part of the i582
workaround?
Also, do you have any of the other errata information handy, so we can
track those down also? I'm pretty sure we need to enable the wakeup
dependency between PER and CORE also for OMAP3, but can't recall the
reference.
- Paul
From: Paul Walmsley <paul@pwsan.com>
Date: Tue, 18 Sep 2012 16:02:38 -0600
Subject: [PATCH] ARM: OMAP36xx: PM: apply part of the erratum i582 workaround
On OMAP36xx chips with ES < 1.2, if the PER powerdomain goes to OSWR
or OFF while CORE stays at CSWR or ON, or if, upon chip wakeup from
OSWR or OFF, the CORE powerdomain goes ON before PER, the UART3/4
FIFOs and McBSP2/3 SIDETONE memories will be unusable. This is
erratum i582 in the OMAP36xx Silicon Errata document.
This patch implements one of several parts of the workaround: the
addition of the wakeup dependency between the PER and WKUP
clockdomains, such that PER will wake up at the same time CORE_L3
does.
This is not a complete workaround. For it to be complete:
1. the PER powerdomain's next power state must not be set to OSWR or
OFF if the CORE powerdomain's next power state is set to CSWR or
ON;
2. the UART3/4 FIFO and McBSP2/3 SIDETONE loopback tests should be run
if the LASTPOWERSTATEENTERED bits for PER and CORE indicate that
PER went OFF while CORE stayed on. If loopback tests fail, then
those devices will be unusable until PER and CORE can undergo a
transition from ON to OSWR/OFF and back ON.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Tero Kristo <redacted>
Cc: Kevin Hilman <redacted>
---
arch/arm/mach-omap2/pm.h | 1 +
arch/arm/mach-omap2/pm34xx.c | 24 +++++++++++++++++++++++-
2 files changed, 24 insertions(+), 1 deletion(-)
@@ -651,7 +651,8 @@ static void __init pm_errata_configure(void)/* Enable the l2 cache toggling in sleep logic */enable_omap3630_toggle_l2_on_restore();if(omap_rev()<OMAP3630_REV_ES1_2)-pm34xx_errata|=PM_SDRC_WAKEUP_ERRATUM_i583;+pm34xx_errata|=(PM_SDRC_WAKEUP_ERRATUM_i583|+PM_PER_ERRATUM_i582);}}
@@ -726,6 +727,27 @@ int __init omap3_pm_init(void)if(IS_PM34XX_ERRATUM(PM_RTA_ERRATUM_i608))omap3630_ctrl_disable_rta();+/*+*TheUART3/4FIFOandthesidetonememoryinMcBSP2/3are+*notcorrectlyresetwhenthePERpowerdomaincomesback+*fromOFForOSWRwhentheCOREpowerdomainiskeptactive.+*SeeOMAP36xxErratumi582"PER Domain reset issue after+*Domain-OFF/OSWRWakeup". This wakeup dependency is not a+*completeworkaround.ThekernelmustalsopreventthePER+*powerdomainfromgoingtoOSWR/OFFwhiletheCORE+*powerdomainisnotgoingtoOSWR/OFF.AndifPERlast+*powerstatewasoffwhileCORElastpowerstatewasON,the+*UART3/4andMcBSP2/3SIDETONEdevicesneedtoruna+*self-testusingtheirloopbacktests;ifthatfails,those+*devicesareunusableuntilthePER/COREcancompleteatransition+*fromONtoOSWR/OFFandthenbacktoON.+*+*XXXTechnicallythisworkaroundisonlyneededifoff-mode+*orOSWRisenabled.+*/+if(IS_PM34XX_ERRATUM(PM_PER_MEMORIES_ERRATUM_i582))+clkdm_add_wkdep(per_clkdm,wkup_clkdm);+clkdm_add_wkdep(neon_clkdm,mpu_clkdm);if(omap_type()!=OMAP2_DEVICE_TYPE_GP){omap3_secure_ram_storage=
What do you think about the following patch to handle part of the i582
workaround?
That patch was an older version; here's one that builds and boots - sorry
about that. It passed the basic PM tests here on 3730ES1.0 Beagle XM and
3730ES1.2 EVM.
Kevin, care to ack it if you're happy with it? We still need to get the
other parts of the i582 workaround into place, of course...
- Paul
From: Paul Walmsley <paul@pwsan.com>
Date: Tue, 18 Sep 2012 16:02:38 -0600
Subject: [PATCH] ARM: OMAP36xx: PM: apply part of the erratum i582 workaround
On OMAP36xx chips with ES < 1.2, if the PER powerdomain goes to OSWR
or OFF while CORE stays at CSWR or ON, or if, upon chip wakeup from
OSWR or OFF, the CORE powerdomain goes ON before PER, the UART3/4
FIFOs and McBSP2/3 SIDETONE memories will be unusable. This is
erratum i582 in the OMAP36xx Silicon Errata document.
This patch implements one of several parts of the workaround: the
addition of the wakeup dependency between the PER and WKUP
clockdomains, such that PER will wake up at the same time CORE_L3
does.
This is not a complete workaround. For it to be complete:
1. the PER powerdomain's next power state must not be set to OSWR or
OFF if the CORE powerdomain's next power state is set to CSWR or
ON;
2. the UART3/4 FIFO and McBSP2/3 SIDETONE loopback tests should be run
if the LASTPOWERSTATEENTERED bits for PER and CORE indicate that
PER went OFF while CORE stayed on. If loopback tests fail, then
those devices will be unusable until PER and CORE can undergo a
transition from ON to OSWR/OFF and back ON.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Tero Kristo <redacted>
Cc: Kevin Hilman <redacted>
---
arch/arm/mach-omap2/pm.h | 1 +
arch/arm/mach-omap2/pm34xx.c | 28 ++++++++++++++++++++++++++--
2 files changed, 27 insertions(+), 2 deletions(-)
@@ -651,14 +651,15 @@ static void __init pm_errata_configure(void)/* Enable the l2 cache toggling in sleep logic */enable_omap3630_toggle_l2_on_restore();if(omap_rev()<OMAP3630_REV_ES1_2)-pm34xx_errata|=PM_SDRC_WAKEUP_ERRATUM_i583;+pm34xx_errata|=(PM_SDRC_WAKEUP_ERRATUM_i583|+PM_PER_MEMORIES_ERRATUM_i582);}}int__initomap3_pm_init(void){structpower_state*pwrst,*tmp;-structclockdomain*neon_clkdm,*mpu_clkdm;+structclockdomain*neon_clkdm,*mpu_clkdm,*per_clkdm,*wkup_clkdm;intret;if(!omap3_has_io_chain_ctrl())
@@ -710,6 +711,8 @@ int __init omap3_pm_init(void)neon_clkdm=clkdm_lookup("neon_clkdm");mpu_clkdm=clkdm_lookup("mpu_clkdm");+per_clkdm=clkdm_lookup("per_clkdm");+wkup_clkdm=clkdm_lookup("wkup_clkdm");#ifdef CONFIG_SUSPENDomap_pm_suspend=omap3_pm_suspend;
@@ -726,6 +729,27 @@ int __init omap3_pm_init(void)if(IS_PM34XX_ERRATUM(PM_RTA_ERRATUM_i608))omap3630_ctrl_disable_rta();+/*+*TheUART3/4FIFOandthesidetonememoryinMcBSP2/3are+*notcorrectlyresetwhenthePERpowerdomaincomesback+*fromOFForOSWRwhentheCOREpowerdomainiskeptactive.+*SeeOMAP36xxErratumi582"PER Domain reset issue after+*Domain-OFF/OSWRWakeup". This wakeup dependency is not a+*completeworkaround.ThekernelmustalsopreventthePER+*powerdomainfromgoingtoOSWR/OFFwhiletheCORE+*powerdomainisnotgoingtoOSWR/OFF.AndifPERlast+*powerstatewasoffwhileCORElastpowerstatewasON,the+*UART3/4andMcBSP2/3SIDETONEdevicesneedtoruna+*self-testusingtheirloopbacktests;ifthatfails,those+*devicesareunusableuntilthePER/COREcancompleteatransition+*fromONtoOSWR/OFFandthenbacktoON.+*+*XXXTechnicallythisworkaroundisonlyneededifoff-mode+*orOSWRisenabled.+*/+if(IS_PM34XX_ERRATUM(PM_PER_MEMORIES_ERRATUM_i582))+clkdm_add_wkdep(per_clkdm,wkup_clkdm);+clkdm_add_wkdep(neon_clkdm,mpu_clkdm);if(omap_type()!=OMAP2_DEVICE_TYPE_GP){omap3_secure_ram_storage=
From: Tero Kristo <hidden> Date: 2012-09-19 09:06:19
On Tue, 2012-09-18 at 22:25 +0000, Paul Walmsley wrote:
Hi Tero,
just looking at the usecounting series to see what is mergeable and
noticed this:
On Fri, 13 Jul 2012, Tero Kristo wrote:
quoted
Secondly, there are multiple erratas for omap3, which say that the
wakedeps should be enabled for the PER domain, see e.g. errata i582 for
omap3630.
Erratum i582 mentions that a wakeup dependency needs to exist between PER
and WKUP such that PER will wake when CORE_L3 does. Our autodeps would
not add this dependency; they just would attempt to add a wakeup
dependency between PER and MPU/IVA2. So we need a different mechanism.
What do you think about the following patch to handle part of the i582
workaround?
Yes, that looks good to me, someone will need to test it though.
Also, do you have any of the other errata information handy, so we can
track those down also? I'm pretty sure we need to enable the wakeup
dependency between PER and CORE also for OMAP3, but can't recall the
reference.
GPIO errata i467 has a workaround which involves wakedeps. i582 is valid
for omap3430 also. I am not able to find anything else regarding
wakedeps right now, at least nothing regarding per vs core.
-Tero
quoted hunk
- Paul
From: Paul Walmsley <paul@pwsan.com>
Date: Tue, 18 Sep 2012 16:02:38 -0600
Subject: [PATCH] ARM: OMAP36xx: PM: apply part of the erratum i582 workaround
On OMAP36xx chips with ES < 1.2, if the PER powerdomain goes to OSWR
or OFF while CORE stays at CSWR or ON, or if, upon chip wakeup from
OSWR or OFF, the CORE powerdomain goes ON before PER, the UART3/4
FIFOs and McBSP2/3 SIDETONE memories will be unusable. This is
erratum i582 in the OMAP36xx Silicon Errata document.
This patch implements one of several parts of the workaround: the
addition of the wakeup dependency between the PER and WKUP
clockdomains, such that PER will wake up at the same time CORE_L3
does.
This is not a complete workaround. For it to be complete:
1. the PER powerdomain's next power state must not be set to OSWR or
OFF if the CORE powerdomain's next power state is set to CSWR or
ON;
2. the UART3/4 FIFO and McBSP2/3 SIDETONE loopback tests should be run
if the LASTPOWERSTATEENTERED bits for PER and CORE indicate that
PER went OFF while CORE stayed on. If loopback tests fail, then
those devices will be unusable until PER and CORE can undergo a
transition from ON to OSWR/OFF and back ON.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Tero Kristo <redacted>
Cc: Kevin Hilman <redacted>
---
arch/arm/mach-omap2/pm.h | 1 +
arch/arm/mach-omap2/pm34xx.c | 24 +++++++++++++++++++++++-
2 files changed, 24 insertions(+), 1 deletion(-)
@@ -651,7 +651,8 @@ static void __init pm_errata_configure(void)/* Enable the l2 cache toggling in sleep logic */enable_omap3630_toggle_l2_on_restore();if(omap_rev()<OMAP3630_REV_ES1_2)-pm34xx_errata|=PM_SDRC_WAKEUP_ERRATUM_i583;+pm34xx_errata|=(PM_SDRC_WAKEUP_ERRATUM_i583|+PM_PER_ERRATUM_i582);}}
@@ -726,6 +727,27 @@ int __init omap3_pm_init(void)if(IS_PM34XX_ERRATUM(PM_RTA_ERRATUM_i608))omap3630_ctrl_disable_rta();+/*+*TheUART3/4FIFOandthesidetonememoryinMcBSP2/3are+*notcorrectlyresetwhenthePERpowerdomaincomesback+*fromOFForOSWRwhentheCOREpowerdomainiskeptactive.+*SeeOMAP36xxErratumi582"PER Domain reset issue after+*Domain-OFF/OSWRWakeup". This wakeup dependency is not a+*completeworkaround.ThekernelmustalsopreventthePER+*powerdomainfromgoingtoOSWR/OFFwhiletheCORE+*powerdomainisnotgoingtoOSWR/OFF.AndifPERlast+*powerstatewasoffwhileCORElastpowerstatewasON,the+*UART3/4andMcBSP2/3SIDETONEdevicesneedtoruna+*self-testusingtheirloopbacktests;ifthatfails,those+*devicesareunusableuntilthePER/COREcancompleteatransition+*fromONtoOSWR/OFFandthenbacktoON.+*+*XXXTechnicallythisworkaroundisonlyneededifoff-mode+*orOSWRisenabled.+*/+if(IS_PM34XX_ERRATUM(PM_PER_MEMORIES_ERRATUM_i582))+clkdm_add_wkdep(per_clkdm,wkup_clkdm);+clkdm_add_wkdep(neon_clkdm,mpu_clkdm);if(omap_type()!=OMAP2_DEVICE_TYPE_GP){omap3_secure_ram_storage=