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

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

[-- Attachment #1.1: Type: text/plain, Size: 2955 bytes --]

* Daniel Vetter wrote:
> 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).

Yes, it's very much like the GTT on Intel chips. In fact I've been using the
gma500 driver as a source for inspiration. Wikipedia confirms that GTT and
GART are synonymous.

> 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.

That's odd. The only users of the IOMMU API that I can find in the kernel
tree are in drivers/remoteproc and drivers/media/video/omap3isp. And omap3isp
doesn't do any actual mapping at a quick glance. Can you point me to where
this is hooked up with the Intel IOMMU?

Thierry

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

[-- Attachment #2: Type: text/plain, Size: 190 bytes --]

_______________________________________________
iommu mailing list
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu