On 2022-02-25 8:25 PM, Pierre-Louis Bossart wrote:
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
Ack.
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.
A single path is tied to either FE or BE. So at most to a single, user-visible endpoint if it's FE. If there are more FEs, then we move to NxFE <-> 1xBE scenario. You can have many pipelines forming the path - most of the pipelines do not contain module connected to any gateway (HDA/SSP/DMIC etc.) anyway.
Yes, dma_id represents any DMA i.e. HDA stream (DMA), SSP port, DMIC fifo etc. And it's not a concept, it's just a member of a structure. Similar field exists in skylake-driver topology too (it's called "port").
- 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.
The IDs found within the topology file do not reflect the IDs that are going to be assigned dynamically during runtime streaming. We do not specify e.g.: pipeline id=8 is made of copier id=3 and copier id=7. Firmware has limited number of modules that can be instantiated per type so static assignment is a big no no.
- struct avs_path_pipeline *owner;
- /* pipeline bindings management */
- struct list_head node;
+};
+#endif