linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: <Codrin.Ciubotariu@microchip.com>
To: <broonie@kernel.org>
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 19:26:35 +0000	[thread overview]
Message-ID: <7ab6bffa-f88e-3e2b-287a-89eee2c01819@microchip.com> (raw)
In-Reply-To: <20201208170422.GG6686@sirena.org.uk>

On 08.12.2020 19:04, Mark Brown wrote:
> 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.
> 

It is DPCM indeed. Well, the first scenario (PCM1) is.
I do not intend to create a PCM for the DAI link, when it is a BE. What 
I meant to say with the runtime->hw is that is mustn't be touched by the 
BE's platform, but there should be something similar (placed elsewhere) 
to consider pcm->config.
The thing is that, in my case, exactly the same DAI link (same cpu, 
codec, platform components) can be a normal DAI link or a BE DAI link. I 
hope to register both PCMs (dynamic with FE and normal), to be able to 
skip the FE DAI link if it's not needed and use the normal PCM variant, 
with the same DAI components used in the BE DAI link. For this, I need a 
platform driver that is not interacting with substream->runtime when is 
part of a BE DAI link. I don't think anyone else is using the SOC 
generic dmaengine as a DAI platform component in a BE.
I do not know too much about the dummy PCM. It seems like it is creating 
a card without DPCM links and fakes a buffer, which is not quite what I 
need. I will investigate more.

Thank you for your sharing your ideas!

Best regards,
Codrin

  reply	other threads:[~2020-12-08 21: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
2020-12-08 19:26   ` Codrin.Ciubotariu [this message]
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=7ab6bffa-f88e-3e2b-287a-89eee2c01819@microchip.com \
    --to=codrin.ciubotariu@microchip.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=broonie@kernel.org \
    --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).