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

[Nicolas Frattaroli <nicolas.frattaroli@collabora.com>]

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