On 2/7/22 07:25, Cezary Rojewski wrote:
> Declare representatives for all crucial elements which stream on ADSP
> side is made of. That covers pipelines and modules subject which are
> presented by struct avs_path_pipeline and avs_path_module respetively.
respectively
> While struct avs_path_binding and struct avs_path do not represent any
> object on firmware side directly, they are needed to help track the
> interconnections and membership of every pipeline and module created.
> +struct avs_path {
> + u32 dma_id;
that is very surprising...
This would seem to limit the concept of an avs path to a single host DMA
channel, which somewhat contradicts that there can be multiple pipelines
in the same path, or that a path can contain mixers.
And even if this is a single dma, what does this represent? the
stream_tag? the BE DMA for SSP/DMIC?
Please clarify the concepts first, it's frustrating to discover this at
patch 8.
> + struct list_head ppl_list;
> + u32 state;
> +
> + struct avs_tplg_path *template;
> + struct avs_dev *owner;
> + /* device path management */
> + struct list_head node;
> +};
> +struct avs_path_binding {
> + struct avs_path_module *source;
> + u8 source_pin;
> + struct avs_path_module *sink;
> + u8 sink_pin;
> +
> + struct avs_tplg_binding *template;
I must admit not clearly seeing how the definitions of
'avs_path_binding' and 'avs_tplg_binding' are related.
More specifically, having a template for something that directly
connects a source to a sink is far from intuitive.
> + struct avs_path_pipeline *owner;
> + /* pipeline bindings management */
> + struct list_head node;
> +};
> +
> +#endif
