Messages in this thread | | | Subject | Re: [PATCH] IBM Lanstreamer bugfixes | From | "Kent E Yoder" <> | Date | Wed, 30 Jan 2002 13:27:29 -0600 |
| |
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/
| |