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: Mon, 08 Aug 2011 11:39:50 +0200 [thread overview]
Message-ID: <4E3FAEE6.4010208@aribaud.net> (raw)
In-Reply-To: <4E3F9D2A.1030002@ti.com>
Le 08/08/2011 10:24, Aneesh V a ?crit :
> Hi Albert,
>
> On Sunday 07 August 2011 12:25 PM, Albert ARIBAUD wrote:
>> Hi Aneesh,
>>
>> (cutting quotation for readability)
>>
>> Le 05/08/2011 16:59, Aneesh V a ?crit :
>>> Hi Albert,
>>
>>> I don't dispute that having buffers aligned is the ideal scenario. The
>>> question is about error-handling the situation when this requirement is
>>> not met.
>>
>> I understand what you're trying to achieve in this respect, that is,
>> make the code as correct as it can be under unspecified conditions. I
>> believe we are differing in how we construe 'as correct as it can be':
>> you want to make the implementation of the called function as correct as
>> it can be' at the expense of introducing a non-intuitive behavior (flush
>> while invalidating), while I prefer the overall system to be as correct
>> as it can be by 'doing exactly what it says on the tin', i.e.
>> invalidating only.
>
> I understand your point of view now. I shall update my cache fix series
> to invalidate only the aligned part of the buffer and to print a big
> warning when the buffer is not aligned.
Thanks Aneesh.
Another point I raised with Hong Xu's patch: for range-limited
operations, in case of a misalignment, why not try to *reduce* to
aligned addresses rather than *expand* it? Moving start up to the next
cache line boundary, and moving stop down, would still cause an
imperfect situation (can't help it anyway) but it would not affect third
party data any more, only the data which the cache range operation was
supposed to affect.
What do you (and others) think?
> best regards,
> Aneesh
Amicalement,
--
Albert.
next prev parent reply other threads:[~2011-08-08 9:39 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
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 [this message]
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=4E3FAEE6.4010208@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