[alsa-devel] [PATCH 27/35] ASoC: Intel: Skylake: Define platform descriptors

[Pierre-Louis Bossart]

On 8/26/19 2:18 PM, Cezary Rojewski wrote:
> On 2019-08-26 19:13, Pierre-Louis Bossart wrote:
>>
>>
>> On 8/24/19 5:51 AM, Cezary Rojewski wrote:
>>> On 2019-08-23 21:50, Pierre-Louis Bossart wrote:
>>>>
>>>>
>>>> On 8/22/19 2:04 PM, Cezary Rojewski wrote:
>>>>> Make use of sst_pdata and declare platform descriptors for all 
>>>>> existing
>>>>> cAVS platforms. Each carries information about base_fw filename,
>>>>> platform specific operations and boards supported.
>>>>
>>>> if you use a constant base_fw name that cannot be made 
>>>> board-specific for specific usages, you will restrict the ability to 
>>>> deal with quirks and custom cases.
>>>>
>>>> real-life example: not so long ago there were two SST firmwares for 
>>>> 'regular' solutions and ultra-low-latency ones, so by having a 
>>>> single name for all APL-based platforms you will generate issues 
>>>> that don't exist today, or you will force users to patch something 
>>>> in the core.
>>>>
>>>
>>> I did not bring up ULL case for a reason. Guess Pandora box is to be 
>>> opened.. so be it.
>>>
>>> ULL stands for Ultra Low Latency and it can be described by the 
>>> following:
>>> - exists only for APL based platforms (more like single platform/ 
>>> model though)
>>> - in consequence, binary isn't present on any other FW branch and any 
>>> other platform apart from APL
>>> - its existence is tied to hardware.. eh.. let's call it a "limitation"
>>> - number of actual vendors is too Ultra Low..
>>> - has limited functionality and validation
>>> - is not the recommended FW for end users in any case
>>> - binary is not going to be upstreamed
>>> - reference board is not going to be upstreamed
>>> - generic (so called main FW) and ULL share the board ACPI ID and 
>>> thus require kernel .config to be modified -or- blacklist.conf with 
>>> be updated
>>> - shares topology filename with generic (main) FW so user still has 
>>> to modify his /lib/firmware. Topology names are currently NHLT-based, 
>>> built from NHLT header data and platform id which are BIOS/ ABL and 
>>> platform specific respectively
>>> (...)
>>
>> I would describe your answer as 'whatabout-ism'. Yes there are plenty 
>> of ways to screw-up, none of them is a justification for assuming that 
>> a single filename will work for everyone.
>>
>> There are also plenty of good reasons to use a different fw and 
>> topology file name. Taking this capability away essentially corners 
>> users into non-upstreamed custom versions.
> 
> There is no "different filename" for /skylake topology on upstream, only 
> fw.

I don't know why we would restrict the discussion to what has been 
upstreamed. This is a fundamental capability that will impact 
non-upstreamed configurations as well.

> 
>>
>>> TLDR:
>>> There is total of 0 people sitting in front of their monitors who are 
>>> consciously going to make use of ULL firmware.
>>> Any user that is going to, will have to play with their kconfig, 
>>> blacklist and replace existing topology file.
>>
>> that's where you are making too many assumptions, if quirks and 
>> dynamic detection capabilities are provided then it's possible to have 
>> a single kernel build that will deal with multiple configurations.
>>
>>> This is normally done by titanic build-bot which, among billion other 
>>> things, ensures /lib/firmware looks like it should given the 
>>> configuration.
>>>
>>> -
>>>
>>> So, one could have provided a nice choice-box within menuconfig to 
>>> ensure only one board can be chosen.
>>> When one does it, one realizes both generic and ULL firmwares are not 
>>> actually tied to any specific board and with more boards (usecases) 
>>> and more kconfigs code gets bloated.
>>>
>>> Moving further, guarding apl_desc with #if-else depending on some 
>>> global generic-vs-ULL configuration which would adjust said 
>>> descriptors with proper FW filename actually seems like a better 
>>> solution..
>>>
>>> ..and then kBOOM comes in and actual design pattern!
>>> Board should have been stated tplg_filename, not the fw_filename. 
>>> Said topology file contains manifest which tells host what libraries 
>>> to load. And thus, we clear the mist and see that one single field 
>>> (which is currently missing in snd_soc_acpi_mach) and some clever 
>>> topology manifest make it all happen: platform-board conflicts cease 
>>> to exist.
>>
>> I am not going to argue further. I've spent a lot of time making sure 
>> the same kernel build can be used across multiple platforms, if you 
>> want to stick to static custom configurations I am not interested in 
>> debating. I just hope your team has enough support folks to deal with 
>> all these configurations.
>>
> 
> Not arguing at all, just stating the facts.
> Idea behind is rather straightforward and my guess it that either you 
> missed the key part -or- my explanations were lackluster.
> We do want kernel to support multiple configurations dynamically. Same 
> goes for allowing for customizations, depending on board chosen. 
> Although, we think topology alone is more than enough.

I am having a hard time on this one. Most quirks are ACPI or DMI based, 
and assuming that the topology magically tells you about the right 
information is a leap of faith that I am not ready to take.

The complexity of the tools and skillset needed to generate a functional 
topology are several orders of magnitude larger than changing a file 
name in a C structure. Even for SOF, the topology is the source of many 
errors, and it feels a lot safer to keep a quirk mechanism that anyone 
can understand rather than assuming that everyone can generate a new 
topology file. There are fewer than 10 people on this planet who 
understand the alsa topology layers in depth, and I don't count myself 
in that lot...

Also for new platforms it's quite common that the tools are delivered 
sometime after power-on steps, so in the initial steps people in the 
trenches make the system work with a topology that was used on a 
previous silicon generation. Tying hardware-related debug and 
topology-related debug is not recommended.

> Existing mach::fw_filename and single tplg file based on data provided 
> from NHLT (function: skl_nhlt_update_topology_bin skl-nhlt.c) already 
> fails us. What is present on upstream is not sufficient and thus 
> build-bots are doing more than they are supposed to.
> 
> Let uss checkout sof machine fields:
> - sof_fw_filename
> - sof_tplg_filename
> 
> and then again, the skl one(s):
> - fw_filename
> 
> Is the difference clear now?
> The key player here is topology file name. Once you tie board with 
> topology you have more than enough customization to do whatever you 
> want. As said, clever usage of topology may even allow you to skip 
> fw_filename entirely. And this is the exact opposite of static 
> configuration.

Except that the boot flow is to first try to boot the DSP with a 
firmware file, then work on topology-related configurations. You would 
be adding a new step that is not desirable in all cases, e.g when you 
care about boot time.

It's also not necessary simpler to base your solution on topology. We 
have tons of topology configurations that are exactly the same for 
different devices, so it's useful to avoid bundling the firmware name 
inside of the topology file.

> In my opinion, SOF needs sof_fw_filename neither.

we will definitely keep the ability to add board-specific quirks. It's 
very useful for e.g. derivatives and experimental cases, e.g. A/B 
testing with one firmware selected with one ACPI ID and another firmware 
selected with another ACPI ID, without mucking with the topology.