PCI rework

Ian Romanick idr at us.ibm.com
Tue May 2 13:34:32 PDT 2006

Hash: SHA1

Mark Kettenis wrote:
>>Date: Mon, 01 May 2006 11:43:19 -0700
>>From: Ian Romanick <idr at us.ibm.com>
>>>I'm talking specifically about pci_device_map_region() and
>>>pci_device_unmap_region().  These interfaces are clearly there because
>>>the Linux sysfs provides these "regions" as files which you can open
>>>and then mmap.  Other operating systems don't support this view, and
>>On those systems (including older Linux kernels that do not have sysfs),
>>pci_device_map_region internally does an mmap on /dev/mem of the proper
> If there is a 1:1 mapping from region ID's to BARs then yes, of course
> this can be done.  How does the mapping work if there are 64-bit Base
> Adress registers, possibly intermixed with 32-bit Base Address
> registers?  The "region" in the interface name is a bit strange, but
> admittedly the PCI standard doesn't really suggest a better name.
> Perhaps pci_device_map_bar() expresses the intent a bit better.

If a device has a 64-bit BAR, a 32-bit BAR, and another 32-bit BAR,
these will be elements 0, 1, and 2 in the regions array in the
pci_device structure.  This seemed like the most logical way for the
library to advertise this to the app.

>>Note that this is currently broken in X on some platforms.  IBM pSeries
>>hardware always maps BARs above 0xffffffff.  If the X-server is built as
>>a 32-bit app (which is the default), it silently drops the upper
>>32-bits.  This problem is propagate to each and every driver.  By
>>isoalting it in a single library, the amount of code that is exposed to
>>this issue is limited.
> Ah yes, 32-bit userland on a 64-bit kernel can be a bit schizophrenic.
> But this just means that currently either:
> a) X doesn't decode 64-bit BARs correctly.

I believe this code is correct.

> b) X uses the wrong type for physical addresses when compiled as a
> 32-bit app on a 64-bit system.

This is absolutely broken.

>>>there's a good reason not to do it: Many PCI devices put mappable
>>>memory addresses in config space outside the standard PCI BARs.  What
>>>you really need is an interface to read from PCI config space and an
>>>interface to map physicall addresses on the pci bus into memory.  Some
>>>standard helper functions to decode the standard BARs is certainly
>>Excluding legacy VGA memory, can you name any?
> I've no experience with graphics hardware.  But the VIA VT8237
> southbridge has Watchdog Timer memory base at offset 0xe8.  The Intel
> ICH7 sothbridge as a gpio base address register at offset 0x48.  Looks
> like the Winbond W89C840F Fast Ethernet adapter has a bootrom at the
> address specified by offset 0x28.

That's just genius. :(  However, doesn't the kernel have quirks (or
whatever they're called) to correctly advertise this to user-mode?
Version: GnuPG v1.4.2.2 (GNU/Linux)


More information about the xorg mailing list