All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stephen Warren <swarren@wwwdotorg.org>
To: Mark Brown <broonie@opensource.wolfsonmicro.com>
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, 05 Jun 2012 15:17:15 -0600	[thread overview]
Message-ID: <4FCE775B.7020901@wwwdotorg.org> (raw)
In-Reply-To: <20120605204758.GA8486@opensource.wolfsonmicro.com>

On 06/05/2012 02:48 PM, Mark Brown wrote:
> 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.

OK, that's actually what my inclination was, but I wasn't sure about
changing all the probing in such a radical way, so I didn't mention it.

So, should the logic be something like this early-ish in
snd_soc_instantiate_card():

for every dai link:
    if cpu side is a codec and it isn't probed
        probe it
    if codec side isn't probed
        probe it
something similar for aux devs
something similar for platforms?

And modify soc_probe_dai_link() to only probe DAIs, never anything else.

Is the following loop still required:

> 	/* early DAI link probe */
> 	for (order = SND_SOC_COMP_ORDER_FIRST; order <= SND_SOC_COMP_ORDER_LAST;
> 			order++) {

I'm not sure what the probe ordering stuff is achieving, and whether
it's really intended for just CPU DAIs, just all DAIs, just CODECS,
everything...

  reply	other threads:[~2012-06-05 21:17 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
2012-06-05 21:17     ` Stephen Warren [this message]
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=4FCE775B.7020901@wwwdotorg.org \
    --to=swarren@wwwdotorg.org \
    --cc=alsa-devel@alsa-project.org \
    --cc=broonie@opensource.wolfsonmicro.com \
    --cc=lrg@ti.com \
    /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.