Re: [Patch v2] Make PCI extended config space (MMCONFIG) a driveropt-in

[Tony Camuso]

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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/