Thanks, Vaibhav Hiremath
> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:linux-omap- > [EMAIL PROTECTED] On Behalf Of Tomi Valkeinen > Sent: Thursday, November 20, 2008 4:22 PM > To: linux-omap@vger.kernel.org > Subject: OMAP Framebuffer memory allocation and mapping > > Hi, > > I have a couple of questions regarding the memory management for the > new > display subsystem. > > The new DSS allocates memory with dma_alloc_writecombine() and mmaps > it > to user space with dma_mmap_writecombine(). Allocation is done when > omapfb starts up. Normally memory gets very quickly too fragmented > for > dma_alloc_writecombine() to work, but setting > CONFIG_FB_OMAP_CONSISTENT_DMA_SIZE helps this. > > However, even when CONFIG_FB_OMAP_CONSISTENT_DMA_SIZE is set to 14, > I > am, for some reason, not able to allocate 1280x1024x4 (~5.2M) > framebuffer. Could the consistent DMA area be already too > fragmented, or > is there some size limit there? > [Hiremath, Vaibhav] Similar issue I had also faced while implementing VRFB rotation on new DSS of yours. I increased the value of MAX_ORDER to 12 (currently set to 11), defined in include/linux/mmzone.h file. And it worked for me; I am allocating 2048*720*4 bytes of buffer. I am not sure community acceptance on this, probably somebody could suggest better way to this. > There's also support to allocate fb memory in very early phase with > reserve_bootmem(), which needs a predefined physical address and > size > that can come from the bootloader. I've been looking at the old DSS > to > see how this memory should be mapped, but I haven't been able to get > it > to work. It looks like the DSS DMA and the user space have a bit > different view of the memory, so my assumption is that there's some > caching or similar being done. > > So how to setup the memory gotten from reserve_bootmem() (or > alloc_bootmem()) so that it would work the same way as > dma_alloc_writecombine()'s memory? > > And generally: any other ideas how to improve the memory management > of > the DSS? > > Tomi > > > -- > To unsubscribe from this list: send the line "unsubscribe linux- > omap" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
