On Mon, 8 Oct 2007 19:28:51 +0800 Harald Welte <[EMAIL PROTECTED]> 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) <[EMAIL PROTECTED]>
