linux-kernel - Re: [RFC PATCH] ASoC: pcm_dmaengine: Add support for BE DAIs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 8 Dec 2020 19:26:35 +0000
From:   <Codrin.Ciubotariu@...rochip.com>
To:     <broonie@...nel.org>
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 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