All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sughosh Ganu <urwithsughosh@gmail.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [RFC PATCH] arm: arm926ejs: flush cache before disable it
Date: Mon, 8 Jul 2013 19:37:22 +0530	[thread overview]
Message-ID: <20130708140722.GA6642@Hardy> (raw)
In-Reply-To: <20130708143216.22906bf7@lilith>

hi Albert,

On Mon Jul 08, 2013 at 02:32:16PM +0200, Albert ARIBAUD wrote:
> Hi Sughosh,
> 
> On Mon, 8 Jul 2013 17:38:46 +0530, Sughosh Ganu
> <urwithsughosh@gmail.com> wrote:
> 
> > hi Albert,
> > On Mon Jul 08, 2013 at 12:22:57PM +0200, Albert ARIBAUD wrote:
> > 
> > <snip>
> > 
> > > It you flush first then disable, you leave a time window between the
> > > two where a write to the cache can happen (either because your code
> > > does one, or because the compiler optimized one in). If it happens,
> > > then you disable a cache which is still dirty -- IOW, your flushing
> > > has failed its mission, and your cache and memory are still not
> > > coherent.
> > 
> > Since this is specific to arm926ejs, can we not flush *and* invalidate
> > the dcache before disabling it -- since the arm926ejs cache uses a
> > read allocate policy, flushing and invalidating a cache before
> > disabling it would not result in the cache getting written to in the
> > window that you refer to. Also, flushing and cleaning is an atomic
> > operation.
> 
> 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.

-sughosh

  reply	other threads:[~2013-07-08 14:07 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 [this message]
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
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=20130708140722.GA6642@Hardy \
    --to=urwithsughosh@gmail.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.