[alsa-devel] Ambiguous DAPM widget names and DPCM

[Mark Brown]

On Tue, Jul 23, 2013 at 05:34:59PM +0200, Daniel Mack wrote:
> On 23.07.2013 14:30, Mark Brown wrote:

> > Could you go into more detail about the ambiguity you see here?

> I have a platform which has two codecs (cs4271, ak4101) connected to one
> McASP instance. For DPCM, the link structure looks like this:

>   mcasp <-> snd-soc-dummy, .dynamic = 1
>   mcasp <-> cs4271, .no_pcm = 1
>   mcasp <-> ak4101, .no_pcm = 1

> With printk() in snd_soc_dapm_new_control(), I see the following widgets
> being created during boot (one pair for each Codec, and two pairs for
> the platform dai):

OK, so the issue here is probably that you're overloading the single
McASP object rather than anything else - that's always been a bit of a
hack and I suspect it's going to be causing issues again now.  In which
case we probably do need to bite the bullet on making multi-drop DAIs
work.  But let's see...

> And the widgets referenced by the audio map will hence have to be named
> "Playback" or "Capture" as well, which has no chance to refer to the
> correct one, right?

Lookups are done first in the local DAPM context so so long as the thing
that's setting up the links is doing so in the same context everything
should be OK.  This is needed so you can have two of the same device in
a system.

> > This is obviously required, yes - just as with everything else you
> > shouldn't use the same name twice.

> Yeah, but snd_soc_dapm_new_dai_widgets() relies on
> dai->driver->playback.stream_name and takes that as widget name. So is
> this approach faulty, and the automatically generated name would need to
> be based on dev_name(dai->dev)? Or do we need to clean up all drivers in
> order to make their streams unique? Then again, the question is how to
> deal with multiple instances of the same dai driver, and how to tell
> them apart in the audio map.

The prefix mechanism is intended to address this; however it's only
currently supported for CODECs.  If we move the prefixes to components
then they should be usable for CPU DAIs.

> > 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.

> Which older driver would rely on that, and can we safely remove it?

Probably none right now.
-------------- 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/ae29025e/attachment.sig>