Re: [RFC v2 6/8] gpu: drm: tegra: Remove redundant host1x
From: Thierry Reding
Date: Wed Dec 05 2012 - 03:33:41 EST
On Mon, Nov 26, 2012 at 03:19:12PM +0200, Terje Bergstrom wrote:
> From: Arto Merilainen <amerilainen@xxxxxxxxxx>
>
> This patch removes the redundant host1x driver from tegradrm and
> makes necessary bindings to the separate host driver.
>
> This modification introduces a regression: Because there is no
> general framework for attaching separate devices into the
> same address space, this patch removes the ability to use IOMMU
> in tegradrm.
>
> Signed-off-by: Arto Merilainen <amerilainen@xxxxxxxxxx>
> Signed-off-by: Terje Bergstrom <tbergstrom@xxxxxxxxxx>
I've been thinking about this some more and came to the conclusion that
since we will already have a tight coupling between host1x and tegra-drm
we may just as well keep the client registration code in host1x. The way
I imagine this to work would be to export a public API from tegra-drm,
say tegra_drm_init() and tegra_drm_exit(), that could be called in place
of drm_platform_init() and drm_platform_exit() in the current code.
tegra_drm_init() could then be passed the host1x platform device to bind
to. The only thing that would need to be done is move the fields in the
host1x structure specific to DRM into a separate structure. host1x would
have to export host1x_drm_init/exit() which the DRM can invoke to have
all DRM clients register to the DRM subsystem.
From a hierarchical point of view this makes sense, with host1x being
the parent of all DRM subdevices. It allows us to reuse the current code
from tegra-drm that has been tested and works properly even for module
unload/reload. We also get to keep the proper encapsulation and the
switch to the separate host1x driver will require a much smaller patch.
Does anybody see a disadvantage in this approach?
Thierry
Attachment:
pgp00000.pgp
Description: PGP signature