ioremap problem on highmem

ioremap problem on highmem

[Otto Solares]

Hi!

FYI radeonfb is failing when highmem enabled, workaround with kernel param 'mem' < 896M.

Interesting bits from dmesg:

Linux version 2.6.0-test6-bk7 (solca@solcahomedesk) (gcc version 3.3.2 20030908 (Debian prerelease)) #10 SMP Mon Oct 6 11:37:35 CST 2003
Video mode to be used for restore is ffff
BIOS-provided physical RAM map:
 BIOS-e820: 0000000000000000 - 000000000009f800 (usable)
 BIOS-e820: 000000000009f800 - 00000000000a0000 (reserved)
 BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
 BIOS-e820: 0000000000100000 - 000000007ffec000 (usable)
 BIOS-e820: 000000007ffec000 - 000000007ffef000 (ACPI data)
 BIOS-e820: 000000007ffef000 - 000000007ffff000 (reserved)
 BIOS-e820: 000000007ffff000 - 0000000080000000 (ACPI NVS)
 BIOS-e820: 00000000fec00000 - 00000000fec01000 (reserved)
 BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
 BIOS-e820: 00000000ffff0000 - 0000000100000000 (reserved)
1151MB HIGHMEM available.
896MB LOWMEM available.
found SMP MP-table at 000f7e90
hm, page 000f7000 reserved twice.
hm, page 000f8000 reserved twice.
hm, page 000f7000 reserved twice.
hm, page 000f8000 reserved twice.
On node 0 totalpages: 524268
  DMA zone: 4096 pages, LIFO batch:1
  Normal zone: 225280 pages, LIFO batch:16
  HighMem zone: 294892 pages, LIFO batch:16
Kernel command line: BOOT_IMAGE=Linux ro root=303 video=radeonfb:1024x768-8@60
Console: colour VGA+ 80x25
Memory: 2072716k/2097072k available (1575k kernel code, 23240k reserved, 472k data, 148k init, 1179568k highmem)
radeonfb_pci_register BEGIN
radeonfb: ref_clk=2700, ref_div=12, xclk=16600 from BIOS
radeonfb: probed DDR SGRAM 262144k videoram
radeon_get_moninfo: bios 4 scratch = 2000002
radeonfb: cannot map FB
Total HugeTLB memory allocated, 0
highmem bounce pool size: 64 pages

-solca



-------------------------------------------------------
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

Re: ioremap problem on highmem

[Jon Smirl]

This is a better work around:

kernel /vmlinuz-2.6.0-test7 ro root=/dev/hda5 acpi=ht hdd=ide-scsi
reserve=FE000000-100000000

This reserves a block of address space for the Radeon card and then pushes the
rest of RAM as highmem.

--- Otto Solares <solca@guug.org> wrote:
> Hi!
> 
> FYI radeonfb is failing when highmem enabled, workaround with kernel param
> 'mem' < 896M.
> 
> Interesting bits from dmesg:
> 
> Linux version 2.6.0-test6-bk7 (solca@solcahomedesk) (gcc version 3.3.2
> 20030908 (Debian prerelease)) #10 SMP Mon Oct 6 11:37:35 CST 2003
> Video mode to be used for restore is ffff
> BIOS-provided physical RAM map:
>  BIOS-e820: 0000000000000000 - 000000000009f800 (usable)
>  BIOS-e820: 000000000009f800 - 00000000000a0000 (reserved)
>  BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
>  BIOS-e820: 0000000000100000 - 000000007ffec000 (usable)
>  BIOS-e820: 000000007ffec000 - 000000007ffef000 (ACPI data)
>  BIOS-e820: 000000007ffef000 - 000000007ffff000 (reserved)
>  BIOS-e820: 000000007ffff000 - 0000000080000000 (ACPI NVS)
>  BIOS-e820: 00000000fec00000 - 00000000fec01000 (reserved)
>  BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
>  BIOS-e820: 00000000ffff0000 - 0000000100000000 (reserved)
> 1151MB HIGHMEM available.
> 896MB LOWMEM available.
> found SMP MP-table at 000f7e90
> hm, page 000f7000 reserved twice.
> hm, page 000f8000 reserved twice.
> hm, page 000f7000 reserved twice.
> hm, page 000f8000 reserved twice.
> On node 0 totalpages: 524268
>   DMA zone: 4096 pages, LIFO batch:1
>   Normal zone: 225280 pages, LIFO batch:16
>   HighMem zone: 294892 pages, LIFO batch:16
> Kernel command line: BOOT_IMAGE=Linux ro root=303
> video=radeonfb:1024x768-8@60
> Console: colour VGA+ 80x25
> Memory: 2072716k/2097072k available (1575k kernel code, 23240k reserved, 472k
> data, 148k init, 1179568k highmem)
> radeonfb_pci_register BEGIN
> radeonfb: ref_clk=2700, ref_div=12, xclk=16600 from BIOS
> radeonfb: probed DDR SGRAM 262144k videoram
> radeon_get_moninfo: bios 4 scratch = 2000002
> radeonfb: cannot map FB
> Total HugeTLB memory allocated, 0
> highmem bounce pool size: 64 pages
> 
> -solca
> 
> 
> 
> -------------------------------------------------------
> 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
> _______________________________________________
> Linux-fbdev-devel mailing list
> Linux-fbdev-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel


=====
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

Re: ioremap problem on highmem

[Otto Solares]

Good catch! hopefully someone fix the real problem so we don't
have to use workarounds.

-solca

On Mon, Oct 13, 2003 at 01:30:58PM -0700, Jon Smirl wrote:
> This is a better work around:
> 
> kernel /vmlinuz-2.6.0-test7 ro root=/dev/hda5 acpi=ht hdd=ide-scsi
> reserve=FE000000-100000000
> 
> This reserves a block of address space for the Radeon card and then pushes the
> rest of RAM as highmem.


-------------------------------------------------------
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

Re: ioremap problem on highmem

[Jon Smirl]

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

Re: ioremap problem on highmem

[Otto Solares]

On Mon, Oct 13, 2003 at 05:46:51PM -0700, Jon Smirl wrote:
> 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.

I agree with point 3.

> 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.

Without fbcon, where the printk goes?

> Right now I am exploring this alternative:
> 1) System boots using VGA mode or whatever BIOS provides.

I think you are talking x86 specific, i currently use sparc and powerpc too,
for sparc i use dummycon and works nicely, i have not tried dummycon in
powerpc but i assume it should work, so i assume you are talking something
so simple and dumb like dummycon in this point.

> 2) DRI drivers are loaded. They have been modified to use PCI subsys to find
> hardware.

Good.

> 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.

Yea, i think too that console should be userspace but terminal management should stay in
the kernel side as i like all the useful vt ioctls :-)

> 4) Run X or standalone mesa on another VT. Everything shares DRI driver for
> hardware interface.

Nice.

> 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.

Hey, this sound too cool to be true ;) any code yet? i would like to develop
on such beast.

-solca



-------------------------------------------------------
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

Re: ioremap problem on highmem

[Jon Smirl]

--- Otto Solares <solca@guug.org> wrote:

I almost have the DRI changes done. 

I haven't tried adjusting the DRI Creator3D driver for my changes since I don't
have Sparc hardware.  Does sparc use the same kind of PCI ID probing that x86
does in a kernel module? Which 3D hardware do you have?

I'll check the DRI changes in as soon as they work; they are pretty minor. Then
I can get back to working on standalone Mesa. The whole purpose in doing this
is to fix things so that standalone Mesa doesn't need a config file.

Dummy con is spac equivalent of VGA con on X86.

> Without fbcon, where the printk goes?
How does klogd get the printk's? I think it reads them from /proc/kmsg. The
terminal program can get them the same way.

> Hey, this sound too cool to be true ;) any code yet? i would like to develop
> on such beast.
Want to write the terminal program? or work on the user libs? Go ahead and
start coding. See the drmtest program in the mesa tree.



=====
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

Re: ioremap problem on highmem

[Otto Solares]

On Mon, Oct 13, 2003 at 09:51:43PM -0700, Jon Smirl wrote:
> --- Otto Solares <solca@guug.org> wrote:
> 
> I almost have the DRI changes done. 

Good.

> I haven't tried adjusting the DRI Creator3D driver for my changes since I don't
> have Sparc hardware.  Does sparc use the same kind of PCI ID probing that x86
> does in a kernel module? Which 3D hardware do you have?

I have written several patches for sparc linux and i never noted a
difference in PCI management from x86 & sparc64, drivers use the same
kernel api for such things, but i am no expert in that matter, maybe
sparc guru David Miller can help you.

My main 3D card is a Radeon 9200 at home and a Nvidia Ti4600 at work.

> I'll check the DRI changes in as soon as they work; they are pretty minor. Then
> I can get back to working on standalone Mesa. The whole purpose in doing this
> is to fix things so that standalone Mesa doesn't need a config file.
> 
> Dummy con is spac equivalent of VGA con on X86.

Sparc equivalent is epromcon, dummycon is just a kernel requirement
to have something registered as a console, but is useless to display
something.

> > Without fbcon, where the printk goes?
> How does klogd get the printk's? I think it reads them from /proc/kmsg. The
> terminal program can get them the same way.

If something goes wrong nobody will see it, a practical solution will be
that people use their favorite console (fbcon,vgacon,epromcon,dummycon,serialcon).
when they quit exiting a standalone mesa program with your dri changes (if i
understand correctly your dri changes entirely bypass fbdev) we simply return
from vt graphics mode to vt text mode, is kernel responsability to restore
the console to a usable state, IMO.  I don't know if that is the {fb,vga}con case.

Also we are protected from hardware access by other programs using the vt
layer assuming we install proper vt switching signal handlers correctly
AND the others programs respect vt switching.

> > Hey, this sound too cool to be true ;) any code yet? i would like to develop
> > on such beast.
> Want to write the terminal program? or work on the user libs? Go ahead and
> start coding. See the drmtest program in the mesa tree.

Ok, let me hack a bit, i have proper vt and input working code.

-solca



-------------------------------------------------------
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

Re: ioremap problem on highmem

[Jon Smirl]

I have the new DRI driver working. I just need to come up with an API scheme
that maintains backwards compatiblity with Xfree. My first attempt doesn't work
with existing Xfree binaries.

=====
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

Re: ioremap problem on highmem

[James Simmons]

> If something goes wrong nobody will see it, a practical solution will be
> that people use their favorite console (fbcon,vgacon,epromcon,dummycon,serialcon).
> when they quit exiting a standalone mesa program with your dri changes (if i
> understand correctly your dri changes entirely bypass fbdev) we simply return
> from vt graphics mode to vt text mode, is kernel responsability to restore
> the console to a usable state, IMO.  I don't know if that is the {fb,vga}con
> case.

Its is the userland responability to restore the console state after 
leaving KDGRAPHICS mode. You need to save the hardware state before you 
leave KDTEXT mode as well. 

> Also we are protected from hardware access by other programs using the vt
> layer assuming we install proper vt switching signal handlers correctly
> AND the others programs respect vt switching.

:-( 

> > Want to write the terminal program? or work on the user libs? Go ahead and
> > start coding. See the drmtest program in the mesa tree.
> 
> Ok, let me hack a bit, i have proper vt and input working code.

Doesn't help much on non intel platforms. I guess this Mesa solution is 
only x86 specific :-(




-------------------------------------------------------
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

Re: ioremap problem on highmem

[Benjamin Herrenschmidt]

On Thu, 2003-10-16 at 01:11, James Simmons wrote:

> Its is the userland responability to restore the console state after 
> leaving KDGRAPHICS mode. You need to save the hardware state before you 
> leave KDTEXT mode as well. 

That's a bit nasty as I just wrote, and very unpractical. Especially
since it's really a _LOT_ simpler for the fbdev to just restore its
state when going back to KDTEXT.

Ben.




-------------------------------------------------------
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

Re: ioremap problem on highmem

[Otto Solares]

On Thu, Oct 16, 2003 at 12:15:53PM +0200, Benjamin Herrenschmidt wrote:
> On Thu, 2003-10-16 at 01:11, James Simmons wrote:
> 
> > Its is the userland responability to restore the console state after 
> > leaving KDGRAPHICS mode. You need to save the hardware state before you 
> > leave KDTEXT mode as well. 
> 
> That's a bit nasty as I just wrote, and very unpractical. Especially
> since it's really a _LOT_ simpler for the fbdev to just restore its
> state when going back to KDTEXT.

Agree.  fbcon should save it's state before leaving KDTEXT or
reinitialize when leaving KDGRAPHICS.

-solca



-------------------------------------------------------
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

Re: ioremap problem on highmem

[James Simmons]

> > > Its is the userland responability to restore the console state after 
> > > leaving KDGRAPHICS mode. You need to save the hardware state before you 
> > > leave KDTEXT mode as well. 
> > 
> > That's a bit nasty as I just wrote, and very unpractical. Especially
> > since it's really a _LOT_ simpler for the fbdev to just restore its
> > state when going back to KDTEXT.
> 
> Agree.  fbcon should save it's state before leaving KDTEXT or
> reinitialize when leaving KDGRAPHICS.

I agree. The way the console system does it now is just broken. Even VGA 
console should save and restore its state. It wouldn't be a huge leap to 
do that either since we have code to change the screen resolution when we 
use different font sizes. The pieces are there, it just a matter of 
putting them together. Of course this is a 2.7.X issue.




-------------------------------------------------------
This SF.net email sponsored by: Enterprise Linux Forum Conference & Expo
The Event For Linux Datacenter Solutions & Strategies in The Enterprise 
Linux in the Boardroom; in the Front Office; & in the Server Room 
http://www.enterpriselinuxforum.com

Re: ioremap problem on highmem

[Geert Uytterhoeven]

On Mon, 13 Oct 2003, Otto Solares wrote:
> On Mon, Oct 13, 2003 at 05:46:51PM -0700, Jon Smirl wrote:
> > Right now I am exploring this alternative:
> > 1) System boots using VGA mode or whatever BIOS provides.

Which may be nothing, or a frame buffer...

> I think you are talking x86 specific, i currently use sparc and powerpc too,
> for sparc i use dummycon and works nicely, i have not tried dummycon in
> powerpc but i assume it should work, so i assume you are talking something
> so simple and dumb like dummycon in this point.

dummycon is used on all architectures that don't have VGA, since the console
subsystem is initialized before the fbdev subsystem, so we need a dummy console
driver to keep the console subsystem happy, until we have a real console
driver.

BTW, changing the initialization order is not acceptable, since VGA people want
to see output as early as possible.

I'm afraid this reasoning also speaks against your proposition, since we would
need userspace to see any kernel messages, which is quite inconvenient if
anything goes wrong...

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds



-------------------------------------------------------
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

Re: ioremap problem on highmem

[Geert Uytterhoeven]

On Mon, 13 Oct 2003, Jon Smirl wrote:
> 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.

Another approach: on fully-accelerated drivers, you don't need the ioremap(),
so there's no problem.

On non-accelerated drivers, you need the ioremap(), but usually unaccelerated
hardware is old and has only a few MiB of graphics memory anyway, so there's no
problem.

On partially-accelerated drivers, we can limit the amount of graphics memory
that's ioremapped(), and thus limit the (virtual) screen size. The remaining
problem here is that user space may want to know about the full graphics memory
size, while fbcon cannot handle that.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds



-------------------------------------------------------
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

Re: ioremap problem on highmem

[Jon Smirl]

--- Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> On Mon, 13 Oct 2003, Jon Smirl wrote:
> > 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.
> 
> Another approach: on fully-accelerated drivers, you don't need the ioremap(),
> so there's no problem.
> 
> On non-accelerated drivers, you need the ioremap(), but usually unaccelerated
> hardware is old and has only a few MiB of graphics memory anyway, so there's
> no
> problem.
> 
> On partially-accelerated drivers, we can limit the amount of graphics memory
> that's ioremapped(), and thus limit the (virtual) screen size. The remaining
> problem here is that user space may want to know about the full graphics
> memory
> size, while fbcon cannot handle that.
> 

How about removing all ioremaps from the fb drivers. Then fbcon can check if
they are accelerated or not and do the ioremap in fbcon if they are not.

=====
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

Re: ioremap problem on highmem

[James Simmons]

> How about removing all ioremaps from the fb drivers. Then fbcon can check if
> they are accelerated or not and do the ioremap in fbcon if they are not.

Sounds reasonable. The issue then is drivers that provide partial 
accelerated support.



-------------------------------------------------------
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

Re: ioremap problem on highmem

[James Simmons]

> Another approach: on fully-accelerated drivers, you don't need the ioremap(),
> so there's no problem.

  Absolete agree. The only problem is fb_read and fb_write. What if we use 
the imageblit function? The only thing is we have to do between 1 and 3 
blits to the screen. The 2nd and 3rd blit is for the single pixel high 
line at the top and bottom of image blit.
  Another issue is hardware cursors often take a chunk of framebuffer 
space to draw a image. That space has to be off screen otherwise the 
cursor would show up at the bottom of the screen. I remember asking this 
question before about ioremapping the cursor area seperate from the 
framebuffer.

> On non-accelerated drivers, you need the ioremap(), but usually unaccelerated
> hardware is old and has only a few MiB of graphics memory anyway, so there's no
> problem.

Yeap. 

> On partially-accelerated drivers, we can limit the amount of graphics memory
> that's ioremapped(), and thus limit the (virtual) screen size. The remaining
> problem here is that user space may want to know about the full graphics memory
> size, while fbcon cannot handle that.

   Yes!!! First of all we should only map whole screen sizes. If the 
screen is at 640x480 then we should only allow 480, 960, 1440 size virtual y 
resolutions. What would be nice is to see a surface api.	



-------------------------------------------------------
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

Re: ioremap problem on highmem

[James Simmons]

> I just think the whole concept
> of mapping the framebuffer in to kernel space needs to be eliminated. 

I agree. That is why I moved the api over to a accelerated api. The idea 
was to get people to write accelerated drivers. Drivers using acceleration 
don't need to map the framebuffer in kernel space.

> 1) System boots using VGA mode or whatever BIOS provides.

On x86 platforms this fine but for the rest of the world this is not.

> 2) DRI drivers are loaded. They have been modified to use PCI subsys to find
> hardware.

You could make a dricon but you going to have to add kernel side graphics 
support. You need image drawing in kernel space in the DRI driver then to 
do printk's. You will also need to copyareas and fillrect functions. Then 
you will need mode switching support as well as cursor support. Basically 
you will have to port all of fbdev into the DRI api. Then you will need to 
make sure DRI working on arm and m68k and uClinux platforms. 

> 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.

So we will see printk's when init runs. It will make life much harders to 
read oops if we never get there.

> 4) Run X or standalone mesa on another VT. Everything shares DRI driver for
> hardware interface.

And this helps printk support how? You just can't get around the need for 
a framebuffer console on non x86 platforms. The day will come when x86 
will also no longer support VGA text mode.

> 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. 

Also long as you port the entire api into DRI I'm fine with that.

> 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.

Nice. Still doesn't solve the need to display oops meessages tho. 



-------------------------------------------------------
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

Re: ioremap problem on highmem

[Jon Smirl]

--- James Simmons <jsimmons@infradead.org> wrote:
> 
> > I just think the whole concept
> > of mapping the framebuffer in to kernel space needs to be eliminated. 
> 
> I agree. That is why I moved the api over to a accelerated api. The idea 
> was to get people to write accelerated drivers. Drivers using acceleration 
> don't need to map the framebuffer in kernel space.
> 
> > 1) System boots using VGA mode or whatever BIOS provides.
> 
> On x86 platforms this fine but for the rest of the world this is not.
> 
I'm looking at this as more of a choice. If you have DRI supported hardware
pick the DRI scheme, otherwise continue with existing framebuffer.  DRI only
supports about 10% of existing graphics cards, but these 10% are used in 90% of
current general purpose systems. 

DRI doesn't exist on most embedded device, PDA's, etc. so stick with the
current framebuffer. The ioremap is only causing problems on systems with over
1GB memory so this eliminates most smaller devices.

My main motivation for this is to have a single driver controlling the graphics
hardware on DRI supported systems. This will eliminate the problem with saving
hardware state between VT's. 

Another issue I am having trouble with is having mode setting/EDID code in a
device driver. That is a lot of seldom used code sitting in a device driver.
I'd rather see it in a user space library. Some hardware (Rage128) can only
read EDID info from user space becuase of real mode INT10 problems.


=====
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

Re: ioremap problem on highmem

[James Simmons]

> My main motivation for this is to have a single driver controlling the 
> graphics hardware on DRI supported systems. This will eliminate the problem 
> with saving hardware state between VT's. 

Unless you disable the VT console system you still have to to deal with 
switching from KDTEXT to KDGRAPHICS and back again. Its also userlands 
responiblity to save the console state and restore it.

> Another issue I am having trouble with is having mode setting/EDID code in a
> device driver. That is a lot of seldom used code sitting in a device driver.

Prehaps but on platforms lacking firmware that sets the video mode this is 
a problem. A good example is most mips boxes. The prom almost nevers 
initializes the graphics cards. You have to set the video mode yourself. 
No way around it. 

> I'd rather see it in a user space library. Some hardware (Rage128) can only
> read EDID info from user space becuase of real mode INT10 problems.

Read it using i2c. I have code for the aty128 driver that reads EDID 
information. No problems with it.




-------------------------------------------------------
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

Re: ioremap problem on highmem

[Jon Smirl]

--- James Simmons <jsimmons@infradead.org> wrote:
> > Another issue I am having trouble with is having mode setting/EDID code in
> a device driver. That is a lot of seldom used code sitting in a device
> driver.
> 
> Prehaps but on platforms lacking firmware that sets the video mode this is 
> a problem. A good example is most mips boxes. The prom almost nevers 
> initializes the graphics cards. You have to set the video mode yourself. 
> No way around it. 
> 
How about making a small driver with all of it's code marked __init that
initializes the mode on boxes with absolutely no support? That would be enough
to get us to the point where we can run user mode code and provide a more full
featured driver. The user mode driver would have full support for mode
setting/edid in user space libraries.

=====
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

Re: ioremap problem on highmem

[Benjamin Herrenschmidt]

> How about making a small driver with all of it's code marked __init that
> initializes the mode on boxes with absolutely no support? That would be enough
> to get us to the point where we can run user mode code and provide a more full
> featured driver. The user mode driver would have full support for mode
> setting/edid in user space libraries.

That would need proper synchronisation with whatever kernel driver does
command processing (something we +/- lack today as well) since we must
stop it when doing mode switching.

Actually, I much prefer keeping the mode setting driver in the kernel
(like any other OS btw). While the accel stuffs location is debatable
(best option beeing what DRI does imho, that is a kernel module taking
care of sending the command blocks & dealing with irqs, while the actual
constuct of the command blocks goes to userland).

Ben.




-------------------------------------------------------
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

I2C standalone vs integrated?

[Jon Smirl]

--- James Simmons <jsimmons@infradead.org> wrote:
> > I'd rather see it in a user space library. Some hardware (Rage128) can only
> > read EDID info from user space becuase of real mode INT10 problems.
> 
> Read it using i2c. I have code for the aty128 driver that reads EDID 
> information. No problems with it.

Can you add it to the aty128 driver in 2.6? I tried porting ben's code from his
new radeonfb driver into aty128fb but I couldn't get it to work.

Also, I2C drivers for Intel810, Savage, Voodoo, etc are implemented as
standalone I2C drivers. Ben implemented his and Matrox as an integral part of
the fb driver. Wouldn't it be better to implement these all standalone? It's
probably the same amount of code, and I can use the standalone ones from Mesa
without loading framebuffer support.

=====
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

Re: I2C standalone vs integrated?

[Benjamin Herrenschmidt]

> Also, I2C drivers for Intel810, Savage, Voodoo, etc are implemented as
> standalone I2C drivers. Ben implemented his and Matrox as an integral part of
> the fb driver. Wouldn't it be better to implement these all standalone? It's
> probably the same amount of code, and I can use the standalone ones from Mesa
> without loading framebuffer support.

(Note: I didn't do the Matrox part)

Regarding the standalone, I'm not too sure about it. I even though about
not using the linux i2c layer at all, it's not very convenient, and we
need to wrap the i2c accesses in all sort of tweaks to make DDC work
properly in all cases (all the stuff in radeon_probe_i2c_connector()
typically).

I'd rather see things built on top of framebuffer drivers (fbcon staying
something separate).

Ben.




-------------------------------------------------------
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

Re: I2C standalone vs integrated?

[James Simmons]

> Regarding the standalone, I'm not too sure about it. I even though about
> not using the linux i2c layer at all, it's not very convenient, and we
> need to wrap the i2c accesses in all sort of tweaks to make DDC work
> properly in all cases (all the stuff in radeon_probe_i2c_connector()
> typically).
> 
> I'd rather see things built on top of framebuffer drivers (fbcon staying
> something separate).

I see us doing something like ALSA did for i2c. I don't think it would be 
easy to use stand alone i2c drivers.




-------------------------------------------------------
This SF.net email sponsored by: Enterprise Linux Forum Conference & Expo
The Event For Linux Datacenter Solutions & Strategies in The Enterprise 
Linux in the Boardroom; in the Front Office; & in the Server Room 
http://www.enterpriselinuxforum.com

Re: ioremap problem on highmem

[Benjamin Herrenschmidt]

On Thu, 2003-10-16 at 01:17, James Simmons wrote:
> > My main motivation for this is to have a single driver controlling the 
> > graphics hardware on DRI supported systems. This will eliminate the problem 
> > with saving hardware state between VT's. 
> 
> Unless you disable the VT console system you still have to to deal with 
> switching from KDTEXT to KDGRAPHICS and back again. Its also userlands 
> responiblity to save the console state and restore it.

Which is a bit hellish... I would love a callback "restore" (or maybe
just a set_par with a "force" attribute bypassing check of old par !=
new par that most drivers have that gets called on switch back from
KDGRAPHICS to KDTEXT. In my experience, this is the only way to get
things back properly after XFree with radeons.

XFree _could_ probably be fixed, but it's a bit difficult, especially
saving & restoring the entire 2D accel state, and you know how long it
would take for an xfree fix to get in, while it's so easy for radeonfb
to just put back its own settings...




-------------------------------------------------------
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

Re: ioremap problem on highmem

[Benjamin Herrenschmidt]

> 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.

Can you think about non-x86 please ? Most of them don't have anything
remotely like VGA / BIOS

Ben.




-------------------------------------------------------
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