The topology2 framework allows for code reuse, modularity, macros and arithmetic to determine settings.

Sadly, our existing cavs topologies are 'developer' level and a number of ground rules were forgotten.

• all controls and PCM names SHALL have a meaningful name.

"volume playback 1' is not acceptable, each PGA and control shall be clearly identified with a pipeline information and position in the pipeline.
The use of 'master' SHALL be revisited. There SHALL not be more than one 'master' control on a path to an endpoint.

when possible, all PCM and control names SHALL be backwards compatible with existing UCM files. Don't be creative.

• topology2/cavs files SHALL have the same level of modularity as topology1. We know e.g. for HDaudio/SoundWire/I2S that we'll have tons of variations (jack, no jack, echo reference, one amp, 2 amps, BT, HDMI with 3/4 streams). We have to track and make sure all variability in topology1 is supported in topology2

• the indices used for pipelines and components matter. in topology1 we could easily identify when a pipeline was connected to SSP0. This information is lost in topology2. so the rule is that just by using at the topology viewer, anyone SHALL be able to know which PCM device to use to play on a specific DAI.

Example of poor index management can be seen on this topology:

copier.host.1.1 is not related to the PCM index.
copier.SSP.12.1 is not related to the DAI index.
All modules use '.1' at the end except the copier.module.8.2. It's unclear what all these 1s mean, and which we need a different convention for a copier?

• all generated topology2 files SHALL be named with the conventions used in the kernel. A topology file that is not known to the kernel SHALL be moved to a developer directory. (Done)

Examples of bad names: cavs-mtl-sdw-dmic cavs-sdw-src-gain-mixin cavs-mixin-mixout-hda-2ch-tgl cavs-tgl-nocodec cavs-passthrough-hdmi
Examples of good names: sof-mtl-nocodec
That's actually the only good name in the entire set of topology2 files....

Common sense really.