Current topology only allows for widget configuration before the widget
is registered. This patch also allows further configuration and usage
after registration is complete.
Signed-off-by: Liam Girdwood <liam.r.girdwood@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
We should be declaring snd_kcontrol_new and soc_dai_link as both are
used within this header so need to be declared.
[Reworded commit message to indicate this wasn't an immediate build
failure -- broonie]
Signed-off-by: Liam Girdwood <liam.r.girdwood@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
This patch will check the type of embedded controls for a widget, and
only free the TLV of volume mixers. Bytes controls don't have TLV.
Just free the private value which is used as struct soc_mixer_control
for volume mixers or soc_bytes_ext for bytes controls. No need to cast
to these types before freeing it.
Signed-off-by: Mengdong Lin <mengdong.lin@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Topology will also create FE DAI links dynamically from the PCM
objects. These links will be removed when the component is removed
and its topology info is unloaded.
The component driver can implement link_load/unload ops for extra
intialization (e.g. error check) and destruction.
Signed-off-by: Mengdong Lin <mengdong.lin@linux.intel.com>
Acked-by: Liam Girdwood <liam.r.girdwood@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Topology will create FE DAIs dynamically from the PCM objects,
and register them to the component.
A PCM topoplogy object describes a FE DAI and DAI link. Later
patch will add FE DAI links as well.
Change tplg load ops for DAI:
- Only process a DAI.
- Pass the DAI driver pointer to the component driver for
extra initialization.
Signed-off-by: Mengdong Lin <mengdong.lin@linux.intel.com>
Acked-by: Liam Girdwood <liam.r.girdwood@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Add kcontrol to the tlv callbacks in soc_bytes_ext, as it is
needed for referencing the corresponding control in the driver
code
Also fix the only upstream user in topology core
Signed-off-by: Mythri P K <mythri.p.k@intel.com>
Signed-off-by: Jeeja KP <jeeja.kp@intel.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Allow vendor drivers to define bespoke bytes ext handlers and IDs for
TLV bytes controls. And the topology core will bind these handlers by
matching IDs defined by the vendor driver and user space topology
data file.
And TLV callback binding is moved to soc_tplg_kcontrol_bind_io(). This
function process all handler binding now.
Signed-off-by: Mengdong Lin <mengdong.lin@intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Vendor specific handlers should override standard handlers. So we can
handle things in the order from specific to generic.
Signed-off-by: Mengdong Lin <mengdong.lin@intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Allow the topology code to be compiled out so that users who don't need
topology don't need to havve the code compiled in, saving them some
memory.
Some more configuration could be added to remove some of the hooks into
the core data structures but that is probably best done with some
refactoring to use functions to do the updates of the data structures
rather than ifdefing in the code as we'd need to do at the minute.
Suggested-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
The topology core parses the FW topology file for known block types and
instanciates any common ALSA/ASoC objects that it discovers. The core
also passes any block that is does not understand to client component
drivers for enumeration.
The core exports some APIs to client drivers in order to load and unload
firmware topology data as use case require.
Currently the core deals with the following object types :-
o kcontrols. This includes TLV, enumerated and bytes controls.
o DAPM widgets. All types with any associated kcontrol.
o DAPM graph.
o FE PCM. FE PCM capabilities and configuration can be defined.
o BE DAI Link. BE DAI link capabilities and configuration can be defined.
o Codec <-> codec style links capabilities and configuration.
Signed-off-by: Liam Girdwood <liam.r.girdwood@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Liam Girdwood