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: Confusing about Playback/Capture, CODEC/CODEC links, and snd_soc_dapm_link_dai_widgets()
Date: Fri, 1 Jun 2012 22:41:47 +0100 [thread overview]
Message-ID: <20120601214146.GD4258@opensource.wolfsonmicro.com> (raw)
In-Reply-To: <20120531233702.GA30717@opensource.wolfsonmicro.com>
[-- Attachment #1.1: Type: text/plain, Size: 1070 bytes --]
On Fri, Jun 01, 2012 at 12:37:09AM +0100, Mark Brown wrote:
> On Thu, May 31, 2012 at 04:49:26PM -0600, Stephen Warren wrote:
> > But if (2) is correct, I wonder why soc_dapm_stream_event()'s first if
> > statement appears to consider the playback_widget of both sides of the
> > DAI to be coupled; wouldn't one side's playback widget be coupled to the
> > other side's capture widget?
> The DAIs on CPUs have the opposite sense to DAIs on CODECs. In a
> traditional CPU<->CODEC link we do connect the two playback widgets
> directly to each other. The current code isn't correct, it's not
> normally noticable since most of the time the CPU DAI end of the link is
> a baseband which doesn't do anything real and is always activated
> bidirectionally so it really makes no odds which widget we look at.
> I'll fix this tomorrow.
Sorry, I misremembered the context here (should've looked at the code
not the quote!). The current code is correct, it will only be used in
the case where we have a "real CPU" not the CODEC<->CODEC case so it's
doing the right thing.
[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
next prev parent reply other threads:[~2012-06-01 21:41 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 [this message]
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
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=20120601214146.GD4258@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.