On 1/30/2022 8:15 PM, Cezary Rojewski wrote:
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.
Although Cezary wrote that avs_path_reset/_pause/_run maps nicely to trigger operation it's not direct mapping. AVS FW has requirements on order of operations on pipelines (which are grouped in paths on kernel side). For example on TRIGGER_STOP we need to first pause all pipelines before issuing reset to any of them. This is required by FW, so that if there are two pipelines it doesn't pause and reset one of them, while the other one is still in running state, as this causes xruns on FW side.
Relevant fragment from "[RFC 27/37] ASoC: Intel: avs: non-HDA PCM BE operations" + case SNDRV_PCM_TRIGGER_STOP: + ret = avs_path_pause(data->path); + if (ret < 0) + dev_err(dai->dev, "pause BE path failed: %d\n", ret); + + if (cmd == SNDRV_PCM_TRIGGER_STOP) { + ret = avs_path_reset(data->path); + if (ret < 0) + dev_err(dai->dev, "reset FE path failed: %d\n", ret); + } + break; +
I would say that such behavior doesn't translate nicely to generic API.
I tried looking once again at how one would split the path concept to make it more generic, but it is hard. On one hand paths are tied to AVS driver topology design, on the other hand we have (mentioned above) FW requirements.
To describe it in more detail, in AVS we need topology as it describes bindings between paths. Simple topologies have route map similar to this one:
SectionGraph."ssp0_Tx_spt-audio-playback" { index "0"
lines [ "ssp0 Tx, , ssp0p_be" "ssp0p_be, , ssp0p_fe" "ssp0p_fe, , spt-audio-playback" ] }
where ssp0p_be and ssp0p_fe are widgets describing BE and FE configuration.
Taking for example FE widget we have:
SectionWidget."ssp0p_fe" { index "0" type "scheduler" no_pm "true" ignore_suspend "false"
data [ "path_tmpl2_data" ] }
where we can see that apart from its own configuration it has additional data describing path inside it:
SectionData."path_tmpl2_data" { tuples [ "path_tmpl2_tuples" "path_tmpl2_path0_tuples" "path_tmpl2_path0_ppl0_tuples" "path_tmpl2_path0_ppl0_mod0_tuples" "path_tmpl2_path0_ppl0_bindid0_tuples" ] }
now for the concept of paths the most interesting field is "path_tmpl2_path0_ppl0_bindid0_tuples" as it describes to which path we want to bind. It is done this way as FW modules internally have pins, and while in most cases one wants to just bind on pin 0, sometimes there is a need to describe more complicated connections. And so we circled back to FW requirements.
Overall I would say that path design in AVS is tied too much to FW requirements to be made generic. And even if some general API was provided we would still need most of current code on AVS path to handle the requirements, while we would have additional constrains coming from API above.
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.
Similarly to the above I'm open to suggestions on how such API may look like.
Best Regards, Amadeusz