From patchwork Tue Jun 27 04:02:34 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Jian Hui Lee X-Patchwork-Id: 1800403 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@legolas.ozlabs.org Authentication-Results: legolas.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=lists.ubuntu.com (client-ip=91.189.94.19; helo=huckleberry.canonical.com; envelope-from=kernel-team-bounces@lists.ubuntu.com; receiver=) Authentication-Results: legolas.ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=canonical.com header.i=@canonical.com header.a=rsa-sha256 header.s=20210705 header.b=u8uIKtK8; dkim-atps=neutral Received: from huckleberry.canonical.com (huckleberry.canonical.com [91.189.94.19]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by legolas.ozlabs.org (Postfix) with ESMTPS id 4Qqrfz68vJz20XS for ; Tue, 27 Jun 2023 14:03:38 +1000 (AEST) Received: from localhost ([127.0.0.1] helo=huckleberry.canonical.com) by huckleberry.canonical.com with esmtp (Exim 4.86_2) (envelope-from ) id 1qDzvH-0001xz-T0; Tue, 27 Jun 2023 04:03:23 +0000 Received: from smtp-relay-internal-1.internal ([10.131.114.114] helo=smtp-relay-internal-1.canonical.com) by huckleberry.canonical.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.86_2) (envelope-from ) id 1qDzvD-0001xW-T4 for kernel-team@lists.ubuntu.com; Tue, 27 Jun 2023 04:03:19 +0000 Received: from mail-oi1-f197.google.com (mail-oi1-f197.google.com [209.85.167.197]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by smtp-relay-internal-1.canonical.com (Postfix) with ESMTPS id B0D703F120 for ; Tue, 27 Jun 2023 04:03:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=canonical.com; s=20210705; t=1687838599; bh=T4aJkkWMCUF0ZRUjn2+QE87p9I2C+vMsR+CsOU++TSg=; h=From:To:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version:Content-Type; b=u8uIKtK85clGrnOpXdxbgicNQtSMadawV0QOgmppPVV3XQslvWjV/Ol/Jsif/hJYu ZTOsKgz6PIqDRAi1L8f6CkOdKmojyhlSOr1TvUS1GZnEWdjeAgI5fK0tWJhVtFYMrs aV038R9vT56B0cqVCQ7GITgKmzKeoEUzMiuIduMoTqLrgi/civtNBwCtao7M//fyQv FBY7n9TYUBOBPVjX+YRVOHD/z205lAhs8eJ6getyPb/FLhwUfbHEyTL/5ya4Jp4Tms cRHmoztz/n+7+1b84R1141YbCd2e/qDkTMmb7u6zBpzren4a8iwyizE9IbzV+KBdzs LzMF+oCMfslZQ== Received: by mail-oi1-f197.google.com with SMTP id 5614622812f47-3a0397c72cfso3459501b6e.2 for ; Mon, 26 Jun 2023 21:03:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1687838598; x=1690430598; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=T4aJkkWMCUF0ZRUjn2+QE87p9I2C+vMsR+CsOU++TSg=; b=DSN5olHIZvn0ZjfaFKSGmmX6xugtvHlcVYy5IV+q1jEOV/rSDyfTfnOjxr/JuQj7de Clv+5jWaHDGIvOOYGVise/TDW9E1zk+LoOT9ZR+DUpVCqGUSw8lfe7y/l6NRxTdrNwCs FPNDtcYKT4p8YLaKDsBqAsD97ElXTshrt3iBa/BALnkANsrxvBUGCWTiE+UxfMpCM+eB +6fHgcrzEcmSvx/aeXhuNGcmwlU6CgMreHkV6V1OBr6wGxYbCI1HhZPHWorhtuv4CvLZ iqr3IZ/ULY0IclvgusHfzDCWsMUzPVsZATxQtfABmpE++zQWoF5MQV/OJJW4yDcCMrZP nZfw== X-Gm-Message-State: AC+VfDxhiYEHxi/bs+0xZ8Z30kNyIOzMuBsqk8v3AHk7bIwXeGf+4kyu hjFrVxNELTTrkkGchNi4iDGyK8SJICyceN5YVDdJjdmcOddO9srhwIC/NWUwLsPkE4qdT5r4bSR dRu0jDItpLwswVSCNVfSdR8Fj+mVT9/9UHrCZmZpYxrhiPS32bg== X-Received: by 2002:a05:6808:8da:b0:3a0:697d:ce29 with SMTP id k26-20020a05680808da00b003a0697dce29mr11065454oij.42.1687838598618; Mon, 26 Jun 2023 21:03:18 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ7mCguCOkqI8H5Cy1XytXD0lK5yJWcQyHDNviuVeffNtJ/UWjmy99kkW7rHIczaSMHEsoZlRA== X-Received: by 2002:a05:6808:8da:b0:3a0:697d:ce29 with SMTP id k26-20020a05680808da00b003a0697dce29mr11065448oij.42.1687838598313; Mon, 26 Jun 2023 21:03:18 -0700 (PDT) Received: from localhost.localdomain (118-163-61-247.hinet-ip.hinet.net. [118.163.61.247]) by smtp.gmail.com with ESMTPSA id n91-20020a17090a5ae400b002471deb13fcsm5235015pji.6.2023.06.26.21.03.17 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 26 Jun 2023 21:03:17 -0700 (PDT) From: Jian Hui Lee To: kernel-team@lists.ubuntu.com Subject: [SRU][Jammy:linux-intel-iotg][PATCH 1/1] ALSA: hda: Fix unhandled register update during auto-suspend period Date: Tue, 27 Jun 2023 12:02:34 +0800 Message-Id: <20230627040234.11418-2-jianhui.lee@canonical.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230627040234.11418-1-jianhui.lee@canonical.com> References: <20230627040234.11418-1-jianhui.lee@canonical.com> MIME-Version: 1.0 X-BeenThere: kernel-team@lists.ubuntu.com X-Mailman-Version: 2.1.20 Precedence: list List-Id: Kernel team discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kernel-team-bounces@lists.ubuntu.com Sender: "kernel-team" From: Takashi Iwai BugLink: https://bugs.launchpad.net/bugs/2025106 commit 81302b1c7c997e8a56c1c2fc63a296ebeb0cd2d0 upstream. It's reported that the recording started right after the driver probe doesn't work properly, and it turned out that this is related with the codec auto-suspend. Namely, after the probe phase, the usage count goes zero, and the auto-suspend is programmed, but the codec is kept still active until the auto-suspend expiration. When an application (e.g. alsactl) updates the mixer values at this moment, the values are cached but not actually written. Then, starting arecord thereafter also results in the silence because of the missing unmute. The root cause is the handling of "lazy update" mode; when a mixer value is updated *after* the suspend, it should update only the cache and exits. At the resume, the cached value is written to the device, in turn. The problem is that the current code misinterprets the state of auto-suspend as if it were already suspended. Although we can add the check of the actual device state after pm_runtime_get_if_in_use() for catching the missing state, this won't suffice; the second call of regmap_update_bits_check() will skip writing the register because the cache has been already updated by the first call. So we'd need fixes in two different places. OTOH, a simpler fix is to replace pm_runtime_get_if_in_use() with pm_runtime_get_if_active() (with ign_usage_count=true). This change implies that the driver takes the pm refcount if the device is still in ACTIVE state and continues the processing. A small caveat is that this will leave the auto-suspend timer. But, since the timer callback itself checks the device state and aborts gracefully when it's active, this won't be any substantial problem. Long story short: we address the missing register-write problem just by replacing the pm_runtime_*() call in snd_hda_keep_power_up(). Fixes: fc4f000bf8c0 ("ALSA: hda - Fix unexpected resume through regmap code path") Reported-by: Amadeusz Sławiński Closes: https://lore.kernel.org/r/a7478636-af11-92ab-731c-9b13c582a70d@linux.intel.com Suggested-by: Cezary Rojewski Cc: Link: https://lore.kernel.org/r/20230518113520.15213-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman (cherry picked from commit e6a624451afbafb7f6779600aad243c185893c26) Signed-off-by: Jian Hui Lee --- sound/hda/hdac_device.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/hda/hdac_device.c b/sound/hda/hdac_device.c index b7e5032b61c9..bfd858577676 100644 --- a/sound/hda/hdac_device.c +++ b/sound/hda/hdac_device.c @@ -611,7 +611,7 @@ EXPORT_SYMBOL_GPL(snd_hdac_power_up_pm); int snd_hdac_keep_power_up(struct hdac_device *codec) { if (!atomic_inc_not_zero(&codec->in_pm)) { - int ret = pm_runtime_get_if_in_use(&codec->dev); + int ret = pm_runtime_get_if_active(&codec->dev, true); if (!ret) return -1; if (ret < 0)