On Tue, 2013-07-23 at 10:30 +0200, Daniel Mack wrote:
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.
You might be the first to hit this as I never hit it with OMAP4 or the Haswell DSP code (but it's possible everything just worked for me).
Fwiw, the Haswell audio DSP code can be found here :-
https://git.kernel.org/cgit/linux/kernel/git/lrg/asoc.git/log/?h=intel/haswe...
Dynamic Compressed audio support is now in this branch too.
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?
I did initially have something like that for OMAP that based the DAI widget name on the DAI device name, but this also needed something that would work for codecs with multiple DAI's. In the end it wasn't required for OMAP, but it sounds like something like a unique name is required now.
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.
Hmm, it looks like your FE is being treated as a regular static PCM in this case.
Liam