Thread (1 message) 1 message, 1 author, 2012-07-01

Re: Tegra DRM device tree bindings

From: Lucas Stach <hidden>
Date: 2012-07-01 17:06:01
Also in: dri-devel, linux-iommu, linux-tegra

Possibly related (same subject, not in this thread)

Am Samstag, den 30.06.2012, 20:01 +0200 schrieb Thierry Reding:
On Fri, Jun 29, 2012 at 04:20:31PM +0300, Terje Bergström wrote:
quoted
On 28.06.2012 20:19, Lucas Stach wrote:
quoted
TTM though solves more advanced matters, like buffer synchronisation
between 3D and 2D block of hardware or syncing buffer access between GPU
and CPU.
One of the most interesting things of TTM is the ability to purge the
GPU DMA buffers to scattered sysmem or even swap them out, if they are
not currently used by the GPU. It then makes sure to move them in the
contig space again when the GPU really needs them and fix up the GPU
command stream with the new buffer address.
We preferably should choose dma_buf as a common interface towards
buffers. That way whatever we choose as the memory manager, all dma_buf
aware drivers will be able to use buffers allocated by other drivers.

We probably need to accommodate multiple memory managers to take care of
legacy and new drivers. If V4L2 and DRM projects all move to dma_buf, we
have the possibility to do zero-copy video without forcing everybody to
use the same memory manager.
I agree. Supporting DMA BUF also doesn't seem very difficult.
quoted
As I understand, TTM is good for platforms where we have a separate
frame buffer memory, as is the case with most of the graphics cards. In
Tegra, graphics and CPU occupy the same memory, so I'm not sure if we
require the level of functionality that TTM provides. I guess the level
of functionality and the complexity that it brings is one reason why TTM
hasn't really caught on in the ARM world.

The synchronization primitives attached to TTM are slightly confusing.
At the bottom level, it's operations which need to be synchronized
between each other. That's the API level that we should to export from
kernel to user space. It's then up to libdrm level (or whatever is doing
the rendering in user space) to decide which operations it wants to have
completed before a buffer can be reused/read/passed on to the next stage.

Anyway, if we hide the memory manager behind dma_buf, we're free to muck
around with multiple of them and see what works best.
Exactly. Other subthreads echo this as well. Using CMA seems the easiest
and most flexible for now but still covers everything we need. If it
turns out that it isn't suited for more advanced stuff once we start
supporting 3D then we can still opt for something like TTM.
As working code is the primary goal, I would say go for it. I still
think TTM is the way to go, even for simple things like a DRM
framebuffer driver, but as CMA and TTM won't collide in their goals it
should be easy to put TTM in there after we have something going with
CMA.

Lucas

_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help