topology: sof-cml-rt5682: change SSP port num for rt5682

[ranj063]

The CML board has the rt5682 connected to SSP0 and the
machine driver defines the dai link for the headset
with the name "SSP0-codec" too. So change the topology
file accordingly.

Signed-off-by: Ranjani Sridharan ranjani.sridharan@linux.intel.com

[plbossart]

isn't this going to break the RVP-based solution? the WHL-based solution does use SSP1 as a quirk (see the sof_rt5682.c machine driver (line 66) , and we have no way of detecting differences between WHL and CML.

[ranj063]

@plbossart yes it will. Should we have 2 separate tplg files then?

[lgirdwood]

@ranj063 yes two files, but it seem the kernel has no way of knowing which to load ? @plbossart DMI name for differentiation ?

[plbossart]

On 2/7/19 3:24 PM, Liam Girdwood wrote: @ranj063 <https://github.com/ranj063> yes two files, but it seem the kernel has no way of knowing which to load ? @plbossart <https://github.com/plbossart> DMI name for differentiation ?

it's a bit overkill to change topology files just for a single SSP. See how painful it is to maintain alignment between files that use the same SSPs...We should really have something to change the topology directly - which would have the added benefit of solving my Baytrail-CR problem where we need to use SSP0 instead of SSP2.

…

[ranj063]

@plbossart I have a crazy idea of maybe avoiding the SSP numbers from topology. With a little bit of intelligence built into the topology parser, we can derive that information from the machine driver. Let me think about this today.

[lgirdwood]

@ranj063 we will have FW with no OS or other OS so any port mapping must be explicit from topology.
@plbossart we can still use the same file, but we have a macro for SSP port that is set differently depending on whether we build topology for CML or another.

[plbossart]

On 2/8/19 2:53 AM, Liam Girdwood wrote: @ranj063 <https://github.com/ranj063> we will have FW with no OS or other OS so any port mapping must be explicit from topology. @plbossart <https://github.com/plbossart> we can still use the same file, but we have a macro for SSP port that is set differently depending on whether we build topology for CML or another

It's really painful to have to maintain this and the selection. It's a generic problem we have and we should try and solve it with a better solution. We already do a DMI-based hack in the machine driver, I don't want to replicate this for the topology selection.

…

[ranj063]

@plbossart @lgirdwood sure, I will add the option to choose which platform the topology is being built for

[plbossart]

We really need think about distributions. They will generate a set of files and that will be it. The approach where we can dynamically change the topology file depending on what is needed is very nice for developers, but can't work for distros. we really a have two solutions
a) use multiple topology files, and quirks to define which one is used
b) use a single file but logic that updates the BE part of the topology file.

[lgirdwood]

@plbossart option b will work today. i.e. we take an existing topology.m4 per platform (since the topology will depend on avail cores/mips/memory) and the adjust/override the port mapping in the driver. However, this would still need a quirk table in the driver unless you have thought of a better method ?

[plbossart]

@lgirdwood we typically have a quirk in the machine driver, so ideally we'd update the topology as we register the card. If we need a quirk in both the machine driver and platform driver that's really painful.

[lgirdwood]

@plbossart I think we are good then just having the quirk in the machine driver then. We should de-duplicate some of our generic platform topologies since I think we have a lot of overlap with only changes for SSP mappings.

[ranj063]

@lgirdwood @plbossart can I duplicate the topologies for now and then incrementally clean them up for all platforms in a future PR after my holidays?

[lgirdwood]

@ranj063 yep, as long as we have an enhancement to track

[ranj063]

@lgirdwood updated now. I'll add an issue to make sure to clean this up later