[PATCH v2 13/27] drm/tegra: Move subdevice infrastructure to host1x

[Thierry Reding]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131008/d37bdfce/attachment.pgp>