Breakthrough:

I managed to fix some issues with initialization and now the lists at
/sys/kernel/debug/asoc/omap5-uevm/401f1000.aess/dapm/
resp.
/sys/kernel/debug/asoc/PandaBoardES/401f1000.aess/dapm/
and the contents of e.g. the file BE_IN are almost the same.
So I can get a nice picture from vizdapm.

2 days searching... Finally it was an area where conversion from platform
driver to component driver I had done ca. 2 years ago was incomplete and
a workaround.

What I have not tested are for other bugs and issues and if I can play
any sound... Well, the legacy interface still works.

So it is time to clean up the patches and merge into letux-6.2.0.

And then continue with debugging.
BR,
Nikolaus


Am 20.02.2023 um 16:01 schrieb H. Nikolaus Schaller <hns@goldelico.com>:

Hi Peter,

Am 19.02.2023 um 22:13 schrieb H. Nikolaus Schaller <hns@goldelico.com>:

Hi Peter,
I have changed the subject to focus on the next issue.

Am 19.02.2023 um 20:06 schrieb H. Nikolaus Schaller <hns@goldelico.com>:

I have found more reasons to go that way. One is the setup of e.g.

{"omap-mcbsp.1 Playback", NULL, "BT_VX_DL"},

McBSP also have some funky stuff due to DT naming.

Yes, the "omap-mcbsp.1 Playback" (or "40122000.mcbsp Playback") is currently my main
blocking point because it does not appear in the widget list to be matched and the above
shown route can not be established.

So far I have analysed that. The issue is with the BE McBSPs.

basically they are defined in (my new) code by

SND_SOC_DAILINK_DEFS(link_be_mcbsp1,
DAILINK_COMP_ARRAY(COMP_CPU("omap-mcbsp.1")), // NOTE: will be overwritten by OF node
DAILINK_COMP_ARRAY(COMP_DUMMY()),
DAILINK_COMP_ARRAY(COMP_PLATFORM("aess")));

It does not matter how they are called inside COMP_CPU() because it is nullified by code
and the OF node is inserted. Since it is named "40122000.mcbsp" by the OF-Node (same on the
3.15 kernel) I have modified the snd_soc_dapm_route to

/* Connections between twl6040 and ABE */
{"Headset Playback", NULL, "PDM_DL1"},
{"Handsfree Playback", NULL, "PDM_DL2"},
{"PDM_UL1", NULL, "Capture"},
/* Bluetooth <--> ABE*/
{"40122000.mcbsp Playback", NULL, "BT_VX_DL"},
{"BT_VX_UL", NULL, "40122000.mcbsp Capture"},
/* FM <--> ABE */
{"40124000.mcbsp Playback", NULL, "MM_EXT_DL"},
{"MM_EXT_UL", NULL, "40124000.mcbsp Capture"},

Then, at some point it is to be added by snd_soc_dapm_add_route(). This fails
(here with a lot of private printk):

[  120.829254] snd_soc_dapm_add_routes: 20: dapm=c1deb17c route=bf21d004
[  120.836212] snd_soc_dapm_add_route: source = BT_VX_DL sink = 40122000.mcbsp Playback
[  120.844482] snd_soc_dapm_add_route: try widget Headset Stereophone
[  120.851104] snd_soc_dapm_add_route: try widget Earphone Spk
[  120.857116] snd_soc_dapm_add_route: try widget Ext Spk
[  120.862670] snd_soc_dapm_add_route: try widget Line Out


...

[  121.545959] snd_soc_dapm_add_route: try widget Handsfree Playback
[  121.554321] snd_soc_dapm_add_route: try widget Vibra Playback
[  121.560394] omap-abe-twl6040 sound: ASoC: Failed to add route BT_VX_DL -> 40122000.mcbsp Playback(*)
[  121.570098] snd_soc_dapm_add_routes: 21: dapm=c1deb17c route=bf21d038
[  121.576904] snd_soc_dapm_add_route: source = 40122000.mcbsp Capture sink = BT_VX_UL

So there is no widget to match "40122000.mcbsp Playback". Should there be one?
Or should there be a different mechanism to identify the route?


I've added similar printk to the 3.15 kernel and there, the missing widgets do exist:

[   29.286834] snd_soc_dapm_add_routes: 11: dapm=bf1050d8 route=ec6096c0
[   29.286834] snd_soc_dapm_add_route: source = BT_VX_DL sink = 40122000.mcbsp Playback
[   29.286834] snd_soc_dapm_add_route: try widget 40124000.mcbsp Capture
[   29.286834] snd_soc_dapm_add_route: try widget 40124000.mcbsp Playback
[   29.286834] snd_soc_dapm_add_route: try widget 40122000.mcbsp Capture
[   29.286865] snd_soc_dapm_add_route: try widget 40122000.mcbsp Playback
[   29.286865] snd_soc_dapm_add_route: try widget Legacy Capture
[   29.286865] snd_soc_dapm_add_route: try widget Legacy Playback
[   29.286865] snd_soc_dapm_add_route: try widget Analog Capture
[   29.286865] snd_soc_dapm_add_route: try widget Headset Playback

...

So something is missing in my 6.2 kernel to create these mcbsp widgets...

Next I searched the 3.15 tree for something with mcbsp + widgets and finally
came across this patch:

$ git show 13a6bf336f13e3
commit 13a6bf336f13e3257de204648587012f38df59c2 (omap-audio/base-bnw/mcbsp)
Author: Peter Ujfalusi <peter.ujfalusi@ti.com>
Date:   Wed May 7 15:53:27 2014 +0300

   ASoC: omap-mcbsp: Register dai widgets to be used by AESS routing

   Since McBSP is used with AESS platform driver we need to create the dai
   widgets in order to be able to have complete route.

   Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>

diff --git a/sound/soc/omap/omap-mcbsp.c b/sound/soc/omap/omap-mcbsp.c
index 6c19bba235700..378f143dcc1f8 100644
--- a/sound/soc/omap/omap-mcbsp.c
+++ b/sound/soc/omap/omap-mcbsp.c
@@ -559,6 +559,8 @@ static int omap_mcbsp_probe(struct snd_soc_dai *dai)

       pm_runtime_enable(mcbsp->dev);

+       snd_soc_dapm_new_dai_widgets(&dai->dapm, dai);
+
       return 0;
}


And indeed, we need this (moved to sound/soc/ti/omap-mcbsp.c) as well.
Plus two additional lines of code to form the individual stream_names
which are needed by snd_soc_dapm_new_dai_widgets().

Unfortunately, all this is just a minor breakthrough...
But I can now focus on other aspects where the 6.2 setup is still incomplete.

BR,
Nikolaus