Devicetree
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "David Heidelberg" <david@ixit.cz>
Cc: robh@kernel.org, devicetree@vger.kernel.org, conor+dt@kernel.org
Subject: Re: [PATCH RFC v2 1/6] ASoC: qcom: sdm845: Demystify TDM masks a bit
Date: Thu, 03 Sep 2026 18:40:49 +0000	[thread overview]
Message-ID: <20260903184050.20BBA1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260903-pixel3-audio-v2-1-7c22ed915291@ixit.cz>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] Incorrect semantic definition and conflation of TDM RX/TX masks for the CPU capture path.
--

commit 14c4efbbf7408318c5b2824f99db089826af6b11
Author: David Heidelberg <david@ixit.cz>

ASoC: qcom: sdm845: Demystify TDM masks a bit

This commit attempts to clarify the TDM masks by defining individual bits
for left/right speakers and microphones instead of using hardcoded hex values.

> diff --git a/sound/soc/qcom/sdm845.c b/sound/soc/qcom/sdm845.c
> index 6843ab8ba017e..0ce8265ab1c1f 100644
> --- a/sound/soc/qcom/sdm845.c
> +++ b/sound/soc/qcom/sdm845.c
> @@ -23,9 +23,14 @@
>  #define DEFAULT_MCLK_RATE		24576000
>  #define TDM_BCLK_RATE		6144000
>  #define MI2S_BCLK_RATE		1536000
> -#define LEFT_SPK_TDM_TX_MASK    0x30
> -#define RIGHT_SPK_TDM_TX_MASK   0xC0
> -#define SPK_TDM_RX_MASK         0x03
> +#define LEFT_SPK_TDM_RX_MASK	BIT(0)
> +#define RIGHT_SPK_TDM_RX_MASK	BIT(1)
> +#define SPK_TDM_RX_MASK		(LEFT_SPK_TDM_RX_MASK | RIGHT_SPK_TDM_RX_MASK)
> +#define MIC1_TDM_RX_MASK	BIT(2)
> +#define MIC2_TDM_RX_MASK	BIT(3)
> +#define MIC_TDM_RX_MASK		(MIC1_TDM_RX_MASK | MIC2_TDM_RX_MASK)

[Severity: Low]
Is this naming convention accurate for the hardware routing?

Microphones capture audio, meaning they transmit data to the CPU rather than
receive it. Naming this an RX mask seems to misrepresent the physical data
flow and makes the definitions confusing.

> +#define LEFT_SPK_TDM_TX_MASK	(BIT(4) | BIT(5))
> +#define RIGHT_SPK_TDM_TX_MASK	(BIT(6) | BIT(7))

[ ... ]

> @@ -128,8 +133,10 @@ static int sdm845_tdm_snd_hw_params(struct snd_pcm_substream *substream,
>  			goto end;
>  		}
>  	} else {
> -		ret = snd_soc_dai_set_tdm_slot(cpu_dai, 0xf, 0,
> -				8, slot_width);
> +		ret = snd_soc_dai_set_tdm_slot(cpu_dai,
> +					       SPK_TDM_RX_MASK |
> +					       MIC_TDM_RX_MASK, 0,
> +					       NUM_TDM_SLOTS, slot_width);

[Severity: Low]
Does this combination of masks correctly reflect the TDM slot usage for
capture in sdm845_tdm_snd_hw_params()?

It appears the speaker mask, which defines playback slots on the DOUT wire,
is being combined with the new microphone mask merely to mathematically
reconstruct the previous 0xf value.

Using an RX mask to configure the CPU transmit mask, which reads from the
DIN wire, makes the capture path configuration difficult to follow. Could
we define a proper set of TX masks for the capture path instead?

>  		if (ret < 0) {
>  			dev_err(rtd->dev, "%s: failed to set tdm slot, err:%d\n",
>  					__func__, ret);

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260903-pixel3-audio-v2-0-7c22ed915291@ixit.cz?part=1

  reply	other threads:[~2026-09-03 18:40 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-03 18:26 [PATCH RFC v2 0/6] Speakers for Pixel 3 / 3 XL David Heidelberg via B4 Relay
2026-09-03 18:26 ` [PATCH RFC v2 1/6] ASoC: qcom: sdm845: Demystify TDM masks a bit David Heidelberg via B4 Relay
2026-09-03 18:40   ` sashiko-bot [this message]
2026-09-03 18:26 ` [PATCH RFC v2 2/6] ASoC: qcom: sdm845: use DSP_A format for TDM codec DAIs David Heidelberg via B4 Relay
2026-09-03 18:26 ` [PATCH RFC v2 3/6] ASoC: qcom: sdm845: Use per-speaker RX masks for TDM slot assignment David Heidelberg via B4 Relay
2026-09-03 18:41   ` sashiko-bot
2026-09-03 18:26 ` [PATCH RFC v2 4/6] ASoC: qcom: sdm845: Set codec dai and component sysclk during startup David Heidelberg via B4 Relay
2026-09-03 18:40   ` sashiko-bot
2026-09-03 18:26 ` [PATCH RFC v2 5/6] ASoC: cs35l36: Implement set_tdm_slot to program RX and TX slots David Heidelberg via B4 Relay
2026-09-03 18:40   ` sashiko-bot
2026-09-04  8:22   ` Konrad Dybcio
2026-09-04  9:26     ` Charles Keepax
2026-09-04  9:23   ` Charles Keepax
2026-09-03 18:26 ` [PATCH RFC v2 6/6] arm64: dts: qcom: sdm845-google: Add basic audio support David Heidelberg via B4 Relay

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=20260903184050.20BBA1F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=david@ixit.cz \
    --cc=devicetree@vger.kernel.org \
    --cc=robh@kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    /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