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

Revision v1 of 7 in this series.

Revisions (7)
  1. v1 [diff vs current]
  2. v1 current
  3. v1 [diff vs current]
  4. v1 [diff vs current]
  5. v1 [diff vs current]
  6. v1 [diff vs current]
  7. v1 [diff vs current]

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

From: Tomi Valkeinen <hidden>
Date: 2012-11-12 13:50:28
Also in: linux-arm-kernel, linux-omap

On 2012-11-12 15:39, Grazvydas Ignotas wrote:
Hi,

On Mon, Nov 12, 2012 at 12:25 PM, Tomi Valkeinen [off-list ref] wrote:
quoted
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:

...

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".
Do at least OMAPFB_QUERY_MEM/OMAPFB_SETUP_MEM still work?
Yes.
quoted
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.
That's a significant change, you should update Documentation/ .
Ah right. The documentation. I never remember =).
What about omapfb.vram, is it still there?
Yes.
Perhaps we also need to select/depend on CMA?
dma_alloc_* funcs work fine without CMA. CMA only makes them work
better. Thus I don't think OMAPFB should depend on CMA, but perhaps CMA
should be enabled by default in omap2plus_defconfig?

 Tomi

Attachments

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