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

Carsten Haitzler (The Rasterman) raster at openmoko.org
Tue Oct 23 08:23:43 CEST 2007


On Mon, 8 Oct 2007 19:28:51 +0800 Harald Welte <laforge at openmoko.org> babbled:

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

At this stage I'd say keep it simple. how much memory will you need for
SD/audio etc. etc - not much, so just steal it in the kernel and present the
rest as a big chunk to userspace in 1 mapping. x will handle the rest. the i8xx
that use SMT basically steal pages from userspace and x (i think) maps those in
via DRI - we won't have DRI to start - maybe never (depends on time and need
for opengl etc.) so i wouldnt bet for now on anything but a static mapping of
most of the video ram for x and some of it stolen for other devices (sd/mmc,
audio, etc.)

-- 
Carsten Haitzler (The Rasterman) <raster at openmoko.org>




More information about the openmoko-kernel mailing list