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 22:34:48 +0100	[thread overview]
Message-ID: <20120605213447.GA12405@opensource.wolfsonmicro.com> (raw)
In-Reply-To: <4FCE775B.7020901@wwwdotorg.org>

On Tue, Jun 05, 2012 at 03:17:15PM -0600, Stephen Warren wrote:

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

Yeah, something like this.

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

The only user of that is OMAP, I can't remember if they've actually got
their users for that upstream or not.  IIRC it's there to resolve clock
order dependencies but I'm not sure there isn't a neater solution with
something like cache only register I/O especially now we've got better
infrastructure.  Or if we can add something based on having a usable
clock API, we can rely on but that doesn't seem too realistic in the
medium term.

      reply	other threads:[~2012-06-05 21:34 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
2012-06-05 21:34       ` Mark Brown [this message]

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=20120605213447.GA12405@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.