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
next prev parent 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).