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

[Pierre-Louis Bossart]

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.