[RFC 08/13] ASoC: Intel: avs: Declare path and its components

[Cezary Rojewski]

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