From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-lf1-f50.google.com (mail-lf1-f50.google.com [209.85.167.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7F98D374169 for ; Sat, 15 Aug 2026 11:37:06 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.167.50 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786793828; cv=none; b=D+2GidD99pdAvMXYTczQvcPKbwrZsZQfrbeS0FTf1q/QxSTpJtRN0WOHArfnnhhRQglDFGfkpdqiJKx6v4Uf9a636Sz1hwVziaHMKgIH3KcmU50crCiEhPEiNZ1XTq7SgV46J6ClBT3/HAWcKNilu1HtGnZF9J76bkLhLOfIAz0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786793828; c=relaxed/simple; bh=tQJ0i1MfjTGpgskD8LkZJQe8cZ1L34361W7BOazpZNI=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=Ergi+N5OLinXINGnMJe4QMuZa0s0xJnydqZoOP03CoJcU7CPBkcHCIQkB78vgcfrya1f+FTOosxzRyz6kA37/6DTzLII4h18bqH84yxM0d5Mva93QxzkaFXm36hK2j9AFr7/h75JZuZzO7WrzqQlw85zKxX86qW43VLEYjAFUtE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=TZNGZHV4; arc=none smtp.client-ip=209.85.167.50 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="TZNGZHV4" Received: by mail-lf1-f50.google.com with SMTP id 2adb3069b0e04-5aeb8c19017so2392514e87.0 for ; Sat, 15 Aug 2026 04:37:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1786793824; x=1787398624; darn=vger.kernel.org; h=content-transfer-encoding:content-type:mime-version:references :in-reply-to:message-id:date:subject:cc:to:from:from:to:cc:subject :date:message-id:reply-to:content-type; bh=G8DJOAERut18sMiiQSBR+SS27P0WTvLv9LFTZmBTo+E=; b=TZNGZHV40LXxHRBx0w3bzrQMcT8Y0YeKXHRlmJkMdx7ZmxH2IbNiTyt+tJg1VPMQjo JGzCfXcF4FTTi64Y+s0qo6XPa89T6f3inPJ7U/E+TU0wTaQkOCRFnM2b10WDMSVAZ2LH 96AkUokn8GbWvf9wlSWiCHmRMnwQal8qoIfwUod+GzWdv/cBX717aQX9FNtWikxomMPF 5TZcO4COCCY7yeeOl6sCVyJTXeKD3KZszM7tFkrVqpQtgs/+1sXnMcfBA3GxLz4g467h 3mXB9ixi4LxvBRt7JZi5eU1UcOI8b/+zeMxIEKlq4F2w4lK8qoFW/fj/2QcgpyfW08EL V9yg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786793824; x=1787398624; h=content-transfer-encoding:content-type:mime-version:references :in-reply-to:message-id:date:subject:cc:to:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=G8DJOAERut18sMiiQSBR+SS27P0WTvLv9LFTZmBTo+E=; b=PVe7OS11GGAJogB4WQq4Gn7pVxwtqQDQLdVsPkx84wL8fLEeNdY+lBC7SKBAbAj20h 2XB7ENqYnllBM4znmqr4y7/nyIbzqUSNGHvjwbc/RZ69gNpsrJgW5xXyN1hDWCHUJVAS OIfdI+zSsYieEGbVIwvcnRzvwEEqDr1HK4z9ZoLq1BsmP/KHOf0LY7O7iViGPMxCy3RM 27LSGYoEOuLfl6cDkxEdoaU/uq87HL2LoKIkUBiBcugHzCd6b/pizKJl22yaU6ehtyDu UFGopxL16ZPLZKYmko1dGz9ENZ9x5pqbFNpHK8wm/mIPS01fVD/qKWAKvdKt1syYiOwU 5sqw== X-Forwarded-Encrypted: i=1; AHgh+RonA6YNNHuJFJLuFNn1t6ndu5mSRXRAnQYuZGBAQBS+WgG11cObyiOjPCp1AWLEwqIHAEvfC++qTAwVmXA=@vger.kernel.org X-Gm-Message-State: AOJu0YxVatitoAGTabgeNMCb6e+6XgI6cPnP11da4uWP0K4Ql4CVi+LF exeL8CoMVXMtRT8Fn/893vKq2UfmJWLH6o2VyqjFbMv7LsS+gEvfZwXF X-Gm-Gg: AR+sD10Cjvl0X7GEZT6psgSJ9JNnovaTPzksu1Xs22tXjO0bEh3YJz60F/ExqWFvSTf 0kTTSpwR5gLFRSUNND0l1vQVkmr3/V99FiG35pYDBaOwnWtZv+/P2G631a43VYSqvwoxsnOT4kv 3XqmNZXlCoNX0s9vtXuZX6dM6AghZVU+lN/lnj4YhOi7daE2MviMuUT7Ow2ut62ZzeHmM8QN5Qk 243q4Bik73HWfKplds3XMQHRQF4PD5rxYOYCBB7SIz4DI2hU+JzbNhQ7EBrMH44icbhWo/+7Xal kJrXC5kQIYU6nshcBgLeQPTGcNmA1/o3AiBxhPEZ2qTtcF1Zhtp6R2MYhXs47fvt7UkuJtRckoy bd+IxT1mTqsaVzFokArwmbSnRDO4+P6Fhq8RfrgFninfcmSzYQkKtKVv6nQlFQ64ht7cgB/o3yf S227h3rtl3PJblLlP3vNzkrn5yT2HbdZlDyiQl6bWzm3w1pZQIXkhMmAPq2hOAwuIvJTD0lrN0Z A/Iys5iQhYWa/cFUMjWs5ag+BAkgEQ9xw== X-Received: by 2002:a05:6512:39c9:b0:5b1:4e5e:559c with SMTP id 2adb3069b0e04-5b45913b876mr2072844e87.30.1786793824145; Sat, 15 Aug 2026 04:37:04 -0700 (PDT) Received: from localhost (host-80-73-162-2.rev.as20985.net. [80.73.162.2]) by smtp.gmail.com with ESMTPSA id 2adb3069b0e04-5b458c0ab08sm1070598e87.73.2026.08.15.04.37.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 15 Aug 2026 04:37:03 -0700 (PDT) From: Andrey Golovko To: Shenghao Ding , Kevin Lu , Baojun Xu , Sen Wang , Liam Girdwood , Mark Brown , Jaroslav Kysela , Takashi Iwai Cc: "Holalu Yogendra, Niranjan" , Pierre-Louis Bossart , Charles Keepax , Vijendar Mukunda , Antoine Monnet , Robin Everaars , Ville Saarinen , linux-sound@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH v3 1/2] ASoC: tas2783-sdw: make multi-byte MBQ registers reachable Date: Sat, 15 Aug 2026 14:40:00 +0300 Message-ID: <20260815112000.4180-2-andrey.golovko@gmail.com> In-Reply-To: <20260815112000.4180-1-andrey.golovko@gmail.com> References: <20260815112000.4180-1-andrey.golovko@gmail.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit tas2783_sdca_mbq_size() declares registers of one, two and four bytes, but the regmap is created with val_bits = 8. The SoundWire MBQ bus rejects any register whose declared size exceeds the configured value width: ctx->val_size = config->val_bits / BITS_PER_BYTE; ... size = ctx->cfg.mbq_size(ctx->dev, reg); if (!size || size > ctx->val_size) return -EINVAL; Both regmap_sdw_mbq_read() and regmap_sdw_mbq_write() bail out on that, so every register the driver itself declares as two or four bytes wide is unreachable through the regmap, in both directions, and the failure happens before anything reaches the bus. That is measurable. On an ASUS ProArt PX13 HN7306EAC with two TAS2783 aggregated on one link, a regmap read of XU22 Control 0x07, declared two bytes, and of XU22 Control 0x12, declared four bytes, returns -EINVAL on both amplifiers. With val_bits widened the same reads reach the peripheral, which answers -ENODATA for both, powered or not - this part appears not to implement them. So the change makes the registers addressable; whether a given peripheral answers is up to the peripheral. Widen val_bits to cover the largest size the callback returns. The callback keeps deciding the size of each individual transfer, so single-byte registers are unaffected. The calibration path needs adjusting along with it. regmap_bulk_write(..., buf, sizeof(u32)) relied on val_bits = 8 to spread one calibration value over four consecutive single-byte registers; with a four-byte value width the same call would ask for four four-byte values and read past the end of the four-byte buffer. Write the four registers explicitly instead, keeping the most-significant-byte -first layout. Read back over the bus, bypassing the cache, the five calibration values of both amplifiers are byte for byte what they were before this patch. What this does not do is repair regcache_sync(). On this machine a sync aborts earlier, at a single-byte Control - the FU23 Mute of channel 0, which tas2783_reg_default[] gives 0x1 while the driver's init sequence writes 0x00, so the sync tries to restore it and the peripheral answers -ENODATA - and no multi-byte register is reached at all. Signed-off-by: Andrey Golovko --- v3: new in this revision. Written on 28 July, held back until the read-only Control patches settled; it is the answer to Mark's question on v2 2/2, which cannot stand without it. sound/soc/codecs/tas2783-sdw.c | 37 +++++++++++++++++++++++++--------- 1 file changed, 28 insertions(+), 9 deletions(-) diff --git a/sound/soc/codecs/tas2783-sdw.c b/sound/soc/codecs/tas2783-sdw.c index caf8fe1bf4db..b657ad031306 100644 --- a/sound/soc/codecs/tas2783-sdw.c +++ b/sound/soc/codecs/tas2783-sdw.c @@ -564,7 +564,13 @@ static bool tas2783_volatile_register(struct device *dev, u32 reg) static const struct regmap_config tas_regmap = { .reg_bits = 32, - .val_bits = 8, + /* + * tas2783_sdca_mbq_size() declares registers of one, two and four + * bytes. val_bits has to cover the widest of those: the SoundWire MBQ + * bus rejects any register whose declared size exceeds val_bits, which + * would make every multi-byte register unreachable in both directions. + */ + .val_bits = 32, .readable_reg = tas2783_readable_register, .writeable_reg = tas2783_writeable_register, .volatile_reg = tas2783_volatile_register, @@ -667,9 +673,9 @@ static s32 tas2783_validate_calibdata(struct tas2783_prv *tas_dev, static void tas2783_set_calib_params_to_device(struct tas2783_prv *tas_dev, u32 *cali_data) { - u32 dev_count, offset, i, device_num; + u32 dev_count, offset, i, j, device_num; u32 reg_value; - u8 buf[4]; + s32 ret; dev_count = cali_data[1]; offset = 3; @@ -683,12 +689,25 @@ static void tas2783_set_calib_params_to_device(struct tas2783_prv *tas_dev, u32 for (i = 0; i < ARRAY_SIZE(tas2783_cali_reg); i++) { reg_value = cali_data[offset + i]; - buf[0] = reg_value >> 24; - buf[1] = reg_value >> 16; - buf[2] = reg_value >> 8; - buf[3] = reg_value & 0xff; - regmap_bulk_write(tas_dev->regmap, tas2783_cali_reg[i], - buf, sizeof(u32)); + + /* + * A calibration value occupies four consecutive + * single-byte registers, most significant byte first. + * Write them one by one: these registers are declared + * as one byte wide by tas2783_sdca_mbq_size(), so a + * multi-byte regmap access would not match the layout. + */ + for (j = 0; j < sizeof(u32); j++) { + ret = regmap_write(tas_dev->regmap, + tas2783_cali_reg[i] + j, + (reg_value >> (24 - 8 * j)) & 0xff); + if (ret) { + dev_err(tas_dev->dev, + "calib write to 0x%x failed, err=%d\n", + tas2783_cali_reg[i] + j, ret); + break; + } + } } break; } -- 2.53.0