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