RE: [PATCH] OMAP3: SDRC : Errata 1.176 Fix - Accesses to DDR stall in SDRC after a Warm-reset
Paul, Sorry for late response. Here is the answer for some of the queries that you had posted. -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Paul Walmsley Sent: Tuesday, January 26, 2010 11:13 AM To: Reddy, Teerth Cc: linux-omap@vger.kernel.org; t...@atomide.com; Kevin Hilman Subject: RE: [PATCH] OMAP3: SDRC : Errata 1.176 Fix - Accesses to DDR stall in SDRC after a Warm-reset Hello Teerth, On Mon, 25 Jan 2010, Reddy, Teerth wrote: From: Paul Walmsley [mailto:p...@pwsan.com] I wonder if this also needs to make sure that all the other system initiators are mute before continuing, for the same reason cited in commit 18862cbe47e37beba98f22c088fbe6fe029df889 ? I suppose that, for example, if an interrupt occurs on the IVA2.2 or the DMA controller tries to access the SDRC, it would hopefully only wedge those initiators and not the whole chip? Do you think we need to take care of the system initiators if we are disabling all the interrupts before going for a warm reset? Are you disabling _all_ the interrupts, or just the MPU's interrupts? Even if you did disable all of the system interrupts, couldn't DMA be ongoing from/to another system initiator, independently of interrupts? We should disable all MPU interrupts. Yes there can be another initiator active in the system parallelly. However all the system initiators will recover from reset once warm reset is triggered. I think this doesn't seem to hold good here. You may be right, but I'd like you to describe your reasoning on this point. Please let me know if you understanding is wrong. My concerns here are twofold: 1. If other system initiators are interacting with the SDRC during this process, is there a danger that the interconnect could enter a state that would prevent the warm reset from occurring, thus wedging the system? This should not happen since bottle neck would be L4, only initiators accessing L4 are expected to be MPU and DMA (and maybe DSP) and L4 has 4 threads. We cannot think of a blocking scenario. 2. When the warm-reset occurs, will it also completely reset other initiators that may be wedged waiting for some SDRC access to complete? Yes Vishwa - Paul -- 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] OMAP3: SDRC : Errata 1.176 Fix - Accesses to DDR stall in SDRC after a Warm-reset
Hello Teerth, On Mon, 25 Jan 2010, Reddy, Teerth wrote: From: Paul Walmsley [mailto:p...@pwsan.com] I wonder if this also needs to make sure that all the other system initiators are mute before continuing, for the same reason cited in commit 18862cbe47e37beba98f22c088fbe6fe029df889 ? I suppose that, for example, if an interrupt occurs on the IVA2.2 or the DMA controller tries to access the SDRC, it would hopefully only wedge those initiators and not the whole chip? Do you think we need to take care of the system initiators if we are disabling all the interrupts before going for a warm reset? Are you disabling _all_ the interrupts, or just the MPU's interrupts? Even if you did disable all of the system interrupts, couldn't DMA be ongoing from/to another system initiator, independently of interrupts? I think this doesn't seem to hold good here. You may be right, but I'd like you to describe your reasoning on this point. Please let me know if you understanding is wrong. My concerns here are twofold: 1. If other system initiators are interacting with the SDRC during this process, is there a danger that the interconnect could enter a state that would prevent the warm reset from occurring, thus wedging the system? 2. When the warm-reset occurs, will it also completely reset other initiators that may be wedged waiting for some SDRC access to complete? - Paul -- 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] OMAP3: SDRC : Errata 1.176 Fix - Accesses to DDR stall in SDRC after a Warm-reset
Hi Paul, I wonder if this also needs to make sure that all the other system initiators are mute before continuing, for the same reason cited in commit 18862cbe47e37beba98f22c088fbe6fe029df889 ? I suppose that, for example, if an interrupt occurs on the IVA2.2 or the DMA controller tries to access the SDRC, it would hopefully only wedge those initiators and not the whole chip? Do you think we need to take care of the system initiators if we are disabling all the interrupts before going for a warm reset? I think this doesn't seem to hold good here. Please let me know if my understanding is wrong. Regards Teerth -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Reddy, Teerth Sent: Monday, January 25, 2010 12:53 PM To: Paul Walmsley Cc: linux-omap@vger.kernel.org; t...@atomide.com; Kevin Hilman Subject: RE: [PATCH] OMAP3: SDRC : Errata 1.176 Fix - Accesses to DDR stall in SDRC after a Warm-reset Hi Paul, -Original Message- From: Paul Walmsley [mailto:p...@pwsan.com] Sent: Thursday, January 14, 2010 2:31 AM To: Reddy, Teerth Cc: linux-omap@vger.kernel.org; t...@atomide.com; Kevin Hilman Subject: Re: [PATCH] OMAP3: SDRC : Errata 1.176 Fix - Accesses to DDR stall in SDRC after a Warm-reset Hello Teerth, another question that just occurred to me. On Wed, 13 Jan 2010, Paul Walmsley wrote: @@ -147,10 +149,9 @@ void omap_prcm_arch_reset(char mode) * cf. OMAP34xx TRM, Initialization / Software Booting * Configuration. */ omap_writel(l, OMAP343X_SCRATCHPAD + 4); + omap3_warmreset(); Wouldn't this code need to enable interrupts before calling omap3_sram_warmreset()? Seems like an interrupt could occur after the SDRC has been placed into idle which could effectively hang the ARM. I agree with you. I ll add the changes to disable interrupts before going for a warm reset. I wonder if this also needs to make sure that all the other system initiators are mute before continuing, for the same reason cited in commit 18862cbe47e37beba98f22c088fbe6fe029df889 ? I suppose that, for example, if an interrupt occurs on the IVA2.2 or the DMA controller tries to access the SDRC, it would hopefully only wedge those initiators and not the whole chip? Do you think we need to take care of the system initiators if we are disabling all the interrupts before going for a warm reset? I think this doesn't seem to hold good here. Please let me know if you understanding is wrong. Regards Teerth -- 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] OMAP3: SDRC : Errata 1.176 Fix - Accesses to DDR stall in SDRC after a Warm-reset
On Fri, 15 Jan 2010, Reddy, Teerth wrote: Will send the updated patch. Thanks, all your above responses make sense. What do you think about some of the other comments I had, re: disabling interrupts, etc? - Paul -- 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] OMAP3: SDRC : Errata 1.176 Fix - Accesses to DDR stall in SDRC after a Warm-reset
Some more comments.
On Wed, 13 Jan 2010, Reddy, Teerth wrote:
From: Teerth Reddy tee...@ti.com
This patch has the workaround for errata 1.176.
In some cases, user is not able to access DDR memory after
warm-reset.This situation occurs while the warm-reset
happens during a read access to DDR memory. In that
particular conditions, DDR memory does not respond to a
corrupted read command due to the warm reset occurence but
SDRC is waiting for read completion.SDRC is not sensitive to
the warm reset, but the interconect is reset on the fly,
thus causing a misalignment between SDRC logic, interconect
logic and DDR memory state.
Root cause description: A corrupted read transaction is
issued to a closed row: (address0, bank0) instead of the
expected read access, violating protocol.
Failure signature: Once the failure occurs and system has
restarted, memory content is not accessible.SDRC registers
can be accessed successfully, until 1st access to memory
location is performed. After 1st access to memory is done,
SDRC is stuck.
WORKAROUND
Steps to perform before a SW reset is trigged, if user needs
to generate a SW reset and keep DDR memory content:
1. Enable self-refresh on idle request
2. Put SDRC in idle
3. Wait until SDRC goes to idle
4. Generate SW reset
Steps to perform after warm reset occurs:
If HW warm reset is the source, apply below steps before
any accesses to SDRAM:
1. Reset SMS and SDRC
2. Re-initialize SMS, SDRC and memory
This would need the u-boot/x-loader workaround changes
as well for the reboot to work correctly.
Signed-off-by: Teerth Reddy tee...@ti.com
---
arch/arm/mach-omap2/prcm.c |9 +++--
arch/arm/mach-omap2/sram34xx.S | 50
arch/arm/plat-omap/include/plat/sram.h |7
arch/arm/plat-omap/sram.c | 19
4 files changed, 81 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/prcm.c b/arch/arm/mach-omap2/prcm.c
index 3ea8177..d66711e 100644
--- a/arch/arm/mach-omap2/prcm.c
+++ b/arch/arm/mach-omap2/prcm.c
@@ -26,6 +26,7 @@
#include plat/prcm.h
#include plat/irqs.h
#include plat/control.h
+#include plat/sram.h
#include clock.h
#include cm.h
@@ -134,9 +135,10 @@ void omap_prcm_arch_reset(char mode)
s16 prcm_offs;
omap2_clk_prepare_for_reboot();
- if (cpu_is_omap24xx())
+ if (cpu_is_omap24xx()) {
prcm_offs = WKUP_MOD;
- else if (cpu_is_omap34xx()) {
+ prm_set_mod_reg_bits(OMAP_RST_DPLL3, prcm_offs, RM_RSTCTRL);
+ } else if (cpu_is_omap34xx()) {
u32 l;
prcm_offs = OMAP3430_GR_MOD;
@@ -147,10 +149,9 @@ void omap_prcm_arch_reset(char mode)
* cf. OMAP34xx TRM, Initialization / Software Booting
* Configuration. */
omap_writel(l, OMAP343X_SCRATCHPAD + 4);
+ omap3_warmreset();
Please add a comment to indicate that this function does not return.
} else
WARN_ON(1);
-
- prm_set_mod_reg_bits(OMAP_RST_DPLL3, prcm_offs, RM_RSTCTRL);
}
static inline u32 __omap_prcm_read(void __iomem *base, s16 module, u16 reg)
diff --git a/arch/arm/mach-omap2/sram34xx.S b/arch/arm/mach-omap2/sram34xx.S
index de99ba2..6a425ca 100644
--- a/arch/arm/mach-omap2/sram34xx.S
+++ b/arch/arm/mach-omap2/sram34xx.S
@@ -33,6 +33,8 @@
#include sdrc.h
#include cm.h
+#include prcm-common.h
+#include prm.h
.text
@@ -68,6 +70,9 @@
/* CM_CLKSEL1_PLL bit settings */
#define CORE_DPLL_CLKOUT_DIV_SHIFT 0x1b
+/* PRM_RSTCTRL bit setting */
+#define EN_DPLL3_RESET 0x4
+
/*
* omap3_sram_configure_core_dpll - change DPLL3 M2 divider
*
@@ -313,3 +318,48 @@ core_m2_mask_val:
ENTRY(omap3_sram_configure_core_dpll_sz)
.word . - omap3_sram_configure_core_dpll
+
+/* omap3_sram_warmreset -
+ *
+ * Enable SDRC self refresh on idle request, put SDRC in idle,
+ * wait until SDRC goes to idle
+ * Enable DPLL3 reset bit in RM_RSTCTRL
+ */
This multi-line comment needs to be fixed to conform with CodingStyle as
mentioned in my previous comments.
+
+ENTRY(omap3_sram_warmreset)
+sdram_in_selfrefresh1:
+ ldr r11, omap3_sdrc_power1 @ read the SDRC_POWER register
+ ldr r12, [r11] @ read the contents of SDRC_POWER
+ mov r9, r12 @ keep a copy of SDRC_POWER bits
+ orr r12, r12, #SRFRONIDLEREQ_MASK @ enable self refresh on idle
+ str r12, [r11] @ write back to SDRC_POWER register
+ ldr r12, [r11] @ posted-write barrier for SDRC
+ ldr r11, omap3_cm_iclken1_core1 @ read the CM_ICLKEN1_CORE reg
+ ldr r12, [r11]
+ bic r12, r12, #EN_SDRC_MASK @ disable iclk bit for SDRC
+ str r12, [r11]
+wait_sdrc_idle2:
+ ldr r11, omap3_cm_idlest1_core1
+ ldr
RE: [PATCH] OMAP3: SDRC : Errata 1.176 Fix - Accesses to DDR stall in SDRC after a Warm-reset
Hello Teerth,
On Wed, 13 Jan 2010, Reddy, Teerth wrote:
-Original Message-
From: Paul Walmsley [mailto:p...@pwsan.com]
Your changes -
+/* Function for SDRC config for warm reset */
+static u32 (*_omap3_sram_warmreset)(void);
+
+void omap3_warmreset()
+{
+ if (WARN_ON(!_omap3_sram_warmreset))
+ return;
+
+ return;
+}
The compile warning is due to the return; I had here. I think I might
still want to have this function as u32.
Why?
- Paul
--
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] OMAP3: SDRC : Errata 1.176 Fix - Accesses to DDR stall in SDRC after a Warm-reset
Hello Teerth, another question that just occurred to me. On Wed, 13 Jan 2010, Paul Walmsley wrote: @@ -147,10 +149,9 @@ void omap_prcm_arch_reset(char mode) * cf. OMAP34xx TRM, Initialization / Software Booting * Configuration. */ omap_writel(l, OMAP343X_SCRATCHPAD + 4); + omap3_warmreset(); Wouldn't this code need to enable interrupts before calling omap3_sram_warmreset()? Seems like an interrupt could occur after the SDRC has been placed into idle which could effectively hang the ARM. I wonder if this also needs to make sure that all the other system initiators are mute before continuing, for the same reason cited in commit 18862cbe47e37beba98f22c088fbe6fe029df889 ? I suppose that, for example, if an interrupt occurs on the IVA2.2 or the DMA controller tries to access the SDRC, it would hopefully only wedge those initiators and not the whole chip? - Paul -- 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] OMAP3: SDRC : Errata 1.176 Fix - Accesses to DDR stall in SDRC after a Warm-reset
On Wed, 13 Jan 2010, Paul Walmsley wrote: Wouldn't this code need to enable interrupts before calling omap3_sram_warmreset()? Rather, this should have read, _disable_ interrupts... - Paul -- 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] OMAP3: SDRC : Errata 1.176 Fix - Accesses to DDR stall in SDRC after a Warm-reset
Hello Teerth, On Tue, 5 Jan 2010, Reddy, Teerth wrote: Can you please push this patch if it looks OK to you? Thanks queued for .33-rc*. - Paul -- 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] OMAP3: SDRC : Errata 1.176 Fix - Accesses to DDR stall in SDRC after a Warm-reset
On Wed, 6 Jan 2010, Paul Walmsley wrote:
On Tue, 5 Jan 2010, Reddy, Teerth wrote:
Can you please push this patch if it looks OK to you?
Thanks queued for .33-rc*.
Well, I take that back. I must be going senile. During compile testing,
your patch generated a compile warning. This caused heightened scrutiny
of your patch - no patch should add compile warnings and that should have
been a red flag when you were working on it. Please fix the compile
warning. Please also make the following changes:
- The assembly language code has no return value; please fix.
- The name of the assembly language code should be something short and
to the point like 'omap3_sram_warmreset' rather than all the
'configure_core_dpll' stuff, which does not make sense for this.
- Your multi-line comment is not in CodingStyle form.
- In the existing format of arch/arm/mach-omap2/sram34xx.S, there
are tabs between assembly language instructions and their arguments,
but you use spaces. Please use tabs.
- You need an infinite loop after you write to RM_RSTCTRL.
That write will be posted and the ARM will just re-execute your
SDRC idle code which is presumably not what you want.
- Please re-test your patch after the above changes.
To help you understand what I'm looking for, I've done some of the above
changes; patch below.
- Paul
---
arch/arm/mach-omap2/prcm.c |9 +++--
arch/arm/mach-omap2/sram34xx.S | 51
arch/arm/plat-omap/include/plat/sram.h |7
arch/arm/plat-omap/sram.c | 18 +++
4 files changed, 81 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/prcm.c b/arch/arm/mach-omap2/prcm.c
index 3ea8177..d66711e 100644
--- a/arch/arm/mach-omap2/prcm.c
+++ b/arch/arm/mach-omap2/prcm.c
@@ -26,6 +26,7 @@
#include plat/prcm.h
#include plat/irqs.h
#include plat/control.h
+#include plat/sram.h
#include clock.h
#include cm.h
@@ -134,9 +135,10 @@ void omap_prcm_arch_reset(char mode)
s16 prcm_offs;
omap2_clk_prepare_for_reboot();
- if (cpu_is_omap24xx())
+ if (cpu_is_omap24xx()) {
prcm_offs = WKUP_MOD;
- else if (cpu_is_omap34xx()) {
+ prm_set_mod_reg_bits(OMAP_RST_DPLL3, prcm_offs, RM_RSTCTRL);
+ } else if (cpu_is_omap34xx()) {
u32 l;
prcm_offs = OMAP3430_GR_MOD;
@@ -147,10 +149,9 @@ void omap_prcm_arch_reset(char mode)
* cf. OMAP34xx TRM, Initialization / Software Booting
* Configuration. */
omap_writel(l, OMAP343X_SCRATCHPAD + 4);
+ omap3_warmreset();
} else
WARN_ON(1);
-
- prm_set_mod_reg_bits(OMAP_RST_DPLL3, prcm_offs, RM_RSTCTRL);
}
static inline u32 __omap_prcm_read(void __iomem *base, s16 module, u16 reg)
diff --git a/arch/arm/mach-omap2/sram34xx.S b/arch/arm/mach-omap2/sram34xx.S
index de99ba2..432777a 100644
--- a/arch/arm/mach-omap2/sram34xx.S
+++ b/arch/arm/mach-omap2/sram34xx.S
@@ -33,6 +33,8 @@
#include sdrc.h
#include cm.h
+#include prcm-common.h
+#include prm.h
.text
@@ -68,6 +70,9 @@
/* CM_CLKSEL1_PLL bit settings */
#define CORE_DPLL_CLKOUT_DIV_SHIFT 0x1b
+/* PRM_RSTCTRL bit setting */
+#define EN_DPLL3_RESET 0x4
+
/*
* omap3_sram_configure_core_dpll - change DPLL3 M2 divider
*
@@ -313,3 +318,49 @@ core_m2_mask_val:
ENTRY(omap3_sram_configure_core_dpll_sz)
.word . - omap3_sram_configure_core_dpll
+
+/*
+ * omap3_sram_warmreset
+ * Enable SDRC self refresh on idle request, put SDRC in idle,
+ * wait until SDRC goes to idle
+ * Enable DPLL3 reset bit in RM_RSTCTRL
+ */
+
+ENTRY(omap3_sram_warmreset)
+
+sdram_in_selfrefresh1:
+ ldr r11, omap3_sdrc_power1 @ read the SDRC_POWER register
+ ldr r12, [r11] @ read the contents of SDRC_POWER
+ mov r9, r12 @ keep a copy of SDRC_POWER bits
+ orr r12, r12, #SRFRONIDLEREQ_MASK @ enable self refresh on idle
+ str r12, [r11] @ write back to SDRC_POWER register
+ ldr r12, [r11] @ posted-write barrier for SDRC
+ ldr r11, omap3_cm_iclken1_core1 @ read the CM_ICLKEN1_CORE reg
+ ldr r12, [r11]
+ bic r12, r12, #EN_SDRC_MASK @ disable iclk bit for SDRC
+ str r12, [r11]
+wait_sdrc_idle2:
+ ldr r11, omap3_cm_idlest1_core1
+ ldr r12, [r11]
+ and r12, r12, #ST_SDRC_MASK @ check for SDRC idle
+ cmp r12, #ST_SDRC_MASK
+ bne wait_sdrc_idle2
+osw_warm_reset:
+ ldr r11, omap3_reset_cntrl
+ ldr r12, [r11]
+ orr r12, r12, #EN_DPLL3_RESET @ Enable DPLL3 reset bit
+ str r12, [r11]
+osw_loop:
+ b osw_loop
+
+omap3_reset_cntrl:
+ .word OMAP34XX_PRM_REGADDR(OMAP3430_GR_MOD, RM_RSTCTRL)
+omap3_sdrc_power1:
+ .word
RE: [PATCH] OMAP3: SDRC : Errata 1.176 Fix - Accesses to DDR stall in SDRC after a Warm-reset
Hi Tony,
Can you please push this patch if it looks OK to you?
Thanks and Regards,
Teerth
-Original Message-
From: Reddy, Teerth
Sent: Wednesday, December 16, 2009 4:13 PM
To: 'linux-omap@vger.kernel.org'
Subject: [PATCH] OMAP3: SDRC : Errata 1.176 Fix - Accesses to DDR stall in
SDRC after a Warm-reset
Updated with Kevin's comments.
From: Teerth Reddy tee...@ti.com
This patch has the workaround for errata 1.176.
In some cases, user is not able to access DDR memory after
warm-reset.This situation occurs while the warm-reset
happens during a read access to DDR memory. In that
particular conditions, DDR memory does not respond to a
corrupted read command due to the warm reset occurence but
SDRC is waiting for read completion.SDRC is not sensitive to
the warm reset, but the interconect is reset on the fly,
thus causing a misalignment between SDRC logic, interconect
logic and DDR memory state.
Root cause description: A corrupted read transaction is
issued to a closed row: (address0, bank0) instead of the
expected read access, violating protocol.
Failure signature: Once the failure occurs and system has
restarted, memory content is not accessible.SDRC registers
can be accessed successfully, until 1st access to memory
location is performed. After 1st access to memory is done,
SDRC is stuck.
WORKAROUND
Steps to perform before a SW reset is trigged, if user needs
to generate a SW reset and keep DDR memory content:
1. Enable self-refresh on idle request
2. Put SDRC in idle
3. Wait until SDRC goes to idle
4. Generate SW reset
Steps to perform after warm reset occurs:
If HW warm reset is the source, apply below steps before
any accesses to SDRAM:
1. Reset SMS and SDRC
2. Re-initialize SMS, SDRC and memory
This would need the u-boot/x-loader workaround changes
as well for the reboot to work correctly.
Signed-off-by: Teerth Reddy tee...@ti.com
---
arch/arm/mach-omap2/prcm.c |9 +++--
arch/arm/mach-omap2/sram34xx.S | 50
arch/arm/plat-omap/include/plat/sram.h |7
arch/arm/plat-omap/sram.c | 20 +
4 files changed, 82 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/prcm.c b/arch/arm/mach-omap2/prcm.c
index 3ea8177..0dedd91 100644
--- a/arch/arm/mach-omap2/prcm.c
+++ b/arch/arm/mach-omap2/prcm.c
@@ -26,6 +26,7 @@
#include plat/prcm.h
#include plat/irqs.h
#include plat/control.h
+#include plat/sram.h
#include clock.h
#include cm.h
@@ -134,9 +135,10 @@ void omap_prcm_arch_reset(char mode)
s16 prcm_offs;
omap2_clk_prepare_for_reboot();
- if (cpu_is_omap24xx())
+ if (cpu_is_omap24xx()) {
prcm_offs = WKUP_MOD;
- else if (cpu_is_omap34xx()) {
+ prm_set_mod_reg_bits(OMAP_RST_DPLL3, prcm_offs, RM_RSTCTRL);
+ } else if (cpu_is_omap34xx()) {
u32 l;
prcm_offs = OMAP3430_GR_MOD;
@@ -147,10 +149,9 @@ void omap_prcm_arch_reset(char mode)
* cf. OMAP34xx TRM, Initialization / Software Booting
* Configuration. */
omap_writel(l, OMAP343X_SCRATCHPAD + 4);
+ omap3_configure_core_dpll_warmreset();
} else
WARN_ON(1);
-
- prm_set_mod_reg_bits(OMAP_RST_DPLL3, prcm_offs, RM_RSTCTRL);
}
static inline u32 __omap_prcm_read(void __iomem *base, s16 module, u16
reg)
diff --git a/arch/arm/mach-omap2/sram34xx.S b/arch/arm/mach-
omap2/sram34xx.S
index de99ba2..0294b0f 100644
--- a/arch/arm/mach-omap2/sram34xx.S
+++ b/arch/arm/mach-omap2/sram34xx.S
@@ -33,6 +33,8 @@
#include sdrc.h
#include cm.h
+#include prcm-common.h
+#include prm.h
.text
@@ -68,6 +70,9 @@
/* CM_CLKSEL1_PLL bit settings */
#define CORE_DPLL_CLKOUT_DIV_SHIFT 0x1b
+/* PRM_RSTCTRL bit setting */
+#define EN_DPLL3_RESET 0x4
+
/*
* omap3_sram_configure_core_dpll - change DPLL3 M2 divider
*
@@ -313,3 +318,48 @@ core_m2_mask_val:
ENTRY(omap3_sram_configure_core_dpll_sz)
.word . - omap3_sram_configure_core_dpll
+
+/* omap3_sram_configure_core_dpll_warmreset
+* Enable SDRC self refresh on idle request, put SDRC in idle,
+* wait until SDRC goes to idle
+* Enable DPLL3 reset bit in RM_RSTCTRL
+*/
+
+ENTRY(omap3_sram_configure_core_dpll_warmreset)
+
+ bl sdram_in_selfrefresh1
+ ldr r11, omap3_reset_cntrl
+ ldr r12, [r11]
+ orr r12, r12, #EN_DPLL3_RESET @ Enable DPLL3 reset bit
+ str r12, [r11]
+
+sdram_in_selfrefresh1:
+ ldr r11, omap3_sdrc_power1 @ read the SDRC_POWER register
+ ldr r12, [r11] @ read the contents of SDRC_POWER
+ mov r9, r12 @ keep a copy of SDRC_POWER bits
+ orr r12, r12, #SRFRONIDLEREQ_MASK @ enable self refresh on
idle
+ str r12, [r11] @ write back to
