Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp2313464imm; Thu, 7 Jun 2018 08:37:19 -0700 (PDT) X-Google-Smtp-Source: ADUXVKJvY2kcLWzz6Eu/yqqgcUKz15LAHHCzlm0twfXttVDvAGBcTiJ8KTiWqVmFXGjvaAZpIYXx X-Received: by 2002:a63:18c:: with SMTP id 134-v6mr2003865pgb.138.1528385839328; Thu, 07 Jun 2018 08:37:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1528385839; cv=none; d=google.com; s=arc-20160816; b=ZiFpG3jC9Ae6e9eyo5Z+Vm9e21/4s1ZzypxiwxKMqB7QhKLnxhpoed3EzozcmzUsig iSqJfpmuzIEI5LW1ieLnmztFV4JxPtkFF9Q4gr9T79CMxX4nFqhAQt8CnrwaON9k+nMI cdbL2a7cg3V0V8dTu7YED6FeWTexfT31l8udqApZrGAoBdDKcOsGlu/Z1i2M5Yhy7gOA cru1ecGr9xPVc+5iVBw4w2ugjqg/rGZoAdBKArZs4b3o44MkBplo0f1PuA6KEIkVaLMj C6YJKUxql2+ikJenwctOA9rgUk+FImu9/j3feclKCZMVAH1/SMhZm0fD4RRHLyNNRSX0 Xm6w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:subject:message-id:date:cc:to :from:mime-version:content-transfer-encoding:content-disposition :arc-authentication-results; bh=eJwODXmLWsgzhuXBpe9QtKyMjv9NytNFy4zZxggpK9Q=; b=nEwphf31FYP086aJSzTk59cYFGInubEx+1JK0wdvWtpbBcekCYdM08Fc7H69BoFa6Z ANvQtk9Rb+JWDL3oMQlNrOJ0VvOXgrGl3q+ByJ6natUDe5F92CDkuGoumChrYRzoOABw Vps1TDE0Q0kN6Dz+M40r+cNEyX3+q52AHSmGzapH27/huqE9sojc65vljKnfsc4b7ngs xNvc16//IW2DTMCInFCmNYMUTlG2ZzNok2dYtUsVeMzWGY0FzwGEl+33Fz8WOzO97q9h UmySgfVU03uP/VjkB+rGzmCJ0HmhFHZ6/7H+b1yUg6ehnRdMElFQhFP+5GdEIpZAfMSP 7V7g== 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 n2-v6si55058625plk.433.2018.06.07.08.37.04; Thu, 07 Jun 2018 08:37:19 -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 S935020AbeFGPe4 (ORCPT + 99 others); Thu, 7 Jun 2018 11:34:56 -0400 Received: from shadbolt.e.decadent.org.uk ([88.96.1.126]:40641 "EHLO shadbolt.e.decadent.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933716AbeFGOml (ORCPT ); Thu, 7 Jun 2018 10:42:41 -0400 Received: from [148.252.241.226] (helo=deadeye) by shadbolt.decadent.org.uk with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1fQvbP-0005hL-EW; Thu, 07 Jun 2018 15:09:23 +0100 Received: from ben by deadeye with local (Exim 4.91) (envelope-from ) id 1fQvbD-0003Gd-EC; Thu, 07 Jun 2018 15:09:11 +0100 Content-Type: text/plain; charset="UTF-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit MIME-Version: 1.0 From: Ben Hutchings To: linux-kernel@vger.kernel.org, stable@vger.kernel.org CC: akpm@linux-foundation.org, "Takashi Iwai" Date: Thu, 07 Jun 2018 15:05:21 +0100 Message-ID: X-Mailer: LinuxStableQueue (scripts by bwh) Subject: [PATCH 3.16 371/410] ALSA: hda/realtek - Always immediately update mute LED with pin VREF In-Reply-To: X-SA-Exim-Connect-IP: 148.252.241.226 X-SA-Exim-Mail-From: ben@decadent.org.uk X-SA-Exim-Scanned: No (on shadbolt.decadent.org.uk); SAEximRunCond expanded to false Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 3.16.57-rc1 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 Signed-off-by: Takashi Iwai [bwh: Backported to 3.16: Use snd_hda_power{down,up}() (without the _pm suffix] Signed-off-by: Ben Hutchings --- 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 @@ -3435,8 +3435,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(codec); snd_hda_set_pin_ctl_cache(codec, spec->mute_led_nid, pinval); + snd_hda_power_down(codec); + } } /* Make sure the led works even in runtime suspend */