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
