On Mon, Oct 01, 2007 at 09:59:09PM +0800, Chia-I Wu wrote: > Set fb_fix_screeninfo.smem_len to RESSIZE(fb_res). This is not the real > vram size, as it is a hardcoded value in glamo-core.c for now.
I would like to start some kind of discussion about the glamo memory allocation policy / scheme before applying that patch. Some parts of the glamo (sd/mmc, maybe others in the future) will need to allocate parts of the glamo internal sdram, while at the same time we have (potentially different processes) in userspace using some part for actual framebuffer memory, 2d, 3d, yuv->rgb conversion, etc. My original idea was to just statically reserve the memory for the kernel users (since there are fewer, and less dynamic memory requirements) and leave one big contiguous chunk for userspace. Somebody (guess the X server) then would have to do the memory management of the smedia-local memory. But I'm really not the expert when it comes to those kinds of things... How does it work with e.g. intel i8xx graphics, when they re-allocate the framebuffer/graphics memory from the X server using the [agp]gart API? As a temporary workaround we can just increase the FB_SIZE constant to a significantly higher value. -- - Harald Welte <[EMAIL PROTECTED]> http://openmoko.org/ ============================================================================ Software for the world's first truly open Free Software mobile phone
