Re: cfb* routines and high mem

[Jon Smirl <jonsmirl@yahoo.com>]

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