Re: [RFC v2 6/8] gpu: drm: tegra: Remove redundant host1x

[Lucas Stach <dev-8ppwABl0HbeELgA04lAiVw@public.gmane.org>]

Am Mittwoch, den 05.12.2012, 13:47 +0200 schrieb Terje Bergström:
[...]
> 
> > The problem that this solves is that the DRM driver needs to be bound to
> > a specific platform device. None of the DRM subdevices are suitable
> > because they are only part of the whole DRM device. I think that host1x
> > is the only device that fits here.
> > 
> > Note that this is only an administrative problem. It shouldn't interfere
> > with the way host1x works. The goal is that the DRM device is registered
> > at the proper hierarchical location.
> > 
> > The circular dependency is indeed a problem, though. Quite frankly I
> > have no idea how to solve this. However the approach taken in the
> > current patch will break several other requirements as I already
> > explained.
> 
> The problem with doing drm_platform_init() with host1x device as
> parameter is that drm_get_platform_dev() will take control of drvdata.
> We'd need to put host1x specific struct host1x pointer to some other
> place and I'm not sure what that place could be.
> 
> You're right in that binding to a sub-device is not a nice way. DRM
> framework just needs a "struct device" to bind to. exynos seems to solve
> this by introducing a virtual device and bind to that. I'm not sure if
> this is the best way, but worth considering?
> 
I also think the introduction of a dummy platform device to aggregate
the various DRM devices would be the best way to keep a clean interface
between host1x and the tegradrm parts.

But I haven't thought through how to instantiate such a dummy device
without clobbering the device tree and sprinkling global data all over
the driver. Perhaps the host1x driver could instantiate such a device
and only provide a single API entry point to make this dummy-drm-device
known to it's subdevices. This way we don't have to move all the drm
specific aggregation of devices into host1x and could keep the API a bit
leaner. Obviously this solution would not get around the circular
dependency completely, but would cut down on it a bit.

Regards,
Lucas