[PATCH 3/3] glamo: report vram size to userspace

Harald Welte laforge at openmoko.org
Mon Oct 8 13:28:51 CEST 2007


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 <laforge at openmoko.org>          	        http://openmoko.org/
============================================================================
Software for the world's first truly open Free Software mobile phone




More information about the openmoko-kernel mailing list