* Quick Q about caches
@ 2002-01-12 8:05 Jason Gunthorpe
2002-01-12 23:51 ` Ralf Baechle
0 siblings, 1 reply; 2+ messages in thread
From: Jason Gunthorpe @ 2002-01-12 8:05 UTC (permalink / raw)
To: linux-mips
Hi All,
I've been working on some cache code for a new processor and I just
quickly wanted to ensure I'm reading the existing stuff right, I hope that
someone who knows a bit more about this codes history could just confirm
some of my guesses :>
So here is what I'm thinking: (read virtually indexed == cache aliasing
problems)
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..
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..
Thanks,
Jason
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: Quick Q about caches
2002-01-12 8:05 Quick Q about caches Jason Gunthorpe
@ 2002-01-12 23:51 ` Ralf Baechle
0 siblings, 0 replies; 2+ messages in thread
From: Ralf Baechle @ 2002-01-12 23:51 UTC (permalink / raw)
To: Jason Gunthorpe; +Cc: linux-mips
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
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2002-01-13 1:21 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2002-01-12 8:05 Quick Q about caches Jason Gunthorpe
2002-01-12 23:51 ` Ralf Baechle
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox