[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20201208170422.GG6686@sirena.org.uk>
Date: Tue, 8 Dec 2020 17:04:22 +0000
From: Mark Brown <broonie@...nel.org>
To: Codrin Ciubotariu <codrin.ciubotariu@...rochip.com>
Cc: alsa-devel@...a-project.org, linux-kernel@...r.kernel.org,
lgirdwood@...il.com, tiwai@...e.com, perex@...ex.cz,
lars@...afoo.de
Subject: Re: [RFC PATCH] ASoC: pcm_dmaengine: Add support for BE DAIs
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.
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists