On 05.12.2012 14:04, Thierry Reding wrote: > On Wed, Dec 05, 2012 at 01:47:38PM +0200, Terje Bergström wrote: >> You're right in that binding to a sub-device is not a nice way. DRM >> framework just needs a "struct device" to bind to. exynos seems to solve >> this by introducing a virtual device and bind to that. I'm not sure if >> this is the best way, but worth considering? > > That was discussed a few months back already and nobody seemed to like > the idea. In fact it was as a result of that discussion that Stephen > brought up the idea to register the DRM driver from a central host1x > driver (it may also have been part of a discussion on IRC, I don't > remember exactly). > > At the time I spent some time on a patch that introduced drm_soc_init() > to solve this by creating a dummy struct device and registering the > driver on top of that. But I abandoned it in favour of fixing the DRM > platform support code. The approach also didn't provide for the proper > encapsulation. I've managed to go through all the other feedback and implement a solution to most of them, so now I have some slack to actually think about the initialization. Sorry about this, but you (meaning all the reviewers) did give us a _lot_ to do. :-) Fortunately, the driver actually became a lot better, too. Back to the topic of tegradrm init. The root cause of the problem is that DRM framework needs some device to assign itself to. The problem is that this device doesn't have any physical counterpart, as it's only for storing a pointer in DRM framework. Please correct me if this is wrong. Moving the client registration to ping pong between DRM and host1x has its problems. host1x driver itself has no use for a list of client devices. It can just iterate its children in case it needs them. In tegradrm, you need a list of devices under tegradrm control, which might or might not be the same as list of devices under host1x hardware. The solutions that many other DRM drivers seem to employ are the virtual devices. Exynos and OMAP drivers do this, as does SH Mobile DRM driver. So I think I'd still go this way, as it's the path of minimum resistance, least amount of code and most localized change. I know it's not ideal, but I'd also not like to get stuck in this. Terje _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
