From: Albert ARIBAUD <albert.u.boot@aribaud.net>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH v2] ARM926ejs: Add routines to invalidate D-Cache
Date: Fri, 05 Aug 2011 08:13:42 +0200 [thread overview]
Message-ID: <4E3B8A16.50604@aribaud.net> (raw)
In-Reply-To: <1312519452-22926-1-git-send-email-hong.xu@atmel.com>
Hi Hong Xu,
Le 05/08/2011 06:44, Hong Xu a ?crit :
> After DMA operation, we need to maintain D-Cache coherency.
> We need to clean cache (write back the dirty lines) and then
> make the cache invalidate as well(hence CPU will fetch data
> written by DMA controller from RAM).
>
> Tested on AT91SAM9261EK with Peripheral DMA controller.
>
> Signed-off-by: Hong Xu<hong.xu@atmel.com>
> Tested-by: Elen Song<elen.song@atmel.com>
> CC: Albert Aribaud<albert.aribaud@free.fr>
> CC: Heiko Schocher<hs@denx.de>
> ---
> Changes since v1
> ~ Per Albert's suggestion, add invalidate_dcache_range originally defined
> in include/common.h
>
> arch/arm/lib/cache.c | 46 ++++++++++++++++++++++++++++++++++++++++++++++
> 1 files changed, 46 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/lib/cache.c b/arch/arm/lib/cache.c
> index 92b61a2..0436443 100644
> --- a/arch/arm/lib/cache.c
> +++ b/arch/arm/lib/cache.c
> @@ -53,3 +53,49 @@ void __flush_dcache_all(void)
> }
> void flush_dcache_all(void)
> __attribute__((weak, alias("__flush_dcache_all")));
> +
> +void __invalidate_dcache_range(unsigned long start, unsigned long stop)
> +{
> + int cache_line_len;
> + unsigned long mva;
> +
> +#ifdef CONFIG_ARM926EJS
> +
> +#ifdef CONFIG_SYS_CACHELINE_SIZE
> + cache_line_len = CONFIG_SYS_CACHELINE_SIZE;
> +#else
> + cache_line_len = 32;
Document magic number 32 -- for instance, indicate ARM architecture spec
paragraph reference in a comment above it (and possibly emit a
compile-time and/or run-time warning) -- or bail out with a compile
error if CONFIG_SYS_CACHELINE_SIZE is not defined.
> +#endif
> + /*
> + * If start and stop are not aligned to cache-line,
> + * the adjacent lines will be cleaned
> + */
> + if ((start& (cache_line_len - 1)) != 0)
> + asm("mcr p15, 0, %0, c7, c10, 1" : : "r" (start));
> + if ((stop& (cache_line_len - 1)) != 0)
> + asm("mcr p15, 0, %0, c7, c10, 1" : : "r" (stop));
> +
> + mva = start& ~(cache_line_len - 1);
> + while (mva< stop) {
> + asm("mcr p15, 0, %0, c7, c6, 1" : : "r"(mva));
> + mva += cache_line_len;
> + }
I, like Reinhard, prefer aligning start and stop and then looping
through a single invalidate mcr.
But I also want to make sure logs tell us anything weird with caches,
and since unaligned start or stop invalidation could lead to trashing
third party data, I would like the code to emit a run-time warning if
that happens, like this:
if ((start& (cache_line_len - 1)) != 0) {
printf("WARNING: aligning start %x on start of cache line\n",
start);
start &= ~(cache_line_len - 1);
}
if ((stop& (cache_line_len - 1)) != (cache_line_len -1) ) {
printf("WARNING: aligning stop %x on end of cache line\n",
stop);
start |= (cache_line_len - 1);
}
That will guarantee that unaligned cache invalidates will be detectable,
and/or that will entice developers to align their starts and stops.
> + /* Drain the WB */
> + asm("mcr p15, 0, %0, c7, c10, 4" : : "r" (0));
> +#endif
> +
> + return;
> +}
> +void invalidate_dcache_range(unsigned long start, unsigned long stop)
> + __attribute__((weak, alias("__invalidate_dcache_range")));
> +
> +void __invalidate_dcache_all(void)
> +{
> +#ifdef CONFIG_ARM926EJS
> + asm("mcr p15, 0, %0, c7, c6, 0" : : "r" (0));
> +#endif
> + return;
> +}
> +void invalidate_dcache_all(void)
> + __attribute__((weak, alias("__invalidate_dcache_all")));
Amicalement,
--
Albert.
next prev parent reply other threads:[~2011-08-05 6:13 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-05 4:44 [U-Boot] [PATCH v2] ARM926ejs: Add routines to invalidate D-Cache Hong Xu
2011-08-05 5:11 ` Reinhard Meyer
2011-08-05 6:17 ` Hong Xu
2011-08-05 6:22 ` Albert ARIBAUD
2011-08-05 6:13 ` Albert ARIBAUD [this message]
2011-08-05 6:38 ` Hong Xu
2011-08-05 6:46 ` Albert ARIBAUD
2011-08-05 7:02 ` Hong Xu
2011-08-05 7:10 ` Aneesh V
2011-08-05 9:20 ` Albert ARIBAUD
2011-08-05 9:56 ` Aneesh V
2011-08-05 10:33 ` Hong Xu
2011-08-05 10:47 ` Aneesh V
2011-08-05 11:03 ` Albert ARIBAUD
2011-08-05 11:23 ` Reinhard Meyer
2011-08-05 11:26 ` Albert ARIBAUD
2011-08-05 11:51 ` Aneesh V
2011-08-05 13:17 ` Albert ARIBAUD
2011-08-05 14:59 ` Aneesh V
2011-08-07 6:55 ` Albert ARIBAUD
2011-08-08 8:24 ` Aneesh V
2011-08-08 9:39 ` Albert ARIBAUD
2011-08-08 9:51 ` Aneesh V
2011-08-08 9:59 ` Reinhard Meyer
2011-08-08 10:12 ` Aneesh V
2011-08-08 10:25 ` Reinhard Meyer
2011-08-08 10:27 ` Aneesh V
2011-08-08 11:05 ` Albert ARIBAUD
2011-08-05 23:04 ` J. William Campbell
2011-08-07 7:07 ` Albert ARIBAUD
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4E3B8A16.50604@aribaud.net \
--to=albert.u.boot@aribaud.net \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox