On 29/11/23 16:39, Pierre-Louis Bossart wrote:
> + .name_prefix = "cs35l56-8"
Can these prefixes be "AMPn" to match the CS35L41, CS35L51 and CS35L56-hda driver? This prefix is used to find the matching firmware files and our naming convention for these has been cs35lxx-xxxx-ampn
Is there anything that depends on the prefixes being "cs35l56-n" ?
IIRC this name_prefix is just used for the codec_conf and hence for control names/UCM. At some point userspace/driver need to know if amp5 is left or right.
We can certainly align on conventions but the values set in this ACPI match table will not be used for firmware download - different scope.
They are used for our firmware download. Each amp can have its own unique firmware file. The ALSA prefix is used to identify which firmware file to load to which amp.
The prefix will only be used when the card is created, specifically for control names. The firmware should be selected and downloaded when the device shows up on the bus. Card creation and device enumeration/initialization happen on different timelines, if the machine driver is "blacklisted" or unbound I am not sure what happens.
There is a dependency between machine driver probe and codec firmware download that I am not able to follow, can you please elaborate?
The codec driver has to choose which firmware to load from under /lib/firmware. It does this using a combination of SSID (to identify the target product), the ALSA prefix string (to identify which amp) and in some systems a GPIO on the motherboard to select between different models of speaker when they have multiple suppliers. This results in a firmware name like:
cs35l56-<silicon rev>-dsp1-misc-<SSID>[-<SPEAKER MODEL>]-<ALSA PREFIX>
You can see this if you look in the linux-firmware repo under cirrus/ for cs35l41 firmware files (though the ALSA PREFIX section in those cases is not "AMPn" because they are not SDCA parts with rotation, they have a fixed left/right assignment.)
We have to be careful of the length of the prefix. The 44 characters of an ALSA control name get eaten up very quickly when we start creating fully-qualified names for controls published by the firmware. So "AMPn" was nice because it was descriptive enough but only uses 5 characters of the 44.
Having said that, I've calculated that we have enough characters (just) to use a prefix of "cs35l56-n". If there's a reason why that is necessary/desirable for SOF or SoundWire then we could do that. But we'd intended to use "AMPn" prefixes.
We just need to decide whether to go with "AMPn". Or switch to using "cs35l56-n" for the ALSA prefix (the therefore the qualifier at the end of the firmware filename).
Yes we have similar issues with control names in topology, the limit is hit very quickly.
I think you missed my point though that the ALSA prefix is only set when the card is created, which can be sometime after the firmware needs to be downloaded. I guess you could pick the firmware in the component probe, which happens during the card creation, but that could be sub-optimal. Given the download times you want the download to proceed as early as possible.
We kick off a background task from our component_probe() to do the firmware download. We need the ALSA prefix, and also the wm_adsp library that actually handles the DSP is ASoC code so it needs a probed component. Doing it in a background work means it doesn't block probe(). And the download to multiple amps can proceed in parallel - obviously that's constrained by bus bandwidth but we are seeing that they interleave.