From patchwork Mon Mar 30 07:30:30 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Thomas Hebb X-Patchwork-Id: 193138 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-9.5 required=3.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED,DKIM_VALID,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH, MAILING_LIST_MULTI, SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,USER_AGENT_GIT autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 89684C43331 for ; Mon, 30 Mar 2020 07:32:51 +0000 (UTC) Received: from alsa0.perex.cz (alsa0.perex.cz [77.48.224.243]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 0E5CA20748 for ; Mon, 30 Mar 2020 07:32:50 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=alsa-project.org header.i=@alsa-project.org header.b="EQDVhlub"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="hvzKxesc" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0E5CA20748 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=alsa-devel-bounces@alsa-project.org Received: from alsa1.perex.cz (alsa1.perex.cz [207.180.221.201]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by alsa0.perex.cz (Postfix) with ESMTPS id 47D6215F9; Mon, 30 Mar 2020 09:31:59 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa0.perex.cz 47D6215F9 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alsa-project.org; s=default; t=1585553569; bh=FZgXbnzGzu7M64gE3e10HN4/mmsOY6MFdg+s/AZGbjU=; h=From:To:Subject:Date:In-Reply-To:References:Cc:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=EQDVhlubtNYRSUKDOqpCOK9Q4JZGDIomy4+kGnMp7hmDVAFoSi9SHc7QqDAGn7qOw Lz5tbbmnJLNxEjQ/jR4E8+3FV/oqn7l/qtxRUNjlSdArmT/463fa4Uda/ULScWGG3m 9MYw4yGFa5l94QHCVEayu2JS4ypl2jI7A8+oR6iY= Received: from alsa1.perex.cz (localhost.localdomain [127.0.0.1]) by alsa1.perex.cz (Postfix) with ESMTP id B3124F8028C; Mon, 30 Mar 2020 09:30:54 +0200 (CEST) Received: by alsa1.perex.cz (Postfix, from userid 50401) id EE92EF8029A; Mon, 30 Mar 2020 09:30:46 +0200 (CEST) Received: from mail-qk1-x743.google.com (mail-qk1-x743.google.com [IPv6:2607:f8b0:4864:20::743]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by alsa1.perex.cz (Postfix) with ESMTPS id 909B0F8028D for ; Mon, 30 Mar 2020 09:30:42 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa1.perex.cz 909B0F8028D Authentication-Results: alsa1.perex.cz; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="hvzKxesc" Received: by mail-qk1-x743.google.com with SMTP id x3so17952128qki.4 for ; Mon, 30 Mar 2020 00:30:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=J0mF9YuJjdBJn2ibrPXteakvuUEew7gBpgHO80gKios=; b=hvzKxesc6T9Xr7/+N5hnlAWriKe2jdgQEGrG6lKHD2Ur5i9WbpwXQKJBUxlzWk4Gfo 5XsHcMb1vv4xi3J7BY5dC9SRJV+1VPMW5HkUaJU5LbVzhVYtUQIw2eAUEZHTPxr0fFW6 FGcKTuHqs8z9C7e1YVZLUGDCt4JzmoVXvLnTjd+YYIQcq7x1v2JWIoce2YdK7bnh/kk+ pRDCGTMW3AAjDXQDFRoNVEqA8+pu1mFKgZP6Pa7TydTYlvbsIuCs09MsI+m+WHV0z66L oYF7MJ3IwkD/hhRzl7IXv9ueclrrM2pwLoUFKsd7d4vXgutuqTM+IAj+Cr3+6KhWWRl4 WP7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=J0mF9YuJjdBJn2ibrPXteakvuUEew7gBpgHO80gKios=; b=JGpsAdwRRZi7Qn3mQdyyx6DmUZZNS6/PYhs3ky2XqJgK1EyOgj7DLk1cEFicWTfUxb nZ6ntR5hKK1cVaJ9TScqYr57/LnS/SsK/gA5W64+EGfvmbG+TcIfjdxMd8rYr1DLBPx5 Z3J0ex4TRz2FnOmLcUICCq7Qgoi0ZgQV7lmCng3stSAVZ951n0jPVEEAxdq/Z7f9KzQw HUt/h4cRxuK5RyHApKlNTH5UxiSJmUlLRQYGbQTiodpv8TEkjlHfpuk34yW3cAzPZsv+ EpIkbeXLXGgFtiPGREIYymhuQDji7beQVQiEvjr7Fxzd9hRUflBqiI4Ygzb7AsgRr1Yl egyA== X-Gm-Message-State: ANhLgQ2vLbrZx7DRw0K1x8bFJ1MEurkvl2JUemLgJ//jinZK431LS4pu aFbFmXKrHjwEeTjI3LgUCc0UwgJWW880BQ== X-Google-Smtp-Source: ADFU+vs6NUiM8C4jsWZ+vAHnLW2Y842aF6c7pNjPZoSWGT35QxH1qwA4b2SFMyyNZ1+dOPROnLh+SQ== X-Received: by 2002:ae9:ed56:: with SMTP id c83mr3965463qkg.200.1585553439424; Mon, 30 Mar 2020 00:30:39 -0700 (PDT) Received: from stingray.lan (pool-173-76-255-234.bstnma.fios.verizon.net. [173.76.255.234]) by smtp.gmail.com with ESMTPSA id n63sm10078499qka.80.2020.03.30.00.30.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 30 Mar 2020 00:30:39 -0700 (PDT) From: Thomas Hebb To: alsa-devel@alsa-project.org, linux-kernel@vger.kernel.or Subject: [PATCH 1/3] ALSA: doc: Document PC Beep Hidden Register on Realtek ALC256 Date: Mon, 30 Mar 2020 03:30:30 -0400 Message-Id: X-Mailer: git-send-email 2.25.2 In-Reply-To: References: MIME-Version: 1.0 Cc: Kailang Yang , Jonathan Corbet , linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, Takashi Iwai , stable@vger.kernel.org, Thomas Hebb X-BeenThere: alsa-devel@alsa-project.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Alsa-devel mailing list for ALSA developers - http://www.alsa-project.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: alsa-devel-bounces@alsa-project.org Sender: "Alsa-devel" This codec (among others) has a hidden set of audio routes, apparently designed to allow PC Beep output without a mixer widget on the output path, which are controlled by an undocumented Realtek vendor register. The default configuration of these routes means that certain inputs aren't accessible, necessitating driver control of the register. However, Realtek has provided no documentation of the register, instead opting to fix issues by providing magic numbers, most of which have been at least somewhat erroneous. These magic numbers then get copied by others into model-specific fixups, leading to a fragmented and buggy set of configurations. To get out of this situation, I've reverse engineered the register by flipping bits and observing how the codec's behavior changes. This commit documents my findings. It does not change any code. Cc: stable@vger.kernel.org Signed-off-by: Thomas Hebb --- Documentation/sound/hd-audio/index.rst | 1 + .../sound/hd-audio/realtek-pc-beep.rst | 129 ++++++++++++++++++ 2 files changed, 130 insertions(+) create mode 100644 Documentation/sound/hd-audio/realtek-pc-beep.rst diff --git a/Documentation/sound/hd-audio/index.rst b/Documentation/sound/hd-audio/index.rst index f8a72ffffe66..6e12de9fc34e 100644 --- a/Documentation/sound/hd-audio/index.rst +++ b/Documentation/sound/hd-audio/index.rst @@ -8,3 +8,4 @@ HD-Audio models controls dp-mst + realtek-pc-beep diff --git a/Documentation/sound/hd-audio/realtek-pc-beep.rst b/Documentation/sound/hd-audio/realtek-pc-beep.rst new file mode 100644 index 000000000000..be47c6f76a6e --- /dev/null +++ b/Documentation/sound/hd-audio/realtek-pc-beep.rst @@ -0,0 +1,129 @@ +=============================== +Realtek PC Beep Hidden Register +=============================== + +This file documents the "PC Beep Hidden Register", which is present in certain +Realtek HDA codecs and controls a muxer and pair of passthrough mixers that can +route audio between pins but aren't themselves exposed as HDA widgets. As far +as I can tell, these hidden routes are designed to allow flexible PC Beep output +for codecs that don't have mixer widgets in their output paths. Why it's easier +to hide a mixer behind an undocumented vendor register than to just expose it +as a widget, I have no idea. + +Register Description +==================== + +The register is accessed via processing coefficient 0x36 on NID 20h. Bits not +identified below have no discernible effect on my machine, a Dell XPS 13 9350:: + + MSB LSB + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | |h|S|L| | B |R| | Known bits + +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ + |0|0|1|1| 0x7 |0|0x0|1| 0x7 | Reset value + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +1Ah input select (B): 2 bits + When zero, expose the PC Beep line (from the internal beep generator, when + enabled with the Set Beep Generation verb on NID 01h, or else from the + external PCBEEP pin) on the 1Ah pin node. When nonzero, expose the headphone + jack (or possibly Line In on some machines) input instead. If PC Beep is + selected, the 1Ah boost control has no effect. + +Amplify 1Ah loopback, left (L): 1 bit + Amplify the left channel of 1Ah before mixing it into outputs as specified + by h and S bits. Does not affect the level of 1Ah exposed to other widgets. + +Amplify 1Ah loopback, right (R): 1 bit + Amplify the right channel of 1Ah before mixing it into outputs as specified + by h and S bits. Does not affect the level of 1Ah exposed to other widgets. + +Loopback 1Ah to 21h [active low] (h): 1 bit + When zero, mix 1Ah (possibly with amplification, depending on L and R bits) + into 21h (headphone jack on my machine). Mixed signal respects the mute + setting on 21h. + +Loopback 1Ah to 14h (S): 1 bit + When one, mix 1Ah (possibly with amplification, depending on L and R bits) + into 14h (internal speaker on my machine). Mixed signal **ignores** the mute + setting on 14h and is present whenever 14h is configured as an output. + +Path diagrams +============= + +1Ah input selection (DIV is the PC Beep divider set on NID 01h):: + + + | | | + +--DIV--+--!DIV--+ {1Ah boost control} + | | + +--(b == 0)--+--(b != 0)--+ + | + >1Ah (Beep/Headphone Mic/Line In)< + +Loopback of 1Ah to 21h/14h:: + + <1Ah (Beep/Headphone Mic/Line In)> + | + {amplify if L/R} + | + +-----!h-----+-----S-----+ + | | + {21h mute control} | + | | + >21h (Headphone)< >14h (Internal Speaker)< + +Background +========== + +All Realtek HDA codecs have a vendor-defined widget with node ID 20h which +provides access to a bank of registers that control various codec functions. +Registers are read and written via the standard HDA processing coefficient +verbs (Set/Get Coefficient Index, Set/Get Processing Coefficient). The node is +named "Realtek Vendor Registers" in public datasheets' verb listings and, +apart from that, is entirely undocumented. + +This particular register, exposed at coefficient 0x36 and named in commits from +Realtek, is of note: unlike most registers, which seem to control detailed +amplifier parameters not in scope of the HDA specification, it controls audio +routing which could just as easily have been defined using standard HDA mixer +and selector widgets. + +Specifically, it selects between two sources for the input pin widget with Node +ID (NID) 1Ah: the widget's signal can come either from an audio jack (on my +laptop, a Dell XPS 13 9350, it's the headphone jack, but comments in Realtek +commits indicate that it might be a Line In on some machines) or from the PC +Beep line (which is itself multiplexed between the codec's internal beep +generator and external PCBEEP pin, depending on if the beep generator is +enabled via verbs on NID 01h). Additionally, it can mix (with optional +amplification) that signal onto the 21h and/or 14h output pins. + +The register's reset value is 0x3717, corresponding to PC Beep on 1Ah that is +then amplified and mixed into both the headphones and the speakers. Not only +does this violate the HDA specification, which says that "[a vendor defined +beep input pin] connection may be maintained *only* while the Link reset +(**RST#**) is asserted", it means that we cannot ignore the register if we care +about the input that 1Ah would otherwise expose or if the PCBEEP trace is +poorly shielded and picks up chassis noise (both of which are the case on my +machine). + +Unfortunately, there are lots of ways to get this register configuration wrong. +Linux, it seems, has gone through most of them. For one, the register resets +after S3 suspend: judging by existing code, this isn't the case for all vendor +registers, and it's led to some fixes that improve behavior on cold boot but +don't last after suspend. Other fixes have successfully switched the 1Ah input +away from PC Beep but have failed to disable both loopback paths. On my +machine, this means that the headphone input is amplified and looped back to +the headphone output, which uses the exact same pins! As you might expect, this +causes terrible headphone noise, the character of which is controlled by the +1Ah boost control. (If you've seen instructions online to fix XPS 13 headphone +noise by changing "Headphone Mic Boost" in ALSA, now you know why.) + +The information here has been obtained through black-box reverse engineering of +the ALC256 codec's behavior and is not guaranteed to be correct. It likely +also applies for the ALC255, ALC257, ALC235, and ALC236, since those codecs +seem to be close relatives of the ALC256. (They all share one initialization +function.) Additionally, other codecs like the ALC225 and ALC285 also have this +register, judging by existing fixups in ``patch_realtek.c``, but specific +data (e.g. node IDs, bit positions, pin mappings) for those codecs may differ +from what I've described here. From patchwork Mon Mar 30 07:30:31 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Thomas Hebb X-Patchwork-Id: 193137 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-9.5 required=3.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED,DKIM_VALID,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH, MAILING_LIST_MULTI, SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,USER_AGENT_GIT autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C1DB2C43331 for ; Mon, 30 Mar 2020 07:33:48 +0000 (UTC) Received: from alsa0.perex.cz (alsa0.perex.cz [77.48.224.243]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 4DEC42073B for ; Mon, 30 Mar 2020 07:33:48 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=alsa-project.org header.i=@alsa-project.org header.b="g0retpWo"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="LncIDrPv" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4DEC42073B Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=alsa-devel-bounces@alsa-project.org Received: from alsa1.perex.cz (alsa1.perex.cz [207.180.221.201]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by alsa0.perex.cz (Postfix) with ESMTPS id A43681675; Mon, 30 Mar 2020 09:32:56 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa0.perex.cz A43681675 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alsa-project.org; s=default; t=1585553626; bh=vNhoGYVnKuisCDVz0bKuroPgac3V2xsV4KBn5pZErMQ=; h=From:To:Subject:Date:In-Reply-To:References:Cc:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=g0retpWoKk3klCFwHeWvJKQHXzGQif1GkYC6sSTHREeRb+E9bkdgKEedfPFSx1xW0 SqZ1FN6G6ORVnKaaX2qRjTKQAVRT/BBDNGYKlf48j0hNWYS6Zbh+IbHt7Dxitspm7g 1ajj4OQOKn5gMtpIrLcNt4vJ2Qyz/Pc0VxFUIMMA= Received: from alsa1.perex.cz (localhost.localdomain [127.0.0.1]) by alsa1.perex.cz (Postfix) with ESMTP id E6D28F802A2; Mon, 30 Mar 2020 09:31:05 +0200 (CEST) Received: by alsa1.perex.cz (Postfix, from userid 50401) id C344FF80299; Mon, 30 Mar 2020 09:30:47 +0200 (CEST) Received: from mail-qv1-xf41.google.com (mail-qv1-xf41.google.com [IPv6:2607:f8b0:4864:20::f41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by alsa1.perex.cz (Postfix) with ESMTPS id BA985F8028C for ; Mon, 30 Mar 2020 09:30:43 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa1.perex.cz BA985F8028C Authentication-Results: alsa1.perex.cz; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="LncIDrPv" Received: by mail-qv1-xf41.google.com with SMTP id bu9so2406145qvb.13 for ; Mon, 30 Mar 2020 00:30:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=YSCR8aNaMptUVJblHXzimEhpdjR3BXiCbmHpK02W3lk=; b=LncIDrPvKfAaA0dhcA1CA6xSu37hTu7qLw8XmXxotN2+at1XgNjhyFv4Y4I7H4/w0W DAWchdINvtcWP8flC+eMYf6hCKTriOhJgVZYvRomEiET7v2tXpQaYI8hiIaCT9BAYkjm y7AaQcqmNHSoL5o3zCMd5He3nETzjhpQMyoi9L3oc+EqyuYRQupNNGTcOnnG06WfolPA +9cpmsf56FAWCiwrkrr7yeD2N1k1dV3ZFestnmeVy08IF22w8zrTD2/BNwb/2vDBqo3J KnbcuxptAesv8x2caZvZy32Jaia2ZCLtDj+TP2gM1PQgnmptCWo19XIPSadg4j/3+6m2 gR9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=YSCR8aNaMptUVJblHXzimEhpdjR3BXiCbmHpK02W3lk=; b=H8ok8PovH797/HoPj8l1cUtRAjN/ZzL8yC5SdMT8esWQdQtFtMkwatCa98vvLjSYr0 4fdnSeSXGTnmma+sBGFY4erXxo4antAvnVm9XkKs0KNLtQlUMX9jfn3VznV/x1fKp5Bd bnl9msYgrtzba3rhg1bmUHmPCoJKKLoxN7ZSbX/KKl0NkHcOK9+4yUX0AU8N+T/BJwFG pzmWJqvUnor5Nb/Hr6g/F6JyLrufT3Qgj6PU8EGmEMnlrq3jNNL5e3VoJHsMovIOEh31 Xz7GsPJ27YlMOAEepe/mRq/xKRmPRmVWkehOGZAiZpW3ybvyUPKzti7rsJKG1NaGOK4c ZW6g== X-Gm-Message-State: ANhLgQ1Qz8onzZII4Ml2LZrs8OUmEibQu8M857XQjkDcEV8nFxQCX7JR MgLBL6UivnsU7lba+XBHSkVELJp+NBik4A== X-Google-Smtp-Source: ADFU+vslCt+RBP2jHzxrwlc3lOO1Rt8opKMEjAVebM0NpBBzZdmUI5QhM+bbgTpwxrVgYbGYdpiuXA== X-Received: by 2002:a05:6214:118d:: with SMTP id t13mr10076777qvv.192.1585553440691; Mon, 30 Mar 2020 00:30:40 -0700 (PDT) Received: from stingray.lan (pool-173-76-255-234.bstnma.fios.verizon.net. [173.76.255.234]) by smtp.gmail.com with ESMTPSA id n63sm10078499qka.80.2020.03.30.00.30.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 30 Mar 2020 00:30:40 -0700 (PDT) From: Thomas Hebb To: alsa-devel@alsa-project.org, linux-kernel@vger.kernel.or Subject: [PATCH 2/3] ALSA: hda/realtek - Set principled PC Beep configuration for ALC256 Date: Mon, 30 Mar 2020 03:30:31 -0400 Message-Id: X-Mailer: git-send-email 2.25.2 In-Reply-To: References: MIME-Version: 1.0 Cc: Kailang Yang , Tomas Espeleta , Sergey Bostandzhyan , Greg Kroah-Hartman , Takashi Iwai , stable@vger.kernel.org, Hui Wang , Thomas Hebb , Jian-Hong Pan , =?utf-8?b?TWljaGHFgiBNaXJvc8WCYXc=?= , linux-kernel@vger.kernel.org X-BeenThere: alsa-devel@alsa-project.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Alsa-devel mailing list for ALSA developers - http://www.alsa-project.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: alsa-devel-bounces@alsa-project.org Sender: "Alsa-devel" The Realtek PC Beep Hidden Register[1] is currently set by patch_realtek.c in two different places: In alc_fill_eapd_coef(), it's set to the value 0x5757, corresponding to non-beep input on 1Ah and no 1Ah loopback to either headphones or speakers. (Although, curiously, the loopback amp is still enabled.) This write was added fairly recently by commit e3743f431143 ("ALSA: hda/realtek - Dell headphone has noise on unmute for ALC236") and is a safe default. However, it happens in the wrong place: alc_fill_eapd_coef() runs on module load and cold boot but not on S3 resume, meaning the register loses its value after suspend. Conversely, in alc256_init(), the register is updated to unset bit 13 (disable speaker loopback) and set bit 5 (set non-beep input on 1Ah). Although this write does run on S3 resume, it's not quite enough to fix up the register's default value of 0x3717. What's missing is a set of bit 14 to disable headphone loopback. Without that, we end up with a feedback loop where the headphone jack is being driven by amplified samples of itself[2]. This change eliminates the write in alc_fill_eapd_coef() and replaces the update in alc256_init() with a write of the fixed value 0x4727. This value ought to have the same behavior as 0x5757--disabling all PC Beep routing that isn't part of the HDA node graph--but it has two differences: 1. To enable non-beep input on 1Ah, the `b` field is set to 1, like the previous code in alc256_init() used, instead of 2, like the value written by alc_fill_eapd_coef() used. My testing shows these two values to behave identically, but, in case there is a difference, a bitwise update of the register seems like a more reliable source of truth than a magic number written without explanation. 2. Loopback amplification is disabled (unset L and R bits) because no loopback path is in use. Affects the ALC255, ALC256, ALC257, ALC235, and ALC236 codecs. [1] Newly documented in Documentation/sound/hd-audio/realtek-pc-beep.rst [2] Setting the "Headphone Mic Boost" control from userspace changes this feedback loop and has been a widely-shared workaround for headphone noise on laptops like the Dell XPS 13 9350. This commit eliminates the feedback loop and makes the workaround unnecessary. Fixes: e3743f431143 ("ALSA: hda/realtek - Dell headphone has noise on unmute for ALC236") Cc: stable@vger.kernel.org Signed-off-by: Thomas Hebb --- sound/pci/hda/patch_realtek.c | 15 +++++++++------ 1 file changed, 9 insertions(+), 6 deletions(-) diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c index 63e1a56f705b..024dd61a788b 100644 --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -367,7 +367,9 @@ static void alc_fill_eapd_coef(struct hda_codec *codec) case 0x10ec0215: case 0x10ec0233: case 0x10ec0235: + case 0x10ec0236: case 0x10ec0255: + case 0x10ec0256: case 0x10ec0257: case 0x10ec0282: case 0x10ec0283: @@ -379,11 +381,6 @@ static void alc_fill_eapd_coef(struct hda_codec *codec) case 0x10ec0300: alc_update_coef_idx(codec, 0x10, 1<<9, 0); break; - case 0x10ec0236: - case 0x10ec0256: - alc_write_coef_idx(codec, 0x36, 0x5757); - alc_update_coef_idx(codec, 0x10, 1<<9, 0); - break; case 0x10ec0275: alc_update_coef_idx(codec, 0xe, 0, 1<<0); break; @@ -3269,7 +3266,13 @@ static void alc256_init(struct hda_codec *codec) alc_update_coefex_idx(codec, 0x57, 0x04, 0x0007, 0x4); /* Hight power */ alc_update_coefex_idx(codec, 0x53, 0x02, 0x8000, 1 << 15); /* Clear bit */ alc_update_coefex_idx(codec, 0x53, 0x02, 0x8000, 0 << 15); - alc_update_coef_idx(codec, 0x36, 1 << 13, 1 << 5); /* Switch pcbeep path to Line in path*/ + /* + * Expose headphone mic (or possibly Line In on some machines) instead + * of PC Beep on 1Ah, and disable 1Ah loopback for all outputs. See + * Documentation/sound/hd-audio/realtek-pc-beep.rst for details of + * this register. + */ + alc_write_coef_idx(codec, 0x36, 0x4727); } static void alc256_shutup(struct hda_codec *codec)