The base_cfg_ext can be used to configure the pins of the module, yes. It can configure individual pins selectively.

If the module for example have 4 input and 2 output pins and only input pin 3 and output pin 0 is used, then the base_cfg_ext shall be:

u16 num_sink_pin_fmts = 1;
u16 num_source_pin_fmts = 1;
u8 reserved[12];
struct sof_ipc4_pin_format sink_pin_fmt[1];
struct sof_ipc4_pin_format source_pin_fmt[1];

Despite that the module have altogether 6 pins, the cfg_ext only have format for the two used pins.

By the current implementation, the sink_pin_fmt will contain the format from the base config (common for pin0s) and the format for the source pin would be coming as a individual section from tplg?

@ujfalusi this implementation assumes that the token num_source_pins/num_sink_pins coming from topology is the number of pins that are actually used by the processing module. so if the module supports a max of 4 and 3 input/output pins but only 1 input/output pin is used, the tplg must set the num_source_pins/num_sink_pins to 1/1.

Do we require that all pins must have format specified? If the module have only single src and sink pins then by definition the formats are derived from the common format and there will be no pin format in tplg.

@ujfalusi requiring the parsing of swidget->num_sink_pins + swidget->num_source_pins doesnt mean that we require the tplg to have set all the pin formats. This function will try to find a max of that many pin formats but will not complain if there are less than that. So if a module doesnt use all its pins, the tplg need only have as many pin formats as needed

Confused as well. no idea what the mapping between pins and formats is.

what's the difference between ch_map and ch_cfg?

does this mean container size? It's very poorly defined IMHO

sampling rate? Unit?

@plbossart all definitions here follow the same format as the input/output audio format defined above. The only reason we need a new token set is because the audio format tokens are meant only for Pin 0. And historically we've never really had units or descriptions in this file. All units, definitions and permissble values are defined in the structure that these tokens are parsed into. For example, struct sof_ipc4_audio_format {}

and what prevents us to add a bit more clarity moving forward? The reason why we didn't have explanations before is that the definitions were self-explanatory, but now they clearly aren't.

in addition, why on earth would we redefine the terms used in the documentation. This is listed as SAMPLING_FREQUENCY.

what is a fmt_cfg, givent that we've already listed all possible options for the format?

'the' audio format for the pin means there is only ONE format allowed, or that ONE format is required? Super confusing.

I am confused, what would the initialization type from from the topology tokens? Is this not something hard-coded in the module code?

why is this part for the topology definitions?

because we dont have anything to indicate this in the manifest today, It might change tomorrow but until then this needs to come from topology

that's completely broken, I can't sign-off on this. @lgirdwood @mwasko we need clearer definitions on what each module requires, and we need them reported to the kernel. We can't put module-related stuff in the topology, that's just wrong and error prone.

how on earth does this work? there is an unused 'valid bit' definition, and we use this super-complicated macro instead.

This is beyond confusing.

I found it not so obvious how it is ensured this does not match output pins. But output pins are always stored after the input pins, so this check is ok.