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] [RFC PATCH] arm: arm926ejs: flush cache before disable it
Date: Tue, 9 Jul 2013 10:28:13 +0200	[thread overview]
Message-ID: <20130709102813.63de0b18@lilith> (raw)
In-Reply-To: <20130709061134.GA3176@Hardy>

Hi Sughosh,

On Tue, 9 Jul 2013 11:41:34 +0530, Sughosh Ganu
<urwithsughosh@gmail.com> wrote:

> hi Albert,
> 
> On Mon Jul 08, 2013 at 09:55:51PM +0200, Albert ARIBAUD wrote:
> 
> <snip>
> 
> > > > Invalidating the cache in addition to flushing it would not prevent
> > > > further writes from dirtying the cache lines if they happen before
> > > > the cache is disabled.
> > > 
> > > I have a doubt on this. The arm926ejs uses a read-allocate policy,
> > > wherein a new cache line is allocated only on a read miss -- a write
> > > to an address not present in the cache gets written to memory. So if
> > > the cache line is invalidated, how will data get written to the cache.
> > 
> > The arm926ej-s data cache does not have a single fixed policy, and
> > does not have a bypass-on-write policy, only write-through and
> > copy-back.
> > 
> > Other, more complex, policies may be defined, but at the MMU, not cache,
> > level, and those are not constant for all arm926ej-s based SoCs; not
> > even constant for a given SoC as they are configurable at run-time to
> > fit the chosen system addressing map.
> 
> Can you please elucidate on these policies. Based on my reading of the
> arm developers manual and the arm926ejs trm, the mmu makes a
> particular region cacheable and/or write bufferable. I did not find
> mention of any other  policies. Maybe pointers or links to the
> documents would help.

You are correct re the other policies of the DDI0198E (ARM926EJ-S
TRM) MMU -- page 3-11, bits 3-2 of the section descriptor. Note however
that you may have to refer to your specific SoC's TRM or equivalent, as
the SoC designer may have defined its own system-level cache and MMU
architecture.

Note in any case that none of the policies mentioned in DDI0198E is
described as read-allocate (let alone "read-allocate only" where writes
would bypass the enabled cache); on the contrary, the only cache
policies mentioned are write-through and write-back, both of which
contradict cache bypass on write.

> > (Besides, bypassing the cache for writes and not reads is of little
> > interest for plain DDR caching.)
> 
> Again, afaik this is independent of the target interface that is being
> cached(if i've missed something, can you please point me to the
> document). Thanks.

Sorry, I don't understand this last comment of yours wrt my point on the
(lack of) interest of bypassing cache for DDR caching.

> -sughosh

Amicalement,
-- 
Albert.

  reply	other threads:[~2013-07-09  8:28 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-02 12:35 [U-Boot] [RFC PATCH] arm: arm926ejs: flush cache before disable it Bo Shen
2013-07-05 21:02 ` Albert ARIBAUD
2013-07-07 23:33   ` Bo Shen
2013-07-08 10:22     ` Albert ARIBAUD
2013-07-08 12:08       ` Sughosh Ganu
2013-07-08 12:32         ` Albert ARIBAUD
2013-07-08 14:07           ` Sughosh Ganu
2013-07-08 19:55             ` Albert ARIBAUD
2013-07-09  3:59               ` Sughosh Ganu
2013-07-09  6:11               ` Sughosh Ganu
2013-07-09  8:28                 ` Albert ARIBAUD [this message]
2013-07-10 10:05                   ` Sughosh Ganu
2013-07-10 12:30                     ` Albert ARIBAUD
2013-07-10 17:34                       ` Sughosh Ganu
2013-07-12  7:35                         ` Albert ARIBAUD
2013-07-08 12:19       ` Sughosh Ganu

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=20130709102813.63de0b18@lilith \
    --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.