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

[Pierre-Louis Bossart]

On 8/27/19 9:58 AM, Cezary Rojewski wrote:
> 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?

you didn't explain how the 'duplicated binaries' would be selected. And 
'instead of' means you suggested an alternative to Mark's proposal.