topology1: add sof-rpl-rt711-l0-rt1316-l12.tplg support

[bardliao]

Adding sof-rpl-rt711-l0-rt1316-l12.tplg. The topology is the same as sof-rpl-rt711-l0-rt1316-l12-rt714-l3, but without local mic (rt714).

[mengdonglin]

@KV2019 This is for customer RPL device. Should such topology updates go to v2.2.x or v2.7?

[kv2019i]

@mengdonglin so this needs to be backported to stable-v2.2 and then include it to a sof-bin release that will include the latest v2.2-tplg package

@lgirdwood we probably should remove all these Intel tplg1 files from main, to make it clear tplg1 updates (for Intel platforms) need to be submitted to stable-v2.2

[plbossart]

@lgirdwood we probably should remove all these Intel tplg1 files from main, to make it clear tplg1 updates (for Intel platforms) need to be submitted to stable-v2.2

Or move topologies out of the sof repos....

[marc-hb]

Or move topologies out of the sof repos....

And then move them back in a couple years later :-)

• [FEATURE] remove SOF build time dependency to rimage headers #8178 (comment)

Quoting that issue:

https://en.wikipedia.org/wiki/Conway%27s_law aside (does not apply here), the ability to make arbitrary combinations is probably the only good reason to have multiple, independent repos. For instance we want the latest SOF-TEST branch to be able to test most SOF branches out of the box. We don't want to branch SOF-TEST every time that we branch SOF, that would be much more work. Obviously, you also don't want SOF-TEST code to change while bisecting SOF. So: a different repo for SOF-TEST. It's different for lower level CMocka unit tests which are in the same repo.

So is there a frequent need to test arbitrary combinations of sof.git version X with sof-TPLG.git version Y [*]? I haven't heard of any so far. If not then a separate repo is a lot of overhead for no value.

[*] I really mean source repos in git. Binary releases are different; many projects release multiple packages from a single repo all the time, this is routine.