From: Andrey Golovko <andrey.golovko@gmail.com>
To: Pierre-Louis Bossart <pierre-louis.bossart@linux.dev>,
Robin Everaars <robineveraars@pm.me>
Cc: shenghao-ding@ti.com, kevin-lu@ti.com, baojun.xu@ti.com,
niranjan.hy@ti.com, broonie@kernel.org, lgirdwood@gmail.com,
linux-sound@vger.kernel.org, ckeepax@opensource.cirrus.com,
mstrozek@opensource.cirrus.com, yung-chuan.liao@linux.intel.com,
vkoul@kernel.org, Vijendar.Mukunda@amd.com,
peter.ujfalusi@linux.intel.com, sen@ti.com,
nealstarkie@gmail.com, bjuraszewski@gmail.com,
Antoine Monnet <antoine@montane.tech>,
linux-kernel@vger.kernel.org
Subject: Re: [BUG] ASoC: tas2783-sdw: every amp on the link selects the same channel, so a two-amp board plays mono
Date: Fri, 07 Aug 2026 08:21:57 +0300 [thread overview]
Message-ID: <a3fb7ef6957612f6eb2edb209fcbb07b@gmail.com> (raw)
In-Reply-To: <39194f6b-2613-42a3-a857-702889add03d@linux.dev>
On 8/6/26 22:30, Pierre-Louis Bossart wrote:
> Maybe the mapping is implicit and defined by the Unique Number
>
> I am not sure though how that Unique Number maps to the -1 and -2 suffix
>
> sdw:0:1:0102:0000:01:8 TAS2783, device_number 3, slave-tas2783
> sdw:0:1:0102:0000:01:b TAS2783, device_number 2, slave-tas2783
>
> which one is left and which one is right?
Measured on a second HN7306EAC (I'm the andrey.golovko in Cc - same
machine, same two amps at unique ID 0x8/0xB): 0x8 is the left speaker,
0xB the right. Confirmed by muting each amp's volume control in turn,
and by speaker-test with a per-amp one-channel mask applied: channel 1
comes out of the physically left speaker only, channel 2 out of the
right only. That matches Robin's amp 1 = left, amp 2 = right.
The Unique Number to -1/-2 suffix mapping is not implicit - it is
hardcoded in the kernel's machine descriptor. amd-acp70-acpi-match.c
has, for exactly this platform (rt721_l1u0_tas2783x2_l1u8b_adr):
.adr = 0x0001380102000001 -> .name_prefix = "tas2783-1", spk_l_endpoint
.adr = 0x00013B0102000001 -> .name_prefix = "tas2783-2", spk_r_endpoint
where spk_l_endpoint/spk_r_endpoint are aggregated endpoints with
group_position 0 and 1. So a channel-to-peripheral binding does exist
in the tree, keyed off the _ADR unique ID and complete with a
left/right position - it is just not plumbed into playback port
allocation: nothing turns group_position into a per-peripheral mask or
offset. device_number (2/3 here) is attach order and indeed cannot be
relied on; the unique ID via the match table can.
For cross-reference: the same mono issue on this machine was reported
in July by Antoine Monnet (added to Cc), with an inline patch of the
same shape as Robin's - per-amp one-channel mask derived from the
name_prefix suffix:
https://lore.kernel.org/all/778f017a-e1c2-4ab6-9968-6e4c6285180b@montane.tech/
I have been running it since late July with correct physical L/R on my
unit (Tested-by in that thread). Robin's finding that the mask value
is ignored and only its weight matters applies to that patch equally:
it works because the DAI-link codec order follows the adr_d table
order above, which happens to match the speakers. Given that the
descriptor already carries group_position per unique ID, deriving the
assignment from that rather than from parsing the name_prefix suffix
looks like the natural fix, and it would keep working if enumeration
order ever changed.
Thanks,
Andrey
prev parent reply other threads:[~2026-08-07 5:22 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-05 18:35 [BUG] ASoC: tas2783-sdw: every amp on the link selects the same channel, so a two-amp board plays mono Robin Everaars
2026-08-06 8:47 ` Pierre-Louis Bossart
2026-08-06 18:43 ` Robin Everaars
2026-08-06 20:30 ` Pierre-Louis Bossart
2026-08-07 5:21 ` Andrey Golovko [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=a3fb7ef6957612f6eb2edb209fcbb07b@gmail.com \
--to=andrey.golovko@gmail.com \
--cc=Vijendar.Mukunda@amd.com \
--cc=antoine@montane.tech \
--cc=baojun.xu@ti.com \
--cc=bjuraszewski@gmail.com \
--cc=broonie@kernel.org \
--cc=ckeepax@opensource.cirrus.com \
--cc=kevin-lu@ti.com \
--cc=lgirdwood@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-sound@vger.kernel.org \
--cc=mstrozek@opensource.cirrus.com \
--cc=nealstarkie@gmail.com \
--cc=niranjan.hy@ti.com \
--cc=peter.ujfalusi@linux.intel.com \
--cc=pierre-louis.bossart@linux.dev \
--cc=robineveraars@pm.me \
--cc=sen@ti.com \
--cc=shenghao-ding@ti.com \
--cc=vkoul@kernel.org \
--cc=yung-chuan.liao@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox