alsa-devel.alsa-project.org archive mirror
 help / color / mirror / Atom feed
From: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
To: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: tiwai@suse.de, alsa-devel@alsa-project.org,
	patches@opensource.wolfsonmicro.com, liam.r.girdwood@intel.com
Subject: Re: [PATCH] ASoC: core: Add support for platform and CODEC drivers	on same device
Date: Fri, 15 Mar 2013 15:35:40 +0000	[thread overview]
Message-ID: <20130315153540.GC2141@opensource.wolfsonmicro.com> (raw)
In-Reply-To: <20130126092020.GH30594@opensource.wolfsonmicro.com>

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
in a patch which does the check in snd_soc_dapm_new_dai_widgets
as that is indeed a more robust and general solution.

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
fair amount of dynamic allocation and leaves a lot of user code
that needs updating (albiet trivially), all just to avoid a
pointlessly duplicated context that does no harm. I do have some
patches moving down this direction whilst I was investigating it
so let me know if this is something we might be interested in
seeing and I will look to find some time to get them into a state
they could be pushed out for comments.

Charles

  reply	other threads:[~2013-03-15 15:35 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-24  9:49 [PATCH] ASoC: core: Add support for platform and CODEC drivers on same device Charles Keepax
2013-01-26  9:19 ` Mark Brown
2013-01-26  9:20 ` Mark Brown
2013-03-15 15:35   ` Charles Keepax [this message]
2013-03-15 15:38     ` [PATCH v2] ASoC: dapm: " Charles Keepax
2013-03-15 18:00       ` Mark Brown
2013-03-15 17:02     ` [PATCH] ASoC: core: " Mark Brown

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20130315153540.GC2141@opensource.wolfsonmicro.com \
    --to=ckeepax@opensource.wolfsonmicro.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=broonie@opensource.wolfsonmicro.com \
    --cc=liam.r.girdwood@intel.com \
    --cc=patches@opensource.wolfsonmicro.com \
    --cc=tiwai@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).