From mboxrd@z Thu Jan 1 00:00:00 1970 From: Takashi Iwai Subject: Re: [PATCH 3/3] snd/hda: Protect concurrent display_power_status with a mutex Date: Mon, 14 Jan 2019 19:00:02 +0100 Message-ID: References: <20190114173753.472-1-chris@chris-wilson.co.uk> <20190114173753.472-3-chris@chris-wilson.co.uk> <154748829141.28151.408499449340104231@skylake-alporthouse-com> Mime-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <154748829141.28151.408499449340104231@skylake-alporthouse-com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: alsa-devel-bounces@alsa-project.org Sender: alsa-devel-bounces@alsa-project.org To: Chris Wilson Cc: Jani Nikula , intel-gfx@lists.freedesktop.org, alsa-devel@alsa-project.org List-Id: intel-gfx@lists.freedesktop.org On Mon, 14 Jan 2019 18:51:31 +0100, Chris Wilson wrote: > > Quoting Takashi Iwai (2019-01-14 17:46:57) > > On Mon, 14 Jan 2019 18:37:53 +0100, > > Chris Wilson wrote: > > > > > > Just in case the audio linkage is swapped between components during the > > > runtime pm sequence, we need to protect the rpm tracking with a mutex. > > > > It's not clear to me how does this happens. > > Could you elaborate a bit more the scenario? > > The code is written such that multiple bits within display_power_status > can be set and cleared simultaneously. There was no serialisation > mentioned in the routine, so I was fearful that the display_power_active > here was being accessed concurrently -- and if that was explaining why > snd/hda appears to be leaking the runtime pm (or at least is holding on > to the wakeref longer than igt expects, > 10s). Aha, and does patch actually "fix" the issue...? It's a simple mutex addition, so no big show, and I'm fine with it, but just wonder whether it really helped. thanks, Takashi