On Thu, 2003-10-16 at 12:41, Jon Smirl wrote: > --- Eric Anholt <[EMAIL PROTECTED]> wrote: > > I'm still working on cleaning the PCI ID stuff up to be portable, which > > I'll commit as soon as I test (I'm trying to get a multihead setup going > > to see if there are problems with that as Michel Daenzer brought up). > > Notably, I'm not using pci_ids.h and instead using the values themselves > > as has been done in the BSD drivers. I believe I have all the correct > > PCI IDs, but I'll take another look against your list. Is there any > > value in the families enum that's being associated with each pci id? > > Right now the drivers have a bunch of ifs/PCI-ID to compute families. Once we > get the PCI ID thing working we can slowly remove the ifs and switch to the > family enums. Families are more important for some chips (radeon) than others. > > The radeon driver already uses the family enum to tell secondary from primary > adapters. This is done so that linux PCI utlities will show the Radeon driver > as owning both devices. GET_SUGGESTED should be modified to return the family > enum too. Then we could remove the PCI ID's and ifs in the radeon DSO that are > recomputing the family. I think it is better to keep the family data in the > PCI ID table than to scatter it all over the code base via if/PCI-ID.
You're talking about the DRM here? Because that's all I was looking at, and I don't see drivers doing cases based on pci id data (checked radeon/mga, don't remember it happening in the others) as much as being passed family information from userland. I'll add a driver private field to the pci id list struct I was using and set it to NULL in the lists. Then we can convert the usage of userland-passed family info to family info from the kernel. Is it worth having a separate probe routine just to have the Linux PCI utilities show the driver as owning the secondary adapter as well? As it is, none of the drivers needed a separate probe routine. > > After that I'll see how hard the versioning ioctl thing would be to try > > to save us needing to add too many new ioctls for smallish changes like > > these. > > Another idea would be to deprecate SET_UNIQUE/GET_UNIQUE and then recover the > IOCTL numbers ten years from now. I really hope that we can come to some agreement on being able to deprecate DRM features after a certain time span or number of releases or something. I think having defined versions will help with that. -- Eric Anholt [EMAIL PROTECTED] http://people.freebsd.org/~anholt/ [EMAIL PROTECTED] ------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
