Modified driver / device probing

[Alex Deucher]

On 2/22/06, Ian Romanick <idr at us.ibm.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> 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:
>
> 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.
>

I don't see many reasons why "ati" should stick around.  It shouldn't
be too hard to split it out into r128, radeon, and ati_misc.  they
were separate at one time abyway.  This would solve other issues as
well.

Alex

> 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?
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.1 (GNU/Linux)
>
> iD8DBQFD/QsOX1gOwKyEAw8RAr3kAJ9U6HSbPI2mbqzqHNqRq07fzRCftwCfXYk7
> pTKj3qo8Kb+UnvrnuxkWm+0=
> =K7iO
> -----END PGP SIGNATURE-----
> _______________________________________________
> xorg mailing list
> xorg at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xorg
>