On Tue, Jul 23, 2013 at 10:30:16AM +0200, Daniel Mack wrote:
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
Could you go into more detail about the ambiguity you see here?
I hacked the names of all components so they are unique, but even then,
This is obviously required, yes - just as with everything else you shouldn't use the same name twice.
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.
The theory here is that the CPUs should be converted into components and then have the DAIs instantiated at component probe time - the creation at link time is there as a crutch for older drivers.
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.
Yes, there's zero use in mainline. I don't think this code has ever been tested.