Re: [RFC 00/37] ASoC: Intel: AVS - Audio DSP for cAVS

[Mark Brown <broonie@kernel.org>]

[-- Attachment #1: Type: text/plain, Size: 3596 bytes --]

On Sun, Jan 30, 2022 at 08:15:26PM +0100, Cezary Rojewski wrote:
> On 2022-01-28 6:00 PM, Mark Brown wrote:

> > AIUI the firmware itself has a bunch of DSP modules that can be
> > dynamically instantiated and what the path stuff is doing is providing
> > fixed sets of instantiations that can be switched between.  It seems
> > like it should be possible to pull out the bit where we have sets of
> > modules we can instantiate from the mechanics of knowing what modules
> > are there and actually setting them up and tearing them down, other DSP
> > implementations would probably be able to benefit from that (at least
> > the larger ones) and I imagine more advanced users would find it useful
> > to be able to reconfigure the DSP pipelines separately from getting
> > firmware releases.

> There is also a notion of 'pipeline'. In cAVS ADSP case, almost all modules
> require parent pipeline in order to be instantiated. Mentioning this as
> modules alone are insufficient to create an audio stream.

> 'avs_path' is a runtime representative.
> 'avs_path_template' is a recipe for avs_path. All templates are created
> during topology load procedure.
> No modules or pipelines exist on DSP side until driver begins the
> (CREATE_PIPELINE + INIT_INSTANCE) IPC sequence. That happens during
> ->hw_params() callback of a DAI.

That doesn't sound like a particularly unsurprising requirement for
firmware to have TBH - I'd expect we'd need generic handling for
partially constructed paths, including only actually instantiating them
when they're complete (in a similar manner to only powering on analogue
paths when everything is joined up).

> So, avs_path_template provides a fixed set of recipes to create concrete
> avs_path what effectively creates modules and pipelines on DSP side.

Sure, I get that that's what it's doing.

> path-API found in path.h is limited and maps nicely to DAI operations:

> avs_path_create()
> avs_path_bind(struct avs_path *path)
> 	used during DAI's ->hw_params()

> avs_path_free(struct avs_path *path)
> avs_path_unbind(struct avs_path *path)
> 	used during DAI's ->hw_free()

> avs_path_reset(struct avs_path *path)
> avs_path_pause(struct avs_path *path)
> avs_path_run(struct avs_path *path, int trigger)
> 	state setters, used during DAI's ->prepare() and ->trigger()

> given this picture, one could say that there are framework elements that
> allow driver writer to implement whatever is needed for DSP-capable driver.

Right, which points towards pulling bits of it that can be made generic
out of the driver and shared with other DSP implementations.

> And now back to the _full picture_ that I'm clearly not seeing yet. How do
> you envision interfaces that should be added to the ASoC framework? Are we
> talking about soc-path.c level of a change? It would be helpful to have even
> a single operation (from the list above) drawn as an example of what is
> expected.

I don't have an off the shelf answer for you here, like I said half the
thing here is to split this out from the rest of the series so it can be
considered separately.  The digital domain stuff is obviously key here,
the main extra bit for any sort of dynamic DSP routing seems to be
working out a way for userspace to set up and remove new paths - that's
probably new userspace ABI.  Perhaps that's a runtime thing with initial
setup in UCM.  Or perhaps it's better to have something closer to what
you have done but split out like topology is so that the bulk of the
code is reusable with other firmwares and there's a thinner layer with
the firmware specific bits in it.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]