Messages in this thread | | | Date | Tue, 29 Jan 2008 21:30:47 -0500 | From | Tony Camuso <> | Subject | Re: [Patch v2] Make PCI extended config space (MMCONFIG) a driver opt-in |
| |
Matthew Wilcox wrote: > On Tue, Jan 29, 2008 at 07:29:51AM -0800, Arjan van de Ven wrote: >>> Right now, that isn't a lot of people in x86 land, but your patch >>> encumbers drivers for non-x86 archs with an additional call to access >>> space that they've never had a problem with. >> lets say s/x86/x86, IA64 and architectures that use intel, amd or via chipsets/ > > Umm .. ia64 already does exactly what I'm proposing for x86. It uses > one SAL interface for bytes below 256 and a different SAL interface for > bytes 256-4095. >
Not exactly. :)
The interface is the same, ia64_sal_pci_config_write() and ia64_sal_pci_config_read(), but a flag bit in the mode argument is used to tell the SAL interface whether to translate the offset component of the config address as having 8 or 12 bits of of displacement.
In my estimation, Ivan's patch, in his implementation of Loic's suggestion, is even more elegant, since there is no need to flag whether the access is for offsets below 256. Ivan's code automatically uses Port IO (or equivalent with Matthew's patch) for offsets below 256 and MMCONFIG for offsets from 256 to 4096.
And even better, it removes the bitmap that tracks MMCONFIG-unfriendly devices for the first 16 buses, a solution that assumes systems with bus numbers higher than 16 will get MMCONFIG right, which turned out to be a very wrong assumption. Furthermore, the config address is translated by the Northbridge. The delivery mechanism to the Northbridge, whether Port IO or MMCONFIG, is utterly opaque to the devices on the bus, since all they see is PCI config cycles, not Port IO or MMCONFIG cycles. The test only needed to be made at the Northbridge level, not at the device level. Ivan's patch removes all this cruft.
| |