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@intel.com
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 : )