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

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

[David Heidelberg via B4 Relay]

From: David Heidelberg <david@ixit.cz>

I'm currently pairing this with cs35l36 codec.

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.

Signed-off-by: David Heidelberg <david@ixit.cz>
---
 sound/soc/qcom/sdm845.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sound/soc/qcom/sdm845.c b/sound/soc/qcom/sdm845.c
index 0ce9dff4dc525..7bf22e24b193a 100644
--- a/sound/soc/qcom/sdm845.c
+++ b/sound/soc/qcom/sdm845.c
@@ -376,17 +376,17 @@ static int sdm845_snd_startup(struct snd_pcm_substream *substream)
 	case QUATERNARY_TDM_RX_0:
 	case QUATERNARY_TDM_TX_0:
 		if (++(data->quat_tdm_clk_count) == 1) {
 			snd_soc_dai_set_sysclk(cpu_dai,
 				Q6AFE_LPASS_CLK_ID_QUAD_TDM_IBIT,
 				TDM_BCLK_RATE, SNDRV_PCM_STREAM_PLAYBACK);
 		}
 
-		codec_dai_fmt |= SND_SOC_DAIFMT_IB_NF | SND_SOC_DAIFMT_DSP_B;
+		codec_dai_fmt |= SND_SOC_DAIFMT_IB_NF | SND_SOC_DAIFMT_DSP_A;
 
 		for_each_rtd_codec_dais(rtd, j, codec_dai) {
 
 			if (!strcmp(codec_dai->component->name_prefix,
 				    "Left")) {
 				ret = snd_soc_dai_set_fmt(
 						codec_dai, codec_dai_fmt);
 				if (ret < 0) {

---
base-commit: ec039126b7fac4e3af35ebccaa7c6f9b6875ba81
change-id: 20260613-rfc-dsp-b-to-a-178a3c0ae7e1

Best regards,
-- 
David Heidelberg <david@ixit.cz>

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 627 bytes --]

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.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[David Heidelberg]

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 ?

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

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 652 bytes --]

On Sun, Jun 14, 2026 at 09:26:42AM +0200, David Heidelberg wrote:
> On 14/06/2026 01:53, Mark Brown wrote:

> > 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.

No, that's buggy.  If the device only supports DSP A then the device
only support DSP A and the driver should express that.  Any hacks that
can be done to make it interoperate with something else should be done
in the framework.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Srinivas Kandagatla]

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.

--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

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

[David Heidelberg]

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
> 

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

[Richard Acayan]

On Sun, Jun 21, 2026 at 05:54:17PM +0200, David Heidelberg wrote:
> 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

No I don't think so, this devicetree property has no effect in
sound/soc/qcom/qdsp6/q6afe-dai.c.

For the Pixel 3a, it only mattered with the RT5514 codec.

> > > > > 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.

I just assumed DSP_A and DSP_B were codec-specific.

> [1] https://gitlab.com/sdm670-mainline/linux/-/commit/9eba5aa993f5fb7b4bf5cc936ec22852987d3f9f