From: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
To: Richard Fitzgerald <rf@opensource.cirrus.com>,
Peter Ujfalusi <peter.ujfalusi@linux.intel.com>,
lgirdwood@gmail.com, broonie@kernel.org
Cc: alsa-devel@alsa-project.org, linux-sound@vger.kernel.org,
kai.vehmanen@linux.intel.com, ranjani.sridharan@linux.intel.com,
cezary.rojewski@intel.com, yung-chuan.liao@linux.intel.com,
ckeepax@opensource.cirrus.com, yong.zhi@intel.com,
chao.song@linux.intel.com
Subject: Re: [PATCH 6/7] ASoC: Intel: soc-acpi-intel-tgl-match: add cs42l43 and cs56l56 support
Date: Wed, 29 Nov 2023 10:39:08 -0600 [thread overview]
Message-ID: <7bae01ac-a0de-47d9-9bd3-6bdfc48e02c1@linux.intel.com> (raw)
In-Reply-To: <d2de7d4c-3984-4737-b879-a1fa829007ff@opensource.cirrus.com>
>>>>>> + .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.
next prev parent reply other threads:[~2023-11-29 18:45 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-27 13:34 [PATCH 0/7] ASoC: Intel: Soundwire related board and match updates Peter Ujfalusi
2023-11-27 13:34 ` [PATCH 1/7] ASoC: Intel: sof_sdw: Make use of dev_err_probe() Peter Ujfalusi
2023-11-27 13:34 ` [PATCH 2/7] ASoC: Intel: sof_sdw: remove unused function declaration Peter Ujfalusi
2023-11-27 13:34 ` [PATCH 3/7] ASoC: Intel: sof_sdw: Add rt722 support Peter Ujfalusi
2023-11-27 13:34 ` [PATCH 4/7] ASoC: Intel: soc-acpi: rt713+rt1316, no sdw-dmic config Peter Ujfalusi
2023-11-27 13:34 ` [PATCH 5/7] ASoC: Intel: soc-acpi: add Gen4.1 SDCA board support for LNL RVP Peter Ujfalusi
2023-11-27 13:34 ` [PATCH 6/7] ASoC: Intel: soc-acpi-intel-tgl-match: add cs42l43 and cs56l56 support Peter Ujfalusi
2023-11-27 14:40 ` Richard Fitzgerald
2023-11-27 17:36 ` Pierre-Louis Bossart
2023-11-28 10:31 ` Richard Fitzgerald
2023-11-28 15:23 ` Pierre-Louis Bossart
2023-11-29 11:14 ` Richard Fitzgerald
2023-11-29 16:39 ` Pierre-Louis Bossart [this message]
2023-11-30 10:15 ` Richard Fitzgerald
2023-11-30 14:27 ` Pierre-Louis Bossart
2023-12-01 9:21 ` Richard Fitzgerald
2023-11-27 13:34 ` [PATCH 7/7] ASoC: Intel: soc-acpi-intel-mtl-match: Add rt722 support Peter Ujfalusi
2023-11-28 13:55 ` [PATCH 0/7] ASoC: Intel: Soundwire related board and match updates Mark Brown
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7bae01ac-a0de-47d9-9bd3-6bdfc48e02c1@linux.intel.com \
--to=pierre-louis.bossart@linux.intel.com \
--cc=alsa-devel@alsa-project.org \
--cc=broonie@kernel.org \
--cc=cezary.rojewski@intel.com \
--cc=chao.song@linux.intel.com \
--cc=ckeepax@opensource.cirrus.com \
--cc=kai.vehmanen@linux.intel.com \
--cc=lgirdwood@gmail.com \
--cc=linux-sound@vger.kernel.org \
--cc=peter.ujfalusi@linux.intel.com \
--cc=ranjani.sridharan@linux.intel.com \
--cc=rf@opensource.cirrus.com \
--cc=yong.zhi@intel.com \
--cc=yung-chuan.liao@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox