> 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
> 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.
These changes aren't changing anything if you look at the patch it simply
moves us from what we have now which is unacceptable for the kernel due
to its duplication of pci.ids, to something that is acceptable to the
kernel, the scripts just create the header files.. the actual compiled
should be nearly the exact same....
I've looked at your patches and my next trick is to start merging across
your PCI changes on top of these, I'd like to get this code into the
kernel so the DRMs are fully sync'ed (I might like also to move the 2.4
compat code into a separate header file...)
this cide doesn't change any behaviour and can't break anything..
> 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"},
yeah I'm aware of this but I'm still using the older sneaky method for now
under the principal of least surprise.. this will me merged in my next
patch...
> 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.
>
> 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.
yes but it is also the current behaviour and changing it in a stable
kernel series is probably not acceptable... I know I wouldnt :-)
> 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.
>
> 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 hardware bugs. The best place to encode
> the family data is in the ID strings. Something like this:
Again I'll look at this, I'm trying to make the DRM move in reviewable
chunks... otherwise we get what we had before where no-one is able to keep
up ..
Dave.
--
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.ie
pam_smb / Linux DECstation / Linux VAX / ILUG person
-------------------------------------------------------
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
