Re: [RFC PATCH v3 4/4] tests/drv_module_reload: add ipvr support

Daniel Vetter
2014-12-18T11:21:15Z

On Thu, Dec 18, 2014 at 11:04 AM, Thierry Reding
<thierry.reding@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
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org