Unable to open hostless PCM device after introduction of commit - ASoC: Stop dummy from overriding hwparams

[Mark Brown]

On Mon, Nov 21, 2022 at 04:29:19PM +0100, Amadeusz Sławiński wrote:

> And finally "snd-soc-dummy" which as mentioned above calls dummy_dma_open
> which originally overridden hwparams set in avs_component_open() with its
> own limited ones.

...

> However, looking at it again, I would consider the existence of
> dummy_dma_open() to be scope creep. If component is really a dummy one it
> should not affect any other components in any way. And if any drivers
> depends on dummy setting parameters for it, I would consider it partially
> broken. And would say that issue should rather be fixed on driver side by
> making a dedicated component for it instead of using a dummy one.

That's not such a clear statement in this case.  The thing with the
hostless links Qualcomm are trying to use here is that we don't actually
want to do any DMA ops at all, these paths never go to memory.  Really
they're CODEC to CODEC links but done in an older way.  There's only DMA
ops there because we need something to keep userspace happy, they don't
actually mean anything and we'd never want them to be used if anything
else is providing actual parameters.

It would be cleaner if these systems were to use a CODEC to CODEC link
but I'm not sure how well that plays with DPCM - the whole thing is a
bit of a house of cards there.

In any case, any news on a fix for this?  The suggestion of a
custom/variant version of the dummy component that explicitly flags that
it's supposed to be used in a hostless configuration does seem like the
least fragile thing.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://mailman.alsa-project.org/pipermail/alsa-devel/attachments/20221125/eca8a2a5/attachment.sig>