Skip to contentSkip to conversation

OMAP Framebuffer memory allocation and mapping

DISCUSSION Tomi Valkeinen 3 participants 3 messages Nov 20, 2008 – Nov 26, 2008

lore
Share & tools
lore

Tomi Valkeinen

author
#0 lore raw

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?

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

#1 lore raw

Thanks,
Vaibhav Hiremath

Quoted 21 lines

-----Original Message-----
From: [email protected] [mailto:linux-omap- [email protected]] On Behalf Of Tomi Valkeinen
Sent: Thursday, November 20, 2008 4:22 PM
To: [email protected]
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.

Quoted 7 lines

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.

Quoted 27 lines

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

#2 lore raw
Quoted 33 lines · Hiremath, Vaibhav

Thanks,
Vaibhav Hiremath

Quoted 21 lines

-----Original Message-----
From: [email protected] [mailto:linux-omap- [email protected]] On Behalf Of Tomi Valkeinen
Sent: Thursday, November 20, 2008 4:22 PM
To: [email protected]
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.

Quoted 7 lines

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?

Quoted 3 lines

[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

Quoted 32 lines
Quoted 19 lines

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?

Quoted 8 lines

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