OMAP Cpuidle/Suspend Cleanups

We do not support MPU OSWR on OMAP3. Get rid of the complex/multiple save_state handling in omap_sram_idle() and just use 2 save_state definitions

save_state = 1, all logic and memory lost, MPU hits OFF save_state = 0, nothing lost, MPU hits CSWR or shallower state

Signed-off-by Rajendra Nayak <[email protected]>

---
 arch/arm/mach-omap2/pm34xx.c    |   35 +++++++++--------------------------
 arch/arm/mach-omap2/sleep34xx.S |    4 +---
 2 files changed, 10 insertions(+), 29 deletions(-)

arch/arm/mach-omap2/pm34xx.c +0 -0

index 7c7b173..8d96b1f 100644

We do not support MPU OSWR on OMAP3. Get rid of the complex/multiple save_state handling in omap_sram_idle() and just use 2 save_state definitions

save_state = 1, all logic and memory lost, MPU hits OFF save_state = 0, nothing lost, MPU hits CSWR or shallower state

Signed-off-by Rajendra Nayak <[email protected]>

Quoted 4 lines · Rajendra Nayak

We do not support MPU OSWR on OMAP3. Get rid of the complex/multiple save_state handling in omap_sram_idle() and just use 2 save_state definitions

Quoted 4 lines

save_state = 1, all logic and memory lost, MPU hits OFF save_state = 0, nothing lost, MPU hits CSWR or shallower state

Signed-off-by Rajendra Nayak<[email protected]>

The code is certainly simpler, but I recall seeing patchsets in the past that implemented OSWR on OMAP3. (Not sure which powerdomains it was implemented for.) Do you know what the status of those patchsets are?

- Paul

pwrdm_pre_transition()/pwrdm_post_transition() have always been high latency operations done within cpuidle to do Powerdomain level book-keeping to know what state transitions for different Powerdomains have been triggered. This is also useful to do a restore-on-demand in some cases when we know the context for the given Powerdomain was lost etc.

Now that we have definitive entry/exit points (thanks to the Powerdomain level usecounting) for Powerdomain transitions, these book-keeping functions can very well be moved from within CPUidle into pwrdm_clkdm_enable()/pwrdm_ clkdm_disable() functions.

Also rename _pwrdm_pre/post_transition_cb() to pwrdm_pre/post_transition() and get rid of the original ones which iterate over all powerdomains.

Signed-off-by Rajendra Nayak <[email protected]>

---
 arch/arm/mach-omap2/omap-mpuss-lowpower.c |    4 ++--
 arch/arm/mach-omap2/pm34xx.c              |    4 ++--
 arch/arm/mach-omap2/powerdomain.c         |   28 ++++++++--------------------
 arch/arm/mach-omap2/powerdomain.h         |    4 ++--
 4 files changed, 14 insertions(+), 26 deletions(-)

arch/arm/mach-omap2/omap-mpuss-lowpower.c +0 -0

index 13670aa..ea19439 100644

Quoted 30 lines · Rajendra Nayak

pwrdm_pre_transition()/pwrdm_post_transition() have always been high latency operations done within cpuidle to do Powerdomain level book-keeping to know what state transitions for different Powerdomains have been triggered. This is also useful to do a restore-on-demand in some cases when we know the context for the given Powerdomain was lost etc.

Now that we have definitive entry/exit points (thanks to the Powerdomain level usecounting) for Powerdomain transitions, these book-keeping functions can very well be moved from within CPUidle into pwrdm_clkdm_enable()/pwrdm_ clkdm_disable() functions.

Also rename _pwrdm_pre/post_transition_cb() to pwrdm_pre/post_transition() and get rid of the original ones which iterate over all powerdomains.

Signed-off-by Rajendra Nayak<[email protected]>

---
  arch/arm/mach-omap2/omap-mpuss-lowpower.c |    4 ++--
  arch/arm/mach-omap2/pm34xx.c              |    4 ++--
  arch/arm/mach-omap2/powerdomain.c         |   28 ++++++++--------------------
  arch/arm/mach-omap2/powerdomain.h         |    4 ++--
  4 files changed, 14 insertions(+), 26 deletions(-)

arch/arm/mach-omap2/omap-mpuss-lowpower.c +0 -0

index 13670aa..ea19439 100644
@@ -255,7 +255,7 @@ int omap4_enter_lowpower(unsigned int cpu, unsigned int power_state)
                 return -ENXIO;
         }
 

arch/arm/mach-omap2/omap-mpuss-lowpower.c int omap4_enter_lowpower(unsigned int cpu, unsigned int power_state) · line 259

Quoted 3 lines

arch/arm/mach-omap2/omap-mpuss-lowpower.c +1 -1

-       pwrdm_pre_transition();
+       pwrdm_cpu_idle();
 

Glad to see this is getting optimized.
I haven't seen how "pwrdm_cpu_[idle/wakeup]()" is implemented but will those work on SMP system ? I mean OMAP4, any CPU can make this call ?

Regards
Santosh

Quoted 31 lines · Santosh

Quoted 30 lines · Rajendra Nayak

pwrdm_pre_transition()/pwrdm_post_transition() have always been high latency operations done within cpuidle to do Powerdomain level book-keeping to know what state transitions for different Powerdomains have been triggered. This is also useful to do a restore-on-demand in some cases when we know the context for the given Powerdomain was lost etc.

Now that we have definitive entry/exit points (thanks to the Powerdomain level usecounting) for Powerdomain transitions, these book-keeping functions can very well be moved from within CPUidle into pwrdm_clkdm_enable()/pwrdm_ clkdm_disable() functions.

Also rename _pwrdm_pre/post_transition_cb() to pwrdm_pre/post_transition() and get rid of the original ones which iterate over all powerdomains.

Signed-off-by Rajendra Nayak<[email protected]>

---
  arch/arm/mach-omap2/omap-mpuss-lowpower.c |    4 ++--
  arch/arm/mach-omap2/pm34xx.c              |    4 ++--
  arch/arm/mach-omap2/powerdomain.c         |   28 ++++++++--------------------
  arch/arm/mach-omap2/powerdomain.h         |    4 ++--
  4 files changed, 14 insertions(+), 26 deletions(-)

arch/arm/mach-omap2/omap-mpuss-lowpower.c +0 -0

index 13670aa..ea19439 100644
@@ -255,7 +255,7 @@ int omap4_enter_lowpower(unsigned int cpu, unsigned int power_state)
                 return -ENXIO;
         }
 

Quoted 7 lines

arch/arm/mach-omap2/omap-mpuss-lowpower.c int omap4_enter_lowpower(unsigned int cpu, unsigned int power_state) · line 259

Quoted 3 lines

arch/arm/mach-omap2/omap-mpuss-lowpower.c +1 -1

-       pwrdm_pre_transition();
+       pwrdm_cpu_idle();
 

Glad to see this is getting optimized.
I haven't seen how "pwrdm_cpu_[idle/wakeup]()" is implemented but will those work on SMP system ? I mean OMAP4, any CPU can make this call ?

Thats a good question. I think Tero did this so he can kick in voltage transitions at the right time in idle/suspend. Given that these deal with incrementing/decrementing the MPU and CORE pwrdm usecounts alone, maybe on OMAP4 (SMP systems) this needs to also increment/decrement the specific CPU usecounts on the CPUs these calls are made.

Quoted 52 lines · Rajendra Nayak

Quoted 43 lines · Santosh

Quoted 41 lines · Rajendra Nayak

pwrdm_pre_transition()/pwrdm_post_transition() have always been high latency
operations done within cpuidle to do Powerdomain level book-keeping to know
what state transitions for different Powerdomains have been triggered.
This is also useful to do a restore-on-demand in some cases when we know
the context for the given Powerdomain was lost etc.

Now that we have definitive entry/exit points (thanks to the Powerdomain
level usecounting) for Powerdomain transitions, these book-keeping functions
can very well be moved from within CPUidle into pwrdm_clkdm_enable()/pwrdm_
clkdm_disable() functions.

Also rename _pwrdm_pre/post_transition_cb() to pwrdm_pre/post_transition()
and get rid of the original ones which iterate over all powerdomains.

Signed-off-by Rajendra Nayak<[email protected]>

---
  arch/arm/mach-omap2/omap-mpuss-lowpower.c |    4 ++--
  arch/arm/mach-omap2/pm34xx.c              |    4 ++--
  arch/arm/mach-omap2/powerdomain.c         |   28
++++++++--------------------
  arch/arm/mach-omap2/powerdomain.h         |    4 ++--
  4 files changed, 14 insertions(+), 26 deletions(-)

arch/arm/mach-omap2/omap-mpuss-lowpower.c +0 -0

index 13670aa..ea19439 100644
@@ -255,7 +255,7 @@ int omap4_enter_lowpower(unsigned int cpu,
 unsigned int power_state)
                 return -ENXIO;
         }
 

Quoted 7 lines

arch/arm/mach-omap2/omap-mpuss-lowpower.c int omap4_enter_lowpower(unsigned int cpu, unsigned int power_state) · line 259

Quoted 3 lines

arch/arm/mach-omap2/omap-mpuss-lowpower.c +1 -1

-       pwrdm_pre_transition();
+       pwrdm_cpu_idle();
 

Glad to see this is getting optimized.
I haven't seen how "pwrdm_cpu_[idle/wakeup]()" is implemented but will those work on SMP system ? I mean OMAP4, any CPU can make this call ?

Quoted 6 lines

Thats a good question. I think Tero did this so he can kick in voltage transitions at the right time in idle/suspend. Given that these deal with incrementing/decrementing the MPU and CORE pwrdm usecounts alone, maybe on OMAP4 (SMP systems) this needs to also increment/decrement the specific CPU usecounts on the CPUs these calls are made.

Yeah, you should keep the usecounts valid by each cpu separately calling these functions. My current set only sets these usecounts based on cpu0 activity, as cpu1 is statically controlled through cpu online / offline. Once per-cpu cpuidle is in, these should be changed so that each individual cpu increases the usecounts when they are brought up, decrease/increase during idle, and decrease when they are brought down. The usecount should always reflect the number of CPUs active on MPU domain.

Quoted 13 lines · Rajendra Nayak

Quoted 12 lines · Santosh

Quoted 11 lines · Rajendra Nayak

pwrdm_pre_transition()/pwrdm_post_transition() have always been high latency operations done within cpuidle to do Powerdomain level book-keeping to know what state transitions for different Powerdomains have been triggered. This is also useful to do a restore-on-demand in some cases when we know the context for the given Powerdomain was lost etc.

Now that we have definitive entry/exit points (thanks to the Powerdomain level usecounting) for Powerdomain transitions, these book-keeping functions can very well be moved from within CPUidle into pwrdm_clkdm_enable()/pwrdm_ clkdm_disable() functions.

Quoted 4 lines

Quoted 4 lines

Quoted 4 lines

Also rename _pwrdm_pre/post_transition_cb() to pwrdm_pre/post_transition() and get rid of the original ones which iterate over all powerdomains.

Signed-off-by Rajendra Nayak<[email protected]>

Quoted 11 lines

Quoted 4 lines

Glad to see this is getting optimized.
I haven't seen how "pwrdm_cpu_[idle/wakeup]()" is implemented but will those work on SMP system ? I mean OMAP4, any CPU can make this call ?

Thats a good question. I think Tero did this so he can kick in voltage transitions at the right time in idle/suspend. Given that these deal with incrementing/decrementing the MPU and CORE pwrdm usecounts alone, maybe on OMAP4 (SMP systems) this needs to also increment/decrement the specific CPU usecounts on the CPUs these calls are made.

Yeah, you should keep the usecounts valid by each cpu separately calling these functions. My current set only sets these usecounts based on cpu0 activity, as cpu1 is statically controlled through cpu online / offline. Once per-cpu cpuidle is in, these should be changed so that each individual cpu increases the usecounts when they are brought up, decrease/increase during idle, and decrease when they are brought down. The usecount should always reflect the number of CPUs active on MPU domain.

Quoted 17 lines · Tero Kristo

Quoted 17 lines · Rajendra Nayak

Quoted 16 lines

Quoted 16 lines · Santosh

Quoted 15 lines

Quoted 15 lines · Rajendra Nayak

Quoted 14 lines

Quoted 14 lines

pwrdm_pre_transition()/pwrdm_post_transition() have always been high latency operations done within cpuidle to do Powerdomain level book-keeping to know what state transitions for different Powerdomains have been triggered. This is also useful to do a restore-on-demand in some cases when we know the context for the given Powerdomain was lost etc.

Now that we have definitive entry/exit points (thanks to the Powerdomain level usecounting) for Powerdomain transitions, these book-keeping functions can very well be moved from within CPUidle into pwrdm_clkdm_enable()/pwrdm_ clkdm_disable() functions.

Also rename _pwrdm_pre/post_transition_cb() to pwrdm_pre/post_transition() and get rid of the original ones which iterate over all powerdomains.

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Signed-off-by Rajendra Nayak<[email protected]>

This is excellent! Thanks for working on this.

However, it needs a rebase against mainline though because I merged a set of optimizations[1] to this code already that only calls pre/post per-pwrdm.

Quoted 17 lines · Tero Kristo

Quoted 16 lines · Rajendra Nayak

Quoted 15 lines · Santosh

Quoted 14 lines · Rajendra Nayak

pwrdm_pre_transition()/pwrdm_post_transition() have always been high latency operations done within cpuidle to do Powerdomain level book-keeping to know what state transitions for different Powerdomains have been triggered. This is also useful to do a restore-on-demand in some cases when we know the context for the given Powerdomain was lost etc.

Now that we have definitive entry/exit points (thanks to the Powerdomain level usecounting) for Powerdomain transitions, these book-keeping functions can very well be moved from within CPUidle into pwrdm_clkdm_enable()/pwrdm_ clkdm_disable() functions.

Also rename _pwrdm_pre/post_transition_cb() to pwrdm_pre/post_transition() and get rid of the original ones which iterate over all powerdomains.

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Signed-off-by Rajendra Nayak<[email protected]>

This is excellent! Thanks for working on this.

However, it needs a rebase against mainline though because I merged a set of optimizations[1] to this code already that only calls pre/post per-pwrdm.

Quoted 19 lines · Kevin Hilman

Quoted 17 lines · Tero Kristo

Quoted 16 lines · Rajendra Nayak

Quoted 15 lines · Santosh

Quoted 14 lines · Rajendra Nayak

pwrdm_pre_transition()/pwrdm_post_transition() have always been high latency operations done within cpuidle to do Powerdomain level book-keeping to know what state transitions for different Powerdomains have been triggered. This is also useful to do a restore-on-demand in some cases when we know the context for the given Powerdomain was lost etc.

Now that we have definitive entry/exit points (thanks to the Powerdomain level usecounting) for Powerdomain transitions, these book-keeping functions can very well be moved from within CPUidle into pwrdm_clkdm_enable()/pwrdm_ clkdm_disable() functions.

Also rename _pwrdm_pre/post_transition_cb() to pwrdm_pre/post_transition() and get rid of the original ones which iterate over all powerdomains.

Quoted 8 lines

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Signed-off-by Rajendra Nayak<[email protected]>

This is excellent! Thanks for working on this.

However, it needs a rebase against mainline though because I merged a set of optimizations[1] to this code already that only calls pre/post per-pwrdm.

Hi Kevin,

I thought some more on this patch, and I think this way of collecting stats and knowing what state transitions the powerdomains been through will not work on OMAP3, mainly because of the autodeps. Might work on OMAP4 and beyond which do not need any autodeps.

Here why I think so,
Lets assume a Powerdomain X with a last module Y active, once Y disables the last clock (lets assume no hardware controlled clocks for simplicity), we clear the last power state register for X. However due to autodeps X does not transition to a target state immediately. It only does so when the MPU (and IVA) go down, and because of the wakeup dependency (autodeps set a sleep and a wakeup dep with both MPU and IVA) is also woken up every time MPU or IVA are up. So its quite possible that X transitions in and out of sleep multiple times before Y decides to re-enable its clocks, which is when we end up

looking for the last power state entered.
Lets say X entered OFF 3 times in between Y disabling and re-enabling its clocks. Though we end up updating the counter only once (instead of
3) we still know and can tell Y that it lost context.
The problem however arises if for some reason X entered OFF twice and happened to stay ON the third time the dependencies were met. When Y re-enables its clocks, we end up telling it that it *did not* lose context because we see the previous power state was ON.

I think as long as we have autodeps, the only way on OMAP3 to accurately do this is to do it for all dependent domains in CPUIdle :(

Quoted 46 lines · Rajendra Nayak

Quoted 19 lines · Kevin Hilman

Quoted 17 lines · Tero Kristo

Quoted 16 lines · Rajendra Nayak

Quoted 15 lines · Santosh

Quoted 14 lines · Rajendra Nayak

pwrdm_pre_transition()/pwrdm_post_transition() have always been high latency operations done within cpuidle to do Powerdomain level book-keeping to know what state transitions for different Powerdomains have been triggered. This is also useful to do a restore-on-demand in some cases when we know the context for the given Powerdomain was lost etc.

Now that we have definitive entry/exit points (thanks to the Powerdomain level usecounting) for Powerdomain transitions, these book-keeping functions can very well be moved from within CPUidle into pwrdm_clkdm_enable()/pwrdm_ clkdm_disable() functions.

Also rename _pwrdm_pre/post_transition_cb() to pwrdm_pre/post_transition() and get rid of the original ones which iterate over all powerdomains.

Quoted 8 lines

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Signed-off-by Rajendra Nayak<[email protected]>

This is excellent! Thanks for working on this.

However, it needs a rebase against mainline though because I merged a set of optimizations[1] to this code already that only calls pre/post per-pwrdm.

Hi Kevin,

I thought some more on this patch, and I think this way of collecting stats and knowing what state transitions the powerdomains been through will not work on OMAP3, mainly because of the autodeps. Might work on OMAP4 and beyond which do not need any autodeps.

Here why I think so,
Lets assume a Powerdomain X with a last module Y active, once Y disables the last clock (lets assume no hardware controlled clocks for simplicity), we clear the last power state register for X. However due to autodeps X does not transition to a target state immediately. It only does so when the MPU (and IVA) go down, and because of the wakeup dependency (autodeps set a sleep and a wakeup dep with both MPU and IVA) is also woken up every time MPU or IVA are up. So its quite possible that X transitions in and out of sleep multiple times before Y decides to re-enable its clocks, which is when we end up

Quoted 8 lines

looking for the last power state entered.
Lets say X entered OFF 3 times in between Y disabling and re-enabling its clocks. Though we end up updating the counter only once (instead of
3) we still know and can tell Y that it lost context.
The problem however arises if for some reason X entered OFF twice and happened to stay ON the third time the dependencies were met. When Y re-enables its clocks, we end up telling it that it *did not* lose context because we see the previous power state was ON.

Yeah, this is definitely a problem.

As long as we have autodeps, everything is centralized around CPU transitions anyways, so it makes sense to keep the accounting centralized too.

Quoted 2 lines

I think as long as we have autodeps, the only way on OMAP3 to accurately do this is to do it for all dependent domains in CPUIdle :(

Or, to get rid of autodeps. ;)

Quoted 1 line · Kevin Hilman

Or, to get rid of autodeps. ;)

Whats the reason for having them anyway?

Some of the wakedeps make sense (per domain due to hw bugs) but sleepdeps...?

Quoted 6 lines

Yeah, this is definitely a problem.

Quoted 5 lines

As long as we have autodeps, everything is centralized around CPU transitions anyways, so it makes sense to keep the accounting centralized too.

Quoted 4 lines

Quoted 4 lines

Quoted 2 lines

Quoted 2 lines

I think as long as we have autodeps, the only way on OMAP3 to accurately do this is to do it for all dependent domains in CPUIdle:(

Or, to get rid of autodeps.;)

Whats the reason for having them anyway? Some of the wakedeps make sense (per domain due to hw bugs) but sleepdeps...?

However a quick test with just your latest usecounting series (without any of my RFC patches) seems to make me think I am still missing something.

If you see the counts below for usbhost and dss, they both seem to go in and out of RET with every MPU transition. Which means the dependencies are still set.

# cat /debug/pm_debug/count
usbhost_pwrdm
(ON),OFF:0,RET:138,INA:0,ON:139,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
sgx_pwrdm (OFF),OFF:1,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
core_pwrdm
(ON),OFF:0,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-MEMBANK2-OFF:0

per_pwrdm (ON),OFF:0,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
dss_pwrdm
(ON),OFF:0,RET:138,INA:0,ON:139,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
cam_pwrdm (RET),OFF:0,RET:1,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
neon_pwrdm (ON),OFF:0,RET:132,INA:6,ON:139,RET-LOGIC-OFF:0
mpu_pwrdm
(ON),OFF:0,RET:132,INA:6,ON:139,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
iva2_pwrdm (RET),OFF:0,RET:1,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-MEMBANK2-OFF:0,RET-MEMBANK3-OFF:0,RET-MEMBANK4-OFF:0

However if I look at the dss registers, I don;t see any fclks are enabled.

# ./readmem 0x48004E00
0x00000000 <- All FCLK disabled.

# ./readmem 0x48004E10
0x00000001 <- ICLK enabled

# ./readmem 0x48004E44
0x00000006 <- dependencies are set with MPU and IVA

# ./readmem 0x48004E48
0x00000003 <- clkdm is under HWSUP.

Any idea why this could be happening?

With usecounting added to Powerdomains, its now possible to track Powerdomain transitions, including when a Powerdomain is turned on and turned down. Add support for hooking up callbacks for such events, which can be used to do things like context save/restore etc. which today is mostly stuffed within CPUidle and Suspend code.

Signed-off-by Rajendra Nayak <[email protected]>

---

With .power_on/.power_down hooks now available within the powerdomain framework, its possible to clean a lot of mpu/core power_on/power_down related code within omap_sram_idle into respective callbacks for these powerdomains.

This should atleast also optimise the core domain context save in CPUidle when attempting deeper C states, to prevent a core domain context save when a device in core is still active. The current code in such cases does a blind context save and tries to put core domain down, even while devices are active.

Signed-off-by Rajendra Nayak <[email protected]>

---

Hi,

Here are some CPUidle/Suspend cleanup patches done by adding some more functionality in the OMAP Powerdomain framework. They mostly cleanup OMAP3 but the same ideas can be used/ applied for OMAP4 and beyond.

The series is based off Teros' series [1] to add usecounting support within the OMAP Powerdomain framework.

The patches are tested with RET/OFF in CPUidle and Suspend on 3630 beagle Xm and 3430 SDP.

regards,
Rajendra

[1] http://www.mail-archive.com/linux-omap at vger.kernel.org/msg72163.html

Rajendra Nayak (4):
ARM: OMAP3: cpuidle: Remove unused MPU OSWR support code
ARM: OMAP: PM: Get rid of Powerdomain book-keeping from cpuidle
ARM: OMAP: powerdomain: Add .power_on/.power_down hooks for
powerdomains
ARM: OMAP3: PM: Use .power_on/.power_down to clean omap_sram_idle

 arch/arm/mach-omap2/omap-mpuss-lowpower.c |    4 +-
 arch/arm/mach-omap2/pm34xx.c              |  158 ++++++++++++++---------------
 arch/arm/mach-omap2/powerdomain.c         |   40 ++++----
 arch/arm/mach-omap2/powerdomain.h         |    8 +-
 arch/arm/mach-omap2/sleep34xx.S           |    4 +-
 5 files changed, 104 insertions(+), 110 deletions(-)

Quoted 7 lines · Rajendra Nayak

Hi,

Here are some CPUidle/Suspend cleanup patches done by adding some more functionality in the OMAP Powerdomain framework. They mostly cleanup OMAP3 but the same ideas can be used/ applied for OMAP4 and beyond.

Quoted 5 lines

The series is based off Teros' series [1] to add usecounting support within the OMAP Powerdomain framework.

The patches are tested with RET/OFF in CPUidle and Suspend on 3630 beagle Xm and 3430 SDP.

This set looks good to me, just requires careful testing that you don't break anything as you are moving lots of stuff around. For debugging purposes (maybe also permanently?), it might be good to keep some sort of failsafe mechanism in place that prevents actual core / per off transitions in case there is a problem with the usecounting, and you accidentally hit core / per off even though the usecounting doesn't expect it (some autoidle mechanism is overlooked for example.)

Maybe add some caching for the programmed next state, and only program the HW register once we get to the callbacks, and restore the next state to ON after leaving...? This should get rid of any unexpected hangs.ly

-Tero

Quoted 20 lines

regards,
Rajendra

[1] http://www.mail-archive.com/linux-omap at vger.kernel.org/msg72163.html

Rajendra Nayak (4):
ARM: OMAP3: cpuidle: Remove unused MPU OSWR support code
ARM: OMAP: PM: Get rid of Powerdomain book-keeping from cpuidle
ARM: OMAP: powerdomain: Add .power_on/.power_down hooks for
powerdomains
ARM: OMAP3: PM: Use .power_on/.power_down to clean omap_sram_idle

  arch/arm/mach-omap2/omap-mpuss-lowpower.c |    4 +-
  arch/arm/mach-omap2/pm34xx.c              |  158 ++++++++++++++---------------
  arch/arm/mach-omap2/powerdomain.c         |   40 ++++----
  arch/arm/mach-omap2/powerdomain.h         |    8 +-
  arch/arm/mach-omap2/sleep34xx.S           |    4 +-
  5 files changed, 104 insertions(+), 110 deletions(-)