[alsa-devel] [PATCH 00/35] ASoC: Intel: Clenaup SST initialization

[Cezary Rojewski]

On 2019-08-27 15:52, Pierre-Louis Bossart wrote:
> 
>>>>>>>>> Not the most elegent solution but I'm wondering if keeping a copy
>>>>>>>>> of the driver as is around and using new locations for the fixed
>>>>>>>>> firmware might be the safest way to handle this.  We could have a
>>>>>>>>> wrapper which tries to load the newer firmware and uses the fixed
>>>>>>>>> driver code if that's there, otherwise tries the old driver with
>>>>>>>>> the existing firmware paths.  This is obviously a horror show and
>>>>>>>>> leaves the old code sitting there but given the mistakes that
>>>>>>>>> have been made the whole situation looks like a house of cards.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Thanks for the feedback Mark. While I'm not yet on the "SOF will 
>>>>>>>> fix this" train, I'm keen to agree to leaving this entirely to 
>>>>>>>> SOF if it comes down to us duplicating /skylake.
>>>>>>>>
>>>>>>>> However, we are not going to give up that easily. I'll see if 
>>>>>>>> some "golden config" hardcodes can't be provided in some 
>>>>>>>> legacy.c file which would be fetched if initial setup fails. 
>>>>>>>> E.g.: 2cores, 3ssps, 1PAGE_SIZE per trace buffer.. and such. 
>>>>>>>> There are quite a few factors to take into consideration though. 
>>>>>>>> If "asking" user via dmesg to upgrade the firmware if his/her 
>>>>>>>> setup contains obsolete binary is really not an option, then 
>>>>>>>> some magic words got to be involved.
>>>>>>>>
>>>>>>>> Czarek
>>>>>>>
>>>>>>> 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?