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

[Pierre-Louis Bossart]

On 8/26/19 3:08 PM, Cezary Rojewski wrote:
> On 2019-08-26 18:51, Pierre-Louis Bossart wrote:
>>
>>
>> On 8/26/19 2:24 AM, Wasko, Michal wrote:
>>>
>>> On 8/25/2019 1:06 PM, Cezary Rojewski wrote:
>>>> On 2019-08-24 15:51, Cezary Rojewski wrote:
>>>>> On 2019-08-23 23:39, Mark Brown wrote:
>>>>>> On Fri, Aug 23, 2019 at 03:12:18PM -0500, Pierre-Louis Bossart wrote:
>>>>>>> On 8/23/19 1:44 PM, Cezary Rojewski wrote:
>>>>>>
>>>>>>>> Wasn't lying about FW version being unreliable. Let's say vendor
>>>>>>>> receives quick FW drop with new RCR.. such eng drop may carry 
>>>>>>>> invalid
>>>>>>>> numbers such as 0.0.0.0..
>>>>>>>> In general, I try to avoid relying on FW version whenever 
>>>>>>>> possible. It
>>>>>>>> can be dumped for debug reasons, true, but to be relied on? Not 
>>>>>>>> really.
>>>>>>
>>>>>>> Goodness, that's really bad. I didn't realize this.
>>>>>>
>>>>>> At a previous employer I modified our build stamping
>>>>>> infrastructure to also include both a timestamp and a serialized
>>>>>> build number in the version number since one of my colleagues was
>>>>>> fond of sending people prereleases of what he was working on to
>>>>>> other people with identical version numbers on different
>>>>>> binaries leading to much confusion and checksumming.  You do see
>>>>>> a lot of things with those serialized version numbers, especially
>>>>>> SVN based projects.
>>>>>>
>>>>>>>> Personally, I'm against all hardcodes and would simply recommend 
>>>>>>>> all
>>>>>>>> user to redirect their symlinks when they do switch kernel - 
>>>>>>>> along with
>>>>>>>> dumping warning/ error message in dmesg. Hardcodes bring 
>>>>>>>> problems with
>>>>>>>> forward compatibility and that's why host should offload them 
>>>>>>>> away to
>>>>>>>> FW.
>>>>>>
>>>>>>> Cezary, I know you are not responsible for all this, but at this 
>>>>>>> point if we
>>>>>>> (Intel) can't guarantee any sort of interoperability with both 
>>>>>>> firmware and
>>>>>>> topology we should make it clear that this driver is not 
>>>>>>> recommended unless
>>>>>>> specific versions of the firmware/topology are used, and as a 
>>>>>>> consequence
>>>>>>> the typical client distros and desktop/laptop users should use 
>>>>>>> HDaudio
>>>>>>> legacy or SOF (for DMICs)
>>>>>>
>>>>>> 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.
>>
>>>
>>> In terms of FW topology compatibility there is an option to read from 
>>> topology manifest
>>> a FW version that it was build for and in  case if it does not match 
>>> FW version present on
>>> the platform then print warning that the FW topology binary should be 
>>> rebuild for current
>>> FW version (x.x.x.x).
>>
>> Can you provide a pointer on how the FW version is embedded in a 
>> .conf/.tplg file? I see a couple where that information does not seem 
>> present.
>>
>>> The above approach at the end may be less confusing then source code 
>>> or binary duplication.
>>
> 
> Indeed. Our existing topology skips that part of internal .xml and thus 
> such information is not propagated to kernel.
> 
> Pierre, how about the binary-duplication - as described above? Btw, 
> that's not a single firmware file ^)^ We would immediately update all of 
> them, together with topologies.

I didn't understand how you would select the new firmwares? Some code 
change needs to happen as well?