Re: ioremap problem on highmem

[Jon Smirl <jonsmirl@yahoo.com>]

Fix is not that simple. There is a basic conflict with mapping framebuffers
into the kernel address space and the kernel's need of that address space for
other purposes. Drivers need to be rewritten to do one of:

1) Map the frame buffer into the kernel address space a few pages at a time.
This is how kernel high mem support works.
2) Map the minimal amount of address space necessary for visible framebuffer.
This is what the VGA driver does. It works most of the time.
3) Use a user space program to map the framebuffer and do the drawing.
4) Use the reserve= to reserve the needed address space. This boots performance
sensitive page tables into highmem while keeping your slow framebuffer in
lowmem.

It is only fbconsole that uses the kernel mapped framebuffer. If you aren't
using fbconsole you could just delete the ioremap code from the framebuffer
driver. Another quick fix would be to eliminate the framebuffer ioremaps from
each driver and instead do it in the fbconsole driver. This would let people
still load fb drivers and not load fbconsole.

The more I learn about fbconsole the more I think it is a bad idea. This is no
comment on the skill of the people writing it, I just think the whole concept
of mapping the framebuffer in to kernel space needs to be eliminated. There is
only 1GB of kernel space and it make no sense to chew up 128MB or 256MB of it
mapping a framebuffer just to get a penguin at boot. I do think penguin is
cute, but not cute enough to waste kernel address space on.

Right now I am exploring this alternative:
1) System boots using VGA mode or whatever BIOS provides.
2) DRI drivers are loaded. They have been modified to use PCI subsys to find
hardware.
3) Run a console program. This program uses a user level lib (from standalone
mesa) to switch to graphics mode and draw the console. Like gnome-terminal does
under X.
4) Run X or standalone mesa on another VT. Everything shares DRI driver for
hardware interface.

The advantage to this is that there is a single hardware driver in the system -
the DRI one; the fb driver is gone. The only loss I see is no penguin at boot. 

Standalone Mesa is using the fb driver to 1) find the hardware, 2) change
modes. Under the new system the DRI driver finds the hardware. Mode
setting/EDID is done with a user level library - like X does. Once get this
finished Standalone Mesa won't need FB any more.


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

__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com


-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php