Re: Tegra DRM device tree bindings

[Lucas Stach <dev-8ppwABl0HbeELgA04lAiVw@public.gmane.org>]

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:
> > On 28.06.2012 20:19, Lucas Stach wrote:
> > > 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.
> 
> > 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