On 04/06/2012 01:20 AM, Thierry Reding wrote: > * Stephen Warren wrote: >> I must admit I'm not at all familiar with the IOMMU APIs, but isn't the >> IOMMU driver/subsystem itself what is managing all the allocations and >> handing them out to clients? And client drivers do things like asking >> for N pages of memory mapped into their aperture? If that is true, I'm >> not sure what the purpose is of the intermediate device you propose. >> Sorry for being somewhat clueless. > > That was my impression too at first. But it seems like all the IOMMU > subsystem does is map individual pages. So you pass it a physical address of > a page along with the IO virtual address to map it to. That's at least the > way it is handled for Tegra 2 GART (and from a quick look also by the Tegra 3 > SMMU). For the SMMU the situation may be different because it may not have a > fixed aperture that needs to contain the IO virtual addresses, though I must > admit I haven't looked at Tegra 3 in enough detail to judge this. > > So this intermediate device would be purely an allocator for the GART > aperture and handle the actual mapping via the IOMMU. This would probably be > really simple and is in fact now done in the DRM driver. The nice thing if > this would be a separate device is that it would be easy to make it a child > of the IOMMU and wouldn't be as counter-intuitive as making the DRM device > the IOMMU's child.
OK, I see. I'll defer to Hiroshi here; he's far more familiar with all this than I am. My only comment is that I'd be surprised to see any kind of memory allocator represented as a driver (as opposed to a utility module) since it's not really representing an actual hardware block. _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
