From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-lj1-f171.google.com (mail-lj1-f171.google.com [209.85.208.171]) (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 47BB23FE652 for ; Wed, 12 Aug 2026 21:33:33 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.208.171 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786570415; cv=none; b=G61/rtPDAGA5y2FHSa6Ygg3aGdFqkK39uyXely55wISGydarkXNnvpzhVYvwi0EDmqlXtorXgdjRhbEPGjrHcZCBZtqROQAdeVJW7voUKWHRxYvNlqAno2SXu1A7hKMKj66Yng082qIjQjoJ7UdqqUkJaa6nQCkj1ph9xh8XH2Y= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786570415; c=relaxed/simple; bh=+ZPA8DnnnB+hEEU/UVSTgEQF5+XXyjqbGyFW2zrE6jw=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: MIME-Version:Content-Type; b=fgIsY7+TcYIxw+Gs7/eX6FSUJJZi+/THpd9XXKYtxZaBqHIHPq93oVUsQ72cTlJsRfNIelLX42YOYfgFx0dG090y3+FXXIuvZLKdK2szbU56Md+s3ZHhVzEEoGJC4+UFJk4Uq7PvmPN9iflw6O3q/awANoCB0rctzDrxCS6trQQ= 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=CefHtLJS; arc=none smtp.client-ip=209.85.208.171 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="CefHtLJS" Received: by mail-lj1-f171.google.com with SMTP id 38308e7fff4ca-39c953950dfso14351921fa.1 for ; Wed, 12 Aug 2026 14:33:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1786570411; x=1787175211; darn=vger.kernel.org; h=content-transfer-encoding:content-type:mime-version:references :in-reply-to:subject:cc:to:from:message-id:date:from:to:cc:subject :date:message-id:reply-to:content-type; bh=9nHTuE7AAYCFKX7KeTMghSgjvrUE2Rt+zw5zVdxCuNw=; b=CefHtLJSkxwImh8c4CR19Hxj2ZKhQZUs6QrsT05ZUhb+23rpkfWTnL+IfcTchVQl/D gUEFncYnto9ao8Emjzwf7CQ6wyGpH3vSbNNgu+2Tnks5tQCMSrbotkq+sIq8HZl3gdMv G2vTIVPxJtDFGOLdl/TgC756XsGOLS8oF9etvS63A/VaZ/VXCUz2McxiF5tRspoweWKi dOUBwbZ11cEnME/BrdQtYRaGQcwupzu9U3Zopq29w/8MlDrD9yDGFOvGFgBX9FPsGDDF HdOmkT/ui+k0Cqr4HXchuSjyNMkxkNmyzmyUTvYJ+SpRVrxTcVf9bTU5FNteNlAecbtp n1eQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786570411; x=1787175211; h=content-transfer-encoding:content-type:mime-version:references :in-reply-to:subject:cc:to:from:message-id:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=9nHTuE7AAYCFKX7KeTMghSgjvrUE2Rt+zw5zVdxCuNw=; b=ILI4A2zXFIlKcdD1ejWJYNz63v2JqbKsrgkP7a1Hex0xf6GWRohNdi6XYNa7FUWjMq pIAzPfdHnCwDZ6JWkbtJDUAWDsS1MHSj9pt5Ksona6rIXulOgZaScXH8/yegybQjCB35 g2p8CE/+IMGJ/fu9Ibwjv1YTQ4W7KMiyKaZY/DqwyFnUxKs6SR8kYRQW3KoZ0QSDyYMU QtkGWKZgcNk2yaQk/VUzBYeXIVTHv+T/OlFf97Y5OtiJIU+1GwsWc94TLL4Km+Iq39AG uxsBdxHkZgRNROKv4YePwpaSRfp0dcUYv/VgxSLqNsHtrdPMXq59QkyRhrV1vgzdklk2 3Dmw== X-Forwarded-Encrypted: i=1; AHgh+RpiTVtlX0J8G3nQlzHEy/DhKaV5ZZ00lur4we7LM9aRLLfw6ge1YlIwW5OWZ2BH2CdvDcnMvqPxfGnHXik=@vger.kernel.org X-Gm-Message-State: AOJu0YxLXvs1YM692BlJIlF35GBsgL0WbzAt7Z+ocd1gXkJFqYajjLUu tlPvfA9WHLH0tWjG3kBcUXsp1yC/IvXujDcijOl9qCu1S1PdwrWXPCIj X-Gm-Gg: AR+sD10K69ubUebFxPJGWqo9YQXrdJ0dTon6zDy60h4PEvronr3qiHcmIB0I0wVKJ4L 6F8jwD/RDCbBg1sExKHNGT6DiOYM2KfZ1yMD/0kly6waYSVHzNaF70aPxlTMy5wq+BzPePf6OYv ElL0oUpmCjuVaKHkGRoJcttgttqoKkA/QxiVDvZ1uWTn+u3mnLZIs6IouBl/o1QGLDQ6whGR1EG A/1s7aSRxqZprO957MBJdJbk3EBqUhMiR6jLVDg4I8Ld4Hsp8PXNvOOtlLHYciD++JSY5fPj+Rc wWH57njEbv28ZRiCPjsI3RyJINd5rDW1C72+NlCVIbWTq7sAvTdg0EjQlS9516AVpIPivZDUPeN FmH326g+2zwbDCEiUhOS4T5DRJMghdOfRchbNt7k6IE1iB27KNmt+Tecf7F29DtaTxLkzFkqnOw Zo30/bCYX5Ri9jnCEEGwPUM8IYq+D3Drf/cPemGMey0bfg76WlHfqHWKdUm+f8uUWpaC11icHAj rWl5FH+he8hHEjbxFm4dEA= X-Received: by 2002:a05:651c:553:b0:39e:a64f:d7a9 with SMTP id 38308e7fff4ca-3a11a4e7fd5mr1720061fa.2.1786570410950; Wed, 12 Aug 2026 14:33:30 -0700 (PDT) Received: from localhost (host-80-73-162-2.rev.as20985.net. [80.73.162.2]) by smtp.gmail.com with ESMTPSA id 38308e7fff4ca-3a11b3dc5bbsm680601fa.19.2026.08.12.14.33.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 12 Aug 2026 14:33:30 -0700 (PDT) Date: Thu, 13 Aug 2026 00:33:29 +0300 Message-ID: From: Andrey Golovko To: Antoine Monnet , linux-sound@vger.kernel.org Cc: Shenghao Ding , Kevin Lu , Baojun Xu , Sen Wang , Mark Brown , Liam Girdwood , Vijendar Mukunda , Vinod Koul , Bard Liao , Pierre-Louis Bossart , Robin Everaars , Ville Saarinen , linux-kernel@vger.kernel.org Subject: Re: ASoC: tas2783-sdw: no stereo channel split for two mono amps -> mono output (AMD ACP SoundWire, ASUS ProArt PX13) In-Reply-To: <778f017a-e1c2-4ab6-9968-6e4c6285180b@montane.tech> References: <29e8c08b-9475-4aba-bce0-6d4a45a26d3b@gmail.com> <778f017a-e1c2-4ab6-9968-6e4c6285180b@montane.tech> 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 Antoine, your patch from 27 July is still the only working stereo fix for these boards, and it is now the only one left: Ville withdrew his series on 11 August and asked that the tags go to Robin and to you, and nobody else has posted anything. It has never been sent as a formal [PATCH], so as things stand it cannot be applied by anyone. I think it should be, and I would like to know how you want that to happen. Where it has been tested ======================== - your machine, ASUS ProArt PX13 HN7306EA (the original report); - mine, ASUS ProArt PX13 HN7306EAC: Tested-by sent on 7 August, and re-confirmed yesterday on a current broonie/sound for-next kernel -- speaker-test -c2 -s1 is the physically left speaker, -s2 the right, with no audible level imbalance between them; - Robin's board, same amp pair, where the one-channel-mask approach was independently established and measured. Robin has asked for Reported-by: and Suggested-by: on the channel-mask patch, since his 5 August report and the follow-up measurement established both the approach and the positional behaviour of sdw_compute_slave_ports(). Two options =========== Either you post it yourself as a proper [PATCH] -- which I would prefer, it is your work -- or, if you would rather not spend time on it, I am happy to send it with your authorship intact: From: Antoine Monnet Reported-by: Robin Everaars Suggested-by: Robin Everaars Tested-by: Andrey Golovko Just say which, and if the second, whether you want anything changed first. I will not send anything under your name without your word. One thing worth putting in the changelog ======================================== The name_prefix -> BIT(n) mapping reads as if the bit chose the channel, and it does not. As Robin measured, inverting the two masks between the amps does not move the audio: sdw_compute_slave_ports() advances the payload offset by hweight32(ch_mask) and never looks at which bit is set, so a one-channel mask fixes mono by defeating mirror mode, and L/R then follows codec order in the DAI link, which on these boards happens to match the speakers. That is worth a sentence in the commit message so nobody later reads the mapping as an ABI promise. It does not make the patch less correct -- the split it produces is right on three machines -- but it is the honest description of why it works. For completeness on the SDCA-correct alternative that Pierre-Louis raised: Ville measured that UDMPU23 ClusterIndex is simply not implemented on his TAS2783 revision, answering COMMAND_IGNORED to writes and to a plain read alike, so that route is closed at least on that silicon. TI have not commented on the intended mechanism. Unrelated, but you followed it: the "no audio after s2idle resume" problem you reported in July is understood and patched. After S0i3 the amplifier comes back with PDE23 at PS3, and a data port cannot complete channel preparation while the Function is powered down; the power-up only ever happened in hw_params(), which a resumed stream never calls again. Patch: https://lore.kernel.org/all/20260813001500.9218-1-andrey.golovko@gmail.com/ Thanks, Andrey