Message ID | 20230523154605.4284-1-srinivas.kandagatla@linaro.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 b10csp2251093vqo; Tue, 23 May 2023 09:04:32 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ5+MbBmNDrXoVnwW2SYS32Oy1/YcegcQ6E9tcvIQ/cFRigkGiXKWV/cJk1TW3kckg7FGnGU X-Received: by 2002:a17:90a:cb09:b0:250:78d0:f78c with SMTP id z9-20020a17090acb0900b0025078d0f78cmr16048300pjt.9.1684857871966; Tue, 23 May 2023 09:04:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1684857871; cv=none; d=google.com; s=arc-20160816; b=oOnfhSaNnQJNUX7ohhvuz8Fgk3OouBxkAxIZbaXiNwfm+dlnLXD3YPClFrfdpAkcOH +1e0X3fpvhgDNQmjVOwSqAQ7KfhZL1lC75hzw4udz6e1kG4O/u1jRAineFPXAdcvfduH +JYcvykwdE2KwpxIXOqEstH2OMnRZ8GZbM7b8zNyzZdQo5csb+TAtkqvNLapLM/O00fx Y8xH04s1A52ZCGoAmNZ6HsLpMQxtcEWMdkklCgBNA3ufFG/P8uG/UI4CgUbiIxZYWeqs 4bDMRGDnp3XexWrw4pbd9hWTc9ks0lowDHlUo+RLrHFYPGX6Xyk1S2D8DfY1X+oaeoBb /Itg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=PfRw2ALokx9vLy8rQUgzg1qNBvtdQEE/4htl4GPyFIo=; b=REOqTWXaJmdITfxlc5HlCZNBhEELhkB+cpHeKFVcBtm9hpNjtbWm36bF2XRw1FyOy+ t3gIbIfHhBUZxN6yfv2/D3/hzq9LDfK1ZD1idqbmZ4XM8rkQizqqPmFMD2kyHFpWErZM tYZqZJIWQKJ2TqW20wwXUkDXoDXgfFKRgRGAGFjwE6yDSohC7zxEO9g0sdtzz1EghmXN 9oDFzhmqWESIaroC1ZE5/vUQUragW9pL5WYQ2y242aoBf6lrGdy9xBcz/1mONUC9sZ/w S2PwRhc2E1FfBPRMmN7SpJt9jl+rusbienu56sV6Pu1eS5rc0/w94mWQbgKIIMj4vSQe QyNw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=nWNoA6Sj; 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=linaro.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id e4-20020a17090a4a0400b002537224e05esi8524003pjh.62.2023.05.23.09.04.16; Tue, 23 May 2023 09:04:31 -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=@linaro.org header.s=google header.b=nWNoA6Sj; 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=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230207AbjEWPq3 (ORCPT <rfc822;ahmedalshaiji.dev@gmail.com> + 99 others); Tue, 23 May 2023 11:46:29 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48102 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237029AbjEWPq2 (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 23 May 2023 11:46:28 -0400 Received: from mail-wm1-x332.google.com (mail-wm1-x332.google.com [IPv6:2a00:1450:4864:20::332]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 09A0F126 for <linux-kernel@vger.kernel.org>; Tue, 23 May 2023 08:46:25 -0700 (PDT) Received: by mail-wm1-x332.google.com with SMTP id 5b1f17b1804b1-3f6042d60b5so26592645e9.2 for <linux-kernel@vger.kernel.org>; Tue, 23 May 2023 08:46:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1684856783; x=1687448783; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=PfRw2ALokx9vLy8rQUgzg1qNBvtdQEE/4htl4GPyFIo=; b=nWNoA6Sjt7sar6bT5Wo7aS7Yc7m34FIb/IPgWD81u2XmfxqZy8KlLpQjOWv16/jon5 r9ollhVW6YH7NfbuUpGGiFI2PoQsBLoeInpaFEAFlbMtNr/hC+EMEAcNhtOpzJEyLd54 7C+AXOqYLclUAvF/sNsb2Bph/vJoPsj+7wFJnrV9n36DSEjRrJ5DivQ7lCMZJVhG2E+x osQRnx+JV6XS7XazzwU6kFsLuDGgV0o3IEblDcwD6iDseVAZKJZb3xcMuuydJ0O53+D/ 1kAnyuwPYstnRQs46f5u26CXhFu20A3z+IeYSdm+azQaZs3NGE6eO/K3Ila8h2n5Gpqw TGZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684856783; x=1687448783; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=PfRw2ALokx9vLy8rQUgzg1qNBvtdQEE/4htl4GPyFIo=; b=D4XUvtloPLKjl2q/JBCf70HeDGaZ+DMeUAGMtyGBHnUeIwTilw2UXjqGGMp1SXjEpo v4L4W7+Ls4T0peGpUNutVGQUxPCV2nRtIhIuoFnpdlXuzVTAvs16q6eRmky2Jo/C2xeC keiwg3VheIH3z8Cs4HK4JtsRfOM+bFY1iExEB8RYj7560+1xAO0BOLn5a2MO9hkNqAVV mBBeQ6cjO20lQQLKSRlyPG22SaAjkA3BY/1TxBLJD5qs5UBlCCEyErml5sOd0xuZuc3Z JVVw5oMNqZE4jtagRoBY/oRQK7nXmtELumrSUDiQyaLwo3hyglc5RKDlgBwLCsh0ANTq sMrQ== X-Gm-Message-State: AC+VfDyh29ZCHj0oLyTbk8lFw35WizHBDaY8JJNlX0R9a6PKJQ9vsXI/ AcPVWl+jBCJ+HNTFn6uqKbVTgg== X-Received: by 2002:a1c:e905:0:b0:3f5:fbd0:94ab with SMTP id q5-20020a1ce905000000b003f5fbd094abmr7809138wmc.3.1684856783483; Tue, 23 May 2023 08:46:23 -0700 (PDT) Received: from localhost.localdomain ([5.133.47.210]) by smtp.gmail.com with ESMTPSA id f4-20020a1c6a04000000b003f1978bbcd6sm3374063wmc.3.2023.05.23.08.46.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 23 May 2023 08:46:22 -0700 (PDT) From: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> To: broonie@kernel.org Cc: perex@perex.cz, tiwai@suse.com, lgirdwood@gmail.com, ckeepax@opensource.cirrus.com, kuninori.morimoto.gx@renesas.com, linux-kernel@vger.kernel.org, pierre-louis.bossart@linux.intel.com, alsa-devel@alsa-project.org, Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Subject: [PATCH 1/2] ASoC: codecs: wsa883x: do not set can_multi_write flag Date: Tue, 23 May 2023 16:46:04 +0100 Message-Id: <20230523154605.4284-1-srinivas.kandagatla@linaro.org> X-Mailer: git-send-email 2.21.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=1.2 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, RCVD_IN_SBL_CSS,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.6 X-Spam-Level: * 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?1766701527881404111?= X-GMAIL-MSGID: =?utf-8?q?1766701527881404111?= |
Series |
[1/2] ASoC: codecs: wsa883x: do not set can_multi_write flag
|
|
Commit Message
Srinivas Kandagatla
May 23, 2023, 3:46 p.m. UTC
regmap-sdw does not support multi register writes, so there is
no point in setting this flag. This also leads to incorrect
programming of WSA codecs with regmap_multi_reg_write() call.
This invalid configuration should have been rejected by regmap-sdw.
Fixes: 43b8c7dc85a1 ("ASoC: codecs: add wsa883x amplifier support")
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
---
sound/soc/codecs/wsa883x.c | 1 -
1 file changed, 1 deletion(-)
Comments
On Tue, May 23, 2023 at 04:46:04PM +0100, Srinivas Kandagatla wrote: > regmap-sdw does not support multi register writes, so there is > no point in setting this flag. This also leads to incorrect > programming of WSA codecs with regmap_multi_reg_write() call. > This invalid configuration should have been rejected by regmap-sdw. Does the CODEC support mulitple writes? If so it seems better to leave the flag set and just do the appropriate fix in the regmap code until such time as it's updated to be able to exercise it.
On 23/05/2023 17:55, Mark Brown wrote: > On Tue, May 23, 2023 at 04:46:04PM +0100, Srinivas Kandagatla wrote: >> regmap-sdw does not support multi register writes, so there is >> no point in setting this flag. This also leads to incorrect >> programming of WSA codecs with regmap_multi_reg_write() call. > >> This invalid configuration should have been rejected by regmap-sdw. > > Does the CODEC support mulitple writes? If so it seems better to leave No, the codec itself does not support multi-write. All the codec register level interface is via SoundWire Bus. which also does not support with the existing code. --srini > the flag set and just do the appropriate fix in the regmap code until > such time as it's updated to be able to exercise it.
On Wed, May 24, 2023 at 09:51:00AM +0100, Srinivas Kandagatla wrote: > On 23/05/2023 17:55, Mark Brown wrote: > > Does the CODEC support mulitple writes? If so it seems better to leave > No, the codec itself does not support multi-write. All the codec register > level interface is via SoundWire Bus. which also does not support with the > existing code. I'm unclear, is this a limitation of the hardware or of the current Soundwire code?
On 24/05/2023 09:57, Mark Brown wrote: > On Wed, May 24, 2023 at 09:51:00AM +0100, Srinivas Kandagatla wrote: >> On 23/05/2023 17:55, Mark Brown wrote: > >>> Does the CODEC support mulitple writes? If so it seems better to leave > >> No, the codec itself does not support multi-write. All the codec register >> level interface is via SoundWire Bus. which also does not support with the >> existing code. > > I'm unclear, is this a limitation of the hardware or of the current > Soundwire code? Its both. Codec itself does not have any private write callback to support this and AFAIU Qualcomm Soundwire controller does not have any such hw facility to program multi-registers for device at one shot. Also to note, the current state of code soundwire regmap write callback assumes that the request to write will always have base address at the start followed by register values. This is not true for multi-register writes which comes in address-value-padding pairs. Am confused on the multi_write feature and looking at regmap bus level write callback. Is write callback used for both Bulk writes and multi-writes? Is multi-write feature of regmap bus or device? --srini
On Wed, May 24, 2023 at 10:42:21AM +0100, Srinivas Kandagatla wrote: > On 24/05/2023 09:57, Mark Brown wrote: > > I'm unclear, is this a limitation of the hardware or of the current > > Soundwire code? > Its both. > Codec itself does not have any private write callback to support this and > AFAIU Qualcomm Soundwire controller does not have any such hw facility to > program multi-registers for device at one shot. How about the *CODEC* hardware? > Is write callback used for both Bulk writes and multi-writes? Only multi-write at this point but we probably should consider redoing bulk writes to use it as well. > Is multi-write feature of regmap bus or device? Well, I don't think any buses that understand registers have implemented it yet but there's nothing fundamental that means that a bus couldn't usefully do something with multi-write. The current users all use raw buses that don't know anything about registers or values.
On 24/05/2023 10:48, Mark Brown wrote: > On Wed, May 24, 2023 at 10:42:21AM +0100, Srinivas Kandagatla wrote: >> On 24/05/2023 09:57, Mark Brown wrote: > >>> I'm unclear, is this a limitation of the hardware or of the current >>> Soundwire code? > >> Its both. > >> Codec itself does not have any private write callback to support this and >> AFAIU Qualcomm Soundwire controller does not have any such hw facility to >> program multi-registers for device at one shot. > > How about the *CODEC* hardware? > No, Codec does not have any such interface to write to device registers directly without going via Soundwire. >> Is write callback used for both Bulk writes and multi-writes? > > Only multi-write at this point but we probably should consider redoing > bulk writes to use it as well. By the looks of the code, its other way around. > >> Is multi-write feature of regmap bus or device? > > Well, I don't think any buses that understand registers have implemented > it yet but there's nothing fundamental that means that a bus couldn't > usefully do something with multi-write. The current users all use raw > buses that don't know anything about registers or values.
On Wed, May 24, 2023 at 11:09:32AM +0100, Srinivas Kandagatla wrote: > On 24/05/2023 10:48, Mark Brown wrote: > > > Is write callback used for both Bulk writes and multi-writes? > > Only multi-write at this point but we probably should consider redoing > > bulk writes to use it as well. > By the looks of the code, its other way around. No, that's not possible. A bulk write requires a contiguous block of registers so can be expressed in terms of a multi-write but a write with discontiguous registers can't be done as a bulk write.
On Tue, 23 May 2023 16:46:04 +0100, Srinivas Kandagatla wrote: > regmap-sdw does not support multi register writes, so there is > no point in setting this flag. This also leads to incorrect > programming of WSA codecs with regmap_multi_reg_write() call. > > This invalid configuration should have been rejected by regmap-sdw. > > > [...] Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next Thanks! [1/2] ASoC: codecs: wsa883x: do not set can_multi_write flag commit: 40ba0411074485e2cf1bf8ee0f3db27bdff88394 [2/2] ASoC: codecs: wsa881x: do not set can_multi_write flag commit: 6e7a6d4797ef521c0762914610ed682e102b9d36 All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark
On Wed, May 24, 2023 at 12:28:10PM +0100, Mark Brown wrote: > On Tue, 23 May 2023 16:46:04 +0100, Srinivas Kandagatla wrote: > > regmap-sdw does not support multi register writes, so there is > > no point in setting this flag. This also leads to incorrect > > programming of WSA codecs with regmap_multi_reg_write() call. > > > > This invalid configuration should have been rejected by regmap-sdw. > > > > > > [...] > > Applied to > > https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next > > Thanks! > > [1/2] ASoC: codecs: wsa883x: do not set can_multi_write flag > commit: 40ba0411074485e2cf1bf8ee0f3db27bdff88394 > [2/2] ASoC: codecs: wsa881x: do not set can_multi_write flag > commit: 6e7a6d4797ef521c0762914610ed682e102b9d36 These were merged for 6.5 but the corresponding sanity check for regmap has now been included in 6.4-rc5 which consequently breaks these codecs (similar for wcd938x-sdw): [ 11.443485] wsa883x-codec sdw:0:0217:0202:00:1: error -ENOTSUPP: regmap_init failed [ 11.443525] wsa883x-codec sdw:0:0217:0202:00:1: Probe of wsa883x-codec failed: -524 [ 11.443554] wsa883x-codec: probe of sdw:0:0217:0202:00:1 failed with error -52 Is it possible to get also these fixes into 6.4 final? Johan
On Mon, Jun 05, 2023 at 10:08:34AM +0200, Johan Hovold wrote:
> Is it possible to get also these fixes into 6.4 final?
They're already queued for 6.4.
On Mon, Jun 05, 2023 at 01:24:04PM +0100, Mark Brown wrote: > On Mon, Jun 05, 2023 at 10:08:34AM +0200, Johan Hovold wrote: > > > Is it possible to get also these fixes into 6.4 final? > > They're already queued for 6.4. Indeed they are. Your patch-applied message said "Applied to ... for-next" and I didn't check your repo before reporting. Sorry about the noise. Johan
diff --git a/sound/soc/codecs/wsa883x.c b/sound/soc/codecs/wsa883x.c index b83b5b0d4bab..2faf66c60703 100644 --- a/sound/soc/codecs/wsa883x.c +++ b/sound/soc/codecs/wsa883x.c @@ -946,7 +946,6 @@ static struct regmap_config wsa883x_regmap_config = { .writeable_reg = wsa883x_writeable_register, .reg_format_endian = REGMAP_ENDIAN_NATIVE, .val_format_endian = REGMAP_ENDIAN_NATIVE, - .can_multi_write = true, .use_single_read = true, };