From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from ixit.cz (ixit.cz [185.100.197.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id F25501E7C2E; Sun, 21 Jun 2026 15:54:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=185.100.197.86 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782057264; cv=none; b=SSHuugmpgDhXCZdRxroKjTCNkTANHVVP8//LmXaAqx66ug16oP49FUkQHOm/P2hPcgkQAEMa/IALoihMKnsKVdhVCkIxShwscPgdCV8Lz9Mi5MD3cs3i4GPo2eZM3pwn03xYCjf0htyxr0vaPImzByRSp7xygOsgV28bgVMGXaA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782057264; c=relaxed/simple; bh=kx+1OhR5t+FtwSj9jKoXpxjWKcVf4VDDgIJwp5BPkYY=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=qqmHi+iq62AJIv3cChh7mXhz91lva/4dWFUgFgoO4hdGqAkKnFrQTlkAPQiFFfgZHR8g8xv7aO9eQMGGu6dCOc5J1n867J+TXhC+DG/mt3r5X9PabcUFCU7eNm1Gzsig4/vlhrCi9aHd7Uj9lIq952rv60v5nrtrGHiszkuHwfM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=ixit.cz; spf=pass smtp.mailfrom=ixit.cz; dkim=pass (1024-bit key) header.d=ixit.cz header.i=@ixit.cz header.b=Cq12duOx; arc=none smtp.client-ip=185.100.197.86 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=ixit.cz Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=ixit.cz Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=ixit.cz header.i=@ixit.cz header.b="Cq12duOx" Received: from [10.0.0.200] (unknown [10.88.125.21]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange x25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ixit.cz (Postfix) with ESMTPSA id 42FF45340E57; Sun, 21 Jun 2026 17:54:18 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ixit.cz; s=dkim; t=1782057258; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=M/eNKPvXbgH3Ts2S0ozJ/U1sKefs/BslszFr6hk4YwE=; b=Cq12duOxg33QSMMT9mo1etZGR1ruYnxbEu3HT1ogNlmORnIpk5hFzP53izRHx46f7zgNHm sUXX1WxGd/fG7bHm4Rn+NmZngWvffwMlxXyg94iRL7jwB1rpAas7fkOri7Yugw+wGhezg7 mczdd70N+9YdsK0bt8olEHeF//3Mtc4= Message-ID: <357aee62-78ec-4ee3-afb8-5be3ffe70cbd@ixit.cz> Date: Sun, 21 Jun 2026 17:54:17 +0200 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH QUESTION] ASoC: qcom: sdm845: use DSP_A format for TDM codec DAIs To: Srinivas Kandagatla , Mark Brown Cc: Liam Girdwood , Jaroslav Kysela , Takashi Iwai , linux-sound@vger.kernel.org, linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org, phone-devel@vger.kernel.org, Konrad Dybcio , Richard Acayan References: <20260613-rfc-dsp-b-to-a-v1-1-7d095fe90a05@ixit.cz> <5f262a04-8e92-4ac1-bd7c-1246231d3de2@ixit.cz> <7f94caa0-48ba-46f3-922e-f16e39fd22c9@kernel.org> Content-Language: en-US From: David Heidelberg Autocrypt: addr=david@ixit.cz; keydata= xsFNBF5v1x4BEADS3EddwsNsvVAI1XF8uQKbdYPY/GhjaSLziwVnbwv5BGwqB1tfXoHnccoA 9kTgKAbiXG/CiZFhD6l4WCIskQDKzyQN3JhCUIxh16Xyw0lECI7iqoW9LmMoN1dNKcUmCO9g lZxQaOl+1bY/7ttd7DapLh9rmBXJ2lKiMEaIpUwb/Nw0d7Enp4Jy2TpkhPywIpUn8CoJCv3/ 61qbvI9y5utB/UhfMAUXsaAgwEJyGPAqHlC0YZjaTwOu+YQUE3AFzhCbksq95CwDz4U4gdls dmv9tkATfu2OmzERZQ6vJTehK0Pu4l5KmCAzYg42I9Dy4E6b17x6NncKbcByQFOXMtG0qVUk F1yeeOQUHwu+8t3ZDMBUhCkRL/juuoqLmyDWKMc0hKNNeZ9BNXgB8fXkRLWEUfgDXsFyEkKp NxUy5bDRlivf6XfExnikk5kj9l2gGlNQwqROti/46bfbmlmc/a2GM4k8ZyalHNEAdwtXYSpP 8JJmlbQ7hNTLkc3HQLRsIocN5th/ur7pPMz1Beyp0gbE9GcOceqmdZQB80vJ01XDyCAihf6l AMnzwpXZsjqIqH9r7T7tM6tVEVbPSwPt4eZYXSoJijEBC/43TBbmxDX+5+3txRaSCRQrG9dY k3mMGM3xJLCps2KnaqMcgUnvb1KdTgEFUZQaItw7HyRd6RppewARAQABzSBEYXZpZCBIZWlk ZWxiZXJnIDxkYXZpZEBpeGl0LmN6PsLBlAQTAQgAPgIbAwULCQgHAgYVCgkICwIEFgIDAQIe AQIXgBYhBNd6Cc/u3Cu9U6cEdGACP8TTSSByBQJl+KksBQkPDaAOAAoJEGACP8TTSSBy6IAQ AMqFqVi9LLxCEcUWBn82ssQGiVSDniKpFE/tp7lMXflwhjD5xoftoWOmMYkiWE86t5x5Fsp7 afALx7SEDz599F1K1bLnaga+budu55JEAYGudD2WwpLJ0kPzRhqBwGFIx8k6F+goZJzxPDsf loAtXQE62UvEKa4KRRcZmF0GGoRsgA7vE7OnV8LMeocdD3eb2CuXLzauHAfdvqF50IfPH/sE jbzROiAZU+WgrwU946aOzrN8jVU+Cy8XAccGAZxsmPBfhTY5f2VN1IqvfaRdkKKlmWVJWGw+ ycFpAEJKFRdfcc5PSjUJcALn5C+hxzL2hBpIZJdfdfStn+DWHXNgBeRDiZj1x6vvyaC43RAb VXvRzOQfG4EaMVMIOvBjBA/FtIpb1gtXA42ewhvPnd5RVCqD9YYUxsVpJ9d+XsAy7uib3BsV W2idAEsPtoqhVhq8bCUs/G4sC2DdyGZK8MRFDJqciJSUbqA+5z1ZCuE8UOPDpZKiW6H/OuOM zDcjh0lOzr4p+/1TSg1PbUh7fQ+nbMuiT044sC1lLtJK0+Zyn0GwhR82oNM4fldNsaHRW42w QGD35+eNo5Pvb3We5XRMlBdhFnj7Siggp4J8/PJ6MJvRyC+RIJPGtbdMB2/RxWunFLn87e5w UgwR9jPMHAstuTR1yR23c4SIYoQ2fzkrRzuazsFNBF5v1x4BEADnlrbta2WL87BlEOotZUh0 zXANMrNV15WxexsirLetfqbs0AGCaTRNj+uWlTUDJRXOVIwzmF76Us3I2796+Od2ocNpLheZ 7EIkq8budtLVd1c06qJ+GMraz51zfgSIazVInNMPk9T6fz0lembji5yEcNPNNBA4sHiFmXfo IhepHFOBApjS0CiOPqowYxSTPe/DLcJ/LDwWpTi37doKPhBwlHev1BwVCbrLEIFjY0MLM0aT jiBBlyLJaTqvE48gblonu2SGaNmGtkC3VoQUQFcVYDXtlL9CVbNo7BAt5gwPcNqEqkUL60Jh FtvVSKyQh6gn7HHsyMtgltjZ3NKjv8S3yQd7zxvCn79tCKwoeNevsvoMq/bzlKxc9QiKaRPO aDj3FtW7R/3XoKJBY8Hckyug6uc2qYWRpnuXc0as6S0wfek6gauExUttBKrtSbPPHiuTeNHt NsT4+dyvaJtQKPBTbPHkXpTO8e1+YAg7kPj3aKFToE/dakIh8iqUHLNxywDAamRVn8Ha67WO AEAA3iklJ49QQk2ZyS1RJ2Ul28ePFDZ3QSr9LoJiOBZv9XkbhXS164iRB7rBZk6ZRVgCz3V6 hhhjkipYvpJ/fpjXNsVL8jvel1mYNf0a46T4QQDQx4KQj0zXJbC2fFikAtu1AULktF4iEXEI rSjFoqhd4euZ+QARAQABwsF8BBgBCAAmAhsMFiEE13oJz+7cK71TpwR0YAI/xNNJIHIFAmX4 qVAFCQ8NoDIACgkQYAI/xNNJIHKN4A/+Ine2Ii7JiuGITjJkcV6pgKlfwYdEs4eFD1pTRb/K 5dprUz3QSLP41u9OJQ23HnESMvn31UENk9ffebNoW7WxZ/8cTQY0JY/cgTTrlNXtyAlGbR3/ 3Q/VBJptf04Er7I6TaKAmqWzdVeKTw33LljpkHp02vrbOdylb4JQG/SginLV9purGAFptYRO 8JNa2J4FAQtQTrfOUjulOWMxy7XRkqK3QqLcPW79/CFn7q1yxamPkpoXUJq9/fVjlhk7P+da NYQpe4WQQnktBY29SkFnvfIAwqIVU8ix5Oz8rghuCcAdR7lEJ7hCX9bR0EE05FOXdZy5FWL9 GHvFa/Opkq3DPmFl/0nt4HJqq1Nwrr+WR6d0414oo1n2hPEllge/6iD3ZYwptTvOFKEw/v0A yqOoYSiKX9F7Ko7QO+VnYeVDsDDevKic2T/4GDpcSVd9ipiKxCQvUAzKUH7RUpqDTa+rYurm zRKcgRumz2Tc1ouHj6qINlzEe3a5ldctIn/dvR1l2Ko7GBTG+VGp9U5NOAEkGpxHG9yg6eeY fFYnMme51H/HKiyUlFiE3yd5LSmv8Dhbf+vsI4x6BOOOq4Iyop/Exavj1owGxW0hpdUGcCl1 ovlwVPO/6l/XLAmSGwdnGqok5eGZQzSst0tj9RC9O0dXO1TZocOsf0tJ8dR2egX4kxM= In-Reply-To: <7f94caa0-48ba-46f3-922e-f16e39fd22c9@kernel.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 14/06/2026 23:40, Srinivas Kandagatla wrote: > > > On 6/14/26 8:26 AM, David Heidelberg wrote: >> On 14/06/2026 01:53, Mark Brown wrote: >>> On Sat, Jun 13, 2026 at 09:55:59PM +0200, David Heidelberg via B4 >>> Relay wrote: >>> >>>> Currently this worked only because the cs35l36 >>>> codec mapped both DSP_A and DSP_B to the same hardware register value >>>> (asp_fmt = 0), which is inherently DSP_A timing. >>> >>>> The CPU-side AFE is configured with qcom,tdm-data-delay = <1> which >>>> produces DSP_A framing. >>>> The codec format should match what is actually on the wire. >>> >>>> So I'm pretty lost if I should go fixing cs35l36 or sdm845.c. >>> >>> That sounds like both.  The Cirrus driver is definitely buggy if it's >>> mapping DSP A and B to the same register value, at least one of those is >>> wrong. >> >> I need to clarify. The CS35L36 supports by default only DSP_A, but when >> extended to "take DSP_B", speaker just works. >> >> This was done previously. >> >> Since there isn't any different configuration on the codec side when >> added DSP_B into same codepath as DSP_A, I would assume QCOM ASoC send >> DSP_A, just marking it as DSP_B ? > > > qcom,tdm-sync-mode = <0>; > qcom,tdm-sync-src = <1>; > sets the short sync with 1 clk delay making it DSP_A. > > for DSP_B you would need, no delay. Sure, does that mean the sdm845.c is currently correctly setting SND_SOC_DAIFMT_DSP_B there? or there is some missing part of logic deciding it? Because the reason audio works when I convince driver either: a) sdm845 ASoC it uses BSP_A instead of B ... or b) cs35l36 it uses BSP_B instead of A implies to me, that: 1. both devices are setting the HW to either BSP_A or BSP_B mode (just don't know which one) 2. but the driver flag for ASoC or codec we setting on the driver side is wrong If one side really used BSP_A and other BSP_B, the audio should be at best heavily distorted, right? Please correct me, if I misunderstood or if there is nice doc I could read about it. Thanks David P.S. I did quick search what close-to-mainline repo has for Pixel 3a to reach working audio and it's slightly different, see [1]. There isn't any change done to the cs35l36 driver in the sdm670 tree. [1] https://gitlab.com/sdm670-mainline/linux/-/commit/9eba5aa993f5fb7b4bf5cc936ec22852987d3f9f > > --srini >> >> There isn't any other consumer to check against and I would assume >> incorrectly configured TDM slot would lead - at least - to disorted output. >> >> The reference (which now works) is here [1]. >> >> David >> >> [1] https://codeberg.org/sdm845/linux/commits/branch/b4/pixel3-audio >