[alsa-devel] Ambiguous DAPM widget names and DPCM

Mark Brown broonie at kernel.org
Tue Jul 23 14:30:17 CEST 2013


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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://mailman.alsa-project.org/pipermail/alsa-devel/attachments/20130723/8f1ba7f9/attachment.sig>


More information about the Alsa-devel mailing list