Re: OMAP Framebuffer memory allocation and mapping

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



* Hiremath, Vaibhav <hvaibhav@xxxxxx> [081120 03:25]:
> 
> 
> Thanks,
> Vaibhav Hiremath
> 
> > -----Original Message-----
> > From: linux-omap-owner@xxxxxxxxxxxxxxx [mailto:linux-omap-
> > owner@xxxxxxxxxxxxxxx] On Behalf Of Tomi Valkeinen
> > Sent: Thursday, November 20, 2008 4:22 PM
> > To: linux-omap@xxxxxxxxxxxxxxx
> > 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.

You might want to dump out the start and end address of you memory
area and make sure it does not overlap with anything else. Earlier
you had to reserve large areas during memory init.. I doubt that it's
still the case though. See also Documentation/arm/memory.txt.

Tony


> > 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 majordomo@xxxxxxxxxxxxxxx
> > 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 majordomo@xxxxxxxxxxxxxxx
> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux