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
