Re: [PATCH] neofb patches

["Michel Dänzer" <michel@daenzer.net>]

On Wed, 2004-04-28 at 18:37, Otto Solares wrote:
> On Wed, Apr 28, 2004 at 12:16:56PM +0200, Michel Dänzer wrote:
> > On Wed, 2004-04-28 at 09:08, Otto Solares wrote:
> > > 
> > > I like the fbdev abstraction but it has too many limitations:
> > 
> > [...]
> > 
> > > - It dangerously coexists currently with the DRM queues and
> > >   SAREA areas.  
> > 
> > How does a DRM SAREA matter to a framebuffer device?
> 
> It matters as long as the SAREA have a hardware lock
> to synchronize access to the hardware.  That lock must
> be owned by a single entity in the kernel, or at least
> the fbdev drivers must be aware of that lock, 

Why? The purpose of the DRM lock is arbitration and state management
between DRM clients. It's not necessarily connected to direct hardware
access.

> it would be more simple if the fbdev drivers take care of it being
> the single entity in the kernel taking care of the hardware.

Jon Smirl thinks it should be the DRM...

> > > Both must merge in fbdev.
> > 
> > I agree that they should cooperate properly, but I don't see how it
> > follows that they must merge.
> 
> DRM and fbdev must merge so i repeat: just a single
> kernel entity should own FIFO queues, shared locks,
> DMA, the framebuffer, IO registers, interrupts, etc.

A small low-level driver could handle this, which both the framebuffer
device and the DRM use. Linus has proposed this approach, and I must say
I like it.


-- 
Earthling Michel Dänzer      |     Debian (powerpc), X and DRI developer
Libre software enthusiast    |   http://svcs.affero.net/rm.php?r=daenzer



-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE. 
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click