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 <email@example.com>
Acked-by: Jordan Crouse <firstname.lastname@example.org>
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
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
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...