* Stephen Warren wrote:
> 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.

I agree. In that case I don't see any other solution than to remove the
requirement of the parent/child relationship from the GART driver. It seems
like the SMMU driver doesn't have such a requirement so it should be fine.

Thierry