Modified driver / device probing

[Ian Romanick]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ian Romanick wrote:
> Here are links to two patches.  The first patch implements a new driver
> / device probing mechanism in the server, and the second implements the
> new entry-point in the mga driver.
> 
> http://users.freedesktop.org/~idr/patches/new_probe-xserver-200602221648.patch
> http://users.freedesktop.org/~idr/patches/new_probe-mga-200602221648.patch
> 
> The basic change is that the DriverRec now contains the list of PCI
> devices supported by the driver.  The server uses that list in
> conjunction with the list of Device sections and the list of available
> PCI devices to determine which devices match the driver.  When a
> matching device is found, the new PciProbe function is called.  This
> just refactors existing code from the driver up to the server.
> 
> I do *not* intend to commit this code.  This is just a mock up of a
> mechanism that could be used in conjunction with the new PCI code that
> I'm writing.  The chipsets, pci_chipsets, and pci_vendor_id fields would
> be replace with an array of pci_match structures:

I've noticed a possible problem with this, so I'd like to get some
feedback.  A Device section can contain a Chipset over-ride.  This
option selects a chipset by name.  The example device section (below)
will cause the device at PCI:1 at 0:0:0 to be treated as a G550, no matter
what it actually is.  This is similar to over-ridding the PCI ID of a
device.

xf86MatchPciInstances uses a table to convert that over-ride name into a
PCI ID.  This is the only use of the DriverRec:chipsets field in my
current patch.  If DriverRec::chipsets, DriverRec::pci_chipsets, and
DriverRec::pci_vendor_id were replaced with an array of pci_match
structures, this functionality would be lost for PCI devices (it would
have no effect on devices probed with the DriverRec::Probe function).

Is *anyone* going to miss it?

If it won't be missed, then I think I can create a new version of
xf86MatchPciInstances that uses this new interface.  The new version
would only be called from xf86CallDriverProbe, and the old version would
continue to exist, as-is, until that interface is fully deprecated.

Section "Device"
	Identifier	"foo"
	Driver		"mga"
	BusID		"PCI:1 at 0:0:0"
	Chipset		"mgag550"
EndSection


> struct pci_match {
> 	uint32_t  device, vendor;
> 	uint32_t  subdevice, subvendor;
> 	uint32_t  class, class_mask;
> 	intptr_t  driver_data;
> };
> 
> Yes, it is intentional that pci_match is identical to the Linux kernel's
> pci_device_id structure.  It is intended to be used in exactly the same
> way by drivers.
> 
> In working on these changes I noticed a couple things that are worth
> pointing out.
> 
> 1. This version of this technique will break "umbrella" drivers like
> ati.  It is possible to use pci_match::driver_data to determine which
> real PciProbe function to call, but I don't see a clean way to implement
> that until then.
> 
> 2. Like the modified mga driver, most driver will only need a PciProbe
> function.  Some drivers, especially those which support other buses,
> will still need a Probe function.  However, it should be possible to use
> the existing Probe function with little or no modification in those cases.
> 
> 3. Why does ScreenInfoPtr have a Probe function?

Any thoughts on this?  It's never used *anywhere* in the code (drivers
or server).  If it's not actually needed, can we schedule it for removal?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFD/zxdX1gOwKyEAw8RAt70AJ9o5lIjNcX/yKdR57+dwhboDlI8pQCfR1S8
0ki8WpTYJvoHd6V76WP0vGo=
=yv9r
-----END PGP SIGNATURE-----