These PCI changes duplicate things that are in framebuffer. Shouldn't we be having a giant argument about them? I would think that is worse that DRM is is
Heh...you sure do like to start fights, don't you? :)
duplicating something in FB. The two IOCTLs I needed for reset don't exist in
either FB or DRM. Anyway I think these changes need to go in. The existing code
is broken in respect to PCI hotplug.
The DRM drivers can't use the existing Linux PCI probe method because the PCI ID tables are in the wrong format. They need two more fields for subvendor, subdevice IDs.
{0x5333, 0x8c20, 0, "Savage 3D"}, {0x5333, 0x8c20, 0, 0, 0, "Savage 3D"},
What is the extra 0? It's present in both "versions", but I'm not sure what its purpose is.
The patch I previously sent out used Linux OS probe method first, then only if
the Linux probe failed did I fallback to the manual scheme. A parallel method
could be used on BSD. The only reason you need the manual scheme is if FB is
already loaded and has the PCI ID registered.
Here's my suggestion. We should do this in 3 steps.
1. Modify Dave's patch to add the two extra fields. Looking at DRM(probe), the extra fields shouldn't require any code changes.
2. Commit the updated version of Dave's patch.
3. Commit some form of Jon's patch. I'm going to find it in the archives and review it. You may want to send out a version that is *just* this part. I seem to recall that your previous patches did more, but that could just be my failing memory.
You want to use the kernel probe scheme first. If the kernel probe suceeds it
will mark the hardware in use. The fallback scheme is a trick to use the
hardware without informing the kernel.
With the current code and no FB loaded, the DRM driver uses the hardware without marking it in use. While no kernel code does this to today, it would be perfectly legal for the kernel to reprogram the PCI BARs for the video memory to move it out of the way for something arriving via hotplug. If DRM is using this memory in stealth mode bad things are going to happen.
Right. That's why it would be good to get at least this portion of your code committed soon.
Second, I had a goal of moving all of the code that is mucking with the hardware registers down into the device driver and then have it present an IOCTL interface. Two reasons for this: 1) it gets rid of need for IOPRIV in the user space app and a reason for root priv 2) it moves the code driving the device into the device driver where it can be shared. Some of this code has per family
Can you elaborate? I'm not super familiar with this part of the DRM, so I just need a clarification. We're just talking about device initialization (i.e., PCI mapping) that the X-server currently does, right?
hardware bugs. The best place to encode the family data is in the ID strings. Something like this:
{0x5333, 0x8c20, 0, 0, 0, {family, "Savage 3D"}},
Not all chips have families so they just get zeros.
Both of the changes are compatible with BSD with some minor tweaks to the code.
I guess I don't understand this. What is the extra data you're proposing to encode in the string? Is that analogous to the device_private field in my old user-space patch? By that I mean does it serve the same purpose?
http://marc.theaimsgroup.com/?l=dri-devel&m=105979521324026&w=2
------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click -- _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
