summaryrefslogtreecommitdiff
path: root/block/blk-settings.c
diff options
context:
space:
mode:
authorDavid Howells <dhowells@redhat.com>2011-03-18 16:54:29 +0000
committerDavid Howells <dhowells@redhat.com>2011-03-18 16:54:29 +0000
commitb75bb2365d50f73c09e42cf2de07f5805a3988ea (patch)
tree53314749f3c9fc43d1d1f351a2704a0741949549 /block/blk-settings.c
parent9ee21723ccc30070f47c411826d4ed013cd050c2 (diff)
MN10300: The icache invalidate functions should disable the icache first
The icache invalidate functions should disable the icache on AM33 and wait for it to quiesce before attempting to invalidate it, and should then wait for it to quiesce again before reenabling it, but on AM34 they should invalidate directly. The same goes for the dcache invalidation, but this isn't used much. Whilst we're at it, this can be wrapped in assembler macros to remove duplicate code. The AM33 manual states that: An operation that invalidates the cache, switches the writing mode, or changes the way mode must be performed after disabling the cache, checking the busy bit, and confirming that the cache is not in operation. for the dcache [sec 2.8.3.2.1]. This is not stated so for the icache [sec 2.8.3.1.1] but the example code there suggests that it is. Whilst the AM34 manual states that the cache must be disabled for both the icache [sec 1.8.3.2.1] and the dcache [sec 1.8.3.2.1], the Panasonic hardware engineers say the manual is wrong and that disabling the caches for invalidation is wrong. Furthermore, they say that disabling the caches on the AM34 whilst running an SMP kernel can lead to incoherency between the various CPU caches and should thus be avoided. Signed-off-by: David Howells <dhowells@redhat.com>
Diffstat (limited to 'block/blk-settings.c')
0 files changed, 0 insertions, 0 deletions