All of lore.kernel.org
 help / color / mirror / Atom feed
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.

  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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.