cfb* routines and high mem

cfb* routines and high mem

[Jon Smirl]

After grepping around for a while it looks like the only user of the cfb*
routines is the console code. There doesn't appear to be a way to get to these
from user space but I may have missed one.

If this is true, then the cfb* code could be moved down into the console
directory and be built into that driver. The frame buffer drivers would just
return NULL for the function pointers if they don't implement an accelerated
routine. Doing this would help isolate high mem access code into fbconsole.

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

Re: cfb* routines and high mem

[Geert Uytterhoeven]

On Sun, 21 Sep 2003, Jon Smirl wrote:
> After grepping around for a while it looks like the only user of the cfb*
> routines is the console code. There doesn't appear to be a way to get to these

And the logo code...

> from user space but I may have missed one.
>
> If this is true, then the cfb* code could be moved down into the console
> directory and be built into that driver. The frame buffer drivers would just
> return NULL for the function pointers if they don't implement an accelerated
> routine. Doing this would help isolate high mem access code into fbconsole.

What about unaccelerated frame buffer drivers for non-cfb hardware?

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:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: cfb* routines and high mem

[Jon Smirl]

We have to do something about the ioremap of large framebuffers in 2.6. Right
now in 2.6, if you have 1GB or more RAM most framebuffers will fail to load.
With the price of memory falling 1GB will become common during the life of 2.6.

The failure is caused by the individual framebuffer drivers ioremap'ing the
framebuffer into kernel address space. With 1GB memory or more it is almost a
certainty that there is not enough kernel address space available.  Even my
16MB cards fail to load.

I believe the best solution to this is to push the ioremap and all fb access
down into fbconsole. This will localize it to a single point. Then modify
fbconsole to map the framebuffer into high mem address space. All accesses to
the high mem framebuffer will need to be bracketed by the high mem access
marcos. I also don't think the kernel has a high mem ioremap() so one will need
to be written.

Will this work for the penguin code?
Are there non-cfb drivers? How hard would it be to convert them?
Is there another solution to the problem?

Don't we pretty much have to do this? I don't think we can just ignore it. 

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

Re: cfb* routines and high mem

[James Simmons]

> I believe the best solution to this is to push the ioremap and all fb access
> down into fbconsole. This will localize it to a single point. Then modify
> fbconsole to map the framebuffer into high mem address space. All accesses to
> the high mem framebuffer will need to be bracketed by the high mem access
> marcos. I also don't think the kernel has a high mem ioremap() so one will need
> to be written.
> 
> Will this work for the penguin code?

No. The penguin code works for fbdev without console support. The logo can 
be displayed for embedded fbdev devices so the developer knows it is 
loaded.

> Are there non-cfb drivers? How hard would it be to convert them?
> Is there another solution to the problem?

There are several non-cfb drivers. Breaking the code up and pushing it 
into the fbconsole layer is a bad idea. 

Accelerated driver (non-cfb) don't need to ioremap the framebuffer memory
except for the case of fb_read/fb_write. That can be handled. What should 
be done is a surface api that allocates the amount of memory we really 
need at any time. 







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

Re: cfb* routines and high mem

[Jon Smirl]

--- James Simmons <jsimmons@infradead.org> wrote:
> No. The penguin code works for fbdev without console support. The logo can 
> be displayed for embedded fbdev devices so the developer knows it is 
> loaded.

Could the penguin code do the ioremap in its code? That way if it fails it
isn't fatal. Right now if the fb driver fails to load the penguin code is kind
of pointless. 

The client of the framebuffer needs to be responsible for the ioremap(), not
the driver. Since if the buffer is mapped to high mem the client code needs to
match. The current scheme prevents a high mem mapping since the client code
isn't high mem aware.

I also think that it is wrong that the fb drivers should fail to load just
because it can't ioremap() to draw the penguin. It would be much better to have
the fb driver load and the penguin disappear.

> 
> > Are there non-cfb drivers? How hard would it be to convert them?
> > Is there another solution to the problem?
> 
> There are several non-cfb drivers. Breaking the code up and pushing it 
> into the fbconsole layer is a bad idea. 
> 
> Accelerated driver (non-cfb) don't need to ioremap the framebuffer memory
> except for the case of fb_read/fb_write. That can be handled. What should 
> be done is a surface api that allocates the amount of memory we really 
> need at any time. 
> 
I'm still having trouble with the fb drivers doing the ioremap() when
fbconsole/penguin is the only client. 1600x1200x4 dual head still takes up 16MB
of address space. 16MB will fail ioremap() on my system. Aren't we just
delaying an inevitable problem with increasing resolutions?


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

Re: cfb* routines and high mem

[Geert Uytterhoeven]

On Mon, 22 Sep 2003, Jon Smirl wrote:
> We have to do something about the ioremap of large framebuffers in 2.6. Right
> now in 2.6, if you have 1GB or more RAM most framebuffers will fail to load.
> With the price of memory falling 1GB will become common during the life of 2.6.
> 
> The failure is caused by the individual framebuffer drivers ioremap'ing the
> framebuffer into kernel address space. With 1GB memory or more it is almost a
> certainty that there is not enough kernel address space available.  Even my
> 16MB cards fail to load.

What's the maximum amount of address space you can remap? If even 16 MiB fails,
there's a serious problem, not only for fbdev, since you can easily imagine
some other hardware/application that needs to ioremap() 16 MiB.

To me it sounds more like a problem to be solved in the ia32-specific mm-code,
since it's caused by ia32-limitations and mm-decisions in the ia32-specific
code.

Yes, the 32-bit era is (finally) almost over!

BTW, as a comparison: on m68k we could easily have a 4Gi/4Gi kernel/user split
if we ever want that, since unlikely ia32, m68k has moves (move from/to address
space) to access the user address space from kernel space.

Gr{oetje,eeting}s,

						Geert (elitist m68k hacker ;-)

--
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:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf