* 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. Perhaps I'm being dense? Thierry
Attachment:
pgpLwQFxW9um0.pgp
Description: PGP signature
