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.
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
