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

[Daniel Vetter]

On Wed, Apr 11, 2012 at 04:11:08PM +0200, 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.
> 
> Maybe your question is answered by my reply to Alan's comment. The mapping
> is actually done to get a linear view for the display controller which
> doesn't support SG transfers. The kernel and user-space already have virtual
> linear buffers.

Hm, in that case it looks like your iommu works more like the gtt on intel
chips and less like the iommu on intel platforms (which we access through
the dma_map api). I wonder whether that will end up in some layering fun
together with dma_buf, which conceptually is at the same level as the dma
api, which usually uses an underlying iommu exposed with the iommu api
you're using.

> Perhaps I'm being dense?

Doesn't sound like that over here ;-)
-Daniel
-- 
Daniel Vetter
Mail: daniel at ffwll.ch
Mobile: +41 (0)79 365 57 48