On Thu, Dec 18, 2014 at 11:04 AM, Thierry Reding <thierry.red...@gmail.com> wrote: >> I double checked the symptom and found it was a deadlock on drm_global_mutex. >> When i915_driver_load() registers the platform device while ipvr module is >> in the system, ipvr's probe() function tries to lock drm_global_mutex which >> was already held by i915. >> I think either of the following 2 actions need to be moved to a bottom half >> e.g. a work queue: >> platform_device_add () call in i915_ved.c (called during >> i915_driver_load()) >> drm_dev_register() call during ipvr's probe() >> Which one makes more sense? pls kindly advise (I personally prefer the >> former one.). > > Yes, that's somewhat ugly, but I don't see a way around that. I'd also > think that moving platform_device_add() to a workqueue would be the best > option here.
Or we simply kill drm_global_mutex for platform drivers that don't use the ->probe hook. It should work when they have a correct order betwen drm_dev_alloc and _register and all the code in between. So just ditch the ->load callback in teh ipvr driver and rework the load sequence as suggested somewhere else and this is fixed already. No need for bottom halfs I think. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
