Add Intel nhlt acpi table encoder plugin into topology2.0 processing.
Nhlt internal structure is defined in:
https://01.org/sites/default/files/595976_intel_sst_nhlt.pdf
Nhlt acpi table contain vendor specific binary data blobs that are used
in some Intel dsp platforms for configuring the dmic and ssp hardware.
The function of this code is mainly to generate the vendor specific
binary blobs, but as there is existing nhlt parser code and header in
kernel there's no point of re-inventing the container: just use the
existing nhlt acpi table format. Basically this code is creating similar
nhlt acpi table that you would get from: cat
/sys/firmware/acpi/tables/NHLT
This code will have implementation for dmic and ssp endpoints. Thus the
code will translate the topology dai tokens into vendor specific binary
blobs and pack them into nhlt acpi table. Ssp and dmic code is lifted
from Sound Open Firmware (sof) code base, thus it will have BSD-3
license.
This plugin can be enabled from command line with:
alsatplg -DPREPROCESS_PLUGINS="nhlt" -c foo.conf -p -o bar.tplg
You can also dump the nhlt binary into a file with additional define:
-DNHLT_BIN="nhlt.bin"
Link: https://github.com/alsa-project/alsa-utils/pull/129
Signed-off-by: Jaska Uimonen <jaska.uimonen@linux.intel.com>
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
Add support for pre-processing TLV objects
For example:
Object.Base.tlv."vtlv_m64s2" {}
will be converted to:
SectionTLV.'vtlv_m64s2' {}
And the mixer controle section will be updated to add
the reference to the tlv object.
Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
Add support for pre-processing object instances in the input
config. An object's attributes can be set in multiple places
such as, within the object instance, default values in the class
defnition, inherited from a parent object or explicitly set
in a parent object. Before converting the object config into
the relevant section in the existing syntax, all the attribute
values must be consolidated into one place so that it is easy
to verify if all mandatory attributes are set.
Also, the name of the object will be constructed from the
attributes defined in the attributes.constructor[] config
in the class definition and the unique attribute's value
must be set from the value passed in the object instance.
This patch create a temporary config for each object instance
and populates its unique attribute value. The rest of the steps
will be added in the following patches.
Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
Add a helper function to look up the class definition for
an object. ex: for an object instance, Object.Widget.pga.0{}, the
function returns the config pointing to Class.Widget.pga{} in
the input conf.
Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
Add a couple of helper functions to print debug messages
and the generated config.
Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
This patch adds support for pre-processing the Topology2.0.
The '-p' switch add pre-processing support during compilation
and the '-P' switch is for converting the Topology2.0
configuration file into the existing syntax.
Topology2.0 is a high level keyword extension on top of the existing ALSA
conf topology format designed to:
1) Simplify the ALSA conf topology definitions by providing high level
"classes" so topology designers need to write less config for common
object definitions.
2) Allow simple reuse of objects. Define once and reuse (like M4) with
the ability to alter objects configuration attributes from defaults.
3) Allow data type and value verification. This is not done today and
frequently crops up in FW bug reports.
Common Topology Classes
-----------------------
Topology today has some common classes that are often reused throughout
with slightly altered configurations. i.e. widgets (components),
pipelines, dais and controls.
Topology2.0 introduces the high level concept of reusable "class" like
definition for that can be used to create topology objects.
Common Topology Attributes
--------------------------
Topology defines a lot of attributes per object with different types
and constraints. Today there is no easy way to validate type or
constraints and this can lead to many hard to find problems in FW at
runtime.
A new keyword "DefineAttribute" has been added to define attribute
constraints such as min value, max value, enum_values etc. This
then allows alsatplg to validate each topology object attribute.
Topology Classes define the list of attributes that they use and
whether the attribute is mandatory, can be overridden by parent users
or is immutable. This also helps alsatplg emit the appropriate errors
for attribute misuse.
Class constructor attributes
----------------------------
Some attributes in the class definition are declared as constructor
attributes and these will be used to construct the name of the object.
For ex: for the host widget, the index and direction are constructor
attributes and the name for the widget is derived as follows:
host.1.playback or host.2.capture etc.
Attribute Inheritance:
----------------------
One of the key features of Topology2.0 is how the attribute values are
propagated from a parent object to a child object. For ex: a pipeline
object can pass down the pipeline_id attribute to all its widgets.
Inheritance is implicit when an object and its embedded child objects
have matching names for a attribute/argument. Attribute values
set explicitly in an object instance always has precedence over
the values inherited from the parent object.
Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
1
1
1
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
Add a command line tool that will parse topology text files and convert to the binary
topology data as used by the kernel.
Signed-off-by: Liam Girdwood <liam.r.girdwood@linux.intel.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
