Thomas Gleixner schreef:
On Tue, 2006-02-14 at 15:59 +0300, Vladimir A. Barinov wrote:
+ }
+
+ if (((bytes & 3) || (bytes < 16)) || ((u32) to & 3) || ((u32)
from & 3)) {
+ if (((bytes & 1) == 0) &&
+ (((u32) to & 1) == 0) && (((u32) from & 1) == 0)) {
+ int words = bytes / 2;
+
+ local_irq_disable();
+ for (i = 0; i < words; i++) {
+ to16[i] = from16[i];
+ }
+ local_irq_enable();
Really necessary to disable all irqs around this transfer? How long
can interrupts be off during that time?
That is needed since the NAND device is binded to the external XIO bus
that could be used by another devices.
Err, you have to protect the whole access sequence then. What protects
the chip against access between the command write and data read ?
If this really is a bus conflict problem, then you need some more
protection than this.
Can you please describe in detail why you think this is necessary.
tglx
Root cause of the problem lies within the early implementation of the
low-level NAND commands. There was a severe risk that the PCI accesses
were stalled because of a Read Status command for the NAND Flash. This
Read Status was launched immediately after program/erase command. The
hardware itself will wait for the Ready/Busy to be high and only then
launch the Read Status command. This behavior caused timeout on the
internal bus because PCI was unable to use the pins during this wait.
If this problem was coinciding with an ISR that tried to perform a PCI
status register, then this PCI access could possibly timeout (because
the PCI pins were already claimed for the XIO access that is depending
on the RBY signal).
Since the problem only showed during the PCI device ISR, the
quick'n'dirty hack was to disable interrupts during XIO accesses.
A better fix that should be available somewhere, is to improve the
low-level NAND driver that will first check the status of the Ready/Busy
line and only THEN launch the Read NAND Status command...
Jurgen
