Re: [RFC 0/4] Add NVIDIA Tegra DRM support

[Thierry Reding <thierry.reding-RM9K5IK7kjKj5M59NBduVrNAH6kLmebB@public.gmane.org>]

[-- Attachment #1: Type: text/plain, Size: 1648 bytes --]

* Alan Cox wrote:
> On Wed, 11 Apr 2012 14:10:26 +0200
> Thierry Reding <thierry.reding-RM9K5IK7kjKj5M59NBduVrNAH6kLmebB@public.gmane.org> wrote:
> 
> > This series adds a basic DRM driver for NVIDIA Tegra 2 processors. It
> > currently only supports the RGB output and I've successfully tested it
> > against the fbcon kernel module and the xf86-video-modesetting driver.
> > The code uses the Tegra's IOMMU/GART to remap non-contiguous memory.
> > This means that currently video memory is limited to 32 MB, the size of
> > the GART aperture.
> 
> You should only need continguous memory with GEM for the framebuffer /
> console bits via /dev/fb. In theory the fb layer can be taught to hanndle
> non linear framebuffers but nobody has yet done so. (Now there's a GSOC
> project ... ;))
> 
> What we do on GMA500 is to allocate the kernel framebuffer from linearly
> mapped memory but the normal GEM objects from anywhere as the GEM mapping
> into userspace will deal with presenting it to user space as a virtually
> linear buffer.

That's actually what the driver does as well. It uses the shmfs-backed memory
provided by GEM and only maps it through the GART to provide a linear view
for the display controller which cannot do scatter-gather I/O. Neither the
kernel nor the user-space mapping go through the GART.

You are right that for anything but the framebuffer objects it probably
doesn't matter. It's a little hard to tell because I don't have any
documentation for either the 2D nor 3D engines. Eventually a better option
might be to use stolen memory instead of remapping it through the GART.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]