summaryrefslogtreecommitdiff
path: root/fs/jbd/journal.c
diff options
context:
space:
mode:
authorPaul Walmsley <paul@pwsan.com>2009-03-12 20:11:43 +0100
committerRussell King <rmk+kernel@arm.linux.org.uk>2009-03-12 19:25:02 +0000
commite4707dd3e9d0cb57597b6568a5e51fea5d6fca41 (patch)
treec76a6cb54e4f90a8deebf380bf8fe8a5f6eb2750 /fs/jbd/journal.c
parent6dc4a47a0cf423879b505af0e29997fca4088630 (diff)
[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>
Diffstat (limited to 'fs/jbd/journal.c')
0 files changed, 0 insertions, 0 deletions