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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
