Re: [PATCH] Retain the write-only OD from being clobbered

[Sergei Shtylylov <sshtylyov@ru.mvista.com>]

Hello.

Jordan Crouse wrote:

> First of several patches forwarded to me by Sergei Shtylyov.  Ralf,
> these should be good to go for the tree.
> 
> Retain the write-only OD bit from being clobbered by coherency_setup()
> 
> Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
> Acked-by: Jordan Crouse <jordan.crouse@amd.com>

    A long story of a long standing bug follows...
    AMD Au1x00 board setup code in au1x00_setup() sets CONFIG.OD bit for the 
early steppings of the Au1x00 SOCs, consulting the PRID table in 
arch/mips/au1000/common/cputable.c. This bit disables the bus transaction 
overlapping which causes a number of errata in those early SOC steppings 
(including the one that I think we've run into with USB host--at least setting 
the bit back to 1 fixed it, although disabling USB host DMA coherency also 
seemd to help). The problem is that this bit is write-only and reads
as 0 on almost all SOCs that need it set. So, when the arch/mm/c-r4k.c code
does RMW to the CONFIG reg. in coherency_setup(), its value is lost, and the
chip again becomes prone to all the nasty errata that it has just been saved
from... :-)
       There's couple more places in the assembly code where the CP0 CONFIG 
reg. is written without care of OD bit:
    1) In the cache parity error handler (arch/mips/mm/cex-gen.S) -- as the 
panic() call follows shortly, probably CACHE.OD=0 doesn't matter much at this 
point;
    2) In arch/mips/au1000/common/sleeper.S, when the CPU regs are being
restored on wakeup; Au1x00 PM code in 2.6 seem to have fallen out of
maintenance, and the stack frame set up there seemed just erratic (2.4
situation in this module is much better).
    I didn't touch both those places. And of course, this CONFIG.OD bug is
present in 2.4 kernels as well...

WBR, Sergei