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