All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hong Xu <hong.xu@atmel.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH v2] ARM926ejs: Add routines to invalidate D-Cache
Date: Fri, 05 Aug 2011 14:38:43 +0800	[thread overview]
Message-ID: <4E3B8FF3.2070400@atmel.com> (raw)
In-Reply-To: <4E3B8A16.50604@aribaud.net>

Hi Albert,

On 08/05/2011 02:13 PM, Albert ARIBAUD wrote:
> 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>

[...]

>> +
>> +#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.

ARM926EJ-S Technical Reference Manual (r0p4/r0p5) only defines one cache 
line size, "32". From my understanding, the standard ARM926EJ-S 
implementation shall use 32 bytes cache line size. Of course this can be 
overwritten by CONFIG_SYS_CACHELINE_SIZE, but shall we force to define it?

Frankly I have not found a proper place to define this(aka. not using 32 
here), for example as a Macro.

>
>> +#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);
> }

I've tried to deal with the case that the (start, stop) is not aligned. 
If mis-align happens, the adjacent lines will be cleaned before 
invalidating. And from my view it's impossible for a driver to always 
pass aligned address to invalidate_dcache_range.

To answer your question in another email

 > How do you know the dirty data should be flushed rather than 
invalidated?

"Dirty" means this cache is changed by CPU but not has not been written 
into memory or WB. If we invalidate it, data will lost. In most cases, I 
do not see a situation why the dirty data shall not be written into memory.

BR,
Eric
>
[...]
> Amicalement,

  reply	other threads:[~2011-08-05  6:38 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
2011-08-05  6:38   ` Hong Xu [this message]
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=4E3B8FF3.2070400@atmel.com \
    --to=hong.xu@atmel.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 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.