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.
[Index of Archives]
[Pulseaudio]
[Linux Audio Users]
[ALSA Devel]
[Fedora Desktop]
[Fedora SELinux]
[Big List of Linux Books]
[Yosemite News]
[KDE Users]
