From patchwork Mon Mar 21 15:00:21 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Takashi Iwai X-Patchwork-Id: 8635821 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 0291D9F3D1 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 1368420173 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 0B448200ED 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 BC8366E62E; Mon, 21 Mar 2016 20:51:16 +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 723E26E5EE for ; Mon, 21 Mar 2016 15:00:24 +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 C036CAD22; Mon, 21 Mar 2016 15:00:21 +0000 (UTC) Date: Mon, 21 Mar 2016 16:00:21 +0100 Message-ID: From: Takashi Iwai To: "Yang, Libin" In-Reply-To: <96A12704CE18D347B625EE2D4A099D190468405F@SHSMSX103.ccr.corp.intel.com> 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 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. Takashi -- 8< -- From: Takashi Iwai Subject: [PATCH] drm/i915: Don't handle NULL encoder as an error in get_eld notifier Since we fixed the dig_port_map[] assignment rather in a dynamic manner by the commit [2f791908a70e: drm/i915: Fix bogus dig_port_map[] assignment for pre-HSW], the NULL encoder is no longer an error but it just indicates that the unconnected state. However, in the caller (HD-audio) side, it's taken as a serious error, and it leads to the missing update of ELD after unplugging. As a fix, this patch changes get_eld notifier to return zero and initialize the enabled argument properly as false when no encoder is mapped for indicating the unconnected state. Fixes: 2f791908a70e ('drm/i915: Fix bogus dig_port_map[] assignment for pre-HSW') Cc: # v4.5 Signed-off-by: Takashi Iwai --- drivers/gpu/drm/i915/intel_audio.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_audio.c b/drivers/gpu/drm/i915/intel_audio.c index 31f6d212fb1b..63493a63500e 100644 --- a/drivers/gpu/drm/i915/intel_audio.c +++ b/drivers/gpu/drm/i915/intel_audio.c @@ -717,13 +717,13 @@ static int i915_audio_component_get_eld(struct device *dev, int port, struct intel_encoder *intel_encoder; struct intel_digital_port *intel_dig_port; const u8 *eld; - int ret = -EINVAL; + int ret = 0; + *enabled = false; mutex_lock(&dev_priv->av_mutex); intel_encoder = dev_priv->dig_port_map[port]; /* intel_encoder might be NULL for DP MST */ if (intel_encoder) { - ret = 0; intel_dig_port = enc_to_dig_port(&intel_encoder->base); *enabled = intel_dig_port->audio_connector != NULL; if (*enabled) {