On 13.11.2012 10:03, Thierry Reding wrote: > That should be fixed with v2 I posted a few hours ago. That's true. > Yes, Tegra30 support will follow in a separate patch. As for IOMMU > support it should eventually be made completely transparent, but I'm not > opposed to adding a patch with explicit IOMMU support back in if it > turns out that it can't be done transparently. The trouble with this is that the generic case demands that we support each device having a separate address space. But, on Tegra30 SMMU has only four address spaces, so in Tegra30 case we actually end up using the same address space for multiple devices. Second problem is trying to avoid double mapping. With 2D acceleration, we need support for allocating buffers, and mapping them to DC, host1x and 2D. DMA Mapping API has a problem in that it doesn't allow just allocating - it forces mapping the buffer to a device at the same time. So, when 2D submit contains a reference to a dma-buf, the buffer has already been mapped to some device, but we don't have a good way of detecting that. We end up mapping it again, which is a performance killer and possibly a coherence problem. Fortunately this is all related to 2D acceleration, so we can defer both of these problems for now. Best regards, Terje -- To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
