PCI rework

[Ian Romanick]

-----BEGIN PGP SIGNED MESSAGE-----
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
>>offset.
> 
> 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
>>>desirable.
>>
>>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?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)

iD8DBQFEV8JXX1gOwKyEAw8RAgPZAJ0c+J9Z2yZHQu09n+/Gaed1dpEy2QCdElN5
KCR7n6uZKd50GM8SdXCL64U=
=Htgz
-----END PGP SIGNATURE-----