Debugging CPU-side DAI hardware with a dummy codec

Debugging CPU-side DAI hardware with a dummy codec

[Nicolas Frattaroli]

Hello,

I'm currently working on a CPU-side audio controller. In the process of that, 
I'd like to probe the actual I2S/TDM signal coming out of the thing with a logic 
analyzer, with no codec connected at all.

So I add a codec to my device tree:

	dummy_codec: dummy-codec {
		compatible = "please-replace-me";
		/* these might not get picked up, whatever, bear with me */
		assigned-clocks = <&cru CLK_SAI0_MCLKOUT_TO_IO>;
		assigned-clock-rates = <12288000>;
		#sound-dai-cells = <0>;
	};

and reference it in a simple-audio-card:

	dummy_thicc_sound: dummy-thicc-sound {
		compatible = "simple-audio-card";
		simple-audio-card,name = "Dumdum";
		simple-audio-card,format = "i2s";
		simple-audio-card,mclk-fs = <256>;

		simple-audio-card,cpu {
			sound-dai = <&sai0>;
			dai-tdm-slot-num = <4>;
			dai-tdm-slot-width = <16>;
		};

		simple-audio-card,codec {
			sound-dai = <&dummy_codec>;
		};
	};

The thought here is to let the probe defer, and just manually bind the driver.

So I set a driver override on my dummy-codec node:

  # echo "snd-soc-dummy" > /sys/bus/platform/devices/dummy-codec/driver_override

And hope to now be able to bind the snd-soc-dummy driver on the faux bus to it:

  # echo "dummy-codec" > /sys/bus/faux/drivers/faux_driver/snd-soc-dummy/driver/bind
  -bash: echo: write error: No such device

Clearly, that doesn't work.

I know there's no DT compatible because it'd be abused by lazy vendors to avoid
writing proper codec drivers, but I'm really genuinely trying to just look at
the signals of the DAI here and there is no codec whatsoever.

Apparently I'm the first to ever try and do this because both my mailing list
searches and documentation greps came up empty.

I hope someone can shed some light on this, as it seems like something audio
controller developers would be doing all the time.

Kind regards,
Nicolas Frattaroli

Re: Debugging CPU-side DAI hardware with a dummy codec

[Mark Brown]

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

On Tue, Apr 08, 2025 at 09:58:07PM +0200, Nicolas Frattaroli wrote:

> So I set a driver override on my dummy-codec node:

>   # echo "snd-soc-dummy" > /sys/bus/platform/devices/dummy-codec/driver_override
> 
> And hope to now be able to bind the snd-soc-dummy driver on the faux bus to it:

>   # echo "dummy-codec" > /sys/bus/faux/drivers/faux_driver/snd-soc-dummy/driver/bind
>   -bash: echo: write error: No such device

> Clearly, that doesn't work.

I don't know what specifically you've tripped up over there but there is
a little bit of special casing for the dummy CODEC since it's intended
to fill gaps with partially configured DPCM stream, not actually be
used.  If you just care about the signals then it would be easier to
pick some simple CODEC with no registers, as a bonus you won't have to
futz around at runtime overriding bindings.

> I hope someone can shed some light on this, as it seems like something audio
> controller developers would be doing all the time.

I suspect most people test with an actual system.  A bunch of things get
easier if you can actually play and record sound.

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

Re: Debugging CPU-side DAI hardware with a dummy codec

[Nicolas Frattaroli]

On Wednesday, 9 April 2025 17:01:58 Central European Summer Time Mark Brown wrote:
> On Tue, Apr 08, 2025 at 09:58:07PM +0200, Nicolas Frattaroli wrote:
> 
> > So I set a driver override on my dummy-codec node:
> 
> >   # echo "snd-soc-dummy" > /sys/bus/platform/devices/dummy-codec/driver_override
> > 
> > And hope to now be able to bind the snd-soc-dummy driver on the faux bus to it:
> 
> >   # echo "dummy-codec" > /sys/bus/faux/drivers/faux_driver/snd-soc-dummy/driver/bind
> >   -bash: echo: write error: No such device
> 
> > Clearly, that doesn't work.
> 
> I don't know what specifically you've tripped up over there but there is
> a little bit of special casing for the dummy CODEC since it's intended
> to fill gaps with partially configured DPCM stream, not actually be
> used.  If you just care about the signals then it would be easier to
> pick some simple CODEC with no registers, as a bonus you won't have to
> futz around at runtime overriding bindings.

I actually ended up finding `sound/soc/generic/test-component.c`, which almost
works for my purposes bar not having any tdm slot callbacks, which makes ASoC
core not use it for TDM. That's simple enough to add:

---
diff --git a/sound/soc/generic/test-component.c b/sound/soc/generic/test-component.c
index 5430d25deaef..89b995987e2d 100644
--- a/sound/soc/generic/test-component.c
+++ b/sound/soc/generic/test-component.c
@@ -140,6 +140,15 @@ static int test_dai_set_fmt(struct snd_soc_dai *dai, unsigned int fmt)
 	return 0;
 }
 
+static int test_dai_set_tdm_slot(struct snd_soc_dai *dai,
+				 unsigned int tx_mask, unsigned int rx_mask,
+				 int slots, int slot_width)
+{
+	dev_info(dai->dev, "set tdm slot: tx_mask=0x%08X, rx_mask=0x%08X, slots=%d, slot_width=%d\n",
+		 tx_mask, rx_mask, slots, slot_width);
+	return 0;
+}
+
 static int test_dai_mute_stream(struct snd_soc_dai *dai, int mute, int stream)
 {
 	mile_stone(dai);
@@ -203,6 +212,7 @@ static const u64 test_dai_formats =
 
 static const struct snd_soc_dai_ops test_ops = {
 	.set_fmt		= test_dai_set_fmt,
+	.set_tdm_slot		= test_dai_set_tdm_slot,
 	.startup		= test_dai_startup,
 	.shutdown		= test_dai_shutdown,
 	.auto_selectable_formats	= &test_dai_formats,
@@ -214,6 +224,7 @@ static const struct snd_soc_dai_ops test_verbose_ops = {
 	.set_pll		= test_dai_set_pll,
 	.set_clkdiv		= test_dai_set_clkdiv,
 	.set_fmt		= test_dai_set_fmt,
+	.set_tdm_slot		= test_dai_set_tdm_slot,
 	.mute_stream		= test_dai_mute_stream,
 	.startup		= test_dai_startup,
 	.shutdown		= test_dai_shutdown,
---

I also had to use an audio-graph-card instead of a simple-audio-card, as the
test component only supports those. So the DT just consists of a dummy codec
node with the "test-codec-verbose" compatible, the dai properties, and a port
with an endpoint pointing to the CPU-side DAI endpoint. There's then also the
dummy audio-graph-card, with `dais` set to a phandle to the CPU-side DAI port
property, and the CPU-side DAI with that port property and an endpoint within
it (pointed to by the codec) that points at the codec. It works, and if I get
the time I'll try writing this all up into a fitting way in the documentation,
as no documentation references to the test components exist.

> 
> > I hope someone can shed some light on this, as it seems like something audio
> > controller developers would be doing all the time.
> 
> I suspect most people test with an actual system.  A bunch of things get
> easier if you can actually play and record sound.
> 

I did try that, with no success :( The shortlist of codecs that do TDM, come on
affordable dev boards I can get my hands on and have a mainline Linux driver
came down to basically just the TI tas6424. I stared at it with no audio coming
out before I had the logic analyzer. Debugging 20 or so wire connections for
serial audio, I²C codec control, amplifier power, amp mute, speakers, etc. was
a very large problem space to explore. Even if I had the logic analyzer at that
stage, I would've had to have minimised the risk of getting distracted by
simpler hypotheses than what it actually ended up being. Turns out I am somehow
sending TDM data on the second falling bit clock edge after frame sync goes
high, whereas the codec (and most things doing TDM'd I2S I assume) will want
it on the first falling bit clock edge.

Thanks for the reply, it gave me the push to go deep diving into what sort of 
codecs I can use in the DT to get to what I needed, instead of trying to bind
a driver at runtime.

Cheers,
Nicolas Frattaroli

Re: Debugging CPU-side DAI hardware with a dummy codec

[Mark Brown]

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

On Wed, Apr 09, 2025 at 09:56:35PM +0200, Nicolas Frattaroli wrote:

> I actually ended up finding `sound/soc/generic/test-component.c`, which almost
> works for my purposes bar not having any tdm slot callbacks, which makes ASoC
> core not use it for TDM. That's simple enough to add:

If you want to sumbmit that upstream (probably with the logging
dropped/tone down to debug) then the TDM support would be there for the
next person who needs it...

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

Re: Debugging CPU-side DAI hardware with a dummy codec

[Daniel Baluta]

> > I hope someone can shed some light on this, as it seems like something audio
> > controller developers would be doing all the time.
>
> I suspect most people test with an actual system.  A bunch of things get
> easier if you can actually play and record sound.

Mark, that's true in most of the cases. But for silicon IP
pre-validation using emulation
environments most of the SoC creators use a synthetic codec so things like being
able to probe a dummy-codec does make some sense.

Nicolas,

Can you please paste your patches (dts and the rest)?

thanks,
Daniel.

Re: Debugging CPU-side DAI hardware with a dummy codec

[Nicolas Frattaroli]

On Thursday, 10 April 2025 12:54:16 Central European Summer Time Daniel Baluta wrote:
> > > I hope someone can shed some light on this, as it seems like something audio
> > > controller developers would be doing all the time.
> >
> > I suspect most people test with an actual system.  A bunch of things get
> > easier if you can actually play and record sound.
> 
> Mark, that's true in most of the cases. But for silicon IP
> pre-validation using emulation
> environments most of the SoC creators use a synthetic codec so things like being
> able to probe a dummy-codec does make some sense.
> 
> Nicolas,
> 
> Can you please paste your patches (dts and the rest)?
> 
> thanks,
> Daniel.
> 

Hi Daniel,

I'll send the test-component changes in a proper patch submission later.

The DTS in my case looks like this though. `sai0` here is the SoC-side
audio interface. Don't worry about the pinctrl/dma overriding, that's
me disabling capture.

---
diff --git a/arch/arm64/boot/dts/rockchip/rk3576-armsom-sige5.dts b/arch/arm64/boot/dts/rockchip/rk3576-armsom-sige5.dts
index de63b053a06c..6e78713b1a99 100644
--- a/arch/arm64/boot/dts/rockchip/rk3576-armsom-sige5.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3576-armsom-sige5.dts
@@ -84,6 +84,25 @@ simple-audio-card,codec {
 		};
 	};
 
+	dummy_codec: dummy-codec {
+		compatible = "test-codec-verbose";
+		dai-tdm-slot-num = <8>;
+		dai-tdm-slot-width = <16>;
+		#sound-dai-cells = <0>;
+
+		port {
+			codec_endpoint: endpoint {
+				remote-endpoint = <&sai0_endpoint>;
+			};
+		};
+	};
+
+	dummy_sound: dummy-sound {
+		compatible = "audio-graph-card";
+		label = "Dumdum";
+		dais = <&sai0_p0>;
+	};
+
 	vcc_12v0_dcin: regulator-vcc-12v0-dcin {
 		compatible = "regulator-fixed";
 		regulator-name = "vcc_12v0_dcin";
@@ -708,6 +727,26 @@ led_rgb_g: led-green-en {
 	};
 };
 
+&sai0 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&sai0m1_lrck
+			&sai0m1_sclk
+			&sai0m1_sdo0>;
+	dmas = <&dmac0 0>;
+	dma-names = "tx";
+	status = "okay";
+
+	sai0_p0: port {
+		sai0_endpoint: endpoint {
+			dai-format = "i2s";
+			dai-tdm-slot-num = <8>;
+			dai-tdm-slot-width = <16>;
+			mclk-fs = <256>;
+			remote-endpoint = <&codec_endpoint>;
+		};
+	};
+};
+
 &sai1 {
 	pinctrl-names = "default";
 	pinctrl-0 = <&sai1m0_lrck
---

NB. that this is based on my local v2 of the RK3576 SAI series so trying
to apply this with any tooling makes no sense, the main takeaway should be
the audio-graph-card and how the nodes reference each other.

The dummy_codec and dummy_sound nodes are children of the root node
`/ { /* ... */ };` here, the sai0 reference comes from the SoC's dtsi.

Kernel needs to be compiled with CONFIG_SND_TEST_COMPONENT of course if you
want the test components.

Cheers,
Nicolas Frattaroli

Re: Debugging CPU-side DAI hardware with a dummy codec

[Nicolas Frattaroli]

On Thursday, 10 April 2025 13:23:21 Central European Summer Time Nicolas Frattaroli wrote:
> On Thursday, 10 April 2025 12:54:16 Central European Summer Time Daniel Baluta wrote:
> > > > I hope someone can shed some light on this, as it seems like something audio
> > > > controller developers would be doing all the time.
> > >
> > > I suspect most people test with an actual system.  A bunch of things get
> > > easier if you can actually play and record sound.
> > 
> > Mark, that's true in most of the cases. But for silicon IP
> > pre-validation using emulation
> > environments most of the SoC creators use a synthetic codec so things like being
> > able to probe a dummy-codec does make some sense.
> > 
> > Nicolas,
> > 
> > Can you please paste your patches (dts and the rest)?
> > 
> > thanks,
> > Daniel.
> > 
> 
> Hi Daniel,
> 
> I'll send the test-component changes in a proper patch submission later.
> 
> The DTS in my case looks like this though. `sai0` here is the SoC-side
> audio interface. Don't worry about the pinctrl/dma overriding, that's
> me disabling capture.
> 
> ---
> diff --git a/arch/arm64/boot/dts/rockchip/rk3576-armsom-sige5.dts b/arch/arm64/boot/dts/rockchip/rk3576-armsom-sige5.dts
> index de63b053a06c..6e78713b1a99 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3576-armsom-sige5.dts
> +++ b/arch/arm64/boot/dts/rockchip/rk3576-armsom-sige5.dts
> @@ -84,6 +84,25 @@ simple-audio-card,codec {
>  		};
>  	};
>  
> +	dummy_codec: dummy-codec {
> +		compatible = "test-codec-verbose";
> +		dai-tdm-slot-num = <8>;
> +		dai-tdm-slot-width = <16>;
> +		#sound-dai-cells = <0>;
> +
> +		port {
> +			codec_endpoint: endpoint {
> +				remote-endpoint = <&sai0_endpoint>;
> +			};
> +		};
> +	};

Gah, major blunder from my side, the dai-tdm-slot-* properties should be
inside the endpoint node of the codec here like this:

	dummy_codec: dummy-codec {
		compatible = "test-codec-verbose";
		#sound-dai-cells = <0>;

		port {
			codec_endpoint: endpoint {
				dai-tdm-slot-num = <8>;
				dai-tdm-slot-width = <16>;
				remote-endpoint = <&sai0_endpoint>;
			};
		};
	};

Sorry about the confusion.

Cheers,
Nicolas Frattaroli

> [...]
> 
> Cheers,
> Nicolas Frattaroli