Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S935826AbdGTO5P (ORCPT ); Thu, 20 Jul 2017 10:57:15 -0400 Received: from mail-io0-f194.google.com ([209.85.223.194]:37873 "EHLO mail-io0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934466AbdGTO5O (ORCPT ); Thu, 20 Jul 2017 10:57:14 -0400 MIME-Version: 1.0 X-Originating-IP: [2a02:168:5640:0:960b:2678:e223:c1c6] In-Reply-To: <20170720144045.GD3532@e110455-lin.cambridge.arm.com> References: <20170720110450.7435-1-Liviu.Dudau@arm.com> <20170720113853.GX31807@n2100.armlinux.org.uk> <20170720114449.GA19026@n2100.armlinux.org.uk> <20170720125404.GA3532@e110455-lin.cambridge.arm.com> <20170720130829.GY31807@n2100.armlinux.org.uk> <20170720141910.GC3532@e110455-lin.cambridge.arm.com> <20170720142413.GB31807@n2100.armlinux.org.uk> <20170720144045.GD3532@e110455-lin.cambridge.arm.com> From: Daniel Vetter Date: Thu, 20 Jul 2017 16:57:12 +0200 Message-ID: Subject: Re: [PATCH] drm/i2c: tda998x: Fix lockdep warning about possible circular dependency To: Liviu Dudau Cc: Russell King - ARM Linux , David Airlie , DRI devel , LKML Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2803 Lines: 57 On Thu, Jul 20, 2017 at 4:40 PM, Liviu Dudau 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