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
Attachment:
pgpimlsumh1GI.pgp
Description: PGP signature
