ASoC: tas2783-sdw: make multi-byte MBQ registers reachable

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 <andrey.golovko@gmail.com>
Link: https://patch.msgid.link/20260815112000.4180-2-andrey.golovko@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>

0 files changed, 0 insertions, 0 deletions