Re: PCI MMIO flushing and stuff (was Re: 2.2.15 with eepro100: eth0: Too much work at interrupt)

From: Gérard Roudier (groudier@club-internet.fr)
Date: Sat May 20 2000 - 15:47:57 EST


On Sat, 20 May 2000, Jeff Garzik wrote:

> Andrey Savochkin wrote:
> >
> > Hello,
> >
> > On Fri, May 19, 2000 at 04:38:20PM -0700, Dragan Stancevic wrote:
> > > On Fri, May 19, 2000, Kamlesh Bans <kbans@corsair.com> wrote:
> > > ;
> > > ; The "res2" patch Andrey sent me (adding #define USE_IO to the 1.20.2.5
> > > ; driver) works! Hooray!
> > >
> > >
> > > Good spoting Andrey, that explains eeprom checksum :^)
> >
> > 8-()
> >
> > It doesn't explain it for me!
> > The question is not in the delay. Udelay(100) didn't help.
> > It's USE_IO that fixed things for Kamlesh.
>
> It sounds like MMIO flushing might be a problem.
>
>
> > Well, I've heard from other l-k discussions that memory mapping PCI IO isn't
> > very easy. Different write operations may be reordered or coalesced.
> > I would appreciate if someone with PCI knowledge elaborates it for me and
> > gives a hint how to do several writes to a single address with guarantee that
> > they are committed as they are.
>
> I plan to put the following wisdom into pci.txt. As told to me from
> Alan, who claims that Gerard Roudier is the real expert. Gerard in

Thanks, Alan. :-)
Let me claim that Alan is a real _champion_ in kernel maintainance and
kernel development.

> turns claims nothing more than actually reading the PCI spec. :)

This was intented to avoid me from rewriting the PCI specs text by hand
and posting it to the kernel list. :)

> 1) PCI will delay writes, group writes together but it will not re-order
> them or let reads pass writes. [thus, a readl() will cause a PCI flush
> of all delayed writes]

Ok for the ordering rules, but, as I wrote in a previous email, COMBINING
should not be used on common x86 host bridges for non-prefetchable.
(May-be I should keep me up-to-date by reading the Intel doc about
the latest available core-logic chipsets from Intel).
 
> 2) [What happens when two CPUs two to MMIO spaces at the "same time"?]

If they hit the same device, this looks like a software BUG to me. :)

> Both writes will occur. The ordering will be the CPU ordering. It may
> turn them both into a single burst write if they are adjacent and the
> ordering is lower->higher

They must hit 2 different 32 bit DWORDs, happens in ascending address
order and some COMBINING must be enabled (which seems to me unlikely if
targetted region is non prefetchable (generally set as uncached)).

Gérard.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Tue May 23 2000 - 21:00:19 EST