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