Re: [PATCH 1/2] OMAP3 PM: move omap3 sleep to ddr
On Fri, Nov 19, 2010 at 05:14:15PM +0100, ext Derrick, David wrote: -Original Message- From: Jean Pihet [mailto:jean.pi...@newoldbits.com] Sent: Friday, November 19, 2010 9:37 AM On Thu, Nov 18, 2010 at 7:34 PM, Jean Pihet jean.pi...@newoldbits.com wrote: On Thu, Nov 18, 2010 at 7:27 PM, Tony Lindgren t...@atomide.com wrote: * Jean Pihet jean.pi...@newoldbits.com [101118 10:06]: On Thu, Nov 18, 2010 at 6:52 PM, Tony Lindgren t...@atomide.com wrote: About the DPLL lock: 1) wait_sdrc_ok is only called when back from the non-OFF modes, 2) I checked that when running wait_sdrc_ok the CORE is already out of idle and the DPLL is already locked. Note: l-o code has no support for the voltages OFF and the external clocks OFF. What to conclude from 1) and 2)? In my test setup ot looks like wait_sdrc_ok is of no use, but I agree this a premature conclusion. Yeah we should figure out in which cases wait_sdrc_ok is needed. BTW, are you sure you're hitting core idle in your tests? Yes it is OK from the console messages and the counters values in /debug/pm_debug/count. Let me confirm asap with the PRCM registers dump. Here is what I experimented: 1) added a cache flush (v7_flush_kern_cache_all) just before WFI, in all cases, 2) checked the real state entered in low power mode from the console messages, the output of /debug/pm_debug/count and PRCM registers dump 2) is OK, which means that the RET and OFF modes are correctly hit. Can I conclude from 1) that the wake-up code is not running from the cache in RETention? [Derrick, David] To add some context to the wait_sdrc_ok function and why it was added: wait_sdrc_ok was added because the DLL takes 500 L3 clock cycles to lock. So you do not want to go back to DDR before DLL is locked. Also, we found some times DLL never locked so we introduced the DLL kick procedure to force it to lock. The root cause for the DLL not locking has been found though and a workaround implemented. So it should work now :) That still leaves the 500 L3 cycle delay though. Cheers, Peter. -- 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 1/2] OMAP3 PM: move omap3 sleep to ddr
Peter 'p2' De Schrijver peter.de-schrij...@nokia.com writes: On Fri, Nov 19, 2010 at 05:14:15PM +0100, ext Derrick, David wrote: -Original Message- From: Jean Pihet [mailto:jean.pi...@newoldbits.com] Sent: Friday, November 19, 2010 9:37 AM On Thu, Nov 18, 2010 at 7:34 PM, Jean Pihet jean.pi...@newoldbits.com wrote: On Thu, Nov 18, 2010 at 7:27 PM, Tony Lindgren t...@atomide.com wrote: * Jean Pihet jean.pi...@newoldbits.com [101118 10:06]: On Thu, Nov 18, 2010 at 6:52 PM, Tony Lindgren t...@atomide.com wrote: About the DPLL lock: 1) wait_sdrc_ok is only called when back from the non-OFF modes, 2) I checked that when running wait_sdrc_ok the CORE is already out of idle and the DPLL is already locked. Note: l-o code has no support for the voltages OFF and the external clocks OFF. What to conclude from 1) and 2)? In my test setup ot looks like wait_sdrc_ok is of no use, but I agree this a premature conclusion. Yeah we should figure out in which cases wait_sdrc_ok is needed. BTW, are you sure you're hitting core idle in your tests? Yes it is OK from the console messages and the counters values in /debug/pm_debug/count. Let me confirm asap with the PRCM registers dump. Here is what I experimented: 1) added a cache flush (v7_flush_kern_cache_all) just before WFI, in all cases, 2) checked the real state entered in low power mode from the console messages, the output of /debug/pm_debug/count and PRCM registers dump 2) is OK, which means that the RET and OFF modes are correctly hit. Can I conclude from 1) that the wake-up code is not running from the cache in RETention? [Derrick, David] To add some context to the wait_sdrc_ok function and why it was added: wait_sdrc_ok was added because the DLL takes 500 L3 clock cycles to lock. So you do not want to go back to DDR before DLL is locked. Also, we found some times DLL never locked so we introduced the DLL kick procedure to force it to lock. The root cause for the DLL not locking has been found though and a workaround implemented. So it should work now :) Is the workaround for this reflected in Nishanth's series? Kevin That still leaves the 500 L3 cycle delay though. Cheers, Peter. -- 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 1/2] OMAP3 PM: move omap3 sleep to ddr
On Mon, Nov 22, 2010 at 5:03 PM, Kevin Hilman khil...@deeprootsystems.com wrote: Peter 'p2' De Schrijver peter.de-schrij...@nokia.com writes: On Fri, Nov 19, 2010 at 05:14:15PM +0100, ext Derrick, David wrote: -Original Message- From: Jean Pihet [mailto:jean.pi...@newoldbits.com] Sent: Friday, November 19, 2010 9:37 AM On Thu, Nov 18, 2010 at 7:34 PM, Jean Pihet jean.pi...@newoldbits.com wrote: On Thu, Nov 18, 2010 at 7:27 PM, Tony Lindgren t...@atomide.com wrote: * Jean Pihet jean.pi...@newoldbits.com [101118 10:06]: On Thu, Nov 18, 2010 at 6:52 PM, Tony Lindgren t...@atomide.com wrote: About the DPLL lock: 1) wait_sdrc_ok is only called when back from the non-OFF modes, 2) I checked that when running wait_sdrc_ok the CORE is already out of idle and the DPLL is already locked. Note: l-o code has no support for the voltages OFF and the external clocks OFF. What to conclude from 1) and 2)? In my test setup ot looks like wait_sdrc_ok is of no use, but I agree this a premature conclusion. Yeah we should figure out in which cases wait_sdrc_ok is needed. BTW, are you sure you're hitting core idle in your tests? Yes it is OK from the console messages and the counters values in /debug/pm_debug/count. Let me confirm asap with the PRCM registers dump. Here is what I experimented: 1) added a cache flush (v7_flush_kern_cache_all) just before WFI, in all cases, 2) checked the real state entered in low power mode from the console messages, the output of /debug/pm_debug/count and PRCM registers dump 2) is OK, which means that the RET and OFF modes are correctly hit. Can I conclude from 1) that the wake-up code is not running from the cache in RETention? [Derrick, David] To add some context to the wait_sdrc_ok function and why it was added: wait_sdrc_ok was added because the DLL takes 500 L3 clock cycles to lock. So you do not want to go back to DDR before DLL is locked. Also, we found some times DLL never locked so we introduced the DLL kick procedure to force it to lock. The root cause for the DLL not locking has been found though and a workaround implemented. So it should work now :) Is the workaround for this reflected in Nishanth's series? Yes the patch is '[PATCH 02/13] OMAP3: PM: Errata i581 suppport: dll kick strategy' Kevin That still leaves the 500 L3 cycle delay though. Cheers, Peter. -- 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 1/2] OMAP3 PM: move omap3 sleep to ddr
On Mon, Nov 22, 2010 at 05:03:59PM +0100, ext Kevin Hilman wrote: Peter 'p2' De Schrijver peter.de-schrij...@nokia.com writes: On Fri, Nov 19, 2010 at 05:14:15PM +0100, ext Derrick, David wrote: -Original Message- From: Jean Pihet [mailto:jean.pi...@newoldbits.com] Sent: Friday, November 19, 2010 9:37 AM On Thu, Nov 18, 2010 at 7:34 PM, Jean Pihet jean.pi...@newoldbits.com wrote: On Thu, Nov 18, 2010 at 7:27 PM, Tony Lindgren t...@atomide.com wrote: * Jean Pihet jean.pi...@newoldbits.com [101118 10:06]: On Thu, Nov 18, 2010 at 6:52 PM, Tony Lindgren t...@atomide.com wrote: About the DPLL lock: 1) wait_sdrc_ok is only called when back from the non-OFF modes, 2) I checked that when running wait_sdrc_ok the CORE is already out of idle and the DPLL is already locked. Note: l-o code has no support for the voltages OFF and the external clocks OFF. What to conclude from 1) and 2)? In my test setup ot looks like wait_sdrc_ok is of no use, but I agree this a premature conclusion. Yeah we should figure out in which cases wait_sdrc_ok is needed. BTW, are you sure you're hitting core idle in your tests? Yes it is OK from the console messages and the counters values in /debug/pm_debug/count. Let me confirm asap with the PRCM registers dump. Here is what I experimented: 1) added a cache flush (v7_flush_kern_cache_all) just before WFI, in all cases, 2) checked the real state entered in low power mode from the console messages, the output of /debug/pm_debug/count and PRCM registers dump 2) is OK, which means that the RET and OFF modes are correctly hit. Can I conclude from 1) that the wake-up code is not running from the cache in RETention? [Derrick, David] To add some context to the wait_sdrc_ok function and why it was added: wait_sdrc_ok was added because the DLL takes 500 L3 clock cycles to lock. So you do not want to go back to DDR before DLL is locked. Also, we found some times DLL never locked so we introduced the DLL kick procedure to force it to lock. The root cause for the DLL not locking has been found though and a workaround implemented. So it should work now :) Is the workaround for this reflected in Nishanth's series? No. It seems not. The workaround needs VDD2 voltage scaling which seems to be missing now from l-o ? Cheers, Peter. -- 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 1/2] OMAP3 PM: move omap3 sleep to ddr
Peter 'p2' De Schrijver had written, on 11/22/2010 10:22 AM, the following: [...] The root cause for the DLL not locking has been found though and a workaround implemented. So it should work now :) Is the workaround for this reflected in Nishanth's series? No. It seems not. The workaround needs VDD2 voltage scaling which seems to be missing now from l-o ? yep, that is correct - we dont have dvfs/OPP/voltage scaling in kernel.org as of today - until we have those, it might not be possible to push the real workaround. the mentioned patch is, as documented, support for the voltage workaround. -- Regards, Nishanth Menon -- 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 1/2] OMAP3 PM: move omap3 sleep to ddr
Nishanth Menon n...@ti.com writes: Peter 'p2' De Schrijver had written, on 11/22/2010 10:22 AM, the following: [...] The root cause for the DLL not locking has been found though and a workaround implemented. So it should work now :) Is the workaround for this reflected in Nishanth's series? No. It seems not. The workaround needs VDD2 voltage scaling which seems to be missing now from l-o ? yep, that is correct - we dont have dvfs/OPP/voltage scaling in kernel.org as of today - until we have those, it might not be possible to push the real workaround. the mentioned patch is, as documented, support for the voltage workaround. It would be worth noting other known issues that are not worked around in this series due to external dependencies. Also, is the current SR/voltage series as proposed capable of handling the workaround for this fix? Kevin -- 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 1/2] OMAP3 PM: move omap3 sleep to ddr
Kevin Hilman had written, on 11/22/2010 12:23 PM, the following: Nishanth Menon n...@ti.com writes: Peter 'p2' De Schrijver had written, on 11/22/2010 10:22 AM, the following: [...] The root cause for the DLL not locking has been found though and a workaround implemented. So it should work now :) Is the workaround for this reflected in Nishanth's series? No. It seems not. The workaround needs VDD2 voltage scaling which seems to be missing now from l-o ? yep, that is correct - we dont have dvfs/OPP/voltage scaling in kernel.org as of today - until we have those, it might not be possible to push the real workaround. the mentioned patch is, as documented, support for the voltage workaround. It would be worth noting other known issues that are not worked around in this series due to external dependencies. I believe I have done that http://marc.info/?l=linux-omapm=129013172525234w=2 IMPORTANT: this is not a complete workaround implementation as recommended by the silicon errata. this is a support logic for detecting lockups and attempting to recover where possible and is known to provide stability in multiple platforms. Also, is the current SR/voltage series as proposed capable of handling the workaround for this fix? I believe a new series is due sometime- we should see if the required changes are part of that series. Regards, Nishanth Menon -- 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 1/2] OMAP3 PM: move omap3 sleep to ddr
HI Tony, On Thu, Nov 18, 2010 at 7:34 PM, Jean Pihet jean.pi...@newoldbits.com wrote: On Thu, Nov 18, 2010 at 7:27 PM, Tony Lindgren t...@atomide.com wrote: * Jean Pihet jean.pi...@newoldbits.com [101118 10:06]: On Thu, Nov 18, 2010 at 6:52 PM, Tony Lindgren t...@atomide.com wrote: About the DPLL lock: 1) wait_sdrc_ok is only called when back from the non-OFF modes, 2) I checked that when running wait_sdrc_ok the CORE is already out of idle and the DPLL is already locked. Note: l-o code has no support for the voltages OFF and the external clocks OFF. What to conclude from 1) and 2)? In my test setup ot looks like wait_sdrc_ok is of no use, but I agree this a premature conclusion. Yeah we should figure out in which cases wait_sdrc_ok is needed. BTW, are you sure you're hitting core idle in your tests? Yes it is OK from the console messages and the counters values in /debug/pm_debug/count. Let me confirm asap with the PRCM registers dump. Here is what I experimented: 1) added a cache flush (v7_flush_kern_cache_all) just before WFI, in all cases, 2) checked the real state entered in low power mode from the console messages, the output of /debug/pm_debug/count and PRCM registers dump 2) is OK, which means that the RET and OFF modes are correctly hit. Can I conclude from 1) that the wake-up code is not running from the cache in RETention? Thanks, Jean Regards, Tony Thanks, 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 1/2] OMAP3 PM: move omap3 sleep to ddr
* Jean Pihet jean.pi...@newoldbits.com [101119 07:27]: HI Tony, On Thu, Nov 18, 2010 at 7:34 PM, Jean Pihet jean.pi...@newoldbits.com wrote: On Thu, Nov 18, 2010 at 7:27 PM, Tony Lindgren t...@atomide.com wrote: * Jean Pihet jean.pi...@newoldbits.com [101118 10:06]: On Thu, Nov 18, 2010 at 6:52 PM, Tony Lindgren t...@atomide.com wrote: About the DPLL lock: 1) wait_sdrc_ok is only called when back from the non-OFF modes, 2) I checked that when running wait_sdrc_ok the CORE is already out of idle and the DPLL is already locked. Note: l-o code has no support for the voltages OFF and the external clocks OFF. What to conclude from 1) and 2)? In my test setup ot looks like wait_sdrc_ok is of no use, but I agree this a premature conclusion. Yeah we should figure out in which cases wait_sdrc_ok is needed. BTW, are you sure you're hitting core idle in your tests? Yes it is OK from the console messages and the counters values in /debug/pm_debug/count. Let me confirm asap with the PRCM registers dump. Here is what I experimented: 1) added a cache flush (v7_flush_kern_cache_all) just before WFI, in all cases, 2) checked the real state entered in low power mode from the console messages, the output of /debug/pm_debug/count and PRCM registers dump 2) is OK, which means that the RET and OFF modes are correctly hit. Can I conclude from 1) that the wake-up code is not running from the cache in RETention? Sounds pretty safe to me then, thanks for testing. Now we just have to find out in which cases wait_sdrc_ok is needed.. Tony -- 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 1/2] OMAP3 PM: move omap3 sleep to ddr
-Original Message- From: Jean Pihet [mailto:jean.pi...@newoldbits.com] Sent: Friday, November 19, 2010 9:37 AM On Thu, Nov 18, 2010 at 7:34 PM, Jean Pihet jean.pi...@newoldbits.com wrote: On Thu, Nov 18, 2010 at 7:27 PM, Tony Lindgren t...@atomide.com wrote: * Jean Pihet jean.pi...@newoldbits.com [101118 10:06]: On Thu, Nov 18, 2010 at 6:52 PM, Tony Lindgren t...@atomide.com wrote: About the DPLL lock: 1) wait_sdrc_ok is only called when back from the non-OFF modes, 2) I checked that when running wait_sdrc_ok the CORE is already out of idle and the DPLL is already locked. Note: l-o code has no support for the voltages OFF and the external clocks OFF. What to conclude from 1) and 2)? In my test setup ot looks like wait_sdrc_ok is of no use, but I agree this a premature conclusion. Yeah we should figure out in which cases wait_sdrc_ok is needed. BTW, are you sure you're hitting core idle in your tests? Yes it is OK from the console messages and the counters values in /debug/pm_debug/count. Let me confirm asap with the PRCM registers dump. Here is what I experimented: 1) added a cache flush (v7_flush_kern_cache_all) just before WFI, in all cases, 2) checked the real state entered in low power mode from the console messages, the output of /debug/pm_debug/count and PRCM registers dump 2) is OK, which means that the RET and OFF modes are correctly hit. Can I conclude from 1) that the wake-up code is not running from the cache in RETention? [Derrick, David] To add some context to the wait_sdrc_ok function and why it was added: wait_sdrc_ok was added because the DLL takes 500 L3 clock cycles to lock. So you do not want to go back to DDR before DLL is locked. Also, we found some times DLL never locked so we introduced the DLL kick procedure to force it to lock. Regards, David -- 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 1/2] OMAP3 PM: move omap3 sleep to ddr
On Fri, Nov 19, 2010 at 5:14 PM, Derrick, David dderr...@ti.com wrote: -Original Message- From: Jean Pihet [mailto:jean.pi...@newoldbits.com] Sent: Friday, November 19, 2010 9:37 AM On Thu, Nov 18, 2010 at 7:34 PM, Jean Pihet jean.pi...@newoldbits.com wrote: On Thu, Nov 18, 2010 at 7:27 PM, Tony Lindgren t...@atomide.com wrote: * Jean Pihet jean.pi...@newoldbits.com [101118 10:06]: On Thu, Nov 18, 2010 at 6:52 PM, Tony Lindgren t...@atomide.com wrote: About the DPLL lock: 1) wait_sdrc_ok is only called when back from the non-OFF modes, 2) I checked that when running wait_sdrc_ok the CORE is already out of idle and the DPLL is already locked. Note: l-o code has no support for the voltages OFF and the external clocks OFF. What to conclude from 1) and 2)? In my test setup ot looks like wait_sdrc_ok is of no use, but I agree this a premature conclusion. Yeah we should figure out in which cases wait_sdrc_ok is needed. BTW, are you sure you're hitting core idle in your tests? Yes it is OK from the console messages and the counters values in /debug/pm_debug/count. Let me confirm asap with the PRCM registers dump. Here is what I experimented: 1) added a cache flush (v7_flush_kern_cache_all) just before WFI, in all cases, 2) checked the real state entered in low power mode from the console messages, the output of /debug/pm_debug/count and PRCM registers dump 2) is OK, which means that the RET and OFF modes are correctly hit. Can I conclude from 1) that the wake-up code is not running from the cache in RETention? [Derrick, David] To add some context to the wait_sdrc_ok function and why it was added: wait_sdrc_ok was added because the DLL takes 500 L3 clock cycles to lock. So you do not want to go back to DDR before DLL is locked. Also, we found some times DLL never locked so we introduced the DLL kick procedure to force it to lock. Ok thanks for the details. Does that mean that it is unsafe to run the sleep code (in sleep34xx.S) from DDR? Regards, David Regards, 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 1/2] OMAP3 PM: move omap3 sleep to ddr
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Jean Pihet
Sent: Thursday, November 18, 2010 8:52 AM
To: linux-omap@vger.kernel.org
Cc: Vishwanath BS; Kevin Hillman; Jean Pihet
Subject: [PATCH 1/2] OMAP3 PM: move omap3 sleep to ddr
From: Vishwanath BS vishwanath...@ti.com
For historical reasons the OMAP3 sleep code is run from SRAM.
This code can run from DDR which provides better performance and
leaves the SRAM available for other uses.
Tested on ZOOM3, OMAP3EVM, Beagleboard, n900
with full RET and OFF modes.
Sorry, But I disagree with this patch.
There is a silicon errata which cannot be handled with this - RTA disable
- errata i608
You need to disable RTA while coming out of OFF - we cannot handle this on
GP devices if this is not done.
Signed-off-by: Vishwanath BS vishwanath...@ti.com
Cc: Kevin Hillman khil...@deeprootsystems.com
Changed the commit comments.
Cc: Jean Pihet j-pi...@ti.com
---
arch/arm/mach-omap2/pm34xx.c |9 +
1 files changed, 1 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 75c0cd1..035ca47 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -65,8 +65,6 @@ struct power_state {
static LIST_HEAD(pwrst_list);
-static void (*_omap_sram_idle)(u32 *addr, int save_state);
-
static int (*_omap_save_secure_sram)(u32 *addr);
static struct powerdomain *mpu_pwrdm, *neon_pwrdm;
@@ -346,9 +344,6 @@ void omap_sram_idle(void)
int core_prev_state, per_prev_state;
u32 sdrc_pwr = 0;
- if (!_omap_sram_idle)
- return;
-
pwrdm_clear_all_prev_pwrst(mpu_pwrdm);
pwrdm_clear_all_prev_pwrst(neon_pwrdm);
pwrdm_clear_all_prev_pwrst(core_pwrdm);
@@ -422,7 +417,7 @@ void omap_sram_idle(void)
* get saved. The restore path then reads from this
* location and restores them back.
*/
- _omap_sram_idle(omap3_arm_context, save_state);
+ omap34xx_cpu_suspend(omap3_arm_context, save_state);
cpu_init();
/* Restore normal SDRC POWER settings */
@@ -972,8 +967,6 @@ static int __init clkdms_setup(struct clockdomain
*clkdm, void *unused)
void omap_push_sram_idle(void)
{
- _omap_sram_idle = omap_sram_push(omap34xx_cpu_suspend,
- omap34xx_cpu_suspend_sz);
if (omap_type() != OMAP2_DEVICE_TYPE_GP)
_omap_save_secure_sram =
omap_sram_push(save_secure_ram_context,
save_secure_ram_context_sz);
--
1.7.2.3
--
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
--
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 1/2] OMAP3 PM: move omap3 sleep to ddr
NIshant,
On Thu, Nov 18, 2010 at 8:27 PM, Nishanth Menon n...@ti.com wrote:
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Jean Pihet
Sent: Thursday, November 18, 2010 8:52 AM
To: linux-omap@vger.kernel.org
Cc: Vishwanath BS; Kevin Hillman; Jean Pihet
Subject: [PATCH 1/2] OMAP3 PM: move omap3 sleep to ddr
From: Vishwanath BS vishwanath...@ti.com
For historical reasons the OMAP3 sleep code is run from SRAM.
This code can run from DDR which provides better performance and
leaves the SRAM available for other uses.
Tested on ZOOM3, OMAP3EVM, Beagleboard, n900
with full RET and OFF modes.
Sorry, But I disagree with this patch.
There is a silicon errata which cannot be handled with this - RTA disable
- errata i608
You need to disable RTA while coming out of OFF - we cannot handle this on
GP devices if this is not done.
When you come out of Core off, SRAM contents are anyway lost. So you
have to run from DDR after ROM Code completes. This behavior has not
changed with this patch. I fail to understand your concern here.
Vishwa
Signed-off-by: Vishwanath BS vishwanath...@ti.com
Cc: Kevin Hillman khil...@deeprootsystems.com
Changed the commit comments.
Cc: Jean Pihet j-pi...@ti.com
---
arch/arm/mach-omap2/pm34xx.c | 9 +
1 files changed, 1 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 75c0cd1..035ca47 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -65,8 +65,6 @@ struct power_state {
static LIST_HEAD(pwrst_list);
-static void (*_omap_sram_idle)(u32 *addr, int save_state);
-
static int (*_omap_save_secure_sram)(u32 *addr);
static struct powerdomain *mpu_pwrdm, *neon_pwrdm;
@@ -346,9 +344,6 @@ void omap_sram_idle(void)
int core_prev_state, per_prev_state;
u32 sdrc_pwr = 0;
- if (!_omap_sram_idle)
- return;
-
pwrdm_clear_all_prev_pwrst(mpu_pwrdm);
pwrdm_clear_all_prev_pwrst(neon_pwrdm);
pwrdm_clear_all_prev_pwrst(core_pwrdm);
@@ -422,7 +417,7 @@ void omap_sram_idle(void)
* get saved. The restore path then reads from this
* location and restores them back.
*/
- _omap_sram_idle(omap3_arm_context, save_state);
+ omap34xx_cpu_suspend(omap3_arm_context, save_state);
cpu_init();
/* Restore normal SDRC POWER settings */
@@ -972,8 +967,6 @@ static int __init clkdms_setup(struct clockdomain
*clkdm, void *unused)
void omap_push_sram_idle(void)
{
- _omap_sram_idle = omap_sram_push(omap34xx_cpu_suspend,
- omap34xx_cpu_suspend_sz);
if (omap_type() != OMAP2_DEVICE_TYPE_GP)
_omap_save_secure_sram =
omap_sram_push(save_secure_ram_context,
save_secure_ram_context_sz);
--
1.7.2.3
--
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
--
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 1/2] OMAP3 PM: move omap3 sleep to ddr
-Original Message- From: Sripathy, Vishwanath [mailto:vishwanath...@ti.com] Sent: Thursday, November 18, 2010 9:09 AM To: Nishanth Menon Cc: Jean Pihet; linux-omap@vger.kernel.org; Kevin Hillman; Jean Pihet-XID Subject: Re: [PATCH 1/2] OMAP3 PM: move omap3 sleep to ddr NIshant, On Thu, Nov 18, 2010 at 8:27 PM, Nishanth Menon n...@ti.com wrote: -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Jean Pihet Sent: Thursday, November 18, 2010 8:52 AM To: linux-omap@vger.kernel.org Cc: Vishwanath BS; Kevin Hillman; Jean Pihet Subject: [PATCH 1/2] OMAP3 PM: move omap3 sleep to ddr From: Vishwanath BS vishwanath...@ti.com For historical reasons the OMAP3 sleep code is run from SRAM. This code can run from DDR which provides better performance and leaves the SRAM available for other uses. Tested on ZOOM3, OMAP3EVM, Beagleboard, n900 with full RET and OFF modes. Sorry, But I disagree with this patch. There is a silicon errata which cannot be handled with this - RTA disable - errata i608 You need to disable RTA while coming out of OFF - we cannot handle this on GP devices if this is not done. When you come out of Core off, SRAM contents are anyway lost. So you have to run from DDR after ROM Code completes. This behavior has not changed with this patch. I fail to understand your concern here. I could potentially be mistaken. Let me do one thing - I will post out the patches that I have to the list and we can see how this all works together. Regards, Nishanth Menon -- 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 1/2] OMAP3 PM: move omap3 sleep to ddr
Hi Nishant, On Thu, Nov 18, 2010 at 4:11 PM, Nishanth Menon n...@ti.com wrote: -Original Message- From: Sripathy, Vishwanath [mailto:vishwanath...@ti.com] Sent: Thursday, November 18, 2010 9:09 AM To: Nishanth Menon Cc: Jean Pihet; linux-omap@vger.kernel.org; Kevin Hillman; Jean Pihet-XID Subject: Re: [PATCH 1/2] OMAP3 PM: move omap3 sleep to ddr NIshant, On Thu, Nov 18, 2010 at 8:27 PM, Nishanth Menon n...@ti.com wrote: -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Jean Pihet Sent: Thursday, November 18, 2010 8:52 AM To: linux-omap@vger.kernel.org Cc: Vishwanath BS; Kevin Hillman; Jean Pihet Subject: [PATCH 1/2] OMAP3 PM: move omap3 sleep to ddr From: Vishwanath BS vishwanath...@ti.com For historical reasons the OMAP3 sleep code is run from SRAM. This code can run from DDR which provides better performance and leaves the SRAM available for other uses. Tested on ZOOM3, OMAP3EVM, Beagleboard, n900 with full RET and OFF modes. Sorry, But I disagree with this patch. There is a silicon errata which cannot be handled with this - RTA disable - errata i608 You need to disable RTA while coming out of OFF - we cannot handle this on GP devices if this is not done. When you come out of Core off, SRAM contents are anyway lost. So you have to run from DDR after ROM Code completes. This behavior has not changed with this patch. I fail to understand your concern here. I could potentially be mistaken. Let me do one thing - I will post out the patches that I have to the list and we can see how this all works together Ok, fine. I did not find any 36xx specific workaround for the errata i608 issue. Is there one already available? Thanks, Jean Regards, Nishanth Menon -- 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 1/2] OMAP3 PM: move omap3 sleep to ddr
-Original Message- From: Jean Pihet [mailto:jean.pi...@newoldbits.com] Sent: Thursday, November 18, 2010 9:15 AM [...] Tested on ZOOM3, OMAP3EVM, Beagleboard, n900 with full RET and OFF modes. Sorry, But I disagree with this patch. There is a silicon errata which cannot be handled with this - RTA disable - errata i608 You need to disable RTA while coming out of OFF - we cannot handle this on GP devices if this is not done. When you come out of Core off, SRAM contents are anyway lost. So you have to run from DDR after ROM Code completes. This behavior has not changed with this patch. I fail to understand your concern here. I could potentially be mistaken. Let me do one thing - I will post out the patches that I have to the list and we can see how this all works together Ok, fine. I did not find any 36xx specific workaround for the errata i608 issue. Is there one already available? Yes, I have a series of patches addressing that as well.. hoping to test On EMU/HS devices prior to posting - GP devices (3430/3630) tested. Regards, Nishanth Menon -- 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 1/2] OMAP3 PM: move omap3 sleep to ddr
Nishanth Menon n...@ti.com writes: From: Vishwanath BS vishwanath...@ti.com For historical reasons the OMAP3 sleep code is run from SRAM. This code can run from DDR which provides better performance and leaves the SRAM available for other uses. Tested on ZOOM3, OMAP3EVM, Beagleboard, n900 with full RET and OFF modes. Sorry, But I disagree with this patch. There is a silicon errata which cannot be handled with this - RTA disable - errata i608 You need to disable RTA while coming out of OFF - we cannot handle this on GP devices if this is not done. You need to provide some more details here as to exactly why this patch prevents the ability to do this workaround. As Vishwa pointed out, when returning from OFF mode, current code already starts in DDR since SRAM is lost. The current code also already can jump back into SRAM for certain errata/fixup (c.f. es3_sdrc_fix in current code.) Kevin -- 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 1/2] OMAP3 PM: move omap3 sleep to ddr
Kevin Hilman had written, on 11/18/2010 09:52 AM, the following: Nishanth Menon n...@ti.com writes: From: Vishwanath BS vishwanath...@ti.com For historical reasons the OMAP3 sleep code is run from SRAM. This code can run from DDR which provides better performance and leaves the SRAM available for other uses. Tested on ZOOM3, OMAP3EVM, Beagleboard, n900 with full RET and OFF modes. Sorry, But I disagree with this patch. There is a silicon errata which cannot be handled with this - RTA disable - errata i608 You need to disable RTA while coming out of OFF - we cannot handle this on GP devices if this is not done. You need to provide some more details here as to exactly why this patch prevents the ability to do this workaround. As Vishwa pointed out, when returning from OFF mode, current code already starts in DDR since SRAM is lost. The current code also already can jump back into SRAM for certain errata/fixup (c.f. es3_sdrc_fix in current code.) scratchpad_contents.public_restore_ptr - this is the restore pointer that is invoked when we get out of OFF mode. - on 3430 and 3630, I agree it in SDRAM, for es3_sdrc_fix, it relocates the required code to sram as it cannot be run in ddr. - so I believe no issues there. But after wfi in wait_sdrc_ok as part of the code executing in SRAM today omap34xx_cpu_suspend - we are waiting for DPLL3 lock prior to accessing DDR - how do we execute that logic in SDRAM? -- Regards, Nishanth Menon -- 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 1/2] OMAP3 PM: move omap3 sleep to ddr
* Nishanth Menon n...@ti.com [101118 08:46]: But after wfi in wait_sdrc_ok as part of the code executing in SRAM today omap34xx_cpu_suspend - we are waiting for DPLL3 lock prior to accessing DDR - how do we execute that logic in SDRAM? I too am a bit concerned how this will all keep working. For light testing it may be running OK if it happens to run from cache.. Also, moving the code out of SRAM will limit the options for what we may need to do with DDR or L3. Retention is something to consider, are there issues with that? Regards, Tony -- 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 1/2] OMAP3 PM: move omap3 sleep to ddr
* Tony Lindgren t...@atomide.com [101118 09:42]: * Nishanth Menon n...@ti.com [101118 08:46]: But after wfi in wait_sdrc_ok as part of the code executing in SRAM today omap34xx_cpu_suspend - we are waiting for DPLL3 lock prior to accessing DDR - how do we execute that logic in SDRAM? I too am a bit concerned how this will all keep working. For light testing it may be running OK if it happens to run from cache.. This in the retention case, in off-idle those should be powered down.. Tony -- 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 1/2] OMAP3 PM: move omap3 sleep to ddr
On Thu, Nov 18, 2010 at 6:52 PM, Tony Lindgren t...@atomide.com wrote: * Nishanth Menon n...@ti.com [101118 08:46]: But after wfi in wait_sdrc_ok as part of the code executing in SRAM today omap34xx_cpu_suspend - we are waiting for DPLL3 lock prior to accessing DDR - how do we execute that logic in SDRAM? I too am a bit concerned how this will all keep working. For light testing it may be running OK if it happens to run from cache.. As Vishwa pointed out, when going out of OFF mode the SRAM and the caches are lost. That means the low power mode _has to_ rely on SDRAM at wake-up. About the DPLL lock: 1) wait_sdrc_ok is only called when back from the non-OFF modes, 2) I checked that when running wait_sdrc_ok the CORE is already out of idle and the DPLL is already locked. Note: l-o code has no support for the voltages OFF and the external clocks OFF. What to conclude from 1) and 2)? In my test setup ot looks like wait_sdrc_ok is of no use, but I agree this a premature conclusion. Also, moving the code out of SRAM will limit the options for what we may need to do with DDR or L3. What are the options? All the executable code runs from DDR anyway. Retention is something to consider, are there issues with that? No issue so far. See the points 1) and 2) here above. Regards, Tony 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 1/2] OMAP3 PM: move omap3 sleep to ddr
* Jean Pihet jean.pi...@newoldbits.com [101118 10:06]: On Thu, Nov 18, 2010 at 6:52 PM, Tony Lindgren t...@atomide.com wrote: About the DPLL lock: 1) wait_sdrc_ok is only called when back from the non-OFF modes, 2) I checked that when running wait_sdrc_ok the CORE is already out of idle and the DPLL is already locked. Note: l-o code has no support for the voltages OFF and the external clocks OFF. What to conclude from 1) and 2)? In my test setup ot looks like wait_sdrc_ok is of no use, but I agree this a premature conclusion. Yeah we should figure out in which cases wait_sdrc_ok is needed. BTW, are you sure you're hitting core idle in your tests? Regards, Tony -- 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 1/2] OMAP3 PM: move omap3 sleep to ddr
On Thu, Nov 18, 2010 at 7:27 PM, Tony Lindgren t...@atomide.com wrote: * Jean Pihet jean.pi...@newoldbits.com [101118 10:06]: On Thu, Nov 18, 2010 at 6:52 PM, Tony Lindgren t...@atomide.com wrote: About the DPLL lock: 1) wait_sdrc_ok is only called when back from the non-OFF modes, 2) I checked that when running wait_sdrc_ok the CORE is already out of idle and the DPLL is already locked. Note: l-o code has no support for the voltages OFF and the external clocks OFF. What to conclude from 1) and 2)? In my test setup ot looks like wait_sdrc_ok is of no use, but I agree this a premature conclusion. Yeah we should figure out in which cases wait_sdrc_ok is needed. BTW, are you sure you're hitting core idle in your tests? Yes it is OK from the console messages and the counters values in /debug/pm_debug/count. Let me confirm asap with the PRCM registers dump. Regards, Tony Thanks, 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 1/2] OMAP3 PM: move omap3 sleep to ddr
Kevin,
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Saturday, September 25, 2010 1:28 AM
To: Sripathy, Vishwanath
Cc: linux-omap@vger.kernel.org; linaro-...@lists.linaro.org
Subject: Re: [PATCH 1/2] OMAP3 PM: move omap3 sleep to ddr
Vishwanath BS vishwanath...@ti.com writes:
There is no need to keep omap3 sleep code in SRAM.
This code can be run very well on DDR.
/me remains skeptical
This would help us to instrument CPUIdle latencies.
Indeed, but...
I'm afraid we will need a much more descriptive changelog here,
describing in detail why this will still work, and what about the
previous motiviations for running SRAM has changed such that this will
work out of SRAM.
Running the code from SRAM for CPUIdle was more of legacy from OMAP2 and there
was no technical reason why it cannot be run from DDR. Also note that, once MPU
enters off mode, wake up code used to run from DDR earlier (w/o these changes)
as well. I will put more details in the change log.
Tested on ZOOM3.
Tested in what way? This path is used for both idle and suspend, and
needs to be validated for retention and off mode.
I have tested for both retention and off mode in both CPU idle and suspend
path. I will update the changelog in next version.
Vishwa
Kevin
Signed-off-by: Vishwanath BS vishwanath...@ti.com
Cc: Kevin Hillman khil...@deeprootsystems.com
Cc: Linaro linaro-...@lists.linaro.org
---
arch/arm/mach-omap2/pm34xx.c |9 +
1 files changed, 1 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 85ef245..ed9d12c 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -79,8 +79,6 @@ struct power_state {
static LIST_HEAD(pwrst_list);
-static void (*_omap_sram_idle)(u32 *addr, int save_state);
-
static int (*_omap_save_secure_sram)(u32 *addr);
static struct powerdomain *mpu_pwrdm, *neon_pwrdm;
@@ -360,9 +358,6 @@ void omap_sram_idle(void)
int core_prev_state, per_prev_state;
u32 sdrc_pwr = 0;
- if (!_omap_sram_idle)
- return;
-
pwrdm_clear_all_prev_pwrst(mpu_pwrdm);
pwrdm_clear_all_prev_pwrst(neon_pwrdm);
pwrdm_clear_all_prev_pwrst(core_pwrdm);
@@ -438,7 +433,7 @@ void omap_sram_idle(void)
* get saved. The restore path then reads from this
* location and restores them back.
*/
- _omap_sram_idle(omap3_arm_context, save_state);
+ omap34xx_cpu_suspend(omap3_arm_context, save_state);
cpu_init();
if (is_suspending())
@@ -995,8 +990,6 @@ static int __init clkdms_setup(struct clockdomain
*clkdm,
void *unused)
void omap_push_sram_idle(void)
{
- _omap_sram_idle = omap_sram_push(omap34xx_cpu_suspend,
- omap34xx_cpu_suspend_sz);
if (omap_type() != OMAP2_DEVICE_TYPE_GP)
_omap_save_secure_sram =
omap_sram_push(save_secure_ram_context,
save_secure_ram_context_sz);
--
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 1/2] OMAP3 PM: move omap3 sleep to ddr
* Vishwanath BS vishwanath...@ti.com [100924 03:50]: There is no need to keep omap3 sleep code in SRAM. This code can be run very well on DDR. This would help us to instrument CPUIdle latencies. Uhh, are you sure about this? To me it sounds like you're then relying on the code running from the cache for off-idle? What about CONFIG_CPU_ICACHE_DISABLE? Regards, Tony -- 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 1/2] OMAP3 PM: move omap3 sleep to ddr
* Tony Lindgren t...@atomide.com [100924 11:53]: * Vishwanath BS vishwanath...@ti.com [100924 03:50]: There is no need to keep omap3 sleep code in SRAM. This code can be run very well on DDR. This would help us to instrument CPUIdle latencies. Uhh, are you sure about this? To me it sounds like you're then relying on the code running from the cache for off-idle? Actually the caches are off too for off-idle.. Tony -- 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 1/2] OMAP3 PM: move omap3 sleep to ddr
Vishwanath BS vishwanath...@ti.com writes:
There is no need to keep omap3 sleep code in SRAM.
This code can be run very well on DDR.
/me remains skeptical
This would help us to instrument CPUIdle latencies.
Indeed, but...
I'm afraid we will need a much more descriptive changelog here,
describing in detail why this will still work, and what about the
previous motiviations for running SRAM has changed such that this will
work out of SRAM.
Tested on ZOOM3.
Tested in what way? This path is used for both idle and suspend, and
needs to be validated for retention and off mode.
Kevin
Signed-off-by: Vishwanath BS vishwanath...@ti.com
Cc: Kevin Hillman khil...@deeprootsystems.com
Cc: Linaro linaro-...@lists.linaro.org
---
arch/arm/mach-omap2/pm34xx.c |9 +
1 files changed, 1 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 85ef245..ed9d12c 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -79,8 +79,6 @@ struct power_state {
static LIST_HEAD(pwrst_list);
-static void (*_omap_sram_idle)(u32 *addr, int save_state);
-
static int (*_omap_save_secure_sram)(u32 *addr);
static struct powerdomain *mpu_pwrdm, *neon_pwrdm;
@@ -360,9 +358,6 @@ void omap_sram_idle(void)
int core_prev_state, per_prev_state;
u32 sdrc_pwr = 0;
- if (!_omap_sram_idle)
- return;
-
pwrdm_clear_all_prev_pwrst(mpu_pwrdm);
pwrdm_clear_all_prev_pwrst(neon_pwrdm);
pwrdm_clear_all_prev_pwrst(core_pwrdm);
@@ -438,7 +433,7 @@ void omap_sram_idle(void)
* get saved. The restore path then reads from this
* location and restores them back.
*/
- _omap_sram_idle(omap3_arm_context, save_state);
+ omap34xx_cpu_suspend(omap3_arm_context, save_state);
cpu_init();
if (is_suspending())
@@ -995,8 +990,6 @@ static int __init clkdms_setup(struct clockdomain *clkdm,
void *unused)
void omap_push_sram_idle(void)
{
- _omap_sram_idle = omap_sram_push(omap34xx_cpu_suspend,
- omap34xx_cpu_suspend_sz);
if (omap_type() != OMAP2_DEVICE_TYPE_GP)
_omap_save_secure_sram = omap_sram_push(save_secure_ram_context,
save_secure_ram_context_sz);
--
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 1/2] OMAP3 PM: move omap3 sleep to ddr
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Tony Lindgren Sent: Saturday, September 25, 2010 12:40 AM To: Sripathy, Vishwanath Cc: linux-omap@vger.kernel.org; linaro-...@lists.linaro.org; Kevin Hillman Subject: Re: [PATCH 1/2] OMAP3 PM: move omap3 sleep to ddr * Tony Lindgren t...@atomide.com [100924 11:53]: * Vishwanath BS vishwanath...@ti.com [100924 03:50]: There is no need to keep omap3 sleep code in SRAM. This code can be run very well on DDR. This would help us to instrument CPUIdle latencies. Uhh, are you sure about this? To me it sounds like you're then relying on the code running from the cache for off-idle? Actually the caches are off too for off-idle.. The low power code can be executed from DDR and need not be from cache. The only real implementation on OMAP3 is around DVFS code, where you need to put DDR to self refresh and execute some piece of code. That still needs to be executed from some other memory like (SRAM). Regards, Santosh -- 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
