From mboxrd@z Thu Jan 1 00:00:00 1970 From: Lucas Stach Subject: Re: [RFC 4/4] drm: Add NVIDIA Tegra support Date: Sat, 14 Apr 2012 14:51:55 +0200 Message-ID: <1334407915.1659.0.camel@antimon> References: <1334146230-1795-1-git-send-email-thierry.reding@avionic-design.de> <20120411133512.GL4296@phenom.ffwll.local> <20120411141108.GI27337@avionic-0098.adnet.avionic-design.de> <201204111518.41968.arnd@arndb.de> <1334272218.1619.11.camel@antimon> <1334347952.1625.12.camel@antimon> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from km20343-01.keymachine.de (ns.km20343-01.keymachine.de [84.19.182.79]) by gabe.freedesktop.org (Postfix) with ESMTP id 873739E8B0 for ; Sat, 14 Apr 2012 05:52:12 -0700 (PDT) Received: from [192.168.2.101] (p5DC4A935.dip.t-dialin.net [93.196.169.53]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by km20343-01.keymachine.de (Postfix) with ESMTPSA id BA7867D4162 for ; Sat, 14 Apr 2012 14:52:10 +0200 (CEST) In-Reply-To: <1334347952.1625.12.camel@antimon> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org Errors-To: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org To: dri-devel@lists.freedesktop.org List-Id: dri-devel@lists.freedesktop.org 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 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 >