Alsa-Devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: "Péter Ujfalusi" <peter.ujfalusi@linux.intel.com>
To: "Cezary Rojewski" <cezary.rojewski@intel.com>,
	"Pierre-Louis Bossart" <pierre-louis.bossart@linux.intel.com>,
	"Amadeusz Sławiński" <amadeuszx.slawinski@linux.intel.com>,
	lgirdwood@gmail.com, broonie@kernel.org
Cc: chao.song@intel.com, alsa-devel@alsa-project.org,
	ranjani.sridharan@linux.intel.com, kai.vehmanen@linux.intel.com
Subject: Re: [PATCH 12/19] ASoC: SOF: Intel: Set the default firmware library path for IPC4
Date: Wed, 19 Oct 2022 14:16:39 +0300	[thread overview]
Message-ID: <52b62b01-420a-75b8-4355-784f5eb7d62b@linux.intel.com> (raw)
In-Reply-To: <28d040a5-52dd-a8ac-2217-7f71cbf8e905@intel.com>

On 19/10/2022 12:51, Cezary Rojewski wrote:
>> That's not necessarily a valid assumption, it's perfectly possible that
>> a specific OEM decides to allocate more budget for a specific feature
>> and less for others, resulting in libraries that are recompiled,
>> optimized or configured differently. The UUID is a weak notion here, as
>> measured by the same UUID being used for different DSP generations.
>> Nothing prevents someone from generating a slightly different library
>> exposed with the same UUID.
>>
>> We didn't want to restrict our partners and gave them with the ability
>> to put both the base firmware and the libraries in different directories
>> and overload the default path should they wish to do so. They could
>> decide to point to the same directory if they wanted to. That's not our
>> decision.
>>
>> If you look at all recent evolutions, we initially introduced different
>> paths for firmware, then topology, then firmware and topology names. The
>> logic of adding more flexibility for library path follow the pattern of
>> trying to avoid making assumptions we have to undo at a later point.
> 
> Thanks for the elaborate input. The evolution sound good, and is
> perfectly reasonable. My only feedback is - should we put everything
> under /intel directory? If all the paths can be customized, then the
> parent directory needs not to be the same for every firmware package
> regardless of its origin. It's counterintuitive, is it not?

at the moment:
# ls -al /lib/firmware/intel/ | wc -l
108

We might have 2 sets of binaries per platform, one using product key,
other using community key.

If we dump everything in one directory (/lib/firmware/intel/), things
will go out of hand pretty easily which can be somehow handled with
complex file naming. This is only for the basefw, then we have the
libraries (however they are sourced) with again two sets of keys, platforms.

Surely it can be done, but historically SOF prefers to use directories
instead of pre/mid/post-fixing patterns of file names.

Also note that SOF is looking for a module UUID when trying to load a
library we don't track arbitrary file names (see cover letter).

Does this make sense to you?

-- 
Péter

  reply	other threads:[~2022-10-19 11:17 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-18 12:08 [PATCH 00/19] ASoC: SOF: Intel/IPC4: Support for external firmware libraries Peter Ujfalusi
2022-10-18 12:08 ` [PATCH 01/19] ASoC: SOF: loader: Set complete state before post_fw_run op Peter Ujfalusi
2022-10-18 12:08 ` [PATCH 02/19] ASoC: SOF: Introduce container struct for SOF firmware Peter Ujfalusi
2022-10-18 12:09 ` [PATCH 03/19] ASoC: SOF: amd: Use the basefw firmware container directly Peter Ujfalusi
2022-10-18 12:09 ` [PATCH 04/19] ASoC: SOF: Intel: hda-loader: " Peter Ujfalusi
2022-10-18 12:09 ` [PATCH 05/19] ASoC: SOF: Intel: hda-loader-skl: " Peter Ujfalusi
2022-10-18 12:09 ` [PATCH 06/19] ASoC: SOF: Drop the firmware and fw_offset from snd_sof_pdata Peter Ujfalusi
2022-10-18 12:09 ` [PATCH 07/19] ASoC: SOF: ipc: ops: Add support for optional init and exit callbacks Peter Ujfalusi
2022-10-18 12:09 ` [PATCH 08/19] ASoC: SOF: ipc4-loader: Save the maximum number of libraries supported Peter Ujfalusi
2022-10-18 12:09 ` [PATCH 09/19] ASoC: SOF: ipc4: Convert the firmware handling (loader) to library convention Peter Ujfalusi
2022-10-18 12:09 ` [PATCH 10/19] ASoC: SOF: IPC4: Add helper for looking up module by UUID Peter Ujfalusi
2022-10-18 12:09 ` [PATCH 11/19] ASoC: SOF: Add path definition for external firmware libraries Peter Ujfalusi
2022-10-18 12:09 ` [PATCH 12/19] ASoC: SOF: Intel: Set the default firmware library path for IPC4 Peter Ujfalusi
2022-10-18 12:38   ` Amadeusz Sławiński
2022-10-18 13:49     ` Péter Ujfalusi
2022-10-18 15:46       ` Cezary Rojewski
2022-10-18 16:37         ` Pierre-Louis Bossart
2022-10-18 17:18           ` Cezary Rojewski
2022-10-19  9:51           ` Cezary Rojewski
2022-10-19 11:16             ` Péter Ujfalusi [this message]
2022-10-19 11:58               ` Cezary Rojewski
2022-10-19 12:21                 ` Péter Ujfalusi
2022-10-18 12:09 ` [PATCH 13/19] ASoC: SOF: ipc4: Define platform dependent library loading callback Peter Ujfalusi
2022-10-18 12:09 ` [PATCH 14/19] ASoC: SOF: Intel: hda: Add flag to indicate that the firmware is IMR booted Peter Ujfalusi
2022-10-18 12:09 ` [PATCH 15/19] ASoC: SOF: Intel: Add ipc4 library loading implementation Peter Ujfalusi
2022-10-18 12:09 ` [PATCH 16/19] ASoC: SOF: loader: Add support for IPC dependent post firmware boot ops Peter Ujfalusi
2022-10-18 12:09 ` [PATCH 17/19] ASoC: SOF: ipc4: Stop using the query_fw_configuration fw_loader ops Peter Ujfalusi
2022-10-18 12:09 ` [PATCH 18/19] ASoC: SOF: loader: Remove the query_fw_configuration ops Peter Ujfalusi
2022-10-18 12:09 ` [PATCH 19/19] ASoC: SOF: ipc4-loader: Support for loading external libraries Peter Ujfalusi

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=52b62b01-420a-75b8-4355-784f5eb7d62b@linux.intel.com \
    --to=peter.ujfalusi@linux.intel.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=amadeuszx.slawinski@linux.intel.com \
    --cc=broonie@kernel.org \
    --cc=cezary.rojewski@intel.com \
    --cc=chao.song@intel.com \
    --cc=kai.vehmanen@linux.intel.com \
    --cc=lgirdwood@gmail.com \
    --cc=pierre-louis.bossart@linux.intel.com \
    --cc=ranjani.sridharan@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