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@xxxxxxxxxxxxx>
Acked-by: Jordan Crouse <jordan.crouse@xxxxxxx>
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
