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