Thread (6 messages) 6 messages, 3 authors, 2003-09-24

Re: cfb* routines and high mem

flat view

From: James Simmons <hidden>
Date: 2003-09-22 19:17:15

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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help