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

[Cezary Rojewski]

On 2022-01-28 6:00 PM, Mark Brown wrote:


Plenty of good comments, thank you.

As there are several subjects that are part of current discussion, in 
this reply I've decided to focus on 'avs_path'. I'll continue the 
discussion regarding rest of the subjects later on.

> 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.

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

Mentioned all of this as
	_fixed sets of instantiations that can be switched between_
in my opinion implies existence of some sort of pre-allocated paths 
(modules, pipelines) on DSP side, what is not the case here.

> I suspect that at least the template could be pulled apart, and that the
> DMA ID is identifying one end of the pipeline which seems like a concept
> that could be made generic, even though the specific implementation of
> it is going to be firmware/hardware specific.

...

> I think part of the problem here is that there's missing framework,
> coupled with the scaling issues that DPCM has.  Ideally routing in a
> digital context shouldn't be fundamentally different to how we route in
> an analogue context, there's new bits needed for format management (both
> tracking what's valid and ensuring there's appropriate conversions) and
> we really want to be able to dynamically add and remove purely software
> components.  Unfortunately work on actually implementing this mostly
> stalled out.

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.

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.


Regards,
Czarek