Re: [Dri-devel] Adding hardware detection to DRI drivers
On Tue, 21 Oct 2003, Eric Anholt wrote: What is the proper way to get the equivalent of pci_name(pdev) on pre-2.5? Also, what is the cutoff where pci_name is available? Are the values from pci_name decimal or hex? The cut-off is 2.5.74 or so. The numbers are hex, and it's really implemented by just caching the result of sprintf(string, %04x:%02x:%02x.%d, pci_domain_nr(dev-bus), dev-bus-number, PCI_SLOT(dev-devfn), PCI_FUNC(dev-devfn)); (that last %d is irrelevant - the number is alway sin the range 0..7, so it's same in decimal, octal and hex ;). pci_name() is more convenient in printouts etc. If backwards compatibility of compatibility with *BSD makes pci_name() inconvenient, feel free to do it by hand like this, but the important parts I had were: - _please_ use the domain number. There are real machines with multiple independent PCI buses. We've already seen some real-life problems with drivers that look for companion chips without knowing about the domain thing, and as a result they find the wrong chip. The domain problem is rare today, but it will likely be less rare tomorrow. - please start thinking of the day when DRI won't be all about PCI, and the naming might be more complicated than the normal domain/bus/slot/func thing. Thus the suggestion to tag the address with the address type information. So whether you use pci_name() or anything else is much less important than the two points above. Linus --- This SF.net email is sponsored by OSDN developer relations Here's your chance to show off your extensive product knowledge We want to know what you know. Tell us and you have a chance to win $100 http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Adding hardware detection to DRI drivers
On Wed, 2003-10-15 at 10:42, Linus Torvalds wrote: On Wed, 15 Oct 2003, Jon Smirl wrote: If you are familar with the hardware please check that I got the PCI ID lists right. Please fix the fact that modern PCI is _not_ enumerated with just bus, slot, function. A lot of machines are starting to have a domain number, which allows fro multiple independent PCI subsystems in the same machine. On linux, you can use pci_name(pdev) to get a truly unique descriptor of the device (within the PCI subsystem). It will look something like :00:02.0 for domain 0, bus 0, device 2, function 0. In fact, for future sanity, it makes sense to not only have the location, but the bus _type_ there too. Some day, maybe we won't all be using PCI enumeration, and it really makes sense to prepare for that by explicitly saying what _kind_ of address it is. So if you have a struct pci_device *dev, then to uniquely identify it among all other devices, use something like snprintf(name, sizeof(name), pci%s, pci_name(dev)); which will allow you to use the same naming at some later day when/if you want to support something else. In other words, if you were to support sbus, you would have struct sbus_device = find_sbus_device(...) snprintf(name, sizeof(name), sbus%s, sbus_name(dev)); and the name would still be unique, and you can easily parse it to see what kind of device it is and where it is (even though different buses will have different notions of what where is). (Yeah, yeah, you're only supporting PCI-mapped devices now - even the AGP stuff obviously shows up in the PCI namespace. That doesn't mean that you should design the interfaces to only handle PCI). Sent privately first, but I've got a couple more questions now. What is the proper way to get the equivalent of pci_name(pdev) on pre-2.5? Also, what is the cutoff where pci_name is available? Are the values from pci_name decimal or hex? -- Eric Anholt[EMAIL PROTECTED] http://people.freebsd.org/~anholt/ [EMAIL PROTECTED] --- This SF.net email is sponsored by OSDN developer relations Here's your chance to show off your extensive product knowledge We want to know what you know. Tell us and you have a chance to win $100 http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Dri-devel] Adding hardware detection to DRI drivers
Linus Torvalds writes: On Wed, 15 Oct 2003, Michel Dänzer wrote: On Wed, 2003-10-15 at 21:01, Jon Smirl wrote: This new scheme allows the entire PCI probing stage of xfree to be eliminated. I'll believe it when the relevant XFree86 developers agree with you. :) If they don't, they are clueless. There's no way in _hell_ that XFree86 can do as good a job as the kernel, on as wide a variety of hardware. Basically, if the kernel booted far enough that XFree86 is an issue, then the kernel will know how to probe PCI devices. The same is _not_ true of XFree86. I fully agree with you and I wish this had been true at the time I implemented most of the PCI probing code in XFree86. At that time Linux did not provide all information XFree86 required and also relied on the PCI configuration the BIOS performed at POST time. This configuration proved to be wrong in a lot of cases - at least for non active VGA devices. We had to jump thru hoops bending over backwards to 'guess' some information that we could not savely probe. I'm not sure if PCI probing can be eliminated completely from XFree86 as it was suggested in the original posting as it also needs to run with hardware for which no DRI support is available. Furthermore for RAC (Resource Access Control) it needs to know the bus structure (ie which PCI buses live behind a PCI-PCI bridge on which primary bus). All this information however could be retrieved from the kernel. In fact this is done on all platforms except the 'PC-like' ia32 and AMD64 where direct IO access to the configuration space registers is used for performance reasons. On 'sane' OSes which take care of PCI probing and correcting of PCI resources themselves a lot of the PCI validation code could be bypassed. Unfortunately when I suggested this I was told that this code should stay in for all platforms to get much wider testing. I chose to refrain from starting a flamewar Yes, XF86 may need to have some legacy module for backwards compatibility. But thinking that X should try to probe on its own is just silly. There are things like cardbus or compact flash video cards - you need them for external video on things like an iPAQ. I don't think you _really_ want X to know about every single PCI bridge type out there, present and future, and for every architecture out there. For RAC I just would like to know the bus tree (or better to say the PCI-PCI bridges) and I would like to know if devices behind different host bridges or in different domains are in the same address space to know if VGA resources (which a lot of devices still need) may conflict with each other. The information about PCI host bridges was added for some special purposes (like to know if we are allowed to probe for sparsely located 8514 registers). - A question that is rather academical in nature on the platforms where it arises. Egbert. --- This SF.net email is sponsored by OSDN developer relations Here's your chance to show off your extensive product knowledge We want to know what you know. Tell us and you have a chance to win $100 http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Adding hardware detection to DRI drivers
On Tue, 2003-10-21 at 15:33, Linus Torvalds wrote: On Tue, 21 Oct 2003, Eric Anholt wrote: What is the proper way to get the equivalent of pci_name(pdev) on pre-2.5? Also, what is the cutoff where pci_name is available? Are the values from pci_name decimal or hex? The cut-off is 2.5.74 or so. The numbers are hex, and it's really implemented by just caching the result of sprintf(string, %04x:%02x:%02x.%d, pci_domain_nr(dev-bus), dev-bus-number, PCI_SLOT(dev-devfn), PCI_FUNC(dev-devfn)); (that last %d is irrelevant - the number is alway sin the range 0..7, so it's same in decimal, octal and hex ;). pci_name() is more convenient in printouts etc. If backwards compatibility of compatibility with *BSD makes pci_name() inconvenient, feel free to do it by hand like this, but the important parts I had were: - _please_ use the domain number. There are real machines with multiple independent PCI buses. We've already seen some real-life problems with drivers that look for companion chips without knowing about the domain thing, and as a result they find the wrong chip. The domain problem is rare today, but it will likely be less rare tomorrow. - please start thinking of the day when DRI won't be all about PCI, and the naming might be more complicated than the normal domain/bus/slot/func thing. Thus the suggestion to tag the address with the address type information. So whether you use pci_name() or anything else is much less important than the two points above. Excellent, this was just the info I wanted. I think this is all being covered in the changes I'm making now. The issue here was compatibility with linux 2.4.x, and possibly interpreting the busid in the X Server (not 100% sure if I'll need it in the end yet). For pre-2.5.74 I'm using a domain number of 0 on non-alpha and hose-bus-number on alpha, because of the lack of pci_domain_nr(), at least on the 2.4.19 I'm using I still need to figure out how XFree86 deals with domains, and if I can get the busid from XFree86 to match this format. The busid begins with pci:, and currently the DRM has that hardcoded, but it can be changed when we get non-pci drivers. Similarly for libdrm, so far. -- Eric Anholt[EMAIL PROTECTED] http://people.freebsd.org/~anholt/ [EMAIL PROTECTED] --- This SF.net email is sponsored by OSDN developer relations Here's your chance to show off your extensive product knowledge We want to know what you know. Tell us and you have a chance to win $100 http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Adding hardware detection to DRI drivers
Ville Syrj?l? [EMAIL PROTECTED] wrote: On Wed, Oct 15, 2003 at 03:48:38PM -0700, Alex Deucher wrote: there's also this driver: http://www.instmath.rwth-aachen.de:8000/linux/G450-PCI/ I'm not sure how the G4/550 and G200 differ in regard to PCI vs. AGP... AFAIK G450 PCI cards have an AGP-PCI bridge on the card which could do address translation just like the AGP GART. G200/G400 don't have that bridge. I'm not sure if the agpgart driver in that link you posted uses that bridge or some generic PCI GART stuff available on some architectures. Hey, the guy's a good friend of mine - but he never told me he was tweaking DRI stuff I'm pretty shure he wrote the driver for use on his UP2000 Alpha mainboard he used for visualization purpose, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- --- 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
Re: [Dri-devel] Adding hardware detection to DRI drivers
On Thu, 2003-10-16 at 03:08, Jon Smirl wrote: Same patch again with Matrox PCI IDs fixed and a linux-2.4 port. The patches are almost identical. Both against current bitkeeper source. Can people in the know please check the PCI IDs for the other hardware? I'm fairly sure Radeon, Rage128, and Matrox are right but the others haven't been checked. For radeonfb, I'm moving away from linux pci_ids.h list. It's just too much hell to keep in sync and is always a patch reject nightmare... At least for now, and until it's finished, my new radeonfb uses a separate file I stuffed in drivers/video/aty/ that contains a copy of XFree ATI PCI IDs. I may go back to pci_ids.h once the driver is complete enough, but I'd prefer not doing so, that would help keeping in sync with XFree. BTW. Another problem I've been reported recently, at least on one case, the BIOS ROM wasn't properly read on an x86 (signature was 0). I have to investigate more, but since the old driver worked, I tend to think the memory image may have been correct. I wonder about allowing for some kind of fallback here... Ben. --- 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
RE: [Dri-devel] Adding hardware detection to DRI drivers
On Thu, 2003-10-16 at 00:13, Eric Anholt wrote: Seems like we need a set-understood-version ioctl. What I'm imagining is an ioctl that takes in a DRM interface version and/or card-specific DRM interface version. It can then adjust its response to other ioctls appropriately. It would return the maximum of those versions that are understood (which is sort of a duplicate of the current version ioctl, but the generic DRM interface version is the new part). There would be a hook for the card-specific part of the DRM to get this understood version information, too, which may help in dealing with the radeon issues that have been discussed. If you mean the memory layout transition, that won't need this. Does this seem like a good idea? It might still be useful otherwise though. -- Earthling Michel Dnzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer --- 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
Re: [Dri-devel] Adding hardware detection to DRI drivers
Would he be interested in contributing his work back? or maybe explaining how/if he got it working? Alex --- Martin Spott [EMAIL PROTECTED] wrote: Ville Syrj?l? [EMAIL PROTECTED] wrote: On Wed, Oct 15, 2003 at 03:48:38PM -0700, Alex Deucher wrote: there's also this driver: http://www.instmath.rwth-aachen.de:8000/linux/G450-PCI/ I'm not sure how the G4/550 and G200 differ in regard to PCI vs. AGP... AFAIK G450 PCI cards have an AGP-PCI bridge on the card which could do address translation just like the AGP GART. G200/G400 don't have that bridge. I'm not sure if the agpgart driver in that link you posted uses that bridge or some generic PCI GART stuff available on some architectures. Hey, the guy's a good friend of mine - but he never told me he was tweaking DRI stuff I'm pretty shure he wrote the driver for use on his UP2000 Alpha mainboard he used for visualization purpose, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- --- 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 __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com --- 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
Re: [Dri-devel] Adding hardware detection to DRI drivers
On Thu, Oct 16, 2003 at 06:30:53AM -0700, Alex Deucher wrote: Would he be interested in contributing his work back? or maybe explaining how/if he got it working? I'll ask him - he moved to southern Germany earlier this year, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- --- 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
Re: [Dri-devel] Adding hardware detection to DRI drivers
Alex Deucher [EMAIL PROTECTED] wrote: Would he be interested in contributing his work back? or maybe explaining how/if he got it working? Sorry, currently he's forced to finish his dissertation. He says you might have to wait at least a month until he'll be able to deal with that, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- --- 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
Re: [Dri-devel] Adding hardware detection to DRI drivers
--- Michel Dänzer [EMAIL PROTECTED] wrote: On Thu, 2003-10-16 at 03:08, Jon Smirl wrote: [...] a linux-2.4 port. The patches are almost identical. For DRI CVS we need a single patch which works everywhere, see drm_os_linux.h for examples how this is handled for other stuff. The code didn't change any I just moved it around to make it apply to 2.4. You wanted to know it worked with 2.4. I will do another patch against DRI CVS when everything is stable. = Jon Smirl [EMAIL PROTECTED] __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com --- 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
Re: [Dri-devel] Adding hardware detection to DRI drivers
On Wed, 2003-10-15 at 18:08, Jon Smirl wrote: Same patch again with Matrox PCI IDs fixed and a linux-2.4 port. The patches are almost identical. Both against current bitkeeper source. Can people in the know please check the PCI IDs for the other hardware? I'm fairly sure Radeon, Rage128, and Matrox are right but the others haven't been checked. 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? 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. -- 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
Re: [Dri-devel] Adding hardware detection to DRI drivers
no worries... I was just curious. --- Martin Spott [EMAIL PROTECTED] wrote: Alex Deucher [EMAIL PROTECTED] wrote: Would he be interested in contributing his work back? or maybe explaining how/if he got it working? Sorry, currently he's forced to finish his dissertation. He says you might have to wait at least a month until he'll be able to deal with that, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com --- 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
Re: [Dri-devel] Adding hardware detection to DRI drivers
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
Re: [Dri-devel] Adding hardware detection to DRI drivers
On Thu, 2003-10-16 at 03:08, Jon Smirl wrote: [...] a linux-2.4 port. The patches are almost identical. For DRI CVS we need a single patch which works everywhere, see drm_os_linux.h for examples how this is handled for other stuff. What about the other points I raised? Anyway, it seems Eric will look into this. -- Michel Dnzer [EMAIL PROTECTED] wrote: How does standalone Mesa handle video modes etc.? [...] Plan is to do it in user space like Xfree does. Same for cursor support. A new daemon then, or will clients need to run as root? -- Earthling Michel Dnzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer --- 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
Re: [Dri-devel] Adding hardware detection to DRI drivers
On Wed, 15 Oct 2003, Jon Smirl wrote: If you are familar with the hardware please check that I got the PCI ID lists right. Please fix the fact that modern PCI is _not_ enumerated with just bus, slot, function. A lot of machines are starting to have a domain number, which allows fro multiple independent PCI subsystems in the same machine. On linux, you can use pci_name(pdev) to get a truly unique descriptor of the device (within the PCI subsystem). It will look something like :00:02.0 for domain 0, bus 0, device 2, function 0. In fact, for future sanity, it makes sense to not only have the location, but the bus _type_ there too. Some day, maybe we won't all be using PCI enumeration, and it really makes sense to prepare for that by explicitly saying what _kind_ of address it is. So if you have a struct pci_device *dev, then to uniquely identify it among all other devices, use something like snprintf(name, sizeof(name), pci%s, pci_name(dev)); which will allow you to use the same naming at some later day when/if you want to support something else. In other words, if you were to support sbus, you would have struct sbus_device = find_sbus_device(...) snprintf(name, sizeof(name), sbus%s, sbus_name(dev)); and the name would still be unique, and you can easily parse it to see what kind of device it is and where it is (even though different buses will have different notions of what where is). (Yeah, yeah, you're only supporting PCI-mapped devices now - even the AGP stuff obviously shows up in the PCI namespace. That doesn't mean that you should design the interfaces to only handle PCI). Linus --- 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
RE: [Dri-devel] Adding hardware detection to DRI drivers
John, i gave your code a short review and found nothing worth a note. In other words, if there is a problem at all then i've overlooked that due to the speed i browsed it. One thing to ask you: there is always those secondary PCI ID on the current Radeon designs. Do you see some chance to get rid of irritating logfile messages that concern those 2nd ID. I currently do think of this operation for DRM(probe): return 0 = device not supported by this driver return 1 = device is supported by this driver return 2 = device is not useable and must be forecfully ignored in probing. What do you think? -Alex. -Original Message- From: Jon Smirl [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 15, 2003 19:12 To: dri-devel Subject: Re: [Dri-devel] Adding hardware detection to DRI drivers The attached patch adds a new DRM IOCTL: DRM_IOCTL_GET_SUGGESTED_UNIQUE. It works by hooking into the OS PCI device detection at module load time. Each DRM driver now contains the PCI IDs of all the cards that it supports. The OS then matches these to the hardware in the system. Current Xfree binaries will work unmodifed with this change. The new call is needed to support standalone Mesa. Standalone Mesa does not have the PCI probing code that is in Xfree. I'm also trying to make config files an option for standalone Mesa. To use it: open the DRM device IOCTL: DRM_IOCTL_GET_SUGGESTED_UNIQUE. IOCTL: DRM_IOCTL_SET_UNIQUE If you are familar with the hardware please check that I got the PCI ID lists right. The patch is against kernel 2.6.0-test7. I've been told that the same code should would with BSD but I don't run it. = Jon Smirl [EMAIL PROTECTED] __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com --- 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
RE: [Dri-devel] Adding hardware detection to DRI drivers
--- Alexander Stohr [EMAIL PROTECTED] wrote: One thing to ask you: there is always those secondary PCI ID on the current Radeon designs. Do you see some chance to get rid of irritating logfile messages that concern those 2nd ID. The new code allows a different way of initializing XFree. For example: At install time Anacona/hotplug/whatever gets the right DRI device driver installed. Now assuming no xconfig file... xfree loads, opens the first DRM device, and gets SUGGESTED_UNIQUE. That will tell Xfree what video hardware to use. Modes are all determined by the EDID/hardware exchange. This should be enough to get xfree started without a config file. This new scheme allows the entire PCI probing stage of xfree to be eliminated. Of course, if these is an xconfig file the old scheme is used. Also, the device driver claims both the primary and secondary PCI devices. They are marked as such in the PCI id_table. In the card of the secondary devices the driver just claims them and does nothing with them. = Jon Smirl [EMAIL PROTECTED] __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com --- 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
Re: [Dri-devel] Adding hardware detection to DRI drivers
On Wed, 2003-10-15 at 19:12, Jon Smirl wrote: The attached patch adds a new DRM IOCTL: DRM_IOCTL_GET_SUGGESTED_UNIQUE. It works by hooking into the OS PCI device detection at module load time. Each DRM driver now contains the PCI IDs of all the cards that it supports. The OS then matches these to the hardware in the system. Current Xfree binaries will work unmodifed with this change. The new call is needed to support standalone Mesa. Standalone Mesa does not have the PCI probing code that is in Xfree. How does standalone Mesa handle video modes etc.? I'm not sure the DRM is the right place for this, but I certainly think we shouldn't rush to allocate a precious driver independent ioctl until we're absolutely sure it's the best solution. The patch is against kernel 2.6.0-test7. Does it rely on any 2.6 specific APIs? The DRM in DRI CVS must build and work with 2.4 kernels. I've been told that the same code should would with BSD but I don't run it. I doubt it does in this form (seems to use Linux specific APIs directly), but it might be easy to fix that. @@ -160,14 +176,10 @@ #endif /** - * The default number of instances (minor numbers) to initialize. + * Maximum number of devices supported */ -#ifndef DRIVER_NUM_CARDS -#define DRIVER_NUM_CARDS 1 -#endif Does the patch fix all problems with multiple instances in all DRMs? That was the reason only to allow a single instance by default. Also, at least the first patch contained some gratuitous whitespace changes, haven't looked at the second version in detail. -- Earthling Michel Dnzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer --- 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
RE: [Dri-devel] Adding hardware detection to DRI drivers
On Wed, 2003-10-15 at 21:01, Jon Smirl wrote: Now assuming no xconfig file... xfree loads, opens the first DRM device, and gets SUGGESTED_UNIQUE. That will tell Xfree what video hardware to use. Modes are all determined by the EDID/hardware exchange. This should be enough to get xfree started without a config file. This doesn't change anything for stuff like input devices though. Anyway, there's code in XFree86 CVS already which allows the X server to start with no config file using a different approach. This new scheme allows the entire PCI probing stage of xfree to be eliminated. I'll believe it when the relevant XFree86 developers agree with you. :) -- Earthling Michel Dnzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer --- 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
RE: [Dri-devel] Adding hardware detection to DRI drivers
On Wed, 15 Oct 2003, Michel Dänzer wrote: On Wed, 2003-10-15 at 21:01, Jon Smirl wrote: This new scheme allows the entire PCI probing stage of xfree to be eliminated. I'll believe it when the relevant XFree86 developers agree with you. :) If they don't, they are clueless. There's no way in _hell_ that XFree86 can do as good a job as the kernel, on as wide a variety of hardware. Basically, if the kernel booted far enough that XFree86 is an issue, then the kernel will know how to probe PCI devices. The same is _not_ true of XFree86. Yes, XF86 may need to have some legacy module for backwards compatibility. But thinking that X should try to probe on its own is just silly. There are things like cardbus or compact flash video cards - you need them for external video on things like an iPAQ. I don't think you _really_ want X to know about every single PCI bridge type out there, present and future, and for every architecture out there. Linus --- 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
RE: [Dri-devel] Adding hardware detection to DRI drivers
[ Following up to myself ] On Wed, 15 Oct 2003, Linus Torvalds wrote: Yes, XF86 may need to have some legacy module for backwards compatibility. But thinking that X should try to probe on its own is just silly. This is also relevant to 2D, since more and more graphics cards really shouldn't be accessed directly, but through the command queues. Which means that you really want to have a kernel side driver for them anyway, if only to be able to take advantage of interrupts etc. Unless you want to busy-wait. (And no, you're not going to do interrupt routing setup in user mode. You really _need_ the kernel module for that, anyway.) Linus --- 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
RE: [Dri-devel] Adding hardware detection to DRI drivers
On Wed, 2003-10-15 at 22:58, Linus Torvalds wrote: On Wed, 15 Oct 2003, Michel Dnzer wrote: On Wed, 2003-10-15 at 21:01, Jon Smirl wrote: This new scheme allows the entire PCI probing stage of xfree to be eliminated. I'll believe it when the relevant XFree86 developers agree with you. :) If they don't, they are clueless. I'm with you Linus. It just seems that Jon hasn't seen some XFree86 developers speak on the topic yet. :) -- Earthling Michel Dnzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer --- 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
RE: [Dri-devel] Adding hardware detection to DRI drivers
--- Michel Dänzer [EMAIL PROTECTED] wrote: On Wed, 2003-10-15 at 22:58, Linus Torvalds wrote: On Wed, 15 Oct 2003, Michel Dänzer wrote: On Wed, 2003-10-15 at 21:01, Jon Smirl wrote: This new scheme allows the entire PCI probing stage of xfree to be eliminated. I'll believe it when the relevant XFree86 developers agree with you. :) If they don't, they are clueless. I'm with you Linus. It just seems that Jon hasn't seen some XFree86 developers speak on the topic yet. :) The context of the comment was that PCI probing could be optionally eliminated in the case where a DRI driver exists. Since there are many 2D cards without DRI drivers Xfree probing obviously can't be eliminated yet. I'm not planning on modifying Xfree to eliminiate the probing either. I'm just trying to build a base that would allow that code to be written in the future. I want these changes so that I can eliminate the probing code in standalone Mesa. = Jon Smirl [EMAIL PROTECTED] __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com --- 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
RE: [Dri-devel] Adding hardware detection to DRI drivers
On Wed, 2003-10-15 at 14:40, Jon Smirl wrote: Has any one checked the PC IDs in each driver? For example I'm not sure that all of the cards I added to the MGA driver are 3D capable. I went through the Xfree source trying to figure out an accurate list but sometime it wasn't obvious. I've got pretty accurate lists in the BSD DRM I think. I'm going to take a look at integrating your work and making it portable. -- 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
RE: [Dri-devel] Adding hardware detection to DRI drivers
Has any one checked the PC IDs in each driver? For example I'm not sure that all of the cards I added to the MGA driver are 3D capable. I went through the Xfree source trying to figure out an accurate list but sometime it wasn't obvious. = Jon Smirl [EMAIL PROTECTED] __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com --- 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
RE: [Dri-devel] Adding hardware detection to DRI drivers
On Wed, 2003-10-15 at 12:01, Jon Smirl wrote: --- Alexander Stohr [EMAIL PROTECTED] wrote: One thing to ask you: there is always those secondary PCI ID on the current Radeon designs. Do you see some chance to get rid of irritating logfile messages that concern those 2nd ID. The new code allows a different way of initializing XFree. For example: At install time Anacona/hotplug/whatever gets the right DRI device driver installed. Now assuming no xconfig file... xfree loads, opens the first DRM device, and gets SUGGESTED_UNIQUE. That will tell Xfree what video hardware to use. Modes are all determined by the EDID/hardware exchange. This should be enough to get xfree started without a config file. This new scheme allows the entire PCI probing stage of xfree to be eliminated. Of course, if these is an xconfig file the old scheme is used. Also, the device driver claims both the primary and secondary PCI devices. They are marked as such in the PCI id_table. In the card of the secondary devices the driver just claims them and does nothing with them. In the BSD world, kernel drivers attach to a specific piece of hardware. This means that there is a specific association between the drm_device_t *, the /dev/dri/cardX, and what piece of hardware it's supposed to deal with (we violate rules currently, but it needs to be fixed in the future). If the Linux drivers go to probing PCI IDs, could it also start creating /dev/dri/cardXs which are associated with a specific piece of hardware? The get/set unique thing is a problem, though. It seems to me that we ought to have /dev/dri/cardX start with a unique value reporting sufficient information to identify it. A new server would do getuniques on the /dev/dri/cardXs until it found one matching the hardware it was trying to use the drm for. If an old server does a setunique, then it overrides what the kernel had, and at some unspecified time in the future we could deprecate that interface. This eliminates the need for a separate get_suggested_unique ioctl. I'm interested in your changes, I'm going through them now to see how to make them portable, too. -- 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
RE: [Dri-devel] Adding hardware detection to DRI drivers
--- Eric Anholt [EMAIL PROTECTED] wrote: If the Linux drivers go to probing PCI IDs, could it also start creating /dev/dri/cardXs which are associated with a specific piece of hardware? The get/set unique thing is a problem, though. It seems to me that we ought to have /dev/dri/cardX start with a unique value reporting sufficient information to identify it. A new server would do getuniques on the /dev/dri/cardXs until it found one matching the hardware it was trying to use the drm for. If an old server does a setunique, then it overrides what the kernel had, and at some unspecified time in the future we could deprecate that interface. This eliminates the need for a separate get_suggested_unique ioctl. This was the first way I coded it. But when you specificy a driver name in xconfig and no BUSID, xfree uses drmOpenByName(). OpenByName searches the drivers for the driver name and a bank unique id, then sets it. Since the only driver with the right driver name already has the unique id filled in, Xfree fails to load. To fix this you would have to change the existing binaries. = Jon Smirl [EMAIL PROTECTED] __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com --- 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
RE: [Dri-devel] Adding hardware detection to DRI drivers
On Wed, 2003-10-15 at 14:57, Jon Smirl wrote: --- Eric Anholt [EMAIL PROTECTED] wrote: If the Linux drivers go to probing PCI IDs, could it also start creating /dev/dri/cardXs which are associated with a specific piece of hardware? The get/set unique thing is a problem, though. It seems to me that we ought to have /dev/dri/cardX start with a unique value reporting sufficient information to identify it. A new server would do getuniques on the /dev/dri/cardXs until it found one matching the hardware it was trying to use the drm for. If an old server does a setunique, then it overrides what the kernel had, and at some unspecified time in the future we could deprecate that interface. This eliminates the need for a separate get_suggested_unique ioctl. This was the first way I coded it. But when you specificy a driver name in xconfig and no BUSID, xfree uses drmOpenByName(). OpenByName searches the drivers for the driver name and a bank unique id, then sets it. Since the only driver with the right driver name already has the unique id filled in, Xfree fails to load. To fix this you would have to change the existing binaries. Seems like we need a set-understood-version ioctl. What I'm imagining is an ioctl that takes in a DRM interface version and/or card-specific DRM interface version. It can then adjust its response to other ioctls appropriately. It would return the maximum of those versions that are understood (which is sort of a duplicate of the current version ioctl, but the generic DRM interface version is the new part). There would be a hook for the card-specific part of the DRM to get this understood version information, too, which may help in dealing with the radeon issues that have been discussed. Does this seem like a good idea? -- 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
Re: [Dri-devel] Adding hardware detection to DRI drivers
On Wed, Oct 15, 2003 at 02:40:07PM -0700, Jon Smirl wrote: Has any one checked the PC IDs in each driver? For example I'm not sure that all of the cards I added to the MGA driver are 3D capable. The driver only supports G200/G400/G550. Remove the rest. I'm not sure about the G200 PCI entry. The driver doesn't work on PCI cards. Hmm... Why aren't we using the AGP GART to support PCI cards? At least on my system PCI cards can see the AGP aperture... -- Ville Syrjälä [EMAIL PROTECTED] http://www.sci.fi/~syrjala/ --- 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
Re: [Dri-devel] Adding hardware detection to DRI drivers
there's also this driver: http://www.instmath.rwth-aachen.de:8000/linux/G450-PCI/ I'm not sure how the G4/550 and G200 differ in regard to PCI vs. AGP... Alex --- Ville_Syrjälä [EMAIL PROTECTED] wrote: On Wed, Oct 15, 2003 at 02:40:07PM -0700, Jon Smirl wrote: Has any one checked the PC IDs in each driver? For example I'm not sure that all of the cards I added to the MGA driver are 3D capable. The driver only supports G200/G400/G550. Remove the rest. I'm not sure about the G200 PCI entry. The driver doesn't work on PCI cards. Hmm... Why aren't we using the AGP GART to support PCI cards? At least on my system PCI cards can see the AGP aperture... -- Ville Syrjälä [EMAIL PROTECTED] http://www.sci.fi/~syrjala/ __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com --- 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
Re: [Dri-devel] Adding hardware detection to DRI drivers
On Wed, Oct 15, 2003 at 03:48:38PM -0700, Alex Deucher wrote: there's also this driver: http://www.instmath.rwth-aachen.de:8000/linux/G450-PCI/ I'm not sure how the G4/550 and G200 differ in regard to PCI vs. AGP... AFAIK G450 PCI cards have an AGP-PCI bridge on the card which could do address translation just like the AGP GART. G200/G400 don't have that bridge. I'm not sure if the agpgart driver in that link you posted uses that bridge or some generic PCI GART stuff available on some architectures. The G-series chips themselves are really wonderful because you just point them to an address and tell them if that memory is AGP,PCI or local framebuffer and then the chip can do anything with that memory. Some time ago I did a patch for DirectFB which put off-screen surfaces to AGP (or PCI) memory. Unfortunately now that DirectFB has 3D support through DRI I can't really finish that patch. agpgart has a stupid one user limitation and the bind ioctl isn't really multi-user friendly either. What happened to that agpgart 2.0 stuff? Does it lift these restrictions? -- Ville Syrjälä [EMAIL PROTECTED] http://www.sci.fi/~syrjala/ --- 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
