From: Paul Mundt <pmundt@mvista.com>
To: James Simmons <jsimmons@transvirtual.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Linux console project <linuxconsole-dev@lists.sourceforge.net>
Subject: Re: Huge console switching lags
Date: Wed, 3 Oct 2001 10:27:23 -0700 [thread overview]
Message-ID: <20011003102723.A17423@mvista.com> (raw)
In-Reply-To: <20011003101944.29249@smtp.adsl.oleane.com> <Pine.LNX.4.10.10110030955470.32026-100000@transvirtual.com>
In-Reply-To: <Pine.LNX.4.10.10110030955470.32026-100000@transvirtual.com>; from jsimmons@transvirtual.com on Wed, Oct 03, 2001 at 09:58:30AM -0700
[-- Attachment #1: Type: text/plain, Size: 1070 bytes --]
On Wed, Oct 03, 2001 at 09:58:30AM -0700, James Simmons wrote:
> > Well, there are indeed a few improvements to get with machine specific
> > optimisations on unaccelerated framebuffer.
> [snip]...
>
> Neat trick. Please note also that no read operations to the framebuffer
> are done by the fbcon layer. Such reads should be to the shadow buffers
> (vc_screenbuffer) instead. Reading the framebuffer is a userland operation
> and as such you really only tricks for reading in userland.
>
And while we're on the subject of architecture specific optimizations for
unaccelerated framebuffers (or framebuffers in general for that matter),
on SH4 you can remap the video memory area through a store queue and perform
all writes through the remapped store queue area (there are two store queues,
each are 32bytes, and are flushed to the memory they were mapped to on a
prefetch instruction). This allows for very high speed writes to external
memory, as it was designed for.
Regards,
--
Paul Mundt <pmundt@mvista.com>
MontaVista Software, Inc.
[-- Attachment #2: Type: application/pgp-signature, Size: 240 bytes --]
next prev parent reply other threads:[~2001-10-03 17:27 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-10-02 9:11 Huge console switching lags Lorenzo Allegrucci
2001-10-02 16:57 ` Andrew Morton
2001-10-02 17:12 ` James Simmons
2001-10-02 18:10 ` Ricky Beam
2001-10-02 18:22 ` Andrew Morton
2001-10-02 18:24 ` Alan Cox
2001-10-02 18:32 ` Ricky Beam
2001-10-02 18:43 ` Alan Cox
2001-10-02 18:50 ` James Simmons
2001-10-02 22:39 ` Alan Cox
2001-10-02 22:50 ` James Simmons
2001-10-02 22:57 ` Alan Cox
2001-10-02 23:13 ` James Simmons
2001-10-03 10:19 ` Benjamin Herrenschmidt
2001-10-03 16:58 ` James Simmons
2001-10-03 17:27 ` Paul Mundt [this message]
2001-10-04 7:41 ` Geert Uytterhoeven
2001-10-04 16:49 ` James Simmons
2001-10-02 18:56 ` Chris Wedgwood
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=20011003102723.A17423@mvista.com \
--to=pmundt@mvista.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=jsimmons@transvirtual.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxconsole-dev@lists.sourceforge.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