Reparenting a platform device

Thierry Reding thierry.reding at avionic-design.de
Sat Apr 7 21:35:10 EST 2012


* Grant Likely wrote:
> On Thu, 5 Apr 2012 10:42:58 +0200, Thierry Reding <thierry.reding at avionic-design.de> 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).
> > 
> > I've tried two alternatives to achieve this: create the GART device in the
> > user driver's .probe() function and explicitly set the DRM device's parent
> > to the resulting platform device like so:
> > 
> > 	gart = platform_device_alloc(...);
> > 	...
> > 	pdev->dev.parent = &gart->dev;
> 
> Yeah, don't *ever* try to do this.  The device hierarchy is a complex
> data structure which must never be directly manipulated.
> 
> > 
> > The alternative is to use the device tree to look up the GART device node and
> > resolve it to the corresponding struct device:
> > 
> > 	gart_node = of_parse_phandle(drm->dev->of_node, "gart-parent", 0);
> > 	gart = bus_find_device(drm->dev->bus, NULL, gart_node, match_of_node);
> > 
> > Where match_of_node matches each struct device's .of_node field to the
> > gart_node.
> > 
> > Both of these variants seem to work, and the DRM device can be properly
> > attached to the GART device. However, after the DRM driver's .probe() exits,
> > I get the following error:
> 
> I don't understand what you're trying to describe here as the 2nd
> option.
> 
> Regardless, reparenting should not ben the solution at all.  What does
> the device tree that you envision look like for this?  What devices
> are created, and what drivers bind to them?

The reason why I need to reparent at all is because the IOMMU driver requires
the user to be a child of the IOMMU device. If you look at the driver in
drivers/iommu/tegra-gart.c you'll see that it references dev->parent in
several places, most notably in the gart_iommu_attach_dev() function. So
there's really only two options that I can see: 1) create a virtual device
that is a child of the GART and is in charge of the actual allocations from
the GART and have the DRM driver use that interface or 2) change the GART
driver's behaviour in a way that the parent/child relationship is no longer a
requirement.

1) has the advantage of providing a central allocation manager for the GART
and will allow to register multiple clients with the GART. 2) does not have
that advantage.

Another alternative may be to allow only a single device to attach to the
GART that doesn't have to be a child of the GART. That way the DRM could take
care of GART aperture allocations, which seems to be the most logical place
to do that anyway.

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/20120407/66f6ce6e/attachment.sig>


More information about the devicetree-discuss mailing list