I think the delays in the driver *were* just working around PCI posting
effects. I tested by removing all the delays and instead putting
something like:
writew(val, addr);
(void) read(addr);
instead, to flush the PCI cache. Things seem to be happy.
Is this the best way to make sure the PCI cache is flushed for writes that
need to happen immediately? I don't see many other drivers doing it...
Kent
> > 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.
>
> - 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
>
> Alan
-
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/
This archive was generated by hypermail 2b29 : Thu Jan 31 2002 - 21:01:23 EST