On Thu, Jul 20, 2017 at 4:40 PM, Liviu Dudau <Liviu.Dudau@xxxxxxx> wrote: > On Thu, Jul 20, 2017 at 03:24:13PM +0100, Russell King - ARM Linux wrote: >> On Thu, Jul 20, 2017 at 03:19:10PM +0100, Liviu Dudau wrote: >> > On Thu, Jul 20, 2017 at 02:08:29PM +0100, Russell King - ARM Linux wrote: >> > > On Thu, Jul 20, 2017 at 01:54:04PM +0100, Liviu Dudau wrote: >> > > > On Thu, Jul 20, 2017 at 12:44:49PM +0100, Russell King - ARM Linux wrote: >> > > > > Actually, scrub that idea - drm_helper_probe_single_connector_modes() >> > > > > calls drm_edid_to_eld() for these cases anyway, so we must call >> > > > > drm_helper_probe_single_connector_modes() with the audio_mutex held. >> > > > >> > > > OK, so the lockdep warning is spurious? >> > > >> > > I don't think so. I think there's two ways to solve this: >> > > >> > > 1. replace the audio_mutex in tda998x_audio_get_eld() and >> > > tda998x_connector_fill_modes() with a new mutex (eld_mutex) to >> > > protect just the ELD. >> > > >> > > 2. remove the mutex from these two functions, and take the connection_mutex >> > > modeset lock in tda998x_audio_get_eld(). >> > > >> > > However, I don't have a view on which would be best. >> > >> > If you don't mind, I took the liberty of picking option 2, just because >> > I don't like adding new locks when existing ones might do the job. >> >> I don't mind - but one question for the DRM people in connection with >> your patch is whether we need the acquire context for this relatively >> simple lock/copy/unlock sequence. This path for getting the ELD >> shouldn't be holding any other DRM locks. > > Cc-ing Daniel Vetter in hope of clarifications / nod of approval. > However, I can only see my emails in the online dri-devel archive, not > yours, so I can't point him to the whole discussion. > > danvet: a while ago while I was debugging the delayed fb setup I found > a lockdep warning with the tda998x driver. Now I've had some more time > to investigate so I have created a patch trying to fix the issue, which > was on v1 just a re-ordering of places where tda998x's audio_mutex lock > was taken. Russell suggested a different approach, which I have > implemented in [1], but we wonder if we really have to go through the > whole dance. If all you do is take only one ww mutex (wrapped up in drm_modeset_lock for kms) then you can pass a NULL acquire context. The context is only needed when you want to take multiple locks at the same time (to be able to resolve deadlocks). Taking a single lock within the modeset lock class can't deadlock. Reading the kerneldoc that's not explained at all :-( Can you pls type a patch to improve the docs for drm_modeset_lock? Thanks, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
