On 20.12.2012 22:30, Thierry Reding wrote: > The problem with your proposed solution is that, even any of Stephen's > valid objections aside, it won't work. Once the tegra-drm module is > unloaded, the driver's data will be left in the current state and the > link to the dummy device will be lost. The dummy device is created by tegradrm's module init, because it's used only by tegradrm. When tegradrm is unloaded, all the tegradrm devices and drivers are unloaded and freed, including the dummy one. > I don't think waiting for things to fail is the right option here. If we > can make out this problem now, then now is the time to fix it. No > excuses. Of course not. If we know of something that fails now, let's not do that. > And quite frankly given how all the various host1x components are > interlinked I think having a single function that gets the DRM dummy > device for DRM-related clients isn't that bad. I like clear responsibilities. tegradrm is responsible for the DRM interface, and host1x driver is responsible for host1x. tegradrm owns its data, and can pass its pointers to the functions that need it. But fine, I still don't like it, but I'll add host1x_set_tegradrm() and host1x_get_tegradrm(), which act as setter and getter for tegradrm's global data. I still think it's a solution to a problem we don't have, but we've wasted an order of magnitude more time debating it than it takes to implement. Terje _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
