On 05.12.2012 14:04, Thierry Reding wrote: > On Wed, Dec 05, 2012 at 01:47:38PM +0200, Terje Bergström wrote: > Yes, but there's more. For instance I went to great lengths to make sure > there's no global data whatsoever. So all the data is bound to the > host1x device in the current code. I know many other drivers like to > take a shortcut and just put these things into global variables but I > didn't want to. Sure, that feedback is in the todo list. For some parts I already have a proposed solution, but for chip ops not yet. >> The problem with doing drm_platform_init() with host1x device as >> parameter is that drm_get_platform_dev() will take control of drvdata. >> We'd need to put host1x specific struct host1x pointer to some other >> place and I'm not sure what that place could be. > > Not anymore. I submitted a patch so that it no longer does that. The > patch was merged about a month and a half ago. Oops, I must've checked the status from a stale tree. Thanks for that. In this case there's no technical reason why host1x couldn't act as the device to register for drm, as drm wouldn't touch host1x device data in any way. How about if we treat the host1x driver as utility library, and move the code for host1x probe altogether to tegradrm/host1x.c? I haven't yet checked how bad the dependencies between host1x's driver's host1x.c and the rest of the driver are, so I'm not sure if it's feasible and if there would be a clear design. Just tossing in ideas. That would solve the circular dependency problem. I've already committed to contents of host1x.c being very different in downstream and upstream, so this change would just emphasize that. Terje _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
