[RFC 4/4] drm: Add NVIDIA Tegra support
Thierry Reding
thierry.reding at avionic-design.de
Thu Apr 12 17:18:16 EST 2012
* Arnd Bergmann wrote:
> On Wednesday 11 April 2012, Thierry Reding wrote:
> > Daniel Vetter wrote:
> > > 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.
I've looked at Marek's patches but I don't think they'll work for Tegra 2 or
Tegra 3. The corresponding iommu_map() functions only set one PTE, regardless
of the number of bytes passed to them. However, the Tegra TRM indicates that
mapping needs to be done on a per-page basis so contiguous regions cannot be
combined. I suppose the IOMMU driver would have to be fixed to program more
than a single page in that case.
Also this doesn't yet solve the vmap() problem that is needed for the kernel
virtual mapping. I did try using dma_alloc_writecombine(), but that only
works for chunks of 2 MB or smaller, unless I use init_consistent_dma_size()
during board setup, which isn't provided for in a DT setup. I couldn't find
a better alternative, but I admit I'm not very familiar with all the VM APIs.
Do you have any suggestions on how to solve this? Otherwise I'll try and dig
in some more.
Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/devicetree-discuss/attachments/20120412/f028839a/attachment.sig>
More information about the devicetree-discuss
mailing list