From patchwork Mon Mar 21 15:12:05 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Takashi Iwai X-Patchwork-Id: 8635831 Return-Path: X-Original-To: patchwork-intel-gfx@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork1.web.kernel.org (Postfix) with ESMTP id 9C49F9F8A8 for ; Mon, 21 Mar 2016 20:52:42 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id C349F20295 for ; Mon, 21 Mar 2016 20:52:41 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) by mail.kernel.org (Postfix) with ESMTP id C39E82010E for ; Mon, 21 Mar 2016 20:52:40 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 2DA806E65F; Mon, 21 Mar 2016 20:51:21 +0000 (UTC) X-Original-To: intel-gfx@lists.freedesktop.org Delivered-To: intel-gfx@lists.freedesktop.org Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by gabe.freedesktop.org (Postfix) with ESMTPS id 603B16E063 for ; Mon, 21 Mar 2016 15:12:07 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 4A848AB9D; Mon, 21 Mar 2016 15:12:05 +0000 (UTC) Date: Mon, 21 Mar 2016 16:12:05 +0100 Message-ID: From: Takashi Iwai To: "Yang, Libin" In-Reply-To: References: <1458536609-70400-1-git-send-email-libin.yang@linux.intel.com> <96A12704CE18D347B625EE2D4A099D190468405F@SHSMSX103.ccr.corp.intel.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL/10.8 Emacs/24.5 (x86_64-suse-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Cc: "intel-gfx@lists.freedesktop.org" , "Vetter, Daniel" , "libin.yang@linux.intel.com" Subject: Re: [Intel-gfx] [PATCH] drm/i915: intel_audio clear eld buf when disconnecting monitor X-BeenThere: intel-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Intel graphics driver community testing & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_MED, RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On Mon, 21 Mar 2016 16:00:21 +0100, Takashi Iwai wrote: > > On Mon, 21 Mar 2016 15:17:37 +0100, > Yang, Libin wrote: > > > > > > > -----Original Message----- > > > From: Takashi Iwai [mailto:tiwai@suse.de] > > > Sent: Monday, March 21, 2016 6:45 PM > > > To: libin.yang@linux.intel.com > > > Cc: intel-gfx@lists.freedesktop.org; conselvan2@gmail.com; > > > jani.nikula@linux.intel.com; ville.syrjala@linux.intel.com; Vetter, Daniel; > > > tiwai@suse.de; Yang, Libin > > > Subject: Re: [PATCH] drm/i915: intel_audio clear eld buf when > > > disconnecting monitor > > > > > > On Mon, 21 Mar 2016 06:03:29 +0100, > > > libin.yang@linux.intel.com wrote: > > > > > > > > From: Libin Yang > > > > > > > > When disconnecting monitor, dev_priv->dig_port_map[port] > > > > will be set NULL, which causes eld will not be updated in > > > > i915_audio_component_get_eld(). > > > > > > > > This patch clears the eld buf when dev_priv->dig_port_map[port] > > > > is NULL. > > > > > > > > Signed-off-by: Libin Yang > > > > > > While this isn't certainly bad, I don't think it's mandatory. The > > > function returns zero, i.e. no data is copied. So the caller > > > shouldn't expect that the buffer is cleared in this case. > > > > Without the patch, we find when unplug the monitor, the eld info > > will not be updated. The means the eld info in the procfs still remains > > the old info after the monitor is disconnected. > > Well, it's not about zero-clear but rather because the function > returns an error (-EINVAL), and the caller takes it too seriously. > Upon receiving an error code, the HDA driver doesn't read ELD at all, > so it won't help even if you do zero-clear there. > > The alternative fix patch is below. ... or we can fix it in HDA side like below, too. Both patches don't conflict. Takashi -- 8< -- From: Takashi Iwai Subject: [PATCH] ALSA: hda - Fix missing ELD update at unplugging i915 get_eld ops may return an error when no encoder is connected, and currently we regard the error as fatal and skip the whole ELD handling. This ended up with the missing ELD update at unplugging. This patch fixes the issue by treating the error as the unplugged state, instead of skipping the rest. Cc: # v4.5 Signed-off-by: Takashi Iwai --- sound/pci/hda/patch_hdmi.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c index a4bda74cb4e4..cb382de1d11c 100644 --- a/sound/pci/hda/patch_hdmi.c +++ b/sound/pci/hda/patch_hdmi.c @@ -1485,11 +1485,10 @@ static void sync_eld_via_acomp(struct hda_codec *codec, int size; mutex_lock(&per_pin->lock); + *eld->monitor_present = false; size = snd_hdac_acomp_get_eld(&codec->core, per_pin->pin_nid, &eld->monitor_present, eld->eld_buffer, ELD_MAX_SIZE); - if (size < 0) - goto unlock; if (size > 0) { size = min(size, ELD_MAX_SIZE); if (snd_hdmi_parse_eld(codec, &eld->info,