Re: [PATCH v7 0/4] ACPI: NHLT: Access and query helpers

[Andy Shevchenko <andriy.shevchenko@linux.intel.com>]

On Mon, Mar 11, 2024 at 11:16:54AM +0100, Cezary Rojewski wrote:
> The goal of this patchset is to refactor existing interface of
> Non HDAudio Link Table (NHLT) table so it becomes useful for the Intel
> AudioDSP sound-drivers. Right now the useful duplicate resides in
> sound/hda/intel-nhlt.c.
> 
> The API takes form of query functions that help access device or
> audio-format configuration space. This information can be then utilized
> by a sound-driver to perform necessary programming and facilitate
> streaming over I2S/PDM interfaces. Once the series is merged, existing
> sound-drivers can move from utilizing sound/hda/intel-nhlt.c to this
> very code and ultimately the former file can be removed.
> 
> Paired with equivalent change on ACPICA [1].
> 
> -
> 
> Non HDAudio Link Table (NHLT) is designed to separate hardware-related
> description (registers) from AudioDSP firmware-related one i.e.:
> pipelines and modules that together make up the audio stream on Intel
> DSPs. This task is important as same set of hardware registers can be
> used with different topologies and vice versa, same topology could be
> utilized with different set of hardware. As the hardware registers
> description is directly tied to specific platform, intention is to have
> such description part of low-level firmware e.g.: BIOS.
> 
> The initial design has been provided in early Sky Lake (SKL) days. The
> audio architecture goes by the name cAVS. SKL is a representative of
> cAVS 1.5. The table helps describe endpoint capabilities ever since.
> While Raptor Lake (RPL) is the last of cAVS architecture - cAVS 2.5 to
> be precise - its successor, the ACE architecture which begun with
> Meteor Lake (MTL) inherited the design for all I2S and PDM
> configurations. These two configurations are the primary targets for
> NHLT table.
> 
> Due to naming conflicts with existing code, several structs are named
> 'nhlt2' rather than 'nhlt'. Last patch cleans the situation up.

FWIW, I am fine with this version esp. taking into account the specification
and ACPICA work,

Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>

-- 
With Best Regards,
Andy Shevchenko