[RFC 4/4] drm: Add NVIDIA Tegra support

[Lucas Stach]

Oops, meant to put dri-devel on cc here.

Am Freitag, den 13.04.2012, 22:12 +0200 schrieb Lucas Stach:
> Am Freitag, den 13.04.2012, 08:33 +0100 schrieb Dave Airlie:
> > On Fri, Apr 13, 2012 at 12:10 AM, Lucas Stach <dev at lynxeye.de> wrote:
> > > Am Mittwoch, den 11.04.2012, 15:18 +0000 schrieb Arnd Bergmann:
> > >> On Wednesday 11 April 2012, Thierry Reding wrote:
> > >> >   * Daniel Vetter wrote:
> > >> > > On Wed, Apr 11, 2012 at 03:23:26PM +0200, Thierry Reding wrote:
> > >> > > > * Daniel Vetter wrote:
> > >> > > > > On Wed, Apr 11, 2012 at 02:10:30PM +0200, Thierry Reding wrote:
> > >> > > > > > This commit adds a very basic DRM driver for NVIDIA Tegra SoCs. It
> > >> > > > > > currently has rudimentary GEM support and can run a console on the
> > >> > > > > > framebuffer as well as X using the xf86-video-modesetting driver.
> > >> > > > > > Only the RGB output is supported. Quite a lot of things still need
> > >> > > > > > to be worked out and there is a lot of room for cleanup.
> > >> > > > >
> > >> > > > > Indeed, after a quick look there are tons of functions that are just stubs
> > >> > > > > ;-) One thing I wonder though is why you directly use the iommu api and
> > >> > > > > not wrap it up into dma_map? Is arm infrastructure just not there yet or
> > >> > > > > do you plan to tightly integrate the tegra drm with the iommu (e.g. for
> > >> > > > > process space switching or similarly funky stuff)?
> > >> > > >
> > >> > > > I'm not sure I know what you are referring to. Looking for all users of
> > >> > > > iommu_map() doesn't turn up anything related to dma_map. Can you point me in
> > >> > > > the right direction?
> > >> > >
> > >> > > Well, you use the iommu api to map/unmap memory into the iommu for tegra,
> > >> > > whereas usually device drivers just use the dma api to do that. The usual
> > >> > > interface is dma_map_sg/dma_unmap_sg, but there are quite a few variants
> > >> > > around. I'm just wondering why this you've choosen this.
> > >> >
> > >> > I don't think this works on ARM. Maybe I'm not seeing the whole picture but
> > >> > judging by a quick look through the kernel tree there aren't any users that
> > >> > map DMA memory through an IOMMU.
> > >>
> > >>
> > >> dma_map_sg is certainly the right interface to use, and Marek Szyprowski has
> > >> patches to make that work on ARM, hopefully going into v3.5, so you could
> > >> use those.
> > >
> > > Just jumping in here to make sure everyone understands the limitations
> > > of the Tegra 2 GART IOMMU we are talking about here. It has no isolation
> > > capabilities and a really small remapping window of 32MB. So it's
> > > impossible to remap every buffer used by the graphics engines. The only
> > > sane way to handle this is to set aside a chunk of stolen system memory
> > > as VRAM and let a memory manager like TTM handle the allocation of
> > > linear regions and GART mappings. This means a more tight integration of
> > > the DRM driver and the IOMMU, where I think that using the IOMMU API
> > > directly and completely controlling the GART from one driver is the
> > > right way to go for a number of reasons, where my biggest concern is
> > > that we can't implement a sane out-of-remapping space when we go through
> > > the dma_map API.
> > 
> > 
> > It sounds like the old AGP GARTs on PowerPC, where the CPU couldn't
> > get mappings of the GTT space,
> > and the GART was only available to the GPU device.
> > 
> 
> Yes, maybe we should treat the Tegra GART just like this. My current
> plan is to write a TTM backend on top of the IOMMU API as I think this
> is the right level of abstraction and both Tegra 2 GART and Tegra 3 SMMU
> are available through this interface.
> I think we can just allocate the real pages from highmem and flip them
> into IOMMU address space as needed - just the normal TTM use-case.
> 
> -- Lucas
>