Simplify BYT/CHT/BDW card names when used with sof

[plbossart]

Follow-up on @perexg 's suggestion to use simpler names. I removed the byt/cht mention since it's confusing to have a 'byt' card on a 'cht' machine and it adds no value to the user.

I hope it doesn't break all the CI tests...

[ranj063]

looks good except for the one blip

[kv2019i]

@plbossart This feels a bit strange to have nothing about the platform in the card name. E.g. if you have a non-Intel device using SOF and e.g. rt5640 codec, the same UCM file would probably not apply.

Hmm, of course, with limited space, maybe first-come-first-served applies here and in the case another SOF card with rt5650 comes, they will just have to pick another name. I guess this is the intention?

[plbossart]

@plbossart This feels a bit strange to have nothing about the platform in the card name. E.g. if you have a non-Intel device using SOF and e.g. rt5640 codec, the same UCM file would probably not apply.

Hmm, of course, with limited space, maybe first-come-first-served applies here and in the case another SOF card with rt5650 comes, they will just have to pick another name. I guess this is the intention?

total budget is 16 chars:
sof- 4 chars
-rt5640\0: 8 chars
-cx2072x\0: 9 chars
-max98090\0: 10 chars

that leaves 2 chars worst case for the platform definition, so to remain consistent I omitted it. I felt it was better to avoid truncating the codec name than add something specific about Intel.
Also if the device has a DMI name it can be used for UCM, the driver name is the fallback.
Anyways, all these codecs are somewhat old so the odds of a non-Intel SOF-based design are slim at best.

makes sense?

[perexg]

The question is, if the driver name should contain those details like codec and platform. The driver name might be like "sof" and you can put details to the standard card name. The conditions in ucm2 can handle the rest (we may even add lazy load to optimize config loading later).

[plbossart]

The question is, if the driver name should contain those details like codec and platform. The driver name might be like "sof" and you can put details to the standard card name. The conditions in ucm2 can handle the rest (we may even add lazy load to optimize config loading later).

@perexg what do you mean by the standard card name? we set the name once in the snd_soc_card structure, we don't have another mechanism, do we? Wondering if you are talking about extending the ASoC framework here?

[plbossart]

The question is, if the driver name should contain those details like codec and platform. The driver name might be like "sof" and you can put details to the standard card name. The conditions in ucm2 can handle the rest (we may even add lazy load to optimize config loading later).

@perexg what do you mean by the standard card name? we set the name once in the snd_soc_card structure, we don't have another mechanism, do we? Wondering if you are talking about extending the ASoC framework here?

Answering my own question, we do...

struct snd_soc_card {
	const char *name;
	const char *long_name;
	const char *driver_name;

That said why would the name become the driver_name....

[perexg]

Yes, you can set different name via snd_soc_card->driver_name. Appearently, this field is NULL in your case, thus snd_soc_bind_card() will use the snd_soc_card->name field for the driver name.

[plbossart]

Yes, you can set different name via snd_soc_card->driver_name. Appearently, this field is NULL in your case, thus snd_soc_bind_card() will use the snd_soc_card->name field for the driver name.

Just to get the character limitation right, would this mapping be correct?

snd_soc_card.driver_name ->	unsigned char driver[16];	/* Driver name */
   would be "SOF"
snd_soc_card.name ->	unsigned char name[32];		/* Short name of soundcard */
   would be sof-bytcht-rt5640
snd_soc_card.long_name ->	unsigned char longname[80];	/* name + info text about soundcard */
   not touched, so would be sof-bytcht-rt5640 or a DMI-based name, if present.

This one I don't know, would it be based on the driver name?
	unsigned char id[16];		/* ID of card (user selectable) */

[plbossart]

@perexg I did the suggested fixes so now things look better:

root@Zotac:/sys/class/sound/card0# cat /proc/asound/cards
 0 [sofbytchtrt5640]: SOF - sof-bytcht-rt5640
                      ZOTAC-XXXXXX-XX-CherryTrailFFD

The ID still looks horrible, if it's build automatically from the name, we need to require that the name be unique enough for the first 15 chars.

[perexg]

ID is an alias to the card number which may be set via the module parameters (another missing part in ASoC). This string is expected to be user configurable (to address the cards in the system more nicely). Unfortunately, because you use '-' instead space for the card name, the mechanism which picks the last word from the card name does not work like for other drivers.

[plbossart]

ID is an alias to the card number which should be set via the module parameters (another missing part in ASoC). This string is expected to be user configurable (to address the cards in the system more nicely). Unfortunately, because you use '-' instead space for the card name, the mechanism which picks the last word does not work like for other drivers.

I can add a space for the codec name, that's no issue. I don't think anyone was aware of that space requirement :-)

But I must admit I am lost here. Earlier you wrote "For the filename lookup, only the driver and longname strings are used (longname as first)."

so in this case, I have a longname which will never have any UCM match, so we will fallback to the driver name which has become too generic. It's unmanageable if we need to deal with all baytrail/cherrytrail configurations in a single directory?

[plbossart]

@perexg adding a space is magical :-)

root@Zotac:~# aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: rt5640 [sof-bytcht rt5640], device 0: Low Latency (*) []
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: rt5640 [sof-bytcht rt5640], device 1: Media Playback 1 (*) []
  Subdevices: 1/1
  Subdevice #0: subdevice #0
root@Zotac:~# arecord -l
**** List of CAPTURE Hardware Devices ****
card 0: rt5640 [sof-bytcht rt5640], device 0: Low Latency (*) []
  Subdevices: 1/1
  Subdevice #0: subdevice #0
root@Zotac:~# cat /proc/asound/cards 
 0 [rt5640         ]: SOF - sof-bytcht rt5640
                      ZOTAC-XXXXXX-XX-CherryTrailFFD

so now my only concern is how the UCM file is found (order between long card name, short card name, driver name).

[perexg]

I would create SOF/SOF.conf and conditionaly include verb configs from there. You can add one directory level. Ideally based on the string with the components (codec IDs) like we settled for soundwire.

syntax 2
If.bytcht_rt5640 {
   Condition {
      Type String
      Haystack "${CardComponents}"
      Needle "plat:bytcht codec0:rt5640"
   }
   True {
      <SOF/bytcht-rt5640/bytcht-rt5640.conf>
   }
}

or use the card name:

syntax 2
If.bytcht_rt5640 {
   Condition {
      Type String
      Haystack "${CardName}"
      Needle "bytcht rt5640"
   }
   True {
      <SOF/bytcht-rt5640/bytcht-rt5640.conf>
   }
}

We have similar situation for USB / legacy HDA where the driver name is common for all variants (codecs, devices) and we need to do the split based on other information than driver name / long name (DMI name for ASoC).

[plbossart]

@perexg I hit a snag with the UCM include files.
What I wanted to do is this in SOF/SOF.conf

If.bytcht_rt5640 {
	 Condition {
	 	Type String
		Haystack "${CardName}"
		Needle "bytcht rt5640"
	}
	True {
		<bytcr-rt5640/bycr-rt5640.conf>
	}
}

in other words, load the legacy config - which would be tested to see if its used in legacy mode or not. This fails because there are hard-coded paths in alsa-ucm. isn't there a way to specify a local path?

[plbossart]

The matching UCM configurations are here: alsa-project/alsa-ucm-conf#20

[plbossart]

@ranj063 @kv2019i can you take a look, I'd like to send all Baytrail stuff upstream before the merge window.

[plbossart]

@kv2019i @ranj063 @bardliao need your reviews, this PR works nicely with the updated UCM2 files so we should really push this upstream ASAP.

[bardliao]

LGTM. Thanks

[kv2019i]

Ack @plbossart , looks good to go.