From: Albert ARIBAUD <albert.u.boot@aribaud.net>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] ARM926ejs: Add routines to invalidate D-Cache
Date: Mon, 08 Aug 2011 10:01:19 +0200 [thread overview]
Message-ID: <4E3F97CF.8080000@aribaud.net> (raw)
In-Reply-To: <1312773617-10859-1-git-send-email-hong.xu@atmel.com>
Hi Hong Xu,
Le 08/08/2011 05:20, Hong Xu a ?crit :
> After DMA operation, we need to maintain D-Cache coherency.
> So that the DCache must be invalidated (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.u.boot@aribaud.net>
> CC: Aneesh V<aneesh@ti.com>
> CC: Reinhard Meyer<u-boot@emk-elektronik.de>
> CC: Heiko Schocher<hs@denx.de>
> ---
> V2:
> Per Albert's suggestion, add invalidate_dcache_range
>
> V3:
> invalidate_dcache_range emits warning when detecting unaligned buffer
>
> invalidate_dcache_range won't clean any adjacent cache line when detecting
> unaligned buffer and only round up/down the buffer address
> + mva = start;
> + if ((mva& (cache_line_len - 1)) != 0) {
> + printf("WARNING: %s - unaligned buffer detected, starting "
I'd rather have a message about "cache", not "buffer", e.g.
printf("WARNING: %s - start address %x is not aligned\n"
__FUNCTION__, start);
> + mva&= ~(cache_line_len - 1);
> + }
> + if ((stop& (cache_line_len - 1)) != 0) {
> + printf("WARNING: %s - unaligned buffer detected, ending "
> + "address: 0x%08x\n", __FUNCTION__, stop);
Ditto.
> + stop = (stop | (cache_line_len - 1)) + 1;
> + }
> +
> + while (mva< stop) {
> + asm("mcr p15, 0, %0, c7, c6, 1" : : "r"(mva));
> + mva += cache_line_len;
> + }
Thinking more about the degenerate case -- why not round *up* the start
address, and round *down* the stop address, that is, *reduce* the area
to the aligned portion rather than *expand* it into the unknown? That
would make data in "partially owned" cache lines safe from unwanted
invalidation. OTOH, it would not completely invalidate the caller's
data, but at least the malfunction would appear in the faulty calling
code, not elsewhere.
Opinions?
Amicalement,
--
Albert.
next prev parent reply other threads:[~2011-08-08 8:01 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-08 3:20 [U-Boot] [PATCH] ARM926ejs: Add routines to invalidate D-Cache Hong Xu
2011-08-08 8:01 ` Albert ARIBAUD [this message]
2011-08-08 8:58 ` Hong Xu
2011-08-08 17:34 ` Marek Vasut
2011-08-08 17:56 ` Albert ARIBAUD
2011-08-09 1:57 ` Hong Xu
2011-08-09 19:55 ` Marek Vasut
2011-08-10 1:45 ` Hong Xu
2011-08-10 2:46 ` Marek Vasut
2011-08-09 11:05 ` Aneesh V
-- strict thread matches above, loose matches on Subject: below --
2011-08-04 3:45 Hong Xu
2011-08-04 7:11 ` 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=4E3F97CF.8080000@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