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

[Cezary Rojewski]

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.