> > BTW, I don't know what PCI posting effects are...
>
> Ok given
>
> writel(foo, dev->reg);
> udelay(5);
> writel(bar, dev->reg);
>
> The pci bridge is at liberty to delay the first write until the second or a
> read from that device comes along (and wants to do so to merge bursts). It
> tends to bite people
>
> - When they do a write to clear the IRQ status and don't do
> a read so they keep handling lots of phantom level triggered
> interrupts.
Not only (when the write is intended to clear some interrupt condition).
As the actual clear of the interrupt condition is delayed, then it may
just also clear a sub-sequent condition and this condition may be missed
by the driver interrupt routine. Due to this a race, interrupt stall can
occur.
> - When there is a delay (reset is common) that has to be observed
>
> - At the end of a DMA transfer when people unmap stuff early
> and the "stop the DMA" command got delayed
Gérard.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/