]> pilppa.com Git - linux-2.6-omap-h63xx.git/commit
[ARM] 5422/1: ARM: MMU: add a Non-cacheable Normal executable memory type
authorPaul Walmsley <paul@pwsan.com>
Thu, 12 Mar 2009 19:11:43 +0000 (20:11 +0100)
committerRussell King <rmk+kernel@arm.linux.org.uk>
Thu, 12 Mar 2009 19:25:02 +0000 (19:25 +0000)
commite4707dd3e9d0cb57597b6568a5e51fea5d6fca41
treec76a6cb54e4f90a8deebf380bf8fe8a5f6eb2750
parent6dc4a47a0cf423879b505af0e29997fca4088630
[ARM] 5422/1: ARM: MMU: add a Non-cacheable Normal executable memory type

This patch adds a Non-cacheable Normal ARM executable memory type,
MT_MEMORY_NONCACHED.

On OMAP3, this is used for rapid dynamic voltage/frequency scaling in
the VDD2 voltage domain. OMAP3's SDRAM controller (SDRC) is in the
VDD2 voltage domain, and its clock frequency must change along with
voltage. The SDRC clock change code cannot run from SDRAM itself,
since SDRAM accesses are paused during the clock change. So the
current implementation of the DVFS code executes from OMAP on-chip
SRAM, aka "OCM RAM."

If the OCM RAM pages are marked as Cacheable, the ARM cache controller
will attempt to flush dirty cache lines to the SDRC, so it can fill
those lines with OCM RAM instruction code. The problem is that the
SDRC is paused during DVFS, and so any SDRAM access causes the ARM MPU
subsystem to hang.

TI's original solution to this problem was to mark the OCM RAM
sections as Strongly Ordered memory, thus preventing caching. This is
overkill: since the memory is marked as non-bufferable, OCM RAM writes
become needlessly slow. The idea of "Strongly Ordered SRAM" is also
conceptually disturbing. Previous LAKML list discussion is here:

http://www.spinics.net/lists/arm-kernel/msg54312.html

This memory type MT_MEMORY_NONCACHED is used for OCM RAM by a future
patch.

Cc: Richard Woodruff <r-woodruff2@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
arch/arm/include/asm/mach/map.h
arch/arm/mm/mmu.c