linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Péter Ujfalusi" <peter.ujfalusi@linux.intel.com>
To: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>,
	Liam Girdwood <lgirdwood@gmail.com>,
	Mark Brown <broonie@kernel.org>, Jaroslav Kysela <perex@perex.cz>,
	Takashi Iwai <tiwai@suse.com>,
	Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>,
	Bard Liao <yung-chuan.liao@linux.intel.com>,
	Ranjani Sridharan <ranjani.sridharan@linux.intel.com>,
	Daniel Baluta <daniel.baluta@nxp.com>,
	Kai Vehmanen <kai.vehmanen@linux.intel.com>,
	Venkata Prasad Potturu <venkataprasad.potturu@amd.com>,
	Alper Nebi Yasak <alpernebiyasak@gmail.com>,
	Syed Saba Kareem <Syed.SabaKareem@amd.com>,
	Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>,
	Marian Postevca <posteuca@mutex.one>,
	Vijendar Mukunda <Vijendar.Mukunda@amd.com>,
	V sujith kumar Reddy <Vsujithkumar.Reddy@amd.com>,
	Mastan Katragadda <Mastan.Katragadda@amd.com>,
	Ajit Kumar Pandey <AjitKumar.Pandey@amd.com>
Cc: linux-sound@vger.kernel.org, linux-kernel@vger.kernel.org,
	sound-open-firmware@alsa-project.org, kernel@collabora.com
Subject: Re: [PATCH 07/11] ASoC: SOF: core: Skip firmware test for undefined fw_name
Date: Thu, 14 Dec 2023 12:48:13 +0200	[thread overview]
Message-ID: <6e52c5a2-24d5-422a-9a40-a0053729c98e@linux.intel.com> (raw)
In-Reply-To: <20231209205351.880797-8-cristian.ciocaltea@collabora.com>



On 09/12/2023 22:53, Cristian Ciocaltea wrote:
> Some SOF drivers like AMD ACP do not always rely on a single static
> firmware file, but may require multiple files having their names
> dynamically computed on probe time, e.g. based on chip name.

I see, AMD vangogh needs two binary files to be loaded sometimes, it is not using the default name as it hints via the sof_dev_desc ("sof-vangogh.ri").

The constructed names for the two files are just using different pattern:
sof-%PLAT%.ri
vs
sof-%PLAT%-code.bin
sof-%PLAT%-data.bin

iow, instead of the combined .ri file which includes the code and data segment it has 'raw' bin files and cannot use the core for loading the firmware.

What is the reason for this? an .ri file can have two 'modules' one to be written to IRAM the other to DRAM.
sof_ipc3_load_fw_to_dsp()

> In those cases, providing an invalid default_fw_filename in their
> sof_dev_desc struct will prevent probing due to 'SOF firmware
> and/or topology file not found' error.
 
> Fix the issue by allowing drivers to omit initialization for this member
> (or alternatively provide a dynamic override via ipc_file_profile_base)
> and update sof_test_firmware_file() to verify the given profile data and
> skip firmware testing if either fw_path or fw_name is not defined.
> 
> Fixes: 6c393ebbd74a ("ASoC: SOF: core: Implement IPC version fallback if firmware files are missing")
> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
> ---
>  sound/soc/sof/fw-file-profile.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/sound/soc/sof/fw-file-profile.c b/sound/soc/sof/fw-file-profile.c
> index 138a1ca2c4a8..e63700234df0 100644
> --- a/sound/soc/sof/fw-file-profile.c
> +++ b/sound/soc/sof/fw-file-profile.c
> @@ -21,6 +21,9 @@ static int sof_test_firmware_file(struct device *dev,
>  	const u32 *magic;
>  	int ret;
>  
> +	if (!profile->fw_path || !profile->fw_name || !*profile->fw_name)
> +		return 0;

I would rather make the firmware file skipping based on custom loader use and print a dev_dbg() alongside:

diff --git a/sound/soc/sof/fw-file-profile.c b/sound/soc/sof/fw-file-profile.c
index 138a1ca2c4a8..7b91c9551ada 100644
--- a/sound/soc/sof/fw-file-profile.c
+++ b/sound/soc/sof/fw-file-profile.c
@@ -89,6 +89,15 @@ static int sof_test_topology_file(struct device *dev,
 	return ret;
 }
 
+static bool sof_platform_uses_generic_loader(struct snd_sof_dev *sdev)
+{
+	if (sdev->pdata->desc->ops->load_firmware == snd_sof_load_firmware_raw ||
+	    sdev->pdata->desc->ops->load_firmware == snd_sof_load_firmware_memcpy)
+		return true;
+
+	return false;
+}
+
 static int
 sof_file_profile_for_ipc_type(struct snd_sof_dev *sdev,
 			      enum sof_ipc_type ipc_type,
@@ -130,7 +139,8 @@ sof_file_profile_for_ipc_type(struct snd_sof_dev *sdev,
 	 * For default path and firmware name do a verification before
 	 * continuing further.
 	 */
-	if (base_profile->fw_path || base_profile->fw_name) {
+	if ((base_profile->fw_path || base_profile->fw_name) &&
+	    sof_platform_uses_generic_loader(sdev)) {
 		ret = sof_test_firmware_file(dev, out_profile, &ipc_type);
 		if (ret)
 			return ret;
@@ -181,7 +191,8 @@ sof_file_profile_for_ipc_type(struct snd_sof_dev *sdev,
 	out_profile->ipc_type = ipc_type;
 
 	/* Test only default firmware file */
-	if (!base_profile->fw_path && !base_profile->fw_name)
+	if ((!base_profile->fw_path && !base_profile->fw_name) &&
+	    sof_platform_uses_generic_loader(sdev))
 		ret = sof_test_firmware_file(dev, out_profile, NULL);
 
 	if (!ret)
@@ -265,7 +276,9 @@ static void sof_print_profile_info(struct snd_sof_dev *sdev,
 			 "Using fallback IPC type %d (requested type was %d)\n",
 			 profile->ipc_type, ipc_type);
 
-	dev_info(dev, "Firmware paths/files for ipc type %d:\n", profile->ipc_type);
+	/* The firmware path only valid when generic loader is used */
+	if (sof_platform_uses_generic_loader(sdev))
+		dev_info(dev, "Firmware paths/files for ipc type %d:\n", profile->ipc_type);
 
 	dev_info(dev, " Firmware file:     %s/%s\n", profile->fw_path, profile->fw_name);
 	if (profile->fw_lib_path)

> +
>  	fw_filename = kasprintf(GFP_KERNEL, "%s/%s", profile->fw_path,
>  				profile->fw_name);
>  	if (!fw_filename)

checking for custom loader allows you to drop the next patch.
I would also skip the fw path printing in case of a custom loader.

-- 
Péter

  reply	other threads:[~2023-12-14 10:47 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-09 20:53 [PATCH 00/11] Improve SOF support for Steam Deck OLED Cristian Ciocaltea
2023-12-09 20:53 ` [PATCH 01/11] ASoC: amd: acp: Drop redundant initialization of machine driver data Cristian Ciocaltea
2023-12-09 20:53 ` [PATCH 02/11] ASoC: amd: acp: Make use of existing *_CODEC_DAI macros Cristian Ciocaltea
2023-12-09 20:53 ` [PATCH 03/11] ASoC: amd: acp: Add missing error handling in sof-mach Cristian Ciocaltea
2023-12-11 13:31   ` Emil Velikov
2023-12-11 16:56     ` Cristian Ciocaltea
2023-12-09 20:53 ` [PATCH 04/11] ASoC: amd: acp: Update MODULE_DESCRIPTION for sof-mach Cristian Ciocaltea
2023-12-09 20:53 ` [PATCH 05/11] ASoC: SOF: amd: Fix memory leak in amd_sof_acp_probe() Cristian Ciocaltea
2023-12-09 20:53 ` [PATCH 06/11] ASoC: SOF: amd: Optimize quirk for Valve Galileo Cristian Ciocaltea
2023-12-10  3:33   ` Venkata Prasad Potturu
2023-12-10  8:42     ` Cristian Ciocaltea
2023-12-09 20:53 ` [PATCH 07/11] ASoC: SOF: core: Skip firmware test for undefined fw_name Cristian Ciocaltea
2023-12-14 10:48   ` Péter Ujfalusi [this message]
2023-12-14 10:58     ` Venkata Prasad Potturu
2023-12-14 11:57       ` Péter Ujfalusi
2023-12-14 13:28         ` Venkata Prasad Potturu
2023-12-14 11:29     ` Cristian Ciocaltea
2023-12-14 11:35       ` Péter Ujfalusi
2023-12-14 11:40         ` Cristian Ciocaltea
2023-12-14 11:52           ` Péter Ujfalusi
2023-12-14 11:51     ` Péter Ujfalusi
2023-12-14 11:58       ` Cristian Ciocaltea
2023-12-09 20:53 ` [PATCH 08/11] ASoC: SOF: amd: Override default fw name for Valve Galileo Cristian Ciocaltea
2023-12-09 20:53 ` [PATCH 09/11] ASoC: SOF: amd: Compute file paths on firmware load Cristian Ciocaltea
2023-12-10  3:50   ` Venkata Prasad Potturu
2023-12-10  8:56     ` Cristian Ciocaltea
2023-12-09 20:53 ` [PATCH 10/11] ASoC: amd: acp: Use correct DAI link ID for BT codec Cristian Ciocaltea
2023-12-10  3:24   ` Venkata Prasad Potturu
2023-12-10  9:06     ` Cristian Ciocaltea
2023-12-10 10:05       ` Venkata Prasad Potturu
2023-12-10 10:32         ` Cristian Ciocaltea
2023-12-11  5:48           ` Venkata Prasad Potturu
2023-12-09 20:53 ` [PATCH 11/11] ASoC: SOF: topology: Add new DAI type entry for SOF_DAI_AMD_BT Cristian Ciocaltea
2023-12-10  3:30   ` Venkata Prasad Potturu
2023-12-10  9:08     ` Cristian Ciocaltea
2023-12-10  9:51       ` Venkata Prasad Potturu
2023-12-10 10:12         ` Cristian Ciocaltea
2023-12-10 14:01           ` Mark Brown
2023-12-10 15:50             ` Cristian Ciocaltea
2023-12-11  5:58               ` Venkata Prasad Potturu
2023-12-14 12:23                 ` Cristian Ciocaltea
2023-12-14 12:36                   ` Venkata Prasad Potturu
2023-12-14 13:15                   ` Venkata Prasad Potturu
2023-12-14 16:42                     ` Cristian Ciocaltea
2023-12-15  9:58                       ` Venkata Prasad Potturu
2023-12-15 10:57                         ` Cristian Ciocaltea
2023-12-15 12:53                           ` Mark Brown
2023-12-12  6:41             ` Mukunda,Vijendar

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=6e52c5a2-24d5-422a-9a40-a0053729c98e@linux.intel.com \
    --to=peter.ujfalusi@linux.intel.com \
    --cc=AjitKumar.Pandey@amd.com \
    --cc=Mastan.Katragadda@amd.com \
    --cc=Syed.SabaKareem@amd.com \
    --cc=Vijendar.Mukunda@amd.com \
    --cc=Vsujithkumar.Reddy@amd.com \
    --cc=alpernebiyasak@gmail.com \
    --cc=broonie@kernel.org \
    --cc=cristian.ciocaltea@collabora.com \
    --cc=daniel.baluta@nxp.com \
    --cc=kai.vehmanen@linux.intel.com \
    --cc=kernel@collabora.com \
    --cc=kuninori.morimoto.gx@renesas.com \
    --cc=lgirdwood@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-sound@vger.kernel.org \
    --cc=perex@perex.cz \
    --cc=pierre-louis.bossart@linux.intel.com \
    --cc=posteuca@mutex.one \
    --cc=ranjani.sridharan@linux.intel.com \
    --cc=sound-open-firmware@alsa-project.org \
    --cc=tiwai@suse.com \
    --cc=venkataprasad.potturu@amd.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;
as well as URLs for NNTP newsgroup(s).