[RFC] Initial attempt to make ARM use LMB

[tomi.valkeinen@nokia.com (Tomi Valkeinen)]

Hi,

On Mon, 2010-05-17 at 11:44 +0200, ext Russell King - ARM Linux wrote:
> On Mon, May 17, 2010 at 12:38:55PM +0300, Grazvydas Ignotas wrote:
> > On Fri, May 14, 2010 at 1:16 PM, Russell King - ARM Linux
> > <linux@arm.linux.org.uk> wrote:
> > >> because it also uses reserve_bootmem() in
> > >> drivers/video/omap2/vram.c and later ioremap on RAM. Perhaps LMB can
> > >> be used to fix that too?
> > >
> > > WTF is reserve_bootmem doing in a driver?
> > 
> > IIRC Tony refused any new fb related code in arch/arm/*omap* so it
> > ended up there (or maybe because of something else, not that I had
> > anything to do with this).
> 
> Can someone please answer these questions:
> 
> 1. why does the framebuffer need to _reserve_ a set of specific sections
>    of SDRAM rather than _allocate_ a set of sections?
> 2. what range of sizes of SDRAM does the framebuffer driver need?

Yep, vram.c was first located in arch/arm/plat-omap/ but was moved under
drivers/video/omap2 by request from Tony. vram.c is not really a driver,
so in that sense I think it'd fit better into arch/arm/plat-omap/.

To question 1:

- The bootloader may use a certain area of memory to display to boot
image, and the kernel needs to use this same memory area for the
framebuffer, so that we don't get any glitches on the display during
boot. If this is not required, then the memory areas can be allocated.

- OMAP display hardware requires a continuous memory area for the
framebuffer. Allocating such a large continuous memory area later seemed
to be next to impossible, probably because of memory fragmentation.

- Originally I used dma_alloc_*, but that doesn't support the
bootloader-init case, and I also wanted to support having the
framebuffer in OMAP's SRAM. Also, if I recall right, dma_alloc_* didn't
support the huge allocations that are needed for the framebuffer.

To 2:
It varies a lot on the use case. One can configure the reserved VRAM
area, and I would imagine that the smallest would be something like
~150kB (320x240x2) and the largest in extreme case ~40MB (1600x1200*4,
x2 for double buffering and x3 for each overlay).

 Tomi