"Sedjai, Mohamed" wrote:
> Hello everybody,
> I've been following this thread with much attention and interest,
> and I would like to give my small contribution, even though my expertise
> is far lower than yours.
> Our TX49 (R4000 based) manual also states that "if the CACHE instruction
> is issued for the line in which this instruction exists the operation
> is not guaranted". As you can see from the arch/mips/mm/r4xx0.c file,
> TX49 routines always disable caches before operating.
> Recently, one of our customer, raised the question since he was comparing
> performance between TX49 and another comparable MIPS architecture.
> He noticed a huge difference in favor of the other vendor.
> For information it was a multimedia application. Investigations
> showed that the other vendor was running cache flushing operations cached.
> He tried to also run TX49 cached and, miracle, TX49 performed much better
> than the other chip. And the application could run for hours without
> I have contacted our designers, and the answer I got so far is that a problem
> occur depending on the alignement of the CACHE instructions and on the set
> in which they are located (TX49 cache is 4 way set). This confirms Jon's
> investigation. Carsten, can you comment this, as a MIPS insider ? Which
> CPUs are concerned ?
I can only speak for our own products (4Kc serie, 5Kc serie and 20Kc).
They have no problem with running the cache routine from cached space.
"Index load/store Tag" cache operation instructions, however should be executed
uncached space, but they are not used in linux.
> Further investigation are now ongoing to find a proper workaround and thus
> are highly apreciated.
> >From my side I have a very simple question:
> If you run instruction cache flushing cached, then the cache will be dirty
> when the routine returns. At least the line(s) containing the routine itself ?
> Or am I missing something ?
> Best Regards,
> Mohamed SEDJAI
> TOSHIBA Electronics Europe
> PS: Sorry Dominic for a possible misusage of the terminology. BTW I found
> your book
> wonderfully well written and consider it as a reference to anyone who wants
> to write a technical book.
> -----Original Message-----
> From: Jon Burgess [mailto:Jon_Burgess@eur.3com.com]
> Sent: Donnerstag, 11. Juli 2002 18:34
> To: Ralf Baechle
> Cc: Gleb O. Raiko; email@example.com; firstname.lastname@example.org
> Subject: Re: mips32_flush_cache routine corrupts CP0_STATUS with
> > Ralf wrote:
> >Have you tried to insert a large number of nops instead?
> My investigation suggests that a single extra nop is sufficient. I have also
> tried inserting extra nops before the cache routine to see if the relative
> alignment of the instructions with respect to the cacheline has an influence,
> but it has no effect. I am suspicious that if this occurs with the instruction
> following the loop then something odd might be occuring on every loop
> as well. I might try adjusting the instructions in the loop to see if that has
> any effect.
> > Or preferably,
> >how about replacing the __restore_flags() in your example with the
> >following piece of inline assembler:
> > __asm__ __volatile__("mtc0\t%0, $12" ::"r" (flags) : "memory");
> I am happy that the current assembler code looks correct, but this change
> make it simpler.
_ _ ____ ___ Carsten Langgaard Mailto:email@example.com
|\ /|||___)(___ MIPS Denmark Direct: +45 4486 5527
| \/ ||| ____) Lautrupvang 4B Switch: +45 4486 5555
TECHNOLOGIES 2750 Ballerup Fax...: +45 4486 5556