Re: 32 KB SH3 cache issues

[Paul M. <le...@li...>]

On Mon, Aug 27, 2007 at 02:22:20PM +0200, EXTERNAL Brunner Markus (Praktikant;  ST-FIR/Eng) wrote:
> I enabled the SH7705_CACHE_32KB option, but it seems to be broken. I had
> to include <linux/fs.h> in pg-sh7705.c to make it compile. 
> The kernel reportet an CRC error when tried to loaded the initrd. This
> time it didn't even work with writethrough.
> 

> Why is there so much code for the cache handling for the 32KB mode
> (pg-sh7705.c)?
> What has to be done else than writing CCR3 to enable 32kb cache?
> Why doesn't writeback work with 32KB cache?
> 
The problem with this extended mode is that it ends up behaving a lot
more like an SH-4 style dcache, including the cache aliases and
everything that entails. As far as why there are special ops for 7705,
I've never had one to test one, so this is a difficult thing to answer.
The main thing really is that while this extended 32kB mode provides the
7705 with an aliasing dcache, the icache bits are still very much the
same as the rest of the SH-3, so that doesn't require any special
handling. We are rather at the point now where the SH-4 icache and dcache
handling ops have to be decoupled from the cache-sh4/pg-sh4
implementation precisely for things like the SH-X3 cores which do full
dcache coherency but still have traditional SH-4 style icaches that
aren't snooped.

Once there's a decoupling of the SH-4 I/D cache handling, we can probably
rip out most of the SH7705 32kB special casing and just wrap in to that
directly. Now that we are using kmap_coherent()/kunmap_coherent() and the
fixmap slots for page colouring, this is something that can be nopped out
on stock SH-3 and only enabled for the extended cache, which should allow
us to consolidate most of the page copying/clearing. The only thing
that's really a problem here is the PG_mapped bit and the lazy dcache
write-back. Flipping this to PG_dcache_dirty and reversing the logic
would allow us to share a common update_mmu_cache() across all of the
SH-3/SH-4 variants regardless of cache configuration, but we aren't quite
at that point yet. And there was some fallout the last time we tried to
go that route, it's still something that's going to need a bit of
debugging before we can enable it across the board.

If this is an area where you're interested in working in, I have dozens
of different patches for work in this area you might want to play around
with. Getting the kmap_coherent()/kunmap_coherent() bits implemented and
reclaiming the vmalloc space in P3 without hosing some of the more
obscure SH-4 variants was a start towards this, but it is still slow
going.