Linux MIPS Architecture development
 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox