lkml.org 
[lkml]   [2002]   [Jan]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH] IBM Lanstreamer bugfixes
From
Date
  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/

\
 
 \ /
  Last update: 2005-03-22 13:15    [W:0.163 / U:0.128 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site