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: Tue, 9 Aug 2011 21:55:24 +0200 [thread overview]
Message-ID: <201108092155.24250.marek.vasut@gmail.com> (raw)
In-Reply-To: <4E409415.1030005@atmel.com>
On Tuesday, August 09, 2011 03:57:41 AM Hong Xu wrote:
> Hi Marek Vasut,
>
> On 08/09/2011 01:34 AM, Marek Vasut wrote:
> > 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 :-)
>
> __func__ is C99 standard. __FUNCTION__ appears more in U-Boot. ;-)
This doesn't mean it's correct ;-) "majority proof" isn't a proof really.
> GCC manual says some older GCC only recognize __FUNCTION__ .
> If we rely on GCC, it looks __FUNCTION__ will reduce troubles.
Do we support such ancient versions of GCC anyway ? Just to be clear, I'm fine
with either way, just my 2.7183 cents ;-)
>
> BR,
> Eric
>
> >>> + 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.
>
> [...]
next prev parent reply other threads:[~2011-08-09 19:55 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
2011-08-08 17:56 ` Albert ARIBAUD
2011-08-09 1:57 ` Hong Xu
2011-08-09 19:55 ` Marek Vasut [this message]
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=201108092155.24250.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