-
Lennert Buytenhek authored
Patch from Lennert Buytenhek The workaround that we do for avoiding triggering ixp2400 erratum #66 involves mapping I/O pages using XCB=101 instead of XCB=000 so that we prevent the I/O signal to the gasket from being asserted (which can cause data corruption.) But XCB=101 mappings are write-buffered while mappings using XCB=000 are not, which is why if we use XCB=101 mappings we do a readback for every CSR store in an attempt to make sure that the store has been pushed out of the xscale core and the gasket. Unfortunately, there are two issues with this: - we do a readback for every CSR store, which is wrong, because the register we are writing to might have unwanted side-effects on read, for example, in the case of the scratchpad ring enqueue/dequeue registers; and - the readback is totally ineffective in the way we currently do it, because we just issue a load but do not issue any instruction that depends on the return value of that load, so the xscale core does not wait for the load to complete before continuing. See this linux-arm-kernel mailing list post for further information: http://lists.arm.linux.org.uk/pipermail/linux-arm-kernel/2005-September/031314.html This means that my ixp2400 boxes have been running for many months without a working readback in ixp2000_reg_write, without any apparent adverse effects. Two of them have been running for a week now with the actual readback deleted from ixp2000_reg_write, also without any apparent ill effects. So, because in its current form it does more harm than good, the readback in ixp2000_reg_write should simply be killed, as the patch below does. Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org> Signed-off-by: Deepak Saxena <dsaxena@plexity.net> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
931db7d6