OMAP2/3: SRAM: add comment about crashes during a TLB miss

Some users were observing crashes during the execution of CORE DVFS
code from OCM RAM -- a locally-modified copy of the linux-omap code.
Richard Woodruff tracked this down to a DTLB miss which had been
inadvertently and intermittently caused by the local modifications.
(The TLB miss caused the ARM MMU to attempt to walk the page tables
stored in SDRAM, which was not possible since SDRAM is off-line for a
portion of the CORE DVFS OCM RAM code.)

Add a note to the OMAP2 & OMAP3 CORE DVFS SRAM code to warn others that
changes may result in crashes here if they are not carefully tested.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Richard Woodruff <r-woodruff2@ti.com>
Cc: Jon Hunter <jon-hunter@ti.com>
Cc: Nishanth Menon <nm@ti.com>

1 files changed, 6 insertions, 0 deletions

diff --git a/arch/arm/mach-omap2/sram34xx.S b/arch/arm/mach-omap2/sram34xx.S
index b7aba60..7f893a2 100644
--- a/arch/arm/mach-omap2/sram34xx.S
+++ b/arch/arm/mach-omap2/sram34xx.S
@@ -104,6 +104,12 @@
  * 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.
+ *
+ * Richard Woodruff notes that any changes to this code must be carefully
+ * audited and tested to ensure that they don't cause a TLB miss while
+ * the SDRAM is inaccessible.  Such a situation will crash the system
+ * since it will cause the ARM MMU to attempt to walk the page tables.
+ * These crashes may be intermittent.
  */
 ENTRY(omap3_sram_configure_core_dpll)
 	stmfd	sp!, {r1-r12, lr}	@ store regs to stack