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.
Attachment:
signature.asc
Description: PGP signature
