Ambiguous DAPM widget names and DPCM

[Daniel Mack <zonque@gmail.com>]

Hi Mark,
Hi Liam,

I spent some hours reverse-engineering the DPCM code, and I plan to
prepare a patch to add some documentation once I've assembled a fully
working setup. However, I have a general question regarding DAPM widget
names.

DPCM uses DAPM widgets and routes in order to determine the FE <-> BE
connections at runtime. The problem with this is that widget names are
very ambiguous, as the automatically created widgets for DAIs are named
after their stream_name properties, which contain "Playback" or
"Capture" for all components in my case. Hence, the code which walks the
connections (snd_soc_dapm_dai_get_connected_widgets()) will most likely
match the wrong one (which has empty sound/sink lists), which results in
a failure like this:

[   16.606268]  fe: ASoC: fe no valid playback route

I hacked the names of all components so they are unique, but even then,
the problem is that snd_soc_dapm_new_dai_widgets() is called twice for
the CPU DAI, once from soc_probe_platform(), and later from
soc_probe_link_dais(), and both calls would create DAPM widgets with
identical names, resulting in the same problem as described above.

I don't know how to handle this, but I believe that nobody was really
hit by this issue yet, as DPCM doesn't seem to be used widely, at least
not by any machine code in mainline.

One idea would be to change the automatically generated names of DAI
widgets in order to make them unique, or re-factor the lookup routines.

Any opinion on that? Do I miss a general consideration here?

With more hacks in place, the setup somehow succeeds, but when the
stream is opened, we'll hit a BUG() in sound/core/pcm_memory.c, because
the FE device's DMA type is undefined. But that's another topic I'll
address later.


Thanks,
Daniel