From: Marek Vasut <marek.vasut@gmail.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] ARM926ejs: Add routines to invalidate D-Cache
Date: Mon, 8 Aug 2011 19:34:50 +0200 [thread overview]
Message-ID: <201108081934.50668.marek.vasut@gmail.com> (raw)
In-Reply-To: <4E3F97CF.8080000@aribaud.net>
On Monday, August 08, 2011 10:01:19 AM Albert ARIBAUD wrote:
> 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);
__func__ is prefered in linux kernel :-)
>
> > + 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.
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.
That'd introduce even stranger behaviour and it'd be even more sickening to
debug
>
> Opinions?
>
> Amicalement,
next prev parent reply other threads:[~2011-08-08 17:34 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
2011-08-08 8:58 ` Hong Xu
2011-08-08 17:34 ` Marek Vasut [this message]
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=201108081934.50668.marek.vasut@gmail.com \
--to=marek.vasut@gmail.com \
--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