Received: by 2002:a25:1985:0:0:0:0:0 with SMTP id 127csp94813ybz; Thu, 23 Apr 2020 19:12:44 -0700 (PDT) X-Google-Smtp-Source: APiQypK26nDbPwouAoxL9cihI/8VxOItS51r0AyzursaQP6mFl+rlREKRqzctiLblHm8/pGqL5IA X-Received: by 2002:a17:906:c839:: with SMTP id dd25mr5067609ejb.164.1587694363851; Thu, 23 Apr 2020 19:12:43 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1587694363; cv=none; d=google.com; s=arc-20160816; b=m9gBAiUR5cWLPE/btxL5c4+uIkqD0IvxtRAMSXLYFYwzcJ8WxvE0+xYn6TJx5JIwnM aoZP6rlIeHoJG85dirM2Y3lC2luXk6d5aFAvjPeBdHGXTdoglp+PelvDyGllx+QEFFLW 35IQ2VOEUeHlWP9AHGJxKFRrx3SP4IINkJoRtHgWqo8AO0ZK37k1fYKJkQZzK44tSlmG C1pouG7KZOlcDTSMpX2m+hzouHGJozOnaKDfp/vvcGsioZq7sW/I3Vf+STv0mpTP4FcE odGm9BHvg1njUUjqpRGNfanUMe6KUFZNIivqIAsQn0Y2W8IKSvuXug+CQ2B3A+h+zFi0 5u0g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:date:subject:to:from; bh=4d7ASqLfsw7wchhyOU0gdruSqkZAKuDzqyxYdJuK/sM=; b=Wr77yJUGR4Ng42lxryQgUoF6w/VUMbilH4BMGGY2q2J509jqD5xKrVDp+olSV7+nMD Nq/5qGvxaNoLsXJRk8povfRrqETnpkw3NQ2/CPEDL6iqdhOl0pEiXy4GpfxZFF7R9aNv wfWxqwzRsMQjXYaEd6rykGYEjTG9FdD5RNe0sppQsgHf8vTlLQOMYXkhYP9LY7MphBNc 0xm5Sh3leDmfLT9OzquEKyNHKbvYw6OVH4+lA00CdJg3Bw5OaGHRQYUoGDlPPIK4Ihwx C/dy/8VQRYNHeF0xnY/MaXnlXx34Zndq9oibmWlzIC1W+P6mpa6KeHU5JDT4BeW7ZBvP t1Ew== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=nxp.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id l12si2065803edn.565.2020.04.23.19.12.20; Thu, 23 Apr 2020 19:12:43 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=nxp.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726348AbgDXCK0 (ORCPT + 99 others); Thu, 23 Apr 2020 22:10:26 -0400 Received: from inva021.nxp.com ([92.121.34.21]:42220 "EHLO inva021.nxp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726054AbgDXCKZ (ORCPT ); Thu, 23 Apr 2020 22:10:25 -0400 Received: from inva021.nxp.com (localhost [127.0.0.1]) by inva021.eu-rdc02.nxp.com (Postfix) with ESMTP id 39C2D2001EF; Fri, 24 Apr 2020 04:10:24 +0200 (CEST) Received: from invc005.ap-rdc01.nxp.com (invc005.ap-rdc01.nxp.com [165.114.16.14]) by inva021.eu-rdc02.nxp.com (Postfix) with ESMTP id AD14F2001DA; Fri, 24 Apr 2020 04:10:19 +0200 (CEST) Received: from localhost.localdomain (shlinux2.ap.freescale.net [10.192.224.44]) by invc005.ap-rdc01.nxp.com (Postfix) with ESMTP id 2DDEF402D5; Fri, 24 Apr 2020 10:10:14 +0800 (SGT) From: Shengjiu Wang To: lgirdwood@gmail.com, broonie@kernel.org, perex@perex.cz, tiwai@suse.com, shengjiu.wang@nxp.com, tglx@linutronix.de, allison@lohutok.net, info@metux.net, patches@opensource.cirrus.com, alsa-devel@alsa-project.org, linux-kernel@vger.kernel.org Subject: [PATCH v2] ASoC: wm8962: set CLOCKING2 as non-volatile register Date: Fri, 24 Apr 2020 10:01:38 +0800 Message-Id: <6d25d5b36d4b9aeb8655b5e947dad52214e34177.1587693523.git.shengjiu.wang@nxp.com> X-Mailer: git-send-email 2.7.4 X-Virus-Scanned: ClamAV using ClamSMTP Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Previously CLOCKING2 is set as a volatile register, but cause issue at suspend & resume, that some bits of CLOCKING2 is not restored at resume, for example SYSCLK_SRC bits, then the output clock is wrong. The volatile property is caused by CLASSD_CLK_DIV bits, which are controlled by the chip itself. But the datasheet claims these are read only and protected by the security key, and they are not read by the driver at all. So it should be safe to change CLOCKING2 to be non-volatile. Signed-off-by: Shengjiu Wang --- Changes in v2: - Change according to Charles's suggestion to use non-volatile sound/soc/codecs/wm8962.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/sound/soc/codecs/wm8962.c b/sound/soc/codecs/wm8962.c index d9d59f45833f..0a2cfff44441 100644 --- a/sound/soc/codecs/wm8962.c +++ b/sound/soc/codecs/wm8962.c @@ -118,7 +118,7 @@ static const struct reg_default wm8962_reg[] = { { 5, 0x0018 }, /* R5 - ADC & DAC Control 1 */ { 6, 0x2008 }, /* R6 - ADC & DAC Control 2 */ { 7, 0x000A }, /* R7 - Audio Interface 0 */ - + { 8, 0x01E4 }, /* R8 - Clocking2 */ { 9, 0x0300 }, /* R9 - Audio Interface 1 */ { 10, 0x00C0 }, /* R10 - Left DAC volume */ { 11, 0x00C0 }, /* R11 - Right DAC volume */ @@ -788,7 +788,6 @@ static bool wm8962_volatile_register(struct device *dev, unsigned int reg) { switch (reg) { case WM8962_CLOCKING1: - case WM8962_CLOCKING2: case WM8962_SOFTWARE_RESET: case WM8962_THERMAL_SHUTDOWN_STATUS: case WM8962_ADDITIONAL_CONTROL_4: -- 2.21.0