All of lore.kernel.org
 help / color / mirror / Atom feed
From: Antonino Daplas <adaplas@pol.net>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: "James Simmons" <jsimmons@infradead.org>,
	"Michel Dänzer" <michel@daenzer.net>,
	"Linux Fbdev development list"
	<linux-fbdev-devel@lists.sourceforge.net>
Subject: Re: [PATCH] Tile Blitting
Date: 04 Mar 2003 05:32:17 +0800	[thread overview]
Message-ID: <1046725840.1277.8.camel@localhost.localdomain> (raw)
In-Reply-To: <Pine.GSO.4.21.0303021312400.9181-100000@vervain.sonytel.be>

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



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

  reply	other threads:[~2003-03-03 21:31 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-02-23  4:42 [PATCH] Tile Blitting Antonino Daplas
2003-02-23  7:43 ` Antonino Daplas
2003-02-23 11:07   ` Antonino Daplas
2003-02-26 20:11     ` James Simmons
2003-02-27  0:35       ` Antonino Daplas
2003-02-27  1:18         ` James Simmons
2003-02-27 14:15           ` Antonino Daplas
2003-02-27 18:25             ` Michel Dänzer
2003-02-27 19:48               ` James Simmons
2003-03-02 12:14                 ` Geert Uytterhoeven
2003-03-03 21:32                   ` Antonino Daplas [this message]
2003-02-27 21:47               ` Antonino Daplas

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1046725840.1277.8.camel@localhost.localdomain \
    --to=adaplas@pol.net \
    --cc=geert@linux-m68k.org \
    --cc=jsimmons@infradead.org \
    --cc=linux-fbdev-devel@lists.sourceforge.net \
    --cc=michel@daenzer.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.