public inbox for u-boot@lists.denx.de
 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 11:20:08 +0200	[thread overview]
Message-ID: <4E3BB5C8.1030902@aribaud.net> (raw)
In-Reply-To: <4E3B9753.3020002@ti.com>

Hi Aneesh,

On 05/08/2011 09:10, Aneesh V wrote:
> Hi Hong, Albert,
>
> On Friday 05 August 2011 12:16 PM, Albert ARIBAUD wrote:
>> Le 05/08/2011 08:38, Hong Xu a ?crit :
>>> Hi Albert,
>>>
>>> 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.
>>
>> Why would it be impossible? If it is statically allocated it can use
>> __attribute__(aligned)) and if it is dynamically aligned, it can be
>> over-allocated to make sure it starts and ends at cache boundaries.
>>
>>> 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.
>>
>> The problem is the cases that fall outside of 'most'. This kind of issue
>> tends to have effects that, when unwanted, are extremely difficult to
>> link to their cause and makes for long and painful debugging.
>>
>
> IMHO, Hong's approach is correct. If the buffer that is invalidated is
> not aligned to cache-line, one cache-line at the respective boundary
> may have to be flushed to make sure the invalidation doesn't affect
> somebody else's memory.
>
> The solution is for drivers to ensure that any buffer that needs to be
> invalidated is aligned to cache-line boundary at both ends. The above
> approach puts this onus on the driver. I have documented the alignment
> requirement in my recent patch series for fixing arm cache problems.

AIUI, you describe what I requested, so I agree with it. :)

And if there is an alignment requirement, then there is no need any more 
to flush lines when unaligned start/stop is passed, because it would 
only have a use for call cases that do not conform to the requirement.

> best regards,
> Aneesh

Amicalement,
-- 
Albert.

  reply	other threads:[~2011-08-05  9:20 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
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 [this message]
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=4E3BB5C8.1030902@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