Re: [PATCH 00/35] ASoC: Intel: Clenaup SST initialization

From: Cezary Rojewski <cezary.rojewski@intel.com>
To: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>,
	"Wasko, Michal" <michal.wasko@linux.intel.com>,
	Mark Brown <broonie@kernel.org>
Cc: "Wasko, Michal" <michal.wasko@intel.com>,
	alsa-devel@alsa-project.org, tiwai@suse.com, lgirdwood@gmail.com,
	"Kaczmarski, Filip" <filip.kaczmarski@intel.com>
Subject: Re: [PATCH 00/35] ASoC: Intel: Clenaup SST initialization
Date: Tue, 27 Aug 2019 17:08:26 +0200	[thread overview]
Message-ID: <d3474fdb-9479-b6f7-07fb-9f7c2d4ccbe3@intel.com> (raw)
In-Reply-To: <c67909a4-aae4-64f2-6e55-d513030fe085@linux.intel.com>

On 2019-08-27 17:00, Pierre-Louis Bossart wrote:

>>>>>>>>> On the second thought what if instead of duplicating kernel 
>>>>>>>>> code, binaries would be duplicated?
>>>>>>>>> I.e. rather than targeting /intel/dsp_fw_cnl.bin, _new_ 
>>>>>>>>> /skylake would be expecting /intel/dsp_fw_cnl_release.bin? Same 
>>>>>>>>> with topology binaries.
>>>>>>>>> In such case, we "only" need to figure out how to propagate new 
>>>>>>>>> files to Linux distos so whenever someone updates their kernel, 
>>>>>>>>> new binaries are already present in their /lib/firmware.
>>>>>>>>>
>>>>>>>>> If such option is valid, we can postpone /skylake upgrade till 
>>>>>>>>> 5.4 merging window closes and the patches (rough estimation is 
>>>>>>>>> 150) would descend upon alsa-devel in time between 5.4 and 5.5.
>>>>>>>>
>>>>>>>> If the driver and FW update will be within the same kernel 
>>>>>>>> release then IMHO
>>>>>>>> there should be no compatibility problem between those two 
>>>>>>>> components, right?
>>>>>>>> This way kernel users willing to stick to old FW can stay on 
>>>>>>>> older kernel version while
>>>>>>>> others can update and receive all the latest FW functionality 
>>>>>>>> that was developed and enabled.
>>>>>>>
>>>>>>> I am not comfortable with precluding a kernel update because of a 
>>>>>>> single firmware file. There are all sort of reasons for updating 
>>>>>>> a kernel, security, sideband attacks and Android CDD 
>>>>>>> compatibility being the most obvious ones.
>>>>>>>
>>>> The single firmware file will not be a blocker as the driver 
>>>> included in updated kernel will support it.
>>>> All you have to do is the little effort to re-generate your custom 
>>>> topology for the new firmware target.
>>>> The entire operation should not be a problem as there are dedicated 
>>>> utilities like FDK to do that.
>>>
>>> The issue is the same whether it's a topology file or a firmware 
>>> file. The ideal situation is that when the kernel is updated it 
>>> handles both in backwards compatible ways.
>>>
>>> If to deal with a new firmware file you have to regenerate a new 
>>> topology, you are in a different model altogether.
>>>
>>>> Your statement Pierre suggest that everyone should avoid any 
>>>> functional changes in kernel
>>>> that are not critical because that would be problematic for others 
>>>> who switch from older kernel version.
>>>   All I said was that you cannot assume that people who are using an 
>>> old firmware/driver will remain on an old kernel.
>>>
>>> Mark made an initial proposal to essentially freeze the current 
>>> solution, which would make it possible to update the kernel but keep 
>>> the same skylake driver in legacy/maintenance mode only, and an 'new' 
>>> option that would rely on an updated distribution of firmware/driver. 
>>> I did not get the counter proposal from Cezary at all.
>>
>> Ain't my previous message:
>>
>> -
>>
>> On the second thought what if instead of duplicating kernel code, 
>> binaries would be duplicated?
>> I.e. rather than targeting /intel/dsp_fw_cnl.bin, _new_ /skylake would 
>> be expecting /intel/dsp_fw_cnl_release.bin? Same with topology binaries.
>> In such case, we "only" need to figure out how to propagate new files 
>> to Linux distos so whenever someone updates their kernel, new binaries 
>> are already present in their /lib/firmware.
>>
>> If such option is valid, we can postpone /skylake upgrade till 5.4 
>> merging window closes and the patches (rough estimation is 150) would 
>> descend upon alsa-devel in time between 5.4 and 5.5.
>>
>> -
>>
>> a counter proposal?
> 
> you didn't explain how the 'duplicated binaries' would be selected. And 
> 'instead of' means you suggested an alternative to Mark's proposal.

What I have in mind:

We leave the old stuff as is, e.g:
/lib/firmware/intel/dsp_fw_cnl.bin -> points to _old_ FW binaries
/lib/firmware/<PCI-ID>-INTEL-<oem_data_from_NHLT -> points to old topology

Existing /skylake i.e. before our initialization refactor would (kernels 
<5.5?) would still point to these and since they are not being removed 
from linux-firmware, nothing gets broken.

And then we "duplicate" and simply append the new ones:
/lib/firmware/intel/dsp_fw_cnl_release.bin -> points to _new_ FW
/lib/firmware/dfw_cnl_rt274 -> points to _new_ topology

Updated /skylake would simply expect the _new_ files and totally ignore 
the old ones i.e.: descriptors would be pointing to dsp_fw_cnl_release 
and dfw_cnl_rt274.
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel