On Wed, 2005-06-08 at 00:01 -0400, Jon Smirl wrote: > On 6/7/05, Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote: > > On Tue, 2005-06-07 at 15:48 -0400, Jon Smirl wrote: > > > Am I right in this interpretation? First I need to get the > > > bus/device/func of the card, then I need to tell this to the driver > > > (which must already know this info). I then get back the IRQ number, > > > which I then pass back to the driver (which already know this) and > > > tell it to turn interrupts on. > > > > While we are at it, why the hell did we split up the PCI ID in > > bus,dev,fn like that ? We really want either a single structure > > containing the PCI ID to be passed around or a C string. The current > > scheme can't be made to work properly with PCI domains. > > There is no need to fix the call parameters, the calls themselves > aren't really needed. User space shouldn't need to pass the PCI slot > id back into a driver it already has a handle for. The driver should > know this info without being told. > > These call messes are a result of fbdev and DRM not being linked. This > prevents DRM from using the kernel PCI ID mechanism for binding to > hardware. We can't add PCI ID binding to DRM since that prevents fbdev > from loading. The only solution is to link fbdev and DRM.
I don't think framebuffer devices were a consideration (let alone a factor either way) at all back in the days when this code was written... -- Earthling Michel Dänzer | Debian (powerpc), X and DRI developer Libre software enthusiast | http://svcs.affero.net/rm.php?r=daenzer ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click -- _______________________________________________ Dri-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dri-devel
