The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: Richard Acayan <mailingradian@gmail.com>
To: David Heidelberg <david@ixit.cz>
Cc: Srinivas Kandagatla <srini@kernel.org>,
	Mark Brown <broonie@kernel.org>,
	Liam Girdwood <lgirdwood@gmail.com>,
	Jaroslav Kysela <perex@perex.cz>, Takashi Iwai <tiwai@suse.com>,
	linux-sound@vger.kernel.org, linux-arm-msm@vger.kernel.org,
	linux-kernel@vger.kernel.org, phone-devel@vger.kernel.org,
	Konrad Dybcio <konradybcio@kernel.org>
Subject: Re: [PATCH QUESTION] ASoC: qcom: sdm845: use DSP_A format for TDM codec DAIs
Date: Mon, 22 Jun 2026 11:18:51 -0400	[thread overview]
Message-ID: <ajlSW1NYc5qh1bL1@rdacayan> (raw)
In-Reply-To: <357aee62-78ec-4ee3-afb8-5be3ffe70cbd@ixit.cz>

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

      reply	other threads:[~2026-06-22 15:18 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-13 19:55 [PATCH QUESTION] ASoC: qcom: sdm845: use DSP_A format for TDM codec DAIs David Heidelberg via B4 Relay
2026-06-13 23:53 ` Mark Brown
2026-06-14  7:26   ` David Heidelberg
2026-06-14 10:35     ` Mark Brown
2026-06-14 21:40     ` Srinivas Kandagatla
2026-06-21 15:54       ` David Heidelberg
2026-06-22 15:18         ` Richard Acayan [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=ajlSW1NYc5qh1bL1@rdacayan \
    --to=mailingradian@gmail.com \
    --cc=broonie@kernel.org \
    --cc=david@ixit.cz \
    --cc=konradybcio@kernel.org \
    --cc=lgirdwood@gmail.com \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-sound@vger.kernel.org \
    --cc=perex@perex.cz \
    --cc=phone-devel@vger.kernel.org \
    --cc=srini@kernel.org \
    --cc=tiwai@suse.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