On Fri, 2005-06-10 at 20:03 -0400, Adam Jackson wrote: > On Friday 10 June 2005 19:38, Benjamin Herrenschmidt wrote: > > Anyway, I really want a slightly different approach than what Jon is > > doing, that is a 3 modules scenario: > > > > - A basic "stub" module that attaches to the PCI card. It doesn't touch > > the hardware per-se (thus won't break your VGA console, though radeonfb > > without fb console shouldn't either, the problem you have is a bug). > > That stub contains the "common" code like IRQ handling, card type > > detection, maybe vram detection etc... And some locking facility > > See this is what I was thinking, was that there was an "fb" layer below > radeonfb/atyfb/whatever, or alternately that there was a generic pci handler > for each device. Apparently radeonfb is the lowest level right now.
Yes. There can't be a generic PCI handler for lots of reasons, you can't just have several independent drivers tap the same HW without proper locking, arbitration & other device specific things. But we can make a radeon-specific "stub" that puts that common code in a single place and lets the other bits optionally get on top. However, Jon approach is fine for now, as long as the bug that cause the VGA console to be wiped out is fixed. I sent Andrew a patch for it today. Ben. ------------------------------------------------------- This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput a projector? How fast can you ride your desk chair down the office luge track? If you want to score the big prize, get to know the little guy. Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20 -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
