linux-mips
[Top] [All Lists]

Re: Strange, strange occurence

To: "Kevin D. Kissell" <KevinK@mips.com>, "S C" <theansweriz42@hotmail.com>, "Ralf Baechle" <ralf@linux-mips.org>
Subject: Re: Strange, strange occurence
From: "Kevin D. Kissell" <KevinK@mips.com>
Date: Tue, 13 Jul 2004 00:25:37 +0200
Cc: <linux-mips@linux-mips.org>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <BAY2-F27mxl2RtYP35u0000d191@hotmail.com> <020201c46859$fa6b98b0$0deca8c0@Ulysses>
Sender: linux-mips-bounce@linux-mips.org
> Your intuition is correct, and the code in r4k_tlb_init() does look scary.
> But at least in the linux-mips CVS tree, flush_icache_range() tests to see
> if "cpu_has_ic_fills_f_dc" (CPU has Icache fills from Dcache, I presume)
> is set, and if it isn't, it pushes the specified range out of the Dcache 
> before
> flushing the Icache.  I would speculate that either your c-r4k.c is out of
> sync with yout tlb-r4k.c, or you erroneously have cpu_has_ic_fills_f_dc
> set.

Hmm.  On closer examination, there *is* a bug in the current 
r4k_flush_icache_range(),
in that it computes its cache flush loop for the I-cache based on the D-cache 
line size.
Those line sizes are *usually* the same.  By any chance are they different for 
the
TX49 family?  If the icache line is longer than the dcache line, there should 
be no
functional problem, just some wasted cycles.  But if the dcache line were, say, 
twice the length of the Icache line, only half of the icache lines would be 
invalidated...

            Regards,

            Kevin K.


<Prev in Thread] Current Thread [Next in Thread>