[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: PCI I/O vs Memory space
- To: Mailing List Recipients <pci-sig-request@znyx.com>
- Subject: Re: PCI I/O vs Memory space
- From: kimmel@dg-rtp.dg.com (Jeff Kimmel)
- Date: Thu, 29 Aug 1996 15:05 EDT
- Cc: pci-sig@znyx.com
- Resent-Date: Thu, 29 Aug 1996 15:05 EDT
- Resent-From: pci-sig-request@znyx.com
- Resent-Message-Id: <"gHClh1.0._33.NLW9o"@dart>
- Resent-Sender: pci-sig-request@znyx.com
> From: jww@anchor.eng.hou.compaq.com (Jeff Wolford)
>
> One of the big differences is that I/O space has the following
> properties:
For the most part, I disagree that these are valid differences.
See below.
> 1) Non postable
Not as true as it used to be. PCI 2.1 allows host bridges to post
outbound I/O Writes. See paragraph 5 of section 3.2.5.
> 2) Non prefetchable
PCI-based memory need not be (and typically is not) prefetchable.
> 3) Non write gatherable
I read section 3.2.6 to say that all posted writes can be combined.
including outbound I/O Writes posted in a host bridge. Merging is
equally illegal for both I/O Space and (non-prefetchable) Memory
Space.
> 4) Real time completion order is maintained.
There are definitely ordering differences between I/O and Memory Space,
but they're not as clear cut as this. PCI 2.1 has relaxed the ordering
guarantees for both I/O and Memory Space.
The ordering enforced for I/O Space is not equivalent to real time
completion order. Even for devices on the primary PCI bus behind a
host bridge, it is possible for I/O Writes to be posted. For devices
downstream of a PCI-to-PCI bridge, section 3.3.3.3.6 details the
ordering requirements for I/O Space accesses, which are even less
stringent; for instance, any transaction can bypass a Delayed I/O Read
Completion. Beware!
> This is why the new ACPI control space is in I/O space,
> so real time completion order is maintained during a
> power down/up of a subsystem.
While I sympathize with the desire to exploit stronger ordering, I
don't believe this is sufficient justification for using I/O Space.
If the device cannot be made to function using only its Memory Mapped
Space, it violates the spirit of PCI 2.1's strong recommendation that
all devices allow their control functions to be mapped into Memory
Space.
Further, as described above, I/O space ordering is not as strong as it
used to be.
Please try to make all devices function using only the ordering
guaranteed by PCI 2.1 for Memory Mapped I/O behind a PCI-to-PCI
bridge. PCI 2.1 has not made that a trivial task, but it should be
possible without major sacrifices.
> Some of the above can be corrected by the memory attributes, but
> not all and its not clear to me who would set up these
> memory attributes for a I/O card.
>
> Q: Anyone have any insight into who/how a x86 PCI machine would
> set up the memory attributes.
As far as prefetching goes, the device specifies whether its Memory
Mapped I/O Space is prefetchable. If the device says a region is not
prefetchable, a compliant platform must set up its memory attributes
accordingly.
> Q: Any one else have other reasons to use I/O space instead
> of memory space or visa-versa.
I strongly agree with the sentiment that I/O Space should be avoided
unless it is required to support legacy PC requirements, e.g. for boot
device issues. As they grow, even ix86-based systems are finding it
increasingly problematic to accommodate I/O Space.o
Another reason not to provide I/O Space in one's device is that given a
choice, driver writers still seem to gravitate toward using I/O Space
to access a device. This unnecessarily complicates driver portability
(both source and binaries).
> Jeff
- Jeff
Jeff Kimmel 919-248-6066
Data General Corporation FAX: 919-248-6108
62 Alexander Drive, RTP, NC 27709 kimmel@dg-rtp.dg.com