Re: [PATCH 12/19] ASoC: SOF: Intel: Set the default firmware library path for IPC4

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [ALSA User]     [Linux Audio Users]     [Pulse Audio]     [Kernel Archive]     [Asterisk PBX]     [Photo Sharing]     [Linux Sound]     [Video 4 Linux]     [Gimp]     [Yosemite News]

  Powered by Linux