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