--- James Simmons <jsimmons@infradead.org> wrote:

quoted

Fbdev needs to come up with a general solution for mapping large

framebuffers

quoted

on systems with over 1GB memory. For example my system does not have 64MB

of

quoted

free address space below 1GB, this causes my framebuffer drivers to fail

when

quoted

loading. With RAM prices at $200 for 1GB memory 1GB systems will be common
during the 2.6 timeframe.

There are many possible solutions...
1) add reserve=XXXX to the kernel at boot. Drawback to this is reserving
256-512MB takes this memory out of lowmem kernel use. This will push page
tables into highmem slowing the whole system down.

NOPE!!!!

This is what I have to do right now with 1GB of memory and a 64MB Radeon on
2.6. We need to fix this. We should also add an error message right now to
framebuffer ioremap()'s telling users that this what they need to do to get
around the failure.

quoted

2) Only map a 2048x2048x32 piece of the framebuffer. This still uses 16MB

of

quoted

address space which may not always be available. It could be possible to

modify

quoted

the kernel to always reserve this much address space at boot.

I was thinking about a solution like this. We have to consider that alot 
of drivers use the extra memory space to do hardware panning to create a
scrolling effect. We could set a limit to the amount of memory mapped for 
this effect. 

quoted

3) Only map what is actually needed on each mode change. Mode change could

fail

quoted

at run time if not enough free address space.

That is acceptable. I doubt it would fail all the time. We lose th 
eperformance boost for scrolling tho :-(

If you boot in a low res mode, mode changing to a higher res may fail because
there is not enough address space. Trying to fit into the small amount of
remaining VM space may  fragment it preventing you from getting 64MB of
contiguous address space.

quoted

4) Map the buffer into the highmem address space using the highmem access
macros.

We could do a partial mapping into highmem space. Lomem memory what we are 
using now. High memory for what we need less often.

quoted

5) Map the fb in a user process and send it signals to draw.

Yuck!!

I'd like to hear a good explanation of why we need to draw to framebuffers in
the kernel. I'm starting to think that we should draw on whatever the BIOS sets
up untill user space is active. Then point the kernel to a user space process
that draws the console for specific hardware. Kernel VESA fb would always be
loaded as back up in case these processes die. User space proccesses don't have
the same problem with virtual memory address space shortages.

The good news is fully accelerated drivers don't need to ioremap the 
entire range in memory at one time. screen_base is not much use to them. 
The only place this is not true is fb_read and fb_write. We could setup a 
blitting engine use tho :-) Then of course mmap a huge framebuffer to 
memory would fail then with 1 GB memory systems. 

P.S
    How bad is the cost to access high memory?

High mem might be the best solution. Make a rule that kernel framebuffers are
always mapped to high memory. I'd make it a rule so that this code will get
tested on all systems not just a few with 1GB today. Either your page tables
are going into high memory or your framebuffer is, if you ask me there is no
choice about this and the framebuffer is going high.

I have never used highmem before but I think it works something like this.
First we need some way to ioremap() to a highmem address.  Then before each
access to a high mem address there is a macro for converting the high mem
address to a low mem one, and then another macro for freeing it. These marcos
mess with a page table entry for a low mem page and make it point to the high
mem one. There are a limited number for page table entries reserved for this
process so you need to keep mapping and unmapping.

This is slow to a CPU but not to a human,  we're doing an APG or PCI memory
cycle which takes forever anyway. And it sure is easier than explaining why a
system won't boot because it is out of kernel virtual memory space.

=====
Jon Smirl
jonsmirl@yahoo.com

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com


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