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 13:26:00 +0200 [thread overview]
Message-ID: <4E3BD348.5090609@aribaud.net> (raw)
In-Reply-To: <1312543408.31913.170.camel@ubuntu>
Hi Reinhard,
On 05/08/2011 13:23, Reinhard Meyer wrote:
> Dear Albert, Aneesh, Eric,
>>> We have a fundamental problem when it comes to invalidating an
>>> un-aligned buffer. Either you flush the boundary lines and corrupt your
>>> buffer at boundaries OR you invalidate without flushing and corrupt
>>> memory around your buffer. Both are not good! The only real solution is
>>> to have aligned buffers, if you want to have D-cache enabled and do DMA
>>> at the same time.
>>
>> Plus, there should not be *heavy* modifications; DMA engines tend to use
>> essentially two types of memory-resident objects: data buffers and
>> buffer descriptors. There's only a small handful of places in the driver
>> code to look at to find where these objects are allocated and how.
>>
>> So I stand by my opinion: since the cache invalidation routine should
>> only be called with cache-aligned objects, there is no requirement to
>> flush the first (resp. last) cache line in case of unaligned start
>> (resp.stop), and I don't want cache operations performed when they are
>> not required.
>
> After considering all issues, any driver that does flush OR invalidate a
> cache line that it does not fully "own" is prone to cause problems.
>
> At flushing: some DMA might just have put data into the partial line.
> At invalidating: some Software might have put data, but the writeback
> had not occured.
>
> So both flush AND invalidate functions should check for this event and
> emit a proper warning on the console.
Fully agreed.
> My 2.7 cents...
> Reinhard
Amicalement,
--
Albert.
next prev parent reply other threads:[~2011-08-05 11:26 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 [this message]
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=4E3BD348.5090609@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