On Sat, 20 May 2000, Jeff Garzik wrote:
> Andrey Savochkin wrote:
> > On Fri, May 19, 2000 at 05:31:37PM -0400, Jeff Garzik wrote:
> > > In any case, if you were thinking about it, I wouldn't blindly replace
> > > writew() with udelay() or anything like that -- leave the writew() in
> > > there, and add an additional udelay() if the circumstances call for it.
> > > Excluding the writew() increases the potential for seeming EEPROM code
> > > flakiness, because few drivers have thus far been completely audited,
> > > updated, and tested for correct MMIO flush semantics.
>
> > I do not do it blindly! :-)
> > I've checked different available drivers, and all of them uses udelay()
> > without any readw(), except only one which uses inw() and is proven to have
> > problems. And some of these drivers have been working for years.
> > So, I feel quite confidential in removing readw() altogether and implementing
> > eeprom_delay via just udelay(1).
>
> Experience seems to show that PIO reads and writes are posted on x86,
Reads are unlikey to be posted. They can be 'delayed'. Write can be
posted, but I doubt normal IOs to be posted on common host-pci bridges
used with x86.
> while MMIO writes might be combined before posting. So, since 95% of
COMBINING in PCI world means that subsequent DWORD writes to ascending
addresses can be coalesced in a single transaction. Implied ordering of
the writes is preserved. This is allowed even for non-prefetchable address
ranges but I doubt any bridges uses COMBINING by default for
non-prefectable PCI address ranges, at least in x86 world.
MERGING that consists in coalescing BYTE writes to the same DWORD provided
that each BYTE write occurs once is only allowed for non-prefetchable
address ranges. The same way, COLLAPSING that consists in coalescing
multiple writes to the same location and using a single write transaction
is still more restrictive (prefetchable ranges only and not allowed for
PCI-PCI bridges).
All the above *INGs obviously require bridge to use buffers to post the
involved transactions.
> the net drivers using PIO still, judging an MMIO driver from the actions
> of PIO drivers may not lead to correct conclusions.
Even if PCI specifications allow host bridges to use posted buffers also
for PCI legacy IO transactions, it seems such buffers are only used by x86
host bridges for PCI memory writes (and Memory Write and Invalidate). So,
in my opinion, the only relevant difference in x86 world between IO and
MMIO is the use of posted buffers for MMIOs and not for IOs.
Typically, a PCI device driver requires some ordering on operations that
occur concurrently between the CPU and the device, in order to work
properly. Without some knowledge about how the bridge behaves regarding
ordering rules on PCI and how the PCI device actually orders transactions
that may happen concurrently to the driver code, MMIO looks like a risky
exercise to me.
On well-behaving bridges: (required by PCI specs, by the way)
- Ordering of PCI writes that cross the bridge in the same direction
is preserved.
- Bridge must flush posted transactions in both directions prior to
turning a read into a PCI read transaction.
As a result, posted transactions can be flushed either from CPU or
from the PCI BUS by performing a read (possibly dummy) that traverses
the bridge.
The x86 world appears to be the one that implements the strongest ordering
in every places and thus it could well be the simplest case. :-)
> Unless there is a reason -not- to have it there, AFAICS the inw() -must-
> be present.
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