Re: [PATCH 07/13] ASoC: Intel: avs: Add MODULE_FIRMWARE to inform about FW

[Cezary Rojewski <cezary.rojewski@intel.com>]

On 2025-01-10 7:09 PM, Pierre-Louis Bossart wrote:
> 
>> +MODULE_FIRMWARE("intel/skl/dsp_basefw.bin");
>> +MODULE_FIRMWARE("intel/apl/dsp_basefw.bin");
>> +MODULE_FIRMWARE("intel/cnl/dsp_basefw.bin");
>> +MODULE_FIRMWARE("intel/icl/dsp_basefw.bin");
>> +MODULE_FIRMWARE("intel/jsl/dsp_basefw.bin");
>> +MODULE_FIRMWARE("intel/lkf/dsp_basefw.bin");
> 
> Lakefield? Is this really a supported platform? It was EOL'ed a year after launch, wasn't it?

We still keep all the platforms, regardless of their age, in the CI to 
cross check firmware-API compatibility even with newest generations such 
as PanterLake or FriscoLake.

Few years ago the team did quite a job to streamline LakeField (LKF) 
with other cAVS 2.5 platforms on the firmware side. The TLDR is:
- one firmware branch covers from LKF (cAVS 2.1) up to 
AlderLake/RaptorLake and all their spinoffs (cAVS 2.5)
- one tgl.c file on the avs-driver side covers the exact same range

so, any kind of redundancy is greatly limited. With that in mind, we 
utilize the cAVS CI against the ACE (MeteorLake onwards) equivalent to 
verify API compatibility between those two firmware branches to lower 
the software development cost.

>> +MODULE_FIRMWARE("intel/tgl/dsp_basefw.bin");
>> +MODULE_FIRMWARE("intel/ehl/dsp_basefw.bin");
>> +MODULE_FIRMWARE("intel/adl/dsp_basefw.bin");
>> +MODULE_FIRMWARE("intel/adl_n/dsp_basefw.bin");
> 
> If you start listing the variants of ADL, then shouldn't you also list the variants of TGL?
> Same for CNL, there are multiple variants, not to mention different signing keys.

The only reason ADL and ADL-N are listed separately is binary 
incompatibility - MEU differs between the two. In essence, one can use 
ADL-binaries for all ADL/RPL based platforms _except_ for ADL-N based 
ones. The code is the same, the verification process is different. For 
all other major platforms, no MEU differences so one binary covers all 
variants.

In regard to the key, the approach is: it's ignored.

Whatever is in the directory under 'dsp_basefw.bin' will be attempted 
for booting the DSP. By default, what lands on the market is a 
production-type-signed binaries. Internally CI runs with prod -or- debug 
signed binaries but we do not intend to share the latter to the official 
linux-firmware repo.

Kind regards,
Czarek