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.
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.
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.
In my opinion, SOF needs sof_fw_filename neither.