From: Jerome Brunet <jbrunet@baylibre.com>
To: Mark Brown <broonie@kernel.org>
Cc: alsa-devel@alsa-project.org, lgirdwood@gmail.com,
jiada_wang@mentor.com, linux-kernel@vger.kernel.org,
tiwai@suse.com
Subject: Re: [PATCH 1/1] ASoC: soc-pcm: DPCM cares BE channel constraint
Date: Tue, 26 Jun 2018 14:08:40 +0200 [thread overview]
Message-ID: <1530014920.2900.50.camel@baylibre.com> (raw)
In-Reply-To: <20180626115526.GC1779@sirena.org.uk>
On Tue, 2018-06-26 at 12:55 +0100, Mark Brown wrote:
> On Tue, Jun 26, 2018 at 12:18:38PM +0200, Jerome Brunet wrote:
> > On Wed, 2018-06-20 at 18:25 +0900, jiada_wang@mentor.com wrote:
> > > + /* DPCM used FE & BE merged channel */
> > > + unsigned int dpcm_merged_chan:1;
> > Jiada, Mark,
> > Do you think we could extend this flag to let the link choose whether the merge
> > should be performed on the codec dais (as done here) or on the backend cpu dais
> > ?
> > I have more less the same need as Jiada but since my card uses multicodec links,
> > merging on the codec dais does not work for me.
> > Like in soc_pcm_init_runtime_hw(), we can't enforce channels min/max based on
> > the codec when there is multiple codecs on the link.
>
> Ugh, probably that'd work. The ideal thing would be to remove DPCM but
> we're stuck with it for the time being :(
>From comment here and in other mails, I get that you are not big fan of DPCM :)
It is indeed a complex beast ...
It there anything else we can use to represent audio routing within the SoC ?
The SoC I'm working on make heavy use of this, unfortunately.
WARNING: multiple messages have this Message-ID (diff)
From: Jerome Brunet <jbrunet@baylibre.com>
To: Mark Brown <broonie@kernel.org>
Cc: jiada_wang@mentor.com, lgirdwood@gmail.com, perex@perex.cz,
tiwai@suse.com, alsa-devel@alsa-project.org,
linux-kernel@vger.kernel.org
Subject: Re: [alsa-devel] [PATCH 1/1] ASoC: soc-pcm: DPCM cares BE channel constraint
Date: Tue, 26 Jun 2018 14:08:40 +0200 [thread overview]
Message-ID: <1530014920.2900.50.camel@baylibre.com> (raw)
In-Reply-To: <20180626115526.GC1779@sirena.org.uk>
On Tue, 2018-06-26 at 12:55 +0100, Mark Brown wrote:
> On Tue, Jun 26, 2018 at 12:18:38PM +0200, Jerome Brunet wrote:
> > On Wed, 2018-06-20 at 18:25 +0900, jiada_wang@mentor.com wrote:
> > > + /* DPCM used FE & BE merged channel */
> > > + unsigned int dpcm_merged_chan:1;
> > Jiada, Mark,
> > Do you think we could extend this flag to let the link choose whether the merge
> > should be performed on the codec dais (as done here) or on the backend cpu dais
> > ?
> > I have more less the same need as Jiada but since my card uses multicodec links,
> > merging on the codec dais does not work for me.
> > Like in soc_pcm_init_runtime_hw(), we can't enforce channels min/max based on
> > the codec when there is multiple codecs on the link.
>
> Ugh, probably that'd work. The ideal thing would be to remove DPCM but
> we're stuck with it for the time being :(
From comment here and in other mails, I get that you are not big fan of DPCM :)
It is indeed a complex beast ...
It there anything else we can use to represent audio routing within the SoC ?
The SoC I'm working on make heavy use of this, unfortunately.
next prev parent reply other threads:[~2018-06-26 12:08 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-20 9:25 [PATCH 1/1] ASoC: soc-pcm: DPCM cares BE channel constraint jiada_wang
2018-06-20 9:25 ` jiada_wang
2018-06-22 14:57 ` Applied "ASoC: soc-pcm: DPCM cares BE channel constraint" to the asoc tree Mark Brown
2018-06-22 14:57 ` Mark Brown
2018-06-26 10:18 ` [PATCH 1/1] ASoC: soc-pcm: DPCM cares BE channel constraint Jerome Brunet
2018-06-26 10:18 ` [alsa-devel] " Jerome Brunet
2018-06-26 11:55 ` Mark Brown
2018-06-26 11:55 ` [alsa-devel] " Mark Brown
2018-06-26 12:08 ` Jerome Brunet [this message]
2018-06-26 12:08 ` Jerome Brunet
2018-06-26 14:18 ` Mark Brown
2018-06-26 14:18 ` [alsa-devel] " 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=1530014920.2900.50.camel@baylibre.com \
--to=jbrunet@baylibre.com \
--cc=alsa-devel@alsa-project.org \
--cc=broonie@kernel.org \
--cc=jiada_wang@mentor.com \
--cc=lgirdwood@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=tiwai@suse.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.