From: Mark Brown <broonie@kernel.org>
To: Codrin Ciubotariu <codrin.ciubotariu@microchip.com>
Cc: alsa-devel@alsa-project.org, linux-kernel@vger.kernel.org,
lgirdwood@gmail.com, tiwai@suse.com, perex@perex.cz,
lars@metafoo.de
Subject: Re: [RFC PATCH] ASoC: pcm_dmaengine: Add support for BE DAIs
Date: Tue, 8 Dec 2020 17:04:22 +0000 [thread overview]
Message-ID: <20201208170422.GG6686@sirena.org.uk> (raw)
In-Reply-To: <20201202085838.1779525-1-codrin.ciubotariu@microchip.com>
[-- Attachment #1: Type: text/plain, Size: 1153 bytes --]
On Wed, Dec 02, 2020 at 10:58:38AM +0200, Codrin Ciubotariu wrote:
> This patch is more or less incomplete for the described scenario. This
> is because DMAengine's pcm->config is ignored for the BE DAI link, so
> runtime->hw is not updated. Also, since pcm_construct/destruct are not
> called, the DMA channels are allocated only if DT is used.
> Underrun/overrun support would also be a nice to have for the transfers
> involving the buffer allocated for the BE.
> One way to hold trach of these would be to use a substream_be->runtime
> different than the one used for the FE.
> Please share your thoughts.
I have a hard time getting enthusiastic about this but I think that's
more DPCM than anything else. Otherwise this looks sensible as far as
it goes. I don't have particular thoughts on exposing errors for the
BEs - we could do a dummy PCM, TBH that bodge was used in the past for
CODEC<->CODEC links but it's obviously inelegant and messy so I'm not
sure it'd help more than just doing something like log the messages in
the kernel. It certainly doesn't seem good to introduce anything that
is visible to userspace but is DPCM specific.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2020-12-08 17:05 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-02 8:58 [RFC PATCH] ASoC: pcm_dmaengine: Add support for BE DAIs Codrin Ciubotariu
2020-12-08 17:04 ` Mark Brown [this message]
2020-12-08 19:26 ` Codrin.Ciubotariu
2020-12-08 19:31 ` Mark Brown
2020-12-11 18:00 ` Codrin.Ciubotariu
2020-12-14 17:19 ` 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=20201208170422.GG6686@sirena.org.uk \
--to=broonie@kernel.org \
--cc=alsa-devel@alsa-project.org \
--cc=codrin.ciubotariu@microchip.com \
--cc=lars@metafoo.de \
--cc=lgirdwood@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=perex@perex.cz \
--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 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).