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