RE: Tegra DRM device tree bindings

quoted

Am Donnerstag, den 28.06.2012, 10:51 -0600 schrieb Stephen Warren:

quoted

On 06/28/2012 05:12 AM, Thierry Reding wrote:

quoted

On Wed, Jun 27, 2012 at 05:59:55PM +0200, Lucas Stach wrote:

quoted

Am Mittwoch, den 27.06.2012, 16:44 +0200 schrieb Thierry Reding:

...

quoted

quoted

quoted

In the ideal case I would want to not have a carveout size at all.
However there may be situations where you need to make sure some
driver can allocate a given amount of memory. Having to specify
this using a kernel command-line parameter is cumbersome because
it may require changes to the bootloader or whatever. So if you
know that a particular board always needs
128 MiB of carveout, then it makes sense to specify it on a
per-board basis.

If we go with CMA, this is a non-issue, as CMA allows to use the
contig area for normal allocations and only purges them if it
really needs the space for contig allocs.

CMA certainly sounds like the most simple approach. While it may
not be suited for 3D graphics or multimedia processing later on, I
think we could use it at a starting point to get basic framebuffer
and X support up and running. We can always move to something more
advanced like TTM later.

I thought the whole purpose of CMA was to act as the infra-structure
to provide buffers to 3D, camera, etc. in particular allowing
sharing of buffers between them. In other words, isn't CMA the memory

manager?

quoted

quoted

If there's some deficiency with CMA for 3D graphics, it seems like
that should be raised with those designing CMA. Or, am I way off
base with my expectations of CMA?

CMA is just a way of providing large contiguous address space blocks
in a dynamic fashion. The problem CMA solves is: we have a system with
relatively low amounts of sysmem (like 512MB), now to ensure we can
always get large contiguous buffers for use by GPU or VIDEO blocks, we
need to set aside a relatively large contiguous pool (like 128MB). So
we are stealing 128MB of memory from the system while we may or may not

use it, which is bad.

quoted

Now CMA allows to say: I may need 128MB of contig space, but the
system is free to use it as normal memory as long as I don't really
need it. If the space is really needed, CMA purges pages from the area
and may even swap them out. So yes CMA is a memory allocator for contig

memory.

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.

quoted

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.

IMHO the best solution would be to use CMA as a flexible replacement
of the static carveout area and put TTM on top of this to solve the
needs of graphics drivers. We certainly don't want to reinvent the
wheel inside CMA. We have solutions for all those things in the kernel
right now, we just have to glue them together in a sane way.

That is a great explanation. So could you explain what's the relation between
IOMMU api and TTM(or GEM)?
Terje said DMABUF api sits on top of IOMMU api. So for normal device
drivers(such as drm), can forget iommu apis, just use dmabuf api is OK. If so, I
wanna know does TTM/GEM and IOMMU are related? Or TTM/GEM uses
dmabuf apis which calls iommu api to do memory allocation/mapping?
 

Sorry for my stupid question. DMA mapping api sits on top of IOMMU api, not DMABUF.
DMABUF is used to share buffers.
So please ignore what I said.

quoted

Thanks,
Lucas

--
To unsubscribe from this list: send the line "unsubscribe linux-tegra"
in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo
info at http://vger.kernel.org/majordomo-info.html