[PATCH] ALSA: hda: Refactor Intel NHLT init

[Cezary Rojewski]

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 at 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 : )

> [1] https://github.com/thesofproject/linux/pull/2046