On 2020-04-23 18:29, Pierre-Louis Bossart wrote:
On 4/23/20 6:40 AM, Cezary Rojewski wrote:
On 2020-04-23 13:24, Takashi Iwai wrote:
On Thu, 23 Apr 2020 13:21:36 +0200,
Cezary Rojewski wrote:
NHLT fetch based on _DSM prevents ACPI table override mechanism from
being utilized. Make use of acpi_get_table to enable it and get rid of
redundant code.
Signed-off-by: Cezary Rojewski <cezary.rojewski@xxxxxxxxx>
This looks like a nice cleanup and I'll happily apply if anyone can
test with the actual hardware -- currently mine has no DSP, so unable
to check.
thanks,
Takashi
NHLT override method has been added for internal use half a year ago
and is for some time the default method within our CI. This is tested
on a wide spread of hardware, that is any Intel AVS archtecture,
including production laptops.
We are checking independently with SOF CI [1], the NHLT is used to
detect microphone counts so we'll see if there's a regression.
That said, for my education Cezary an you clarify what you typically
override? the settings are usually tied to specific hardware configs.
When speaking of testing purposes, we actually ignore the go-to one/two
format limit which is often applied on production stuff. E.g.: you may
proliferate SSP blobs and make use of up to 256 formats (NHLT enforced
limit IIRC). That goes for SSP loopback testing.
Same applies to DMIC. While hardware tells you 0, 2 or 4 channels,
nothing prevents you to play with different bit depths/ sampling rate.
You could even force 2ch on 4ch setups. Clock changes are also part of
the game.
Also the NHLT may point to a topology file name but with your recent
changes an alternate file can be used, so it's not clear to me how
non-Intel folks might use the override and for what?
NHLT-based topology filename is a long standing issue. When you launch
/skylake on a non-NHLT setup (e.g. Linus laptop) you end up with a
perfectly white-spaced filename. Does not look very secure to me. It
also makes it difficult to share topologies with OEMs - in practice
production stuff is available in dozens of different OEM-id/revision-id
combinations, and thus topology naming becomes a nightmare.
Let's get this nightmare over with.
In perfect world all users would have received their stuff with correct
BIOS settings applied. We, humans, did not reach that point yet though.
It's handy to have a quick workaround for that. While none of NHLT GUI
tools are upstreamed yet, spec is already there. So, a clever user (or
one with Intel's help) can dump his existing NHLT table:
cat /sys/firmware/acpi/tables/NHLT > nhlt.bin
Decompile it -or- play with binary directly to append a missing format.
While I am at it, we recently had a bug report where a user provided the
NHLT, and I had no idea how to go about parsing it to check its
contents. Are there any tools to dump the contents in human-readable
representation?
To my knowledge there are none available externally. Maybe soon this
will change. If I managed to push spec upstream, a 'simple tool'
shouldn't be a problem. But who knows..
Internally? There are few : )
[1] https://github.com/thesofproject/linux/pull/2046
