From: paul@pwsan.com (Paul Walmsley)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 7/9] OMAP3: SDRC: Place SDRC AC timing and MR changes in CORE DVFS SRAM code behind Kconfig
Date: Thu, 03 Dec 2009 06:45:43 -0700 [thread overview]
Message-ID: <20091203134539.16229.20330.stgit@localhost.localdomain> (raw)
In-Reply-To: <20091203134321.16229.87539.stgit@localhost.localdomain>
The code that reprograms the SDRC memory controller during CORE DVFS,
mach-omap2/sram34xx.S:omap3_sram_configure_core_dpll(), does not
ensure that all L3 initiators are prevented from accessing the SDRAM
before modifying the SDRC AC timing and MR registers. This can cause
memory to be corrupted or cause the SDRC to enter an unpredictable
state. This patch places that code behind a Kconfig option,
CONFIG_OMAP3_SDRC_AC_TIMING for now, and adds a note explaining what
is going on. Ideally the code can be added back in once supporting
code is present to ensure that other initiators aren't touching the
SDRAM. At the very least, these registers should be reprogrammable
during kernel init to deal with buggy bootloaders. Users who know
that all other system initiators will not be touching the SDRAM can
also re-enable this Kconfig option.
This is a modification of a patch originally written by Rajendra Nayak
<rnayak@ti.com> (the original is at http://patchwork.kernel.org/patch/51927/).
Rather than removing the code completely, this patch just comments it out.
Thanks to Beno?t Cousson <b-cousson@ti.com> and Christophe Sucur
<c-sucur@ti.com> for explaining the technical basis for this and for
explaining what can be done to make this path work in future code.
Thanks to Richard Woodruff <r-woodruff2@ti.com> and Nishanth Menon
<nm@ti.com> for their comments.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Rajendra Nayak <rnayak@ti.com>
Cc: Christophe Sucur <c-sucur@ti.com>
Cc: Beno?t Cousson <b-cousson@ti.com>
Cc: Richard Woodruff <r-woodruff2@ti.com>
Cc: Nishanth Menon <nm@ti.com>
---
arch/arm/mach-omap2/Kconfig | 13 +++++++++++++
arch/arm/mach-omap2/sram34xx.S | 19 +++++++++++++++++--
2 files changed, 30 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index aad194f..a8d2610 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -100,3 +100,16 @@ config MACH_OMAP_ZOOM2
config MACH_OMAP_4430SDP
bool "OMAP 4430 SDP board"
depends on ARCH_OMAP4
+
+config OMAP3_SDRC_AC_TIMING
+ bool "Enable SDRC AC timing register changes"
+ depends on ARCH_OMAP3 && ARCH_OMAP34XX
+ default n
+ help
+ If you know that none of your system initiators will attempt to
+ access SDRAM during CORE DVFS, select Y here. This should boost
+ SDRAM performance at lower CORE OPPs. There are relatively few
+ users who will wish to say yes at this point - almost everyone will
+ wish to say no. Selecting yes without understanding what is
+ going on could result in system crashes;
+
diff --git a/arch/arm/mach-omap2/sram34xx.S b/arch/arm/mach-omap2/sram34xx.S
index 82aa4a3..de99ba2 100644
--- a/arch/arm/mach-omap2/sram34xx.S
+++ b/arch/arm/mach-omap2/sram34xx.S
@@ -91,8 +91,19 @@
* new SDRC_ACTIM_CTRL_B_1 register contents
* new SDRC_MR_1 register value
*
- * If the param SDRC_RFR_CTRL_1 is 0, the parameters
- * are not programmed into the SDRC CS1 registers
+ * If the param SDRC_RFR_CTRL_1 is 0, the parameters are not programmed into
+ * the SDRC CS1 registers
+ *
+ * NOTE: This code no longer attempts to program the SDRC AC timing and MR
+ * registers. This is because the code currently cannot ensure that all
+ * L3 initiators (e.g., sDMA, IVA, DSS DISPC, etc.) are not accessing the
+ * SDRAM when the registers are written. If the registers are changed while
+ * an initiator is accessing SDRAM, memory can be corrupted and/or the SDRC
+ * may enter an unpredictable state. In the future, the intent is to
+ * re-enable this code in cases where we can ensure that no initiators are
+ * touching the SDRAM. Until that time, users who know that their use case
+ * can satisfy the above requirement can enable the CONFIG_OMAP3_SDRC_AC_TIMING
+ * option.
*/
ENTRY(omap3_sram_configure_core_dpll)
stmfd sp!, {r1-r12, lr} @ store regs to stack
@@ -219,6 +230,7 @@ configure_sdrc:
ldr r12, omap_sdrc_rfr_ctrl_0_val @ fetch value from SRAM
ldr r11, omap3_sdrc_rfr_ctrl_0 @ fetch addr from SRAM
str r12, [r11] @ store
+#ifdef CONFIG_OMAP3_SDRC_AC_TIMING
ldr r12, omap_sdrc_actim_ctrl_a_0_val
ldr r11, omap3_sdrc_actim_ctrl_a_0
str r12, [r11]
@@ -228,11 +240,13 @@ configure_sdrc:
ldr r12, omap_sdrc_mr_0_val
ldr r11, omap3_sdrc_mr_0
str r12, [r11]
+#endif
ldr r12, omap_sdrc_rfr_ctrl_1_val
cmp r12, #0 @ if SDRC_RFR_CTRL_1 is 0,
beq skip_cs1_prog @ do not program cs1 params
ldr r11, omap3_sdrc_rfr_ctrl_1
str r12, [r11]
+#ifdef CONFIG_OMAP3_SDRC_AC_TIMING
ldr r12, omap_sdrc_actim_ctrl_a_1_val
ldr r11, omap3_sdrc_actim_ctrl_a_1
str r12, [r11]
@@ -242,6 +256,7 @@ configure_sdrc:
ldr r12, omap_sdrc_mr_1_val
ldr r11, omap3_sdrc_mr_1
str r12, [r11]
+#endif
skip_cs1_prog:
ldr r12, [r11] @ posted-write barrier for SDRC
bx lr
next prev parent reply other threads:[~2009-12-03 13:45 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-12-03 13:45 [PATCH 0/9] Minor powerdomain/clockdomain/SDRC patches for 2.6.33 Paul Walmsley
2009-12-03 13:45 ` [PATCH 1/9] OMAP2/3 PRCM: don't export prm_*(), cm_*() functions Paul Walmsley
2009-12-03 13:45 ` [PATCH 2/9] OMAP clockdomain/powerdomain: remove CONFIG_OMAP_DEBUG_{CLOCK, POWER}DOMAIN Paul Walmsley
2009-12-03 13:45 ` [PATCH 3/9] OMAP clockdomain/powerdomain: optimize out sleepdep code on OMAP24xx Paul Walmsley
2009-12-03 13:45 ` [PATCH 4/9] OMAP powerdomain/PM: use symbolic constants for the max number of power states Paul Walmsley
2009-12-03 13:45 ` [PATCH 5/9] OMAP powerdomain: rearrange struct powerdomain to save some memory Paul Walmsley
2009-12-03 13:45 ` [PATCH 6/9] OMAP2/3 powerdomain: return errors rather than returning the output of IS_ERR() Paul Walmsley
2009-12-03 13:45 ` Paul Walmsley [this message]
2009-12-03 13:45 ` [PATCH 8/9] OMAP3: PM: Fix for MPU power domain MEM BANK position Paul Walmsley
2009-12-03 13:45 ` [PATCH 9/9] OMAP clock/hwmod: fix off-by-one errors Paul Walmsley
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20091203134539.16229.20330.stgit@localhost.localdomain \
--to=paul@pwsan.com \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox