[alsa-devel] [PATCH] ASoC: core: Add support for platform and CODEC drivers on same device

Mark Brown broonie at opensource.wolfsonmicro.com
Fri Mar 15 18:02:59 CET 2013

On Fri, Mar 15, 2013 at 03:35:40PM +0000, Charles Keepax wrote:
> On Sat, Jan 26, 2013 at 05:20:21PM +0800, Mark Brown wrote:
> > On Thu, Jan 24, 2013 at 09:49:11AM +0000, Charles Keepax wrote:

> > > So this patch will check for existing widgets during soc_probe_platform
> > > and only create new widgets if no existing ones exist.

> > ...or as I was sending that it occurred to me that it'd be even neater
> > to share the DAPM context, though that's much more refactoring.

> Looking at this in more detail sharing the DAPM context doesn't
> fix the issue. The problem is related to overwriting the widgets
> on the DAI which means any routes added to the old widgets are
> no longer considered when DAPM processes the DAI. So I will sent

I don't think you've fully understood my suggestion, or what's involved
in much more refactoring.  I can't fully recall the context since it's
been several months since the discussion came up but I suspect the thing
here is that the widgets are mostly a function of the DAPM context so if
we share the context we share the widgets and don't end up creating
multiple copies.

> However, that said there is some argument for sharing the context
> anyway as there is no need for the one device to have two
> contexts associated with it, however I am not sure it is worth
> it. The most sensible way I can see to do so is to replace the
> dapm structs in snd_soc_platform and snd_soc_codec with pointers
> and dynamically allocate the dapm contexts. However this is a

Why would we need to dynamically allocate anything here?  The DAIs
should all be owned by something (the CODEC or, now, the component).
-------------- 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/20130315/f268f628/attachment.sig>

More information about the Alsa-devel mailing list