From patchwork Wed May 13 00:05:15 2009 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Paul Walmsley X-Patchwork-Id: 23398 Received: from vger.kernel.org (vger.kernel.org [209.132.176.167]) by demeter.kernel.org (8.14.2/8.14.2) with ESMTP id n4D07h4c005431 for ; Wed, 13 May 2009 00:07:43 GMT Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756704AbZEMAHk (ORCPT ); Tue, 12 May 2009 20:07:40 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1756361AbZEMAHj (ORCPT ); Tue, 12 May 2009 20:07:39 -0400 Received: from utopia.booyaka.com ([72.9.107.138]:56377 "EHLO utopia.booyaka.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752439AbZEMAHi (ORCPT ); Tue, 12 May 2009 20:07:38 -0400 Received: (qmail 10591 invoked by uid 526); 13 May 2009 00:07:38 -0000 MBOX-Line: From nobody Tue May 12 18:05:15 2009 From: Paul Walmsley Subject: [PATCH 01/10] OMAP3 SRAM: mark OCM RAM as Non-cacheable Normal memory To: linux-arm-kernel@lists.arm.linux.org.uk Cc: linux-kernel@vger.kernel.org, linux-omap@vger.kernel.org, Paul Walmsley , Tero Kristo , Richard Woodruff Date: Tue, 12 May 2009 18:05:15 -0600 Message-ID: <20090513000509.10349.87859.stgit@localhost.localdomain> In-Reply-To: <20090512235713.10349.49339.stgit@localhost.localdomain> References: <20090512235713.10349.49339.stgit@localhost.localdomain> User-Agent: StGIT/0.14.3.222.gddca MIME-Version: 1.0 Sender: linux-omap-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-omap@vger.kernel.org Mark the SRAM (aka OCM RAM) as Non-cacheable Normal memory[1]. This is to prevent the ARM from evicting existing cache lines to SDRAM while code is executing from the SRAM. Necessary since one of the primary uses for the SRAM is to hold the code and data for the CORE DPLL M2 divider reprogramming code, which must execute while the SDRC is idled. If the ARM attempts to write cache lines back to the while the SRAM code is running, the ARM will stall[2]. TI deals with this problem in the CDP kernel by marking the SRAM as Strongly-ordered memory. Tero Kristo caught a bug in an earlier version of this patch - thanks Tero. ... 1. ARMv7 ARM (DDI 0406A) pp. A3-30, A3-31, B3-32. 2. Private communication with Richard Woodruff Signed-off-by: Paul Walmsley Cc: Tero Kristo Cc: Richard Woodruff --- arch/arm/plat-omap/sram.c | 9 +++++++++ 1 files changed, 9 insertions(+), 0 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/arch/arm/plat-omap/sram.c b/arch/arm/plat-omap/sram.c index fa5297d..3835338 100644 --- a/arch/arm/plat-omap/sram.c +++ b/arch/arm/plat-omap/sram.c @@ -201,6 +201,15 @@ void __init omap_map_sram(void) base = OMAP3_SRAM_PA; base = ROUND_DOWN(base, PAGE_SIZE); omap_sram_io_desc[0].pfn = __phys_to_pfn(base); + + /* + * SRAM must be marked as non-cached on OMAP3 since the + * CORE DPLL M2 divider change code (in SRAM) runs with the + * SDRAM controller disabled, and if it is marked cached, + * the ARM may attempt to write cache lines back to SDRAM + * which will cause the system to hang. + */ + omap_sram_io_desc[0].type = MT_MEMORY_NONCACHED; } omap_sram_io_desc[0].length = 1024 * 1024; /* Use section desc */