All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sven Luther <sven.luther@wanadoo.fr>
To: Jon Smirl <jonsmirl@yahoo.com>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>,
	fb-devel <linux-fbdev-devel@lists.sourceforge.net>
Subject: Re: Large framebuffers and HIGHMEM systems
Date: Wed, 10 Sep 2003 17:56:03 +0200	[thread overview]
Message-ID: <20030910155603.GA15485@iliana> (raw)
In-Reply-To: <20030910150100.89767.qmail@web14914.mail.yahoo.com>

On Wed, Sep 10, 2003 at 08:01:00AM -0700, Jon Smirl wrote:
> --- Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > Or modify ioremap() to print the message? This problem is not only limited to
> > frame buffer devices, but to every driver that needs to ioremap() large
> > regions, right?
> > 
> ioremap() is supposed to map the region into the bottom 1GB or fail. After
> ioremap() fails you need to use a different API to map to the highmem regions.
> The way Linux is set up there is always about 20-30MB of free address space
> below 1GB. All of the hardware I've seen can map into that space. The only
> exception is the huge amount of address space needed for kernel mapped video
> frame buffers.
> 
> Memory below 1GB is important to the kernel for keeping page tables. Page table
> can be pushed above 1GB but you incur performance penalties. There is no
> problem creating a 256MB hole with reserve=XXXX in the 1GB address space to
> allow the latest ATI/NV cards to run with framebuffers; but doing this will
> slow your system down. It is also a very non-obvious solution to why a
> framebuffer fails to load.
> 
> I don't think we should be forcing non-performance sensitve framebuffer memory
> into the bottom 1GB and pushing performance sensitive page tables into highmem.
> Besides, we are going that have to do something, we are likely to have 1GB
> video cards two years from now.

We already have 512MB ones, i guess you will not have to wait for as
long as two years for 1GB video cards.

Friendly,

Sven Luther


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

  reply	other threads:[~2003-09-10 15:56 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-09-09 21:28 Large framebuffers and HIGHMEM systems Jon Smirl
2003-09-10  8:40 ` Geert Uytterhoeven
2003-09-10 15:01   ` Jon Smirl
2003-09-10 15:56     ` Sven Luther [this message]
2003-09-10 16:21       ` Geert Uytterhoeven
2003-09-10 16:33         ` Sven Luther
2003-09-12 22:56 ` James Simmons
2003-09-13  3:19   ` Jon Smirl

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=20030910155603.GA15485@iliana \
    --to=sven.luther@wanadoo.fr \
    --cc=geert@linux-m68k.org \
    --cc=jonsmirl@yahoo.com \
    --cc=linux-fbdev-devel@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 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.