All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Brown <broonie@opensource.wolfsonmicro.com>
To: Stephen Warren <swarren@wwwdotorg.org>
Cc: "alsa-devel@alsa-project.org" <alsa-devel@alsa-project.org>,
	Liam Girdwood <lrg@ti.com>
Subject: Re: Confusion about Playback/Capture, CODEC/CODEC	links, and snd_soc_dapm_link_dai_widgets()
Date: Tue, 5 Jun 2012 21:48:01 +0100	[thread overview]
Message-ID: <20120605204758.GA8486@opensource.wolfsonmicro.com> (raw)
In-Reply-To: <4FCE6B0F.6080106@wwwdotorg.org>

On Tue, Jun 05, 2012 at 02:24:47PM -0600, Stephen Warren wrote:

> Initially, I thought that snd_soc_dapm_new_dai_widgets() could just
> return if the DAI already had widgets, but that doesn't work, since the
> widgets were created for the wrong DAPM context - the I2S1 DAP DAI's
> rather than the I2S CODEC's.

> Perhaps instead of blindly probing the CPU DAI, soc_probe_dai_link()
> should check whether that DAI is part of a CODEC, and instead of calling
> try_module_get() and snd_soc_dapm_new_dai_widgets(), it should just call
> soc_probe_codec() on the parent CODEC (guarded by whether the CODEC was
> already probed). Does that sound right? I'm attempting to make that work
> now, in case it's right.

No, we should just probe CODECs sensibly before we do any of the DAIs
instead of trying to guess what we're doing in the middle of handling
the DAI links.  Your changes will be making the logic even more
complicated here, it should be getting simpler - the reason this blew up
for you is that the probe logic is already far too baroque.  Given the
data we have it'll boil down to similar checks bit it'll be in a clear,
comprehensible CODEC probe step rather than intertwined with other
stuff.  This will also mean that aux_devs make more sense.

  reply	other threads:[~2012-06-05 20:48 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-31 22:49 Confusing about Playback/Capture, CODEC/CODEC links, and snd_soc_dapm_link_dai_widgets() Stephen Warren
2012-05-31 23:37 ` Mark Brown
2012-06-01 17:01   ` Liam Girdwood
2012-06-04 13:02     ` Sebastien LEDUC
2012-06-04 16:57       ` Liam Girdwood
2012-06-01 21:41   ` Mark Brown
2012-06-01 22:31   ` Confusion " Stephen Warren
2012-06-05 20:24 ` Stephen Warren
2012-06-05 20:48   ` Mark Brown [this message]
2012-06-05 21:17     ` Stephen Warren
2012-06-05 21:34       ` 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=20120605204758.GA8486@opensource.wolfsonmicro.com \
    --to=broonie@opensource.wolfsonmicro.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=lrg@ti.com \
    --cc=swarren@wwwdotorg.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.