Re: [PATCH QUESTION] ASoC: qcom: sdm845: use DSP_A format for TDM codec DAIs

[David Heidelberg <david@ixit.cz>]

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
>