Hi Peter and Tony, I am still pushing to get AESS work on the PandaES and the OMAP5 Pyra. We have already great progress, e.g. firmware generation and loading works, all amixers exist and we can see the first frontend interfaces.
Still it is not working - most likely something with power management setup and enabling the dynamic parts of ALSA. For example we get the report that the BE DAIs are not available. Or that mixers are changed while powered down.
Now we have run the vizdapm tool and see quite some differences to the 3.15 kernel (and 3.8).
The first observation is that the DAPM routes for e.g. "HSOR" to "Headset Sterephone" are instantiated twice. It turns out that there are almost identical definitions in DTS and in the driver:
https://elixir.bootlin.com/linux/v6.2-rc8/source/arch/arm/boot/dts/omap4-pan... https://elixir.bootlin.com/linux/v6.2-rc8/source/arch/arm/boot/dts/omap5-boa... https://elixir.bootlin.com/linux/v6.2-rc8/source/sound/soc/ti/omap-abe-twl60...
It seems as if the DT definitions are simply a subset of the driver code table.
But there seems to be no mechanism to find duplicates or ignore the driver-builtin routes if they are defined by DTS.
So please what is the best strategy?
a) remove all entries from DTS since they are a subset of the driver code b) remove the driver table audio_map[] completely and add the missing components to the DTS? b) make the driver ignore the audio_map[] table if there are card->of_dapm_routes and add the missing components to the DTS? c) hack snd_soc_dapm_add_routes() to find and ignore duplicates?
Any advice is welcome.
Best regards, Nikolaus
* H. Nikolaus Schaller hns@goldelico.com [230216 11:01]:
a) remove all entries from DTS since they are a subset of the driver code
If they are driver internal data and not ASoC generic bindings or audio graph stuff, you might be able to get away with setting the routing in the driver based on the device specifc compatible value.
Sorry I don't really know anything about this.. But in general avoiding custom dts bindings is the way to go. And using the standard audio graph bindings where possible between devices might solve some issues, not sure if it applies to this case though.
Regards,
Tony
Hi Tony,
Am 17.02.2023 um 07:57 schrieb Tony Lindgren tony@atomide.com:
- H. Nikolaus Schaller hns@goldelico.com [230216 11:01]:
a) remove all entries from DTS since they are a subset of the driver code
If they are driver internal data and not ASoC generic bindings or audio graph stuff,
Well, I don't know exactly what they are good for...
you might be able to get away with setting the routing in the driver based on the device specifc compatible value.
I guess they are intended for defining board specific routes like Handsfree speakers available or a microphone connector or alike.
But the table in the driver is just a superset of what panda-common or omap5-common defines in the DTS. So nothing would be missing (except a capability to reduce the list of routes) if we take only this.
Sorry I don't really know anything about this.. But in general avoiding custom dts bindings is the way to go.
Good point since this ti,audio-routing is a vendor-specific extension.
It is used by davinci-evm-audio.txt omap-abe-twl6040.txt omap-twl4030.txt
And using the standard audio graph bindings where possible between devices might solve some issues, not sure if it applies to this case though.
On the other hand it seems to be a common vendor/driver specific scheme for others as well. I find bindings for:
allwinner,audio-routing atmel,audio-routing nvidia,audio-routing qcom,audio-routing samsung,audio-routing
some even converted to .yaml.
An example being: arch/arm/boot/dts/exynos5422-odroid.dts + sound/soc/samsung/odroid.c
There, the driver code also has an internal table (odroid_dapm_routes) but some logic which seems to be related to "old DTS": https://elixir.bootlin.com/linux/v6.2-rc8/source/sound/soc/samsung/odroid.c#...
So it seems to be a common pattern to define the routes not in the driver but in the DTS now and have the internal table only as a fallback?
This would mean to ignore the internal table if there is something in the DTS.
Maybe Peter has a good idea how to proceed.
BR and thanks, Nikolaus
Hi Nicolaus,
On 16/02/2023 13:00, H. Nikolaus Schaller wrote:
Hi Peter and Tony, I am still pushing to get AESS work on the PandaES and the OMAP5 Pyra. We have already great progress, e.g. firmware generation and loading works, all amixers exist and we can see the first frontend interfaces.
Still it is not working - most likely something with power management setup and enabling the dynamic parts of ALSA. For example we get the report that the BE DAIs are not available. Or that mixers are changed while powered down.
wow, great progress!
Now we have run the vizdapm tool and see quite some differences to the 3.15 kernel (and 3.8).
The first observation is that the DAPM routes for e.g. "HSOR" to "Headset Sterephone" are instantiated twice. It turns out that there are almost identical definitions in DTS and in the driver:
https://elixir.bootlin.com/linux/v6.2-rc8/source/arch/arm/boot/dts/omap4-pan... https://elixir.bootlin.com/linux/v6.2-rc8/source/arch/arm/boot/dts/omap5-boa... https://elixir.bootlin.com/linux/v6.2-rc8/source/sound/soc/ti/omap-abe-twl60...
right, back in 3.15 (my last bnw branch) the snd_soc_of_parse_audio_routing() would replace the card.dapm_routes while in 6.2 (or somewhere between) the machine driver defined dapm_routes are kept and snd_soc_of_parse_audio_routing() is storing the routes from DT as card.of_dapm_routes
This is going to create duplication, I would likely drop the routes from the driver. The tricky part might be the dmic section, it has never been in DT for some reason... McBSP also have some funky stuff due to DT naming.
It seems as if the DT definitions are simply a subset of the driver code table.
But there seems to be no mechanism to find duplicates or ignore the driver-builtin routes if they are defined by DTS.
So please what is the best strategy?
a) remove all entries from DTS since they are a subset of the driver code b) remove the driver table audio_map[] completely and add the missing components to the DTS? b) make the driver ignore the audio_map[] table if there are card->of_dapm_routes and add the missing components to the DTS? c) hack snd_soc_dapm_add_routes() to find and ignore duplicates?
I would be in between B and C.
Any advice is welcome.
Best regards, Nikolaus
Hi Peter,
Am 19.02.2023 um 10:14 schrieb Péter Ujfalusi peter.ujfalusi@gmail.com:
Hi Nicolaus,
On 16/02/2023 13:00, H. Nikolaus Schaller wrote:
Hi Peter and Tony, I am still pushing to get AESS work on the PandaES and the OMAP5 Pyra. We have already great progress, e.g. firmware generation and loading works, all amixers exist and we can see the first frontend interfaces. Still it is not working - most likely something with power management setup and enabling the dynamic parts of ALSA. For example we get the report that the BE DAIs are not available. Or that mixers are changed while powered down.
wow, great progress!
Now we have run the vizdapm tool and see quite some differences to the 3.15 kernel (and 3.8). The first observation is that the DAPM routes for e.g. "HSOR" to "Headset Sterephone" are instantiated twice. It turns out that there are almost identical definitions in DTS and in the driver: https://elixir.bootlin.com/linux/v6.2-rc8/source/arch/arm/boot/dts/omap4-pan... https://elixir.bootlin.com/linux/v6.2-rc8/source/arch/arm/boot/dts/omap5-boa... https://elixir.bootlin.com/linux/v6.2-rc8/source/sound/soc/ti/omap-abe-twl60...
right, back in 3.15 (my last bnw branch) the snd_soc_of_parse_audio_routing() would replace the card.dapm_routes while in 6.2 (or somewhere between) the machine driver defined dapm_routes are kept and snd_soc_of_parse_audio_routing() is storing the routes from DT as card.of_dapm_routes
Ok, I see. This would mean that a non-empty snd_soc_of_parse_audio_routing() should remove driver defined routes from audio_map[].
This is going to create duplication, I would likely drop the routes from the driver.
I have found more reasons to go that way. One is the setup of e.g.
{"omap-mcbsp.1 Playback", NULL, "BT_VX_DL"},
This could also be moved to the DTS but there is only one drawback: this ti,audio-routes list is static and all entries must be instantiated. This breaks my fallback strategy if the AESS subsystem isn't compiled into the kernel. Then we don't even have a legacy interface.
So the best strategy might be to move all missing routes from audio_map[] to the DTS and remove them in audio_map (which is then basically empty) but add the AESS specific ones if AESS is configured. And rename it into an aess_audio_map[] just handling this case.
The tricky part might be the dmic section, it has never been in DT for some reason...
Probably the same issue as above. It can't be in DT if the DMICs are not to be used. So they are added on demand.
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.
It seems as if the DT definitions are simply a subset of the driver code table. But there seems to be no mechanism to find duplicates or ignore the driver-builtin routes if they are defined by DTS. So please what is the best strategy? a) remove all entries from DTS since they are a subset of the driver code b) remove the driver table audio_map[] completely and add the missing components to the DTS? b) make the driver ignore the audio_map[] table if there are card->of_dapm_routes and add the missing components to the DTS? c) hack snd_soc_dapm_add_routes() to find and ignore duplicates?
I would be in between B and C.
Fine, then let's go this direction.
BR and thanks, Nikolaus
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 [ 120.868286] snd_soc_dapm_add_route: try widget Vibrator [ 120.873901] snd_soc_dapm_add_route: try widget Headset Mic [ 120.879821] snd_soc_dapm_add_route: try widget Main Handset Mic [ 120.886199] snd_soc_dapm_add_route: try widget Sub Handset Mic [ 120.892456] snd_soc_dapm_add_route: try widget Line In [ 120.898010] snd_soc_dapm_add_route: try widget Digital Mic [ 120.903900] snd_soc_dapm_add_route: try widget MM1 Playback [ 120.909912] snd_soc_dapm_add_route: try widget MM1 Capture [ 120.915802] snd_soc_dapm_add_route: try widget MM2 Capture [ 120.921691] snd_soc_dapm_add_route: try widget Voice Playback [ 120.927886] snd_soc_dapm_add_route: try widget Voice Capture [ 120.933990] snd_soc_dapm_add_route: try widget Tones Playback [ 120.940155] snd_soc_dapm_add_route: try widget Modem Playback [ 120.946350] snd_soc_dapm_add_route: try widget Modem Capture [ 120.952423] snd_soc_dapm_add_route: try widget MMLP Playback [ 120.958496] snd_soc_dapm_add_route: try widget TONES_DL [ 120.964050] snd_soc_dapm_add_route: try widget VX_DL [ 120.969360] snd_soc_dapm_add_route: try widget VX_UL [ 120.969360] snd_soc_dapm_add_route: try widget MM_UL1 [ 120.979949] snd_soc_dapm_add_route: try widget MM_UL2 [ 120.981506] snd_soc_dapm_add_route: try widget MM_DL [ 120.990509] snd_soc_dapm_add_route: try widget MODEM_DL [ 120.996032] snd_soc_dapm_add_route: try widget MODEM_UL [ 120.996368] snd_soc_dapm_add_route: try widget PDM_UL1 [ 121.006958] snd_soc_dapm_add_route: try widget PDM_DL1 [ 121.012359] snd_soc_dapm_add_route: try widget PDM_DL2 [ 121.017791] snd_soc_dapm_add_route: try widget BT_VX_UL [ 121.023284] snd_soc_dapm_add_route: try widget BT_VX_DL [ 121.028839] snd_soc_dapm_add_route: try widget MM_EXT_UL [ 121.034454] snd_soc_dapm_add_route: try widget MM_EXT_DL [ 121.040100] snd_soc_dapm_add_route: try widget DMIC0 [ 121.045318] snd_soc_dapm_add_route: try widget DMIC1 [ 121.050537] snd_soc_dapm_add_route: try widget DMIC2 [ 121.051574] snd_soc_dapm_add_route: try widget MUX_UL00 [ 121.061279] snd_soc_dapm_add_route: try widget MUX_UL01 [ 121.066802] snd_soc_dapm_add_route: try widget MUX_UL02 [ 121.067413] snd_soc_dapm_add_route: try widget MUX_UL03 [ 121.077819] snd_soc_dapm_add_route: try widget MUX_UL04 [ 121.078826] snd_soc_dapm_add_route: try widget MUX_UL05 [ 121.088867] snd_soc_dapm_add_route: try widget MUX_UL10 [ 121.089874] snd_soc_dapm_add_route: try widget MUX_UL11 [ 121.099914] snd_soc_dapm_add_route: try widget MUX_VX0 [ 121.101013] snd_soc_dapm_add_route: try widget MUX_VX1 [ 121.110778] snd_soc_dapm_add_route: try widget DL1 Mixer [ 121.116394] snd_soc_dapm_add_route: try widget DL2 Mixer [ 121.116973] snd_soc_dapm_add_route: try widget DL1 Media Volume [ 121.128326] snd_soc_dapm_add_route: try widget Voice Capture Mixer [ 121.129394] snd_soc_dapm_add_route: try widget Capture Mixer [ 121.140838] snd_soc_dapm_add_route: try widget Sidetone Mixer [ 121.146911] snd_soc_dapm_add_route: try widget DL1 PDM [ 121.152465] snd_soc_dapm_add_route: try widget DL1 BT_VX [ 121.158081] snd_soc_dapm_add_route: try widget DL1 MM_EXT [ 121.159332] snd_soc_dapm_add_route: try widget Sidetone Capture VMixer [ 121.170654] snd_soc_dapm_add_route: try widget Voice Capture VMixer [ 121.177276] snd_soc_dapm_add_route: try widget DL1 Capture VMixer [ 121.180358] snd_soc_dapm_add_route: try widget DL2 Capture VMixer [ 121.190124] snd_soc_dapm_add_route: try widget VX UL VMixer [ 121.196014] snd_soc_dapm_add_route: try widget VX DL VMixer [ 121.196594] snd_soc_dapm_add_route: try widget MM VMixer [ 121.207489] snd_soc_dapm_add_route: try widget BE_OUT [ 121.212799] snd_soc_dapm_add_route: try widget BE_IN [ 121.218048] snd_soc_dapm_add_route: try widget MAINMIC [ 121.223449] snd_soc_dapm_add_route: try widget HSMIC [ 121.228698] snd_soc_dapm_add_route: try widget SUBMIC [ 121.234008] snd_soc_dapm_add_route: try widget AFML [ 121.239196] snd_soc_dapm_add_route: try widget AFMR [ 121.240142] snd_soc_dapm_add_route: try widget HSOL [ 121.249481] snd_soc_dapm_add_route: try widget HSOR [ 121.250549] snd_soc_dapm_add_route: try widget HFL [ 121.259704] snd_soc_dapm_add_route: try widget HFR [ 121.260711] snd_soc_dapm_add_route: try widget EP [ 121.269744] snd_soc_dapm_add_route: try widget AUXL [ 121.272521] snd_soc_dapm_add_route: try widget AUXR [ 121.280029] snd_soc_dapm_add_route: try widget VIBRAL [ 121.281066] snd_soc_dapm_add_route: try widget VIBRAR [ 121.290710] snd_soc_dapm_add_route: try widget Analog Left Capture Route [ 121.297821] snd_soc_dapm_add_route: try widget Analog Right Capture Route [ 121.300231] snd_soc_dapm_add_route: try widget MicAmpL [ 121.310363] snd_soc_dapm_add_route: try widget MicAmpR [ 121.311401] snd_soc_dapm_add_route: try widget AFMAmpL [ 121.321197] snd_soc_dapm_add_route: try widget AFMAmpR [ 121.326629] snd_soc_dapm_add_route: try widget ADC Left [ 121.332183] snd_soc_dapm_add_route: try widget ADC Right [ 121.337799] snd_soc_dapm_add_route: try widget Headset Mic Bias [ 121.344024] snd_soc_dapm_add_route: try widget Main Mic Bias [ 121.350006] snd_soc_dapm_add_route: try widget Digital Mic1 Bias [ 121.356353] snd_soc_dapm_add_route: try widget Digital Mic2 Bias [ 121.356933] snd_soc_dapm_add_route: try widget HSDAC Left [ 121.368377] snd_soc_dapm_add_route: try widget HSDAC Right [ 121.369384] snd_soc_dapm_add_route: try widget HFDAC Left [ 121.379852] snd_soc_dapm_add_route: try widget HFDAC Right [ 121.385620] snd_soc_dapm_add_route: try widget VIBRA DAC [ 121.391235] snd_soc_dapm_add_route: try widget Handsfree Left Playback [ 121.392272] snd_soc_dapm_add_route: try widget Handsfree Right Playback [ 121.405120] snd_soc_dapm_add_route: try widget Headset Left Playback [ 121.411834] snd_soc_dapm_add_route: try widget Headset Right Playback [ 121.418640] snd_soc_dapm_add_route: try widget Vibra Left Playback [ 121.419219] snd_soc_dapm_add_route: try widget Vibra Right Playback [ 121.431793] snd_soc_dapm_add_route: try widget Earphone Playback [ 121.438140] snd_soc_dapm_add_route: try widget AUXL Playback [ 121.444122] snd_soc_dapm_add_route: try widget AUXR Playback [ 121.450134] snd_soc_dapm_add_route: try widget HF Left Driver [ 121.456237] snd_soc_dapm_add_route: try widget HF Right Driver [ 121.461761] snd_soc_dapm_add_route: try widget HS Left Driver [ 121.468414] snd_soc_dapm_add_route: try widget HS Right Driver [ 121.474578] snd_soc_dapm_add_route: try widget Earphone Driver [ 121.480773] snd_soc_dapm_add_route: try widget Vibra Left Driver [ 121.487121] snd_soc_dapm_add_route: try widget Vibra Right Driver [ 121.493530] snd_soc_dapm_add_route: try widget Vibra Left Control [ 121.499938] snd_soc_dapm_add_route: try widget Vibra Right Control [ 121.506622] snd_soc_dapm_add_route: try widget HSDAC Power [ 121.506622] snd_soc_dapm_add_route: try widget HF Left PGA [ 121.518188] snd_soc_dapm_add_route: try widget HF Right PGA [ 121.519683] snd_soc_dapm_add_route: try widget Legacy Playback [ 121.530212] snd_soc_dapm_add_route: try widget Legacy Capture [ 121.535980] snd_soc_dapm_add_route: try widget Capture [ 121.535980] snd_soc_dapm_add_route: try widget Headset Playback [ 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?
BR, Nikolaus
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
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