Re: [Linux-fbdev-devel] [PATCH] Tile Blitting

[Antonino D. <ad...@po...>]

On Sun, 2003-03-02 at 20:14, Geert Uytterhoeven wrote:
> On Thu, 27 Feb 2003, James Simmons wrote:
> > > On Don, 2003-02-27 at 15:15, Antonino Daplas wrote: 
> > > > On Thu, 2003-02-27 at 09:18, James Simmons wrote:
> > > >  
> > > > > > Thus, the restriction that the buffer must be completely copied by the
> > > > > > driver before returning.  And because of this restriction, an extra copy
> > > > > > which might be unnecessary cannot be avoided (this was noted by Petr).
> > > > > > 
> > > > > > Treating the buffer as a ringbuffer, we eliminate these restrictions.
> > > > > 
> > > > > I didn't realize that the below was a ringbuffer implementation. The name
> > > > > threw me off. 
> > > > 
> > > > Well, it's not strictly a ringbuffer implementation.  This would require
> > > > a head and tail pointer where fbcon will adjust the tail and the
> > > > driver/hardware will adjust the head.  This will be very difficult to
> > > > implement in a device independent manner.  So we just cheat by issuing
> > > > an fb_sync() per loop to flush all pending commands.
> > > 
> > > That still seems suboptimal though. What the DRM often does is have the
> > > chip write an age value to a scratch register when it's done processing
> > > something. Maybe something like that could be used to avoid waiting for
> > > the chip to go idle at all?
> > 
> > Don't waste your time. I'm removing all the changes that have been done 
> > since 2.5.51. After that I will no longer be co-maintainter of the 
> > framebuffer layer. 
> 
> Are you sure about that?!?!?
> 

I agree.  Actually, I'm not worried about Tile blitting.  It should be
mature since it's basically a rehash of the 2.4 API.  If I'm going to
worry about something, it's the standard accel_putcs() code, especially
if thread-safety is an issue.

Is thread-safety a real problem?  That was also my concern before, which
is why I looked at vt.c.  From what I can see, there's always an
"acquire_console_sem()" before calling any of the console methods. The
console semaphore is supposed to guarantee serialization and exclusive
access to the console (see linux/kernel/printk.c).

Tony