From: Vinod Koul <vinod.koul@intel.com>
To: Mark Brown <broonie@kernel.org>
Cc: liam.r.girdwood@linux.intel.com, patches.audio@intel.com,
alsa-devel@alsa-project.org, Jeeja KP <jeeja.kp@intel.com>
Subject: Re: [PATCH 2/4] ASoC: core: Adds support for cpu loopback dai_link
Date: Wed, 2 Dec 2015 10:53:30 +0530 [thread overview]
Message-ID: <20151202052330.GE1854@localhost> (raw)
In-Reply-To: <20151201122747.GG1929@sirena.org.uk>
[-- Attachment #1.1: Type: text/plain, Size: 1958 bytes --]
On Tue, Dec 01, 2015 at 12:27:47PM +0000, Mark Brown wrote:
> On Tue, Dec 01, 2015 at 08:26:54AM +0530, Vinod Koul wrote:
> > On Mon, Nov 30, 2015 at 04:25:48PM +0000, Mark Brown wrote:
>
> > > Can we make the temporary hack be to check if there's a CODEC defined
> > > in the DAI? It's nasty and fragile but it keeps the hack much better
> > > isolated.
>
> > The flag added here, cpu_loopback would do that and keep this isolated from
> > the rest. The problem with checking if codec is defined will be for dsp
>
> No, it means that the drivers need to set the flag to work around the
> core which is what I want to avoid.
ok fine then
>
> > based loops which terminate in codec. It will not work as we will find codec
> > in the dailink for the voice call (modem-dsp-codec) loop
>
> I'm confused about the situation you're describing here. The
> connections are DAI to DAI so why would any CODEC behind the CPU DAI
> have an impact?
let me try again,
So I would like to for example do a voice call. So I need to DAIlinks for
this. First one is modem-SSP-A and second SSP-B to codec.
I am taking example of SSP-B to codec for configuration
Currently the code envisions that loop is connected as modem-codec, so DAI
links are linked per this assumption
Modem Tx (Pb) ----------> Rx Codec (Cap)
Modem Rx (Cap) <---------- Tx Codec (Pb)
So we link pb-cap and cap-pb connected
But if we do wrt from CPU the situation is different
CPU Tx (Pb) -----------> Codec Tx (Pb)
CPU Rx (Cap) <----------- Codec Rx (Cap)
Since this follows normal playback kind of scenario, we need to link pb-pb
and cap-cap
Now we cannot change this unilaterally so added a flag to signify we want
second mapping for dailink rather then first one
Am okay to change this to something different way, which results in second
mapping from CPU based loops, pls do suggest :)
Thanks
--
~Vinod
[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
next prev parent reply other threads:[~2015-12-02 5:20 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-09 17:49 [PATCH 0/4] ASoC: core: Update for DSP systems Vinod Koul
2015-11-09 17:49 ` [PATCH 1/4] ASoC: core: refactor soc_link_dai_widgets() Vinod Koul
2015-11-18 13:13 ` Applied "ASoC: core: refactor soc_link_dai_widgets()" to the asoc tree Mark Brown
2015-11-09 17:49 ` [PATCH 2/4] ASoC: core: Adds support for cpu loopback dai_link Vinod Koul
2015-11-18 13:17 ` Mark Brown
2015-11-18 13:48 ` Vinod Koul
2015-11-25 16:13 ` Vinod Koul
2015-11-30 16:25 ` Mark Brown
2015-12-01 2:56 ` Vinod Koul
2015-12-01 12:27 ` Mark Brown
2015-12-02 5:23 ` Vinod Koul [this message]
2015-12-02 10:32 ` Mark Brown
2015-12-16 14:48 ` Vinod Koul
2015-12-30 18:03 ` Mark Brown
2016-01-04 15:42 ` Vinod Koul
2015-11-09 17:50 ` [PATCH 3/4] ASoC: core: Pass kcontrol to bytes tlv callbacks Vinod Koul
2015-11-18 13:13 ` Applied "ASoC: core: Pass kcontrol to bytes tlv callbacks" to the asoc tree Mark Brown
2015-11-09 17:50 ` [PATCH 4/4] ASoC: topology: fix info callback for TLV byte control Vinod Koul
2015-11-18 13:13 ` Applied "ASoC: topology: fix info callback for TLV byte control" to the asoc tree 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=20151202052330.GE1854@localhost \
--to=vinod.koul@intel.com \
--cc=alsa-devel@alsa-project.org \
--cc=broonie@kernel.org \
--cc=jeeja.kp@intel.com \
--cc=liam.r.girdwood@linux.intel.com \
--cc=patches.audio@intel.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 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).