Reparenting a platform device

Thierry Reding thierry.reding at avionic-design.de
Fri Apr 6 04:08:05 EST 2012


* Thierry Reding wrote:
> * Stephen Warren wrote:
> > On 04/05/2012 02:42 AM, Thierry Reding wrote:
> > > Hi,
> > > 
> > > I have a device tree where I have a GART device and a DRM device which uses
> > > the GART. The GART is implemented by an IOMMU driver (tegra-gart) and
> > > requires the user device to be a child of the GART device (it explicitly
> > > checks for this when the user device is attached).
> > 
> > Isn't this wrong?
> > 
> > I would expect the device parent/child relationship to reflect the
> > CPU-initiated register access bus topology.
> > 
> > A device's interaction with an IOMMU is an aspect of a device's
> > initiating accesses itself, not CPU-initiated register accesses.
> 
> Actually I have no idea why this was made a requirement. Maybe Hiroshi can
> comment on this. The driver really only needs this to basically obtain a
> pointer to itself. The MSM I/O MMU implementation does something similar,
> though, and goes on to register actual child devices (they are instantiated
> in arch/arm/mach-msm/devices-iommu.c). Each of those devices is then assigned
> a specific memory area it seems.
[...]
> I don't think having more than one device using the IOMMU will work properly
> anyway in the context of the Tegra GART driver because there is not means to
> allocate specific regions of the GART aperture to individual devices. So
> really the one and only client actually needs to manage the allocations from
> the GART aperture.

I've been thinking about this some more and it occurred to me that maybe it
would be best to add an additional layer between the GART and the clients
which could manage the allocations. Such a virtual device could actually be
registered as a child of the GART device and allow individual drivers to
request mappings from it so that there is a single instance handing them out
and keep them consistent.

How does that sound?

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/20120405/7f2c842a/attachment-0001.sig>


More information about the devicetree-discuss mailing list