To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: jgarzik@mandrakesoft.com (Jeff Garzik), linux-kernel@vger.kernel.org
MIME-Version: 1.0
Subject: Re: [PATCH] IBM Lanstreamer bugfixes
Message-ID: <OF0323731B.AAE52C6B-ON85256B51.005748CD@raleigh.ibm.com>
From: "Kent E Yoder" <yoder1@us.ibm.com>
Date: Wed, 30 Jan 2002 13:27:29 -0600
Content-Type: text/plain; charset="us-ascii"
Sender: linux-kernel-owner@vger.kernel.org

  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/