Re: [RFC 18/37] ASoC: Intel: avs: Topology parsing

[Cezary Rojewski <cezary.rojewski@intel.com>]

On 2021-12-21 6:39 PM, Mark Brown wrote:
> On Wed, Dec 08, 2021 at 12:12:42PM +0100, Cezary Rojewski wrote:
> 
>> Implementation of ASoC topology feature for AVS driver. AudioDSP
>> firmware supports a wide range of audio formats, module configurations
>> and multi-pipeline streams. To represent all of this in form of static
>> ALSA topology file, which resides usually in /lib/firmware/, while
>> simultaneously not hindering user from any of the possibilities, 'path
>> template' and its 'path variants' concept is introduced. These are later
>> converted into actual runtime path. This part is explained in follow-up
>> change.
> 
> This sounds like it should be extending the topology code (it's talking
> about "ALSA topologies") but it seems to be outside of that.
> 
>> Path template is just a pattern like its name suggests. It is tied to
>> DAPM widget which represents a FE or a BE and is used during path
>> instantiation when substream is opened for streaming. It carries a range
>> of available variants and only these represent actual implementation of
>> a runtime path in AudioDSP. Only one variant of given path template can
>> be instantiated at a time and selection is based off of audio format
>> provided from userspace and currently selected one on the codec.
> 
> So this sounds like it's baking a table of use cases into the firmware
> rather than a separate UCM type configuration file?
> 
>> AVS topology is split into two major parts: dictionaries - found within
>> ASoC topology manifest - and path templates - found within DAPM widget
>> private data. Dictionaries job is to reduce the total amount of memory
> 
> Or are the use cases baked into the driver code if they're in the DAPM
> widget private data?

I'm sorry for any confusion that arisen in above commit message. 
avs-driver still makes use of typical UCM files, just like 
skylake-driver does. The file has just a different structure (e.g. 
different tokens used) to do both simultaneously: make use of available 
ASoC-topology structs and types while still allowing for shaping streams 
in recommended/optimal manner on ADSP side.

To better understand what I meant by 'shaping': a stream on ADSP side is 
a sequence of pipelines (a sophisticated containers) where each hosts 
one or a number of modules (processing units). The number of pipelines 
and numbers found within them is not constant.
In almost all cases such stream on ADSP side has a beginning and an end. 
'Gateway' is the word used when describing the edges of a stream. There 
is usually a HOST (cpu side) gateway and a LINK (hw side e.g. I2S; 
'codec' comes probably as the closest relative word from ALSA 
dictionary) gateway. To preserve ADSP memory and reduce power 
consumption there are recommendations of how to shape streams.

ADSP firmware supports a large number of configurations and stream 
layouts. Depending on the environment, (even by changing BE/FE formats 
provided), stream layout can differ. Let's assume 3 ADSP module types: 
module1, module2 and module3 and a single playback FE "Speaker" visible 
in userspace.

Your typical playback on FE: "Speaker" for audio format: 16b, 2ch, 48kHz 
could take following shape:

HOST [ [module1] ] -> [ [module2] ] LINK
	pipeline1	pipeline2

However, for a different format (e.g. 44.1Khz), it might be recommended 
to do:

HOST [ [module1] -> [module3] ] -> [ [module2] ] LINK
	pipeline1			pipeline2

HOST: cpu side
LINK: hw side e.g. I2S interface.

And that's why information attached to DAPM widget's private data 
translates to 'set' of concrete stream implementations (i.e. concrete 
data that is later sent to firmware over IPC) rather than a single 
stream implementation. This 'set' has been called 'path template' and 
each entry a 'path variant'. During runtime, depending on the conditions 
provided in hw_params(), a single variant is selected from the set and 
instantiated.

>> +struct avs_tplg_token_parser {
>> +	enum avs_tplg_token token;
>> +	u32 type;
>> +	u32 offset;
>> +	int (*parse)(struct snd_soc_component *comp, void *elem, void *object, u32 offset);
>> +};
>> +
>> +static int
>> +avs_parse_uuid_token(struct snd_soc_component *comp, void *elem, void *object, u32 offset)
>> +{
>> +	struct snd_soc_tplg_vendor_value_elem *tuple = elem;
>> +	guid_t *val = (guid_t *)((u8 *)object + offset);
>> +
>> +	guid_copy((guid_t *)val, (const guid_t *)&tuple->value);
>> +
>> +	return 0;
>> +}
> 
> I have to say I'm having a hard time telling if these parsers are doing
> the right thing - the interface is a bit obscure and all the void *s
> make it hard to follow, and of course the format is undocumented.  I
> looked through a lot of it but I've definitely not gone through this
> code properly.

Again, I'm sorry for the confusion with the parsing technique used here. 
Ack on the documenting the general idea behind parsing seen in 
topology.c file.

To give some immediate insight:
Each 'struct avs_tplg_token_parser *' instance describes a recipe for 
parsing data coming from UCM topology file and assigning obtained value 
to a field of avs-driver specific structure so it can be used later on 
during runtime - streaming.

Let's take a look at an example:
static const struct avs_tplg_token_parser audio_format_parsers[] = {
	{
		.token = AVS_TKN_AFMT_SAMPLE_RATE_U32
		.type = SND_SOC_TPLG_TUPLE_TYPE_WORD,
		.offset = offsetof(struct avs_audio_format, sampling_freq),
		.parse = avs_parse_word_token,
	},
(...)
};

Entry found above is meant to parse vendor tuples with 
token=AVS_TKN_AFMT_SAMPLE_RATE_U32 and assign value coupled with that 
token to a field 'sampling_freq' of struct avs_audio_format. Let take a 
look at said struct:

struct avs_audio_format {
         u32 sampling_freq;
         u32 bit_depth;
         u32 channel_map;
         u32 channel_config;
         u32 interleaving;
         u32 num_channels:8;
         u32 valid_bit_depth:8;
         u32 sample_type:8;
         u32 reserved:8;
} __packed;

For every member (except for 'reserved' one of corse) of that struct, a 
parser will be assigned so a complete set of information that comes from 
UCM file can be eventually translated into an instance of 'struct 
avs_audio_format *'. 'offset' and 'type' members of struct 
avs_tplg_token_parser are here to ensure correct field is assigned to 
and specify the value-type of such field.

At the top of topology.c file we have placed several helpers, all of 
that is done to drastically reduce the size of code found below them. 
These helpers are also equipped with sanity-checks - these checks were 
one of the major reasons for separating the helper code into functions 
so all the if-statements are not repeated dozens of times.

Now, in regard to types: standard types supported by vendor tuples are 
uuid, bool, byte, short, word and string. We have added a 'default' 
parser for each of them. Again, let's look at an example:

static int
avs_parse_word_token(struct snd_soc_component *comp, void *elem, void 
*object, u32 offset)
{
         struct snd_soc_tplg_vendor_value_elem *tuple = elem;
         u32 *val = (u32 *)((u8 *)object + offset);

         *val = le32_to_cpu(tuple->value);

         return 0;
}

where:
- comp, a soc component that is tied to topology being currently parsed
- elem, an instance of a vendor tuple that is being parsed
- object, an instance of an object which fields are being assigned to 
during currently ongoing parsing procedure
- offset, offset of a field that is a member of type which 'object' is 
instance of

 From here, the flow is straightforward: obtain the pointer to the field 
to assign value of 'tuple->value' to and assign it.

For all 'more advanced' fields, additional parsers have been provided - 
with more checks and such to maintain sanity.


Regards,
Czarek