On Tue, May 13, 2014 at 11:31:07PM +0200, Thierry Reding wrote: > A different solution, which seems to be fairly common for DRM drivers > for SoCs, is to instantiate a dummy device so that the DRM driver can > bind to it. This can happen in two forms: add the dummy device directly > in device tree (which goes against pretty much everything that's been > preached about device tree in the past) or the dummy device can be > instantiated in code, which is what the current Tegra DRM/host1x driver > does. Actually the dummy device seems to be an acceptable solution and iirc was even acked by DT maintainers in the last KS. I'm not on top of things, but iirc the thinking was that a dummy device which just pulls in all the relevant real bits with phandles is justified in the board file since it tells you how the board is intended to be used. The justification was that on SoCs where assigning stuff between v4l and drm is really flexible (e.g. on omap or so where you can assign the display pipes essentially freely) the use-case of the board is what matters, and that's a somewhat physical property of it (i.e. in what kind of device it's sitting.) So in your case you'd have a fake display and a fake video device which pulls everything the drm/v4l driver need together. So if the issue is how to get at a master device I think that's simple to solve. If the issue otoh is how the various drivers can get at the bus-like services host1x exposes, then I think a real bus driver makes a lot more sense. And Greg seems to have ideas about that already. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
