All of lore.kernel.org
 help / color / mirror / Atom feed
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.

  reply	other threads:[~2023-11-29 18:46 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.