Message ID | 20230419-asoc-rt5682-maple-v1-1-ed40369c9099@kernel.org |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:b0ea:0:b0:3b6:4342:cba0 with SMTP id b10csp3572718vqo; Tue, 25 Apr 2023 10:48:28 -0700 (PDT) X-Google-Smtp-Source: AKy350aWS4bCFH4KsPHvfC/YLk3xR4D055K2mj3bAerwwgfQhCNhf9HG8kaJmflzfSw2YOsSepHr X-Received: by 2002:a05:6a20:8407:b0:f5:40dd:4c55 with SMTP id c7-20020a056a20840700b000f540dd4c55mr8865657pzd.60.1682444908328; Tue, 25 Apr 2023 10:48:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1682444908; cv=none; d=google.com; s=arc-20160816; b=eqj2fWolQAoHEeKvp6NsTEm6mlbCA1iFTHmgkdGCBCO/Zs1wb34ulVvlUItNP275Mh cFoclyUwZFcY0iSM73O90bNwEktCc6ooZtd0p5Kgixcq9kpt2QKqvHQ4JsG8O4OuV58c nyDhJ+VCvyLIXlyQuX1VnxWXK5NOtWXife28XdWv8sCHPzs3YJQeYfcJCadmpBstp+1o q9plrBKfdwuAarL1PVimcvqmkBiVJ74EBm2Z03qN9n3VhmfY5TOVk+u8o1gOWH3mzk9J wNg3YIjLb6m6fq7tmn4kMgG90jS5OAs2VBV2X6JWvm7701CqZv9jTf2qi/uuw+ZZneAg 1/jg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:message-id:content-transfer-encoding :mime-version:subject:date:from:dkim-signature; bh=mJMaOuYc1pxGZOqQ9tEUrjoMFNMTVJHEmAP/548Voqk=; b=Tei7S0dGLi+U3+sBeeanqDP54AaUQ2mfjdGcy8KbbNMm2mpkjxN28cBaw39zzutHoY JI/3kcWskwVhVB3xCSZ9fmqAESDlkDSAiyZQBJhPbtBiSRxV2A7seakw+rZ57OLDEJgQ liQbU6xK9wOB6W9gj8U9GVWJTXnZ/uryQ8o9tsurGGIqDEA5QhJOf/6gYKWUQVnos4HL mLzoQiD9xKd+Thd4YuiJJ+o5edTBW3HWfl60roTSCVxiPyyxfffk9lFvDI4p1zU5MEcF UteLufsGEqvZvK7TuGKVba/4oaW1GylyCDIl2vCKnoTx4bAUNL9PF3Q3jsWfhTIilHuu F3/Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=CIeHLNXw; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id a6-20020a631a46000000b00502ee712648si14442748pgm.578.2023.04.25.10.48.13; Tue, 25 Apr 2023 10:48:28 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=CIeHLNXw; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234572AbjDYRXB (ORCPT <rfc822;zxc52fgh@gmail.com> + 99 others); Tue, 25 Apr 2023 13:23:01 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35628 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234488AbjDYRW7 (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 25 Apr 2023 13:22:59 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 72177D303 for <linux-kernel@vger.kernel.org>; Tue, 25 Apr 2023 10:22:53 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id F3E87616CC for <linux-kernel@vger.kernel.org>; Tue, 25 Apr 2023 17:22:52 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id EF8FAC433D2; Tue, 25 Apr 2023 17:22:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1682443372; bh=VKteOqI+tR4jwGiz0s3/Zl8oDW+YNdx9hzGF1XdHEMo=; h=From:Date:Subject:To:Cc:From; b=CIeHLNXwrtuZP1fk/mP2JVFX8QiAzb9EH8/FBc5VSnL0x3alVZ26UH1jmp+vrrYd7 BHl60ppi3SsDTAL4oaRPenV6JvwC7N6ypwijCcmDRnPHGufj4N7i+5YSfqfKzOIRPb a6xH1zGfQoXSymyg940vzVk3Rn18gp0HKZLtRVqoTuNAzPh8kQ/buhwfiB8bCCEtjg ju6qyVAv1bdlc1f3Q6bUn6Qb6r0JoOceNMNZpqqPAD/Z8Qglq/mG/YkvjF3kYCq/7B PnTTLtz2m0Ez5snW6A9Sjnf4Nk/bgoZdwubJIw/vZvsUzWSbQFLT2V4x81bg83+G2A 72VYxsKeJPoLw== From: Mark Brown <broonie@kernel.org> Date: Tue, 25 Apr 2023 18:22:46 +0100 Subject: [PATCH] ASoC: rt5682: Use a maple tree based register cache MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20230419-asoc-rt5682-maple-v1-1-ed40369c9099@kernel.org> X-B4-Tracking: v=1; b=H4sIAGUMSGQC/x2N0QrCMAwAf2Xk2UBb57T+yvAh66ILajsSUWHs3 +18vIPjFjBWYYNzs4DyW0xKruB3DaSJ8o1RxsoQXNi71kckKwn1dehOAZ80PxiPI7nOxegTtVC 7gYxxUMpp2spP0fumZ+WrfP+r/rKuP/A3VeB6AAAA To: Oder Chiou <oder_chiou@realtek.com>, Liam Girdwood <lgirdwood@gmail.com>, Jaroslav Kysela <perex@perex.cz>, Takashi Iwai <tiwai@suse.com> Cc: alsa-devel@alsa-project.org, linux-kernel@vger.kernel.org, Mark Brown <broonie@kernel.org> X-Mailer: b4 0.13-dev-00e42 X-Developer-Signature: v=1; a=openpgp-sha256; l=2318; i=broonie@kernel.org; h=from:subject:message-id; bh=VKteOqI+tR4jwGiz0s3/Zl8oDW+YNdx9hzGF1XdHEMo=; b=owEBbQGS/pANAwAKASTWi3JdVIfQAcsmYgBkSAxp2sZLL3hFa9KQamIgB5LVBhsaT19TwxKWmCMD E8FCPLiJATMEAAEKAB0WIQSt5miqZ1cYtZ/in+ok1otyXVSH0AUCZEgMaQAKCRAk1otyXVSH0EvYB/ 9/ZvgAOmb7RxPtTXmPAUyzGqnIhe1YiWSDe9ry8PqS9V7VZiMLecrPa8CkpyTNoZtR7CVaPtYytWDb vx/9GJhs4Ua9/zOHn7EnT6Kikg9H8TE7n1rnVU34v2JfiErArIEmS8533sHpSBjIZmIb2h/b4+EJyK UhEiCEeSPeVKzm63FP3iYRt/JP4rEmVkpaFyLwC5zLjKlAxq+LUa5LhAOWJzSAJaP7iTLNFu8lOwI/ t7R3yMY8nu7nPiq1R8wdGqGy3N6tLvc2iV4E2j0cxhTEb2haqkddl9pVgBMqo8X3BTg9p+2soikPdk Emn+XqqCZlUNtGQBKUbpcniduOQO8V X-Developer-Key: i=broonie@kernel.org; a=openpgp; fpr=3F2568AAC26998F9E813A1C5C3F436CA30F5D8EB X-Spam-Status: No, score=-4.6 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1764171352353695281?= X-GMAIL-MSGID: =?utf-8?q?1764171352353695281?= |
Series |
ASoC: rt5682: Use a maple tree based register cache
|
|
Commit Message
Mark Brown
April 25, 2023, 5:22 p.m. UTC
regmap has introduced a maple tree based register cache which makes use of
this more advanced data structure which has been added to the kernel
recently. Maple trees are much flatter than rbtrees, meaning that they do
not grow to such depths when the register map is sparse which makes access
a bit more efficient. The maple tree cache type is still a bit of a work
in progress but should be effective for some devices already.
RT5682 seems like a good candidate for maple tree. It only supports single
register read/write operations so will gain minimal benefit from storing
the register data in device native format like rbtree does (none for
SoundWire) and has some sparsity in the register map which is a good fit
for maple tree.
Convert to use maple tree. There should be little if any visible difference
at runtime.
Signed-off-by: Mark Brown <broonie@kernel.org>
---
sound/soc/codecs/rt5682-sdw.c | 2 +-
sound/soc/codecs/rt5682s.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
---
base-commit: 4a670ac3e75e517c96cbd01ef870dbd598c3ce71
change-id: 20230419-asoc-rt5682-maple-7da060991ca4
Best regards,
Comments
On 4/25/23 12:22, Mark Brown wrote: > regmap has introduced a maple tree based register cache which makes use of > this more advanced data structure which has been added to the kernel > recently. Maple trees are much flatter than rbtrees, meaning that they do > not grow to such depths when the register map is sparse which makes access > a bit more efficient. The maple tree cache type is still a bit of a work > in progress but should be effective for some devices already. > > RT5682 seems like a good candidate for maple tree. It only supports single > register read/write operations so will gain minimal benefit from storing > the register data in device native format like rbtree does (none for > SoundWire) and has some sparsity in the register map which is a good fit > for maple tree. > > Convert to use maple tree. There should be little if any visible difference > at runtime. Wondering if this is the root cause of the regression we're seeing in [1] on a Chromebook with rt5682 in SoundWire mode? I don't see any other changes to this codec driver and the first problem detected seemed to happen when we did an upstream merge last week. Unfortunately the last merge was on April 24 (sof-dev-rebase-20230424) which is just the day before this commit was added... [1] https://github.com/thesofproject/linux/issues/4371 > > Signed-off-by: Mark Brown <broonie@kernel.org> > --- > sound/soc/codecs/rt5682-sdw.c | 2 +- > sound/soc/codecs/rt5682s.c | 2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/sound/soc/codecs/rt5682-sdw.c b/sound/soc/codecs/rt5682-sdw.c > index 5f80a5d59b65..fb7951f11c92 100644 > --- a/sound/soc/codecs/rt5682-sdw.c > +++ b/sound/soc/codecs/rt5682-sdw.c > @@ -79,7 +79,7 @@ static const struct regmap_config rt5682_sdw_indirect_regmap = { > .max_register = RT5682_I2C_MODE, > .volatile_reg = rt5682_volatile_register, > .readable_reg = rt5682_readable_register, > - .cache_type = REGCACHE_RBTREE, > + .cache_type = REGCACHE_MAPLE, > .reg_defaults = rt5682_reg, > .num_reg_defaults = RT5682_REG_NUM, > .use_single_read = true, > diff --git a/sound/soc/codecs/rt5682s.c b/sound/soc/codecs/rt5682s.c > index 9c34dca58f54..36102fa2b806 100644 > --- a/sound/soc/codecs/rt5682s.c > +++ b/sound/soc/codecs/rt5682s.c > @@ -3046,7 +3046,7 @@ static const struct regmap_config rt5682s_regmap = { > .max_register = RT5682S_MAX_REG, > .volatile_reg = rt5682s_volatile_register, > .readable_reg = rt5682s_readable_register, > - .cache_type = REGCACHE_RBTREE, > + .cache_type = REGCACHE_MAPLE, > .reg_defaults = rt5682s_reg, > .num_reg_defaults = ARRAY_SIZE(rt5682s_reg), > .use_single_read = true, > > --- > base-commit: 4a670ac3e75e517c96cbd01ef870dbd598c3ce71 > change-id: 20230419-asoc-rt5682-maple-7da060991ca4 > > Best regards,
On Tue, May 23, 2023 at 02:24:53PM -0500, Pierre-Louis Bossart wrote: > Wondering if this is the root cause of the regression we're seeing in > [1] on a Chromebook with rt5682 in SoundWire mode? > I don't see any other changes to this codec driver and the first problem > detected seemed to happen when we did an upstream merge last week. > Unfortunately the last merge was on April 24 (sof-dev-rebase-20230424) > which is just the day before this commit was added... Try a revert?
On 5/23/23 14:28, Mark Brown wrote: > On Tue, May 23, 2023 at 02:24:53PM -0500, Pierre-Louis Bossart wrote: > >> Wondering if this is the root cause of the regression we're seeing in >> [1] on a Chromebook with rt5682 in SoundWire mode? > >> I don't see any other changes to this codec driver and the first problem >> detected seemed to happen when we did an upstream merge last week. >> Unfortunately the last merge was on April 24 (sof-dev-rebase-20230424) >> which is just the day before this commit was added... > > Try a revert? I can try, unfortunately that device is not directly testable with a simple PR test so it'll take time. I was just hoping that someone smarter than me had an explanation on the locking issue. We only use interrupt threads and workqueues, not sure why sleeping is an issue.
On Tue, May 23, 2023 at 02:24:53PM -0500, Pierre-Louis Bossart wrote: > I don't see any other changes to this codec driver and the first problem > detected seemed to happen when we did an upstream merge last week. > Unfortunately the last merge was on April 24 (sof-dev-rebase-20230424) > which is just the day before this commit was added... Try this: From 5953e9de359674ff2d95fe4c241bc7880d6d0d82 Mon Sep 17 00:00:00 2001 From: Mark Brown <broonie@kernel.org> Date: Tue, 23 May 2023 20:40:22 +0100 Subject: [PATCH] regmap: maple: Drop the RCU read lock while syncing registers Unfortunately the maple tree requires us to explicitly lock it so we need to take the RCU read lock while iterating. When syncing this means that we end up trying to write out register values while holding the RCU read lock which triggers lockdep issues since that is an atomic context but most buses can't be used in atomic context. Pause the iteration and drop the lock for each register we check to avoid this. Reported-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by: Mark Brown <broonie@kernel.org> --- drivers/base/regmap/regcache-maple.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/base/regmap/regcache-maple.c b/drivers/base/regmap/regcache-maple.c index 2d2d5d7ee447..14f6f49af097 100644 --- a/drivers/base/regmap/regcache-maple.c +++ b/drivers/base/regmap/regcache-maple.c @@ -203,15 +203,18 @@ static int regcache_maple_sync(struct regmap *map, unsigned int min, mas_for_each(&mas, entry, max) { for (r = max(mas.index, lmin); r <= min(mas.last, lmax); r++) { + mas_pause(&mas); + rcu_read_unlock(); ret = regcache_sync_val(map, r, entry[r - mas.index]); if (ret != 0) goto out; + rcu_read_lock(); } } -out: rcu_read_unlock(); +out: map->cache_bypass = false; return ret;
diff --git a/sound/soc/codecs/rt5682-sdw.c b/sound/soc/codecs/rt5682-sdw.c index 5f80a5d59b65..fb7951f11c92 100644 --- a/sound/soc/codecs/rt5682-sdw.c +++ b/sound/soc/codecs/rt5682-sdw.c @@ -79,7 +79,7 @@ static const struct regmap_config rt5682_sdw_indirect_regmap = { .max_register = RT5682_I2C_MODE, .volatile_reg = rt5682_volatile_register, .readable_reg = rt5682_readable_register, - .cache_type = REGCACHE_RBTREE, + .cache_type = REGCACHE_MAPLE, .reg_defaults = rt5682_reg, .num_reg_defaults = RT5682_REG_NUM, .use_single_read = true, diff --git a/sound/soc/codecs/rt5682s.c b/sound/soc/codecs/rt5682s.c index 9c34dca58f54..36102fa2b806 100644 --- a/sound/soc/codecs/rt5682s.c +++ b/sound/soc/codecs/rt5682s.c @@ -3046,7 +3046,7 @@ static const struct regmap_config rt5682s_regmap = { .max_register = RT5682S_MAX_REG, .volatile_reg = rt5682s_volatile_register, .readable_reg = rt5682s_readable_register, - .cache_type = REGCACHE_RBTREE, + .cache_type = REGCACHE_MAPLE, .reg_defaults = rt5682s_reg, .num_reg_defaults = ARRAY_SIZE(rt5682s_reg), .use_single_read = true,