Thread (17 messages) flat view 17 messages, 4 authors, 2012-11-22
STALE5037d

Revision v1 of 3 in this series.

Revisions (3)
  1. v1 current
  2. v1 [diff vs current]
  3. v1 [diff vs current]

Re: [PATCH 0/5] OMAPFB: use dma_alloc instead of omap's vram

From: Tony Lindgren <tony@atomide.com>
Date: 2012-11-12 22:50:37
Also in: linux-arm-kernel, linux-omap

* Tomi Valkeinen [off-list ref] [121112 02:27]:
Hi,

This series changes omapfb to use standard dma_alloc funcs instead of omap
specific vram allocator. This let's us remove the omap vram allocator, making
omapfb platform independent.

However, note that using standard dma funcs causes the following downsides:

1) dma_alloc_attrs doesn't let us allocate at certain physical address.
However, this should not be a problem as this feature of vram allocator
is only used when reserving the framebuffer that was initialized by the
bootloader, and we don't currently support "passing" a framebuffer from
the bootloader to the kernel anyway.

2) dma_alloc_attrs, as of now, always ioremaps the allocated area, and
we don't need the ioremap when using VRFB. This patch uses
DMA_ATTR_NO_KERNEL_MAPPING for the allocation, but the flag is currently
not operational.

3) OMAPFB_GET_VRAM_INFO ioctl cannot return real values anymore. I
changed the ioctl to return 64M for all the values, which, I hope, the
applications will interpret as "there's enough vram".

4) "vram" kernel parameter to define how much ram to reserve for video use no
longer works. The user needs to enable CMA and use "cma" parameter.
Great, thanks for fixing these. Could you please queue these into
a separate branch against v3.7-rc5 that I can also merge into
omap-for-v3.8/cleanup-headers-prepare-multiplatform-v3?

Feel free to add my Acked-by: Tony Lindgren [off-list ref] to the
arch/arm/*omap*/* parts.

Regards,

Tony
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help