dev_info is too noisy for tplg wiget loading, so move it to
debug level
Signed-off-by: NVinod Koul <vinod.koul@intel.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Initialize and creates DSP controls if processing pipe capability
is supported by HW. Updates the dma_id, hw_params to module param
to be used when DSP module has to be configured.
Signed-off-by: NJeeja KP <jeeja.kp@intel.com>
Signed-off-by: NSubhransu S. Prusty <subhransu.s.prusty@intel.com>
Signed-off-by: NVinod Koul <vinod.koul@intel.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

The SKL driver does not code DSP topology in driver. It uses the
newly added ASoC topology core to parse the topology information
(controls, widgets and map) from topology binary.
Each topology element passed private data which contains
information that driver used to identify the module instance
within firmware and send IPCs for that module to DSP firmware
along with parameters.
This patch adds init routine to invoke topology load and callback
for topology creation.
Signed-off-by: NJeeja KP <jeeja.kp@intel.com>
Signed-off-by: NSubhransu S. Prusty <subhransu.s.prusty@intel.com>
Signed-off-by: NVinod Koul <vinod.koul@intel.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

For FE and BE, the PCM parameters come from FE and BE hw_params
values passed. For a FE we convert the FE params to DSP expected
module format and pass to DSP. For a BE we need to find the
gateway settings (i2s/PDM) to be applied. These are queried from
NHLT table and applied.

Further for BE based on direction the settings are applied as
either source or destination parameters.

These helpers here allow the format to be calculated and queried
as per firmware format.
Signed-off-by: NJeeja KP <jeeja.kp@intel.com>
Signed-off-by: NSubhransu S. Prusty <subhransu.s.prusty@intel.com>
Signed-off-by: NVinod Koul <vinod.koul@intel.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

The Skylake driver topology model tries to model the firmware
rule for pipeline and module creation.
The creation rule is:
 - Create Pipe
 - Add modules to Pipe
 - Connect the modules (bind)
 - Start the pipes

Similarly destroy rule is:
 - Stop the pipe
 - Disconnect it (unbind)
 - Delete the pipe

In driver we use Mixer, as there will always be ONE mixer in a
pipeline to model a pipe. The modules in pipe are modelled as PGA
widgets.  The DAPM sequencing rules (mixer and then PGA) are used
to create the sequence DSP expects as depicted above, and then
widget handlers for PMU and PMD events help in that.

This patch adds widget event handlers for PRE/POST PMU and
PRE/POST PMD event for mixer and pga modules.  These event
handlers invoke pipeline creation, destroy, module creation,
module bind, unbind and pipeline bind unbind

Event handler sequencing is implement to target the DSP FW
sequence expectations to enable path from source to sink pipe for
Playback/Capture.
Signed-off-by: NJeeja KP <jeeja.kp@intel.com>
Signed-off-by: NHardik T Shah <hardik.t.shah@intel.com>
Signed-off-by: NSubhransu S. Prusty <subhransu.s.prusty@intel.com>
Signed-off-by: NVinod Koul <vinod.koul@intel.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

To configure a module, driver needs to send input and output PCM
params for a module in DSP. The FE PCM params come from hw_params
ie from user, for a BE they also come from hw_params but from
BE-link fixups.
So based on PCM params required driver has to find a converter
module (src/updown/format) and then do the conversion and
calculate PCM params in these pipelines In this patch we add the
helper modules which allow driver to do these calculations.
Signed-off-by: NHardik T Shah <hardik.t.shah@intel.com>
Signed-off-by: NJeeja KP <jeeja.kp@intel.com>
Signed-off-by: NSubhransu S. Prusty <subhransu.s.prusty@intel.com>
Signed-off-by: NVinod Koul <vinod.koul@intel.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

SKL driver needs to instantiate pipelines and modules in the DSP.
The topology in the DSP is modelled as DAPM graph with a PGA
representing a module instance and mixer representing a pipeline
for a group of modules along with the mixer itself.

Here we start adding building block for handling these. We add
resource checks (memory/compute) for pipelines, find the modules
in a pipeline, init modules in a pipe and lastly bind/unbind
modules in a pipe These will be used by pipe event handlers in
subsequent patches
Signed-off-by: NJeeja KP <jeeja.kp@intel.com>
Signed-off-by: NSubhransu S. Prusty <subhransu.s.prusty@intel.com>
Signed-off-by: NVinod Koul <vinod.koul@intel.com>
Signed-off-by: NMark Brown <broonie@kernel.org>