On Tue, Oct 08, 2013 at 09:25:39AM +0300, Terje Bergström wrote:
On 07.10.2013 11:34, Thierry Reding wrote:
The Tegra DRM driver currently uses some infrastructure to defer the DRM core initialization until all required devices have registered. The same infrastructure can potentially be used by any other driver that requires more than a single sub-device of the host1x module.
Make the infrastructure more generic and keep only the DRM specific code in the DRM part of the driver. Eventually this will make it easy to move the DRM driver part back to the DRM subsystem.
Do we need the host1x_client/tegra_drm_client concept outside DRM? You separated the two in an earlier patch, but the whole structure is there because of limitation in DRM. Shouldn't we keep management of drm clients entirely inside drm?
The DRM specific parts are still all managed within the DRM driver. However the host1x_client API, and specifically the method in which sub-devices can be registered (host1x_client to host1x_device) is completely subsystem agnostic.
That part can be used subsequently by things such as a V4L2 driver to achieve the same thing we've done with Tegra DRM, namely to use several sub-devices collectively to provide the functionality of a "composite" device (VI/CSI).
Second, do we need an own drm_bus for host1x clients? Does it bring something drm_platform doesn't? I couldn't see any immediate difference between the two.
The difference is in that we pass in a host1x_device, which is not a platform device, but really just a wrapped struct device. That in turn provides the whole composite device infrastructure. So, no, it can't be done with drm_platform.
Thierry