[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