All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ralf Baechle <ralf@oss.sgi.com>
To: Jason Gunthorpe <jgg@debian.org>
Cc: linux-mips@oss.sgi.com
Subject: Re: Quick Q about caches
Date: Sat, 12 Jan 2002 15:51:02 -0800	[thread overview]
Message-ID: <20020112155102.A1569@dea.linux-mips.net> (raw)
In-Reply-To: <Pine.LNX.3.96.1020112002634.14010A-100000@wakko.deltatee.com>; from jgg@debian.org on Sat, Jan 12, 2002 at 01:05:30AM -0700

On Sat, Jan 12, 2002 at 01:05:30AM -0700, Jason Gunthorpe wrote:

> So here is what I'm thinking: (read virtually indexed == cache aliasing
> problems)

Right.

> The stuff in c-mips32 is for a processor with virtually indexed primary
> and secondary caches, seperate i/d caches and no io-coherancy
> 
> The stuff in c-rm7k describes a processor with physically indexed
> caches, but seperate non-snooping i and d caches. The IO coherancy stuff
> does too much flushing, notably DMA should never be done to regions that
> are executing, and the flush_scache also does the flush_dcache as in
> c-mips32 (presumably this is what the XXX comment is talking about)
> 
> The SB1 reference tells me that it has a virtually indexed icache that
> also tags ASID's, the CONFIG_VTAG_ICACHE option invokes the special code
> to manage this ASID caching. The rest of the caches are physically indexed
> and IO coherant (woop!). The comment for sb1_flush_page_to_ram does 
> not jive with the stuff in Documentation/cachetlb.txt - I think the
> latter is right and the function should be a nop on a physically tagged
> dcache..
>
> The one thing I don't quite get yet is why flush_dcache_page is a NOP for
> everyone? That must mean the dcache is always physically indexed if
> Documentation/cachetlb.txt is correct.. 

You either need to implement flush_page_to_ram or flush_dcache_page.

> Anyhow, the chip I've got is largely sane, the only annoyance is that 
> the SR7100 has physically tagged but virtually indexed i/d-caches that
> can alias if the page size is less than 8K, the rest seems 
> straightforward..

  Ralf

      reply	other threads:[~2002-01-13  1:21 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-01-12  8:05 Quick Q about caches Jason Gunthorpe
2002-01-12 23:51 ` Ralf Baechle [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=20020112155102.A1569@dea.linux-mips.net \
    --to=ralf@oss.sgi.com \
    --cc=jgg@debian.org \
    --cc=linux-mips@oss.sgi.com \
    /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.