Received: by 10.213.65.68 with SMTP id h4csp892156imn; Tue, 27 Mar 2018 10:41:51 -0700 (PDT) X-Google-Smtp-Source: AIpwx49qsl/K0jkSNaV83CdBv9V+NpIPAf3U257mpWp6yJa53NB1GDL04KMj40SnKeKF3n6s2nKp X-Received: by 10.101.92.139 with SMTP id a11mr185795pgt.6.1522172510992; Tue, 27 Mar 2018 10:41:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1522172510; cv=none; d=google.com; s=arc-20160816; b=XKU3iIqMmoaUO00X/llKuLkMJ84AZwD4woO4u0MqrKYmIZJpMEuuLiBUvj50t52w3o rpsnT7wMDjHNhhb95LWq0J7gFiW3+xvNS4MEI+8pFMwR+zTzf3ob7EaX/J7njGO/Kz5A bRKxmNJ5gYa67elAQJUpdyp12wBglEI7h+7ccpwZXBm6a+7kmeRlXv9fxlQTFPpk3qql Lprk9zegdhiyggEXAZCz36MaOBrURLiG/LeugUmRTlmLm8CThKGzHNVzfJmXbNzmIPFk bn8J+3RATygZ9jyq9FsHy29hm6uAhY1P30drufQ0Y/YbdNDCAkh1H9enrPYAmHyyMbxv Ycww== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :in-reply-to:message-id:date:subject:cc:to:from :arc-authentication-results; bh=x3K1SAHPSkE5ZuSHMkvw1i2HhUJQwuYOEiMz8sfXETg=; b=MB06WyMo7IKq4cMAxlGKU9MvswiKGmB527NNwSiuO89po4EA6xnuFD1bigTRG4M/1M 86Bb8KDa+8zWqSC8Z4gbIJr5GvPfKyCTe4dpaQrPBwBuv8ycFpeGk0av6StfuxHueQZk ECBq6lVLhlID+XVs+jSEzLWgKvV0ICFei/SsGRUi6XtqDc+/3O2Ua5UAD77jLBYeUbla eAu0ZrhgUwnOZAnJEGbCcm9huq74UgFC/NcnF0vF5VyC1nQsl2ighqgVK9qFtJ6RnNwv x6bOdIHKDhrWXAAArvwqCIyLUWYy1K8D9qd9m53Ke5j+KhiLcGESmdmWv+rIx5FWRHCh onhA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id y12si1283567pfk.42.2018.03.27.10.41.33; Tue, 27 Mar 2018 10:41:50 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754156AbeC0QeI (ORCPT + 99 others); Tue, 27 Mar 2018 12:34:08 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:44212 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753100AbeC0QeF (ORCPT ); Tue, 27 Mar 2018 12:34:05 -0400 Received: from localhost (LFbn-1-12247-202.w90-92.abo.wanadoo.fr [90.92.61.202]) by mail.linuxfoundation.org (Postfix) with ESMTPSA id E2C251210; Tue, 27 Mar 2018 16:34:04 +0000 (UTC) From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Takashi Iwai Subject: [PATCH 4.14 015/101] ALSA: hda/realtek - Always immediately update mute LED with pin VREF Date: Tue, 27 Mar 2018 18:26:47 +0200 Message-Id: <20180327162750.912185557@linuxfoundation.org> X-Mailer: git-send-email 2.16.3 In-Reply-To: <20180327162749.993880276@linuxfoundation.org> References: <20180327162749.993880276@linuxfoundation.org> User-Agent: quilt/0.65 X-stable: review MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 4.14-stable review patch. If anyone has any objections, please let me know. ------------------ From: Takashi Iwai commit e40bdb03d3cd7da66bd0bc1e40cbcfb49351265c upstream. Some HP laptops have a mute mute LED controlled by a pin VREF. The Realtek codec driver updates the VREF via vmaster hook by calling snd_hda_set_pin_ctl_cache(). This works fine as long as the driver is running in a normal mode. However, when the VREF change happens during the codec being in runtime PM suspend, the regmap access will skip and postpone the actual register change. This ends up with the unchanged LED status until the next runtime PM resume even if you change the Master mute switch. (Interestingly, the machine keeps the LED status even after the codec goes into D3 -- but it's another story.) For improving this usability, let the driver temporarily powering up / down only during the pin VREF change. This can be achieved easily by wrapping the call with snd_hda_power_up_pm() / *_down_pm(). Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=199073 Cc: Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman --- sound/pci/hda/patch_realtek.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -3488,8 +3488,12 @@ static void alc269_fixup_mic_mute_hook(v pinval = snd_hda_codec_get_pin_target(codec, spec->mute_led_nid); pinval &= ~AC_PINCTL_VREFEN; pinval |= enabled ? AC_PINCTL_VREF_HIZ : AC_PINCTL_VREF_80; - if (spec->mute_led_nid) + if (spec->mute_led_nid) { + /* temporarily power up/down for setting VREF */ + snd_hda_power_up_pm(codec); snd_hda_set_pin_ctl_cache(codec, spec->mute_led_nid, pinval); + snd_hda_power_down_pm(codec); + } } /* Make sure the led works even in runtime suspend */