All of lore.kernel.org
 help / color / mirror / Atom feed
From: Roland Dreier <roland@topspin.com>
To: "Stephan Linke" <Stephan.Linke@epygi.de>
Cc: "Linuxppc-Embedded" <linuxppc-embedded@lists.linuxppc.org>
Subject: Re: Why isn't there an validate_dcache_range() function?
Date: 28 Oct 2002 08:25:09 -0800	[thread overview]
Message-ID: <52pttuh6oq.fsf@topspin.com> (raw)
In-Reply-To: <FCEAKDJJAPHPLJFINDAJOEHFCKAA.Stephan.Linke@epygi.de>


>>>>> "Stephan" == Stephan Linke <Stephan.Linke@epygi.de> writes:

    Stephan> I just got stuck with that question and shurely whoun't
    Stephan> find the answer: If I am using invalidate_dcache_range()
    Stephan> for the data area of an skb shouldn't I enable caching
    Stephan> for that area after the the skb is no longer assigned to
    Stephan> the CPM module? There's no validate_dchace_range() so I
    Stephan> can't.  Why?  There's shurely a reason for that. But I
    Stephan> think using an skb like this will disable caching for
    Stephan> most of the memory areas in a long term view...  Is there
    Stephan> any solution?

invalidate_dcache_range() does not turn off caching for a memory
range.  It just tells the CPU to discard any data for that range that
is currently in the cache.  Future accesses to the range will again
pull data into the CPU cache.  This means that simply using the memory
range again serves the purpose of "validate_dcache_range()" (which as
you note does not actually exist).  However it also means you have to
be careful not to touch the memory range before your external bus
master has finished writing to it (otherwise you could bring invalid
data back into the cache).

Best,
  Roland

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

      reply	other threads:[~2002-10-28 16:25 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-10-28 15:38 Why isn't there an validate_dcache_range() function? Stephan Linke
2002-10-28 16:25 ` Roland Dreier [this message]

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=52pttuh6oq.fsf@topspin.com \
    --to=roland@topspin.com \
    --cc=Stephan.Linke@epygi.de \
    --cc=linuxppc-embedded@lists.linuxppc.org \
    /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.