[alsa-devel] [PATCH v2 3/9] ASoC: Intel: Skylake: add DSP platform widget event handlers

[Liam Girdwood]

On Mon, 2015-08-17 at 22:56 +0530, Vinod Koul wrote:
> From: Jeeja KP <jeeja.kp at intel.com>
> 
> 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: Jeeja KP <jeeja.kp at intel.com>
> Signed-off-by: Hardik T Shah <hardik.t.shah at intel.com>
> Signed-off-by: Subhransu S. Prusty <subhransu.s.prusty at intel.com>
> Signed-off-by: Vinod Koul <vinod.koul at intel.com>
> ---
>  sound/soc/intel/skylake/skl-topology.c | 416 +++++++++++++++++++++++++++++++++
>  1 file changed, 416 insertions(+)
> 

snip...

> +
> +/*
> + * in the Pre-PMD event of mixer we need to do following:
> + *   - Stop the pipe
> + *   - find the source connections and remove that from dapm_path_list
> + *   - unbind with source pipelines if still connected
> + */
> +static int skl_tplg_mixer_dapm_pre_pmd_event(struct snd_soc_dapm_widget *w,
> +								struct skl *skl)
> +{
> +	struct snd_soc_dapm_widget *source, *sink;
> +	struct skl_module_cfg *src_mconfig, *sink_mconfig;
> +	int ret = 0, path_found = 0;
> +	struct skl_dapm_path_list *path_list, *tmp_list;
> +	struct skl_sst *ctx = skl->skl_sst;
> +
> +	dev_dbg(ctx->dev, "%s: widget = %s\n", __func__, w->name);
> +
> +	sink = w;
> +	sink_mconfig = sink->priv;
> +
> +	/* Stop the pipe */
> +	ret = skl_stop_pipe(ctx, sink_mconfig->pipe);
> +	if (ret)
> +		return ret;
> +
> +	list_for_each_entry_safe(path_list, tmp_list, &skl->dapm_path_list, node) {
> +		if (path_list->dapm_path->sink == sink) {
> +			dev_dbg(ctx->dev, "Path found = %s\n", path_list->dapm_path->name);
> +			source = path_list->dapm_path->source;
> +			src_mconfig = source->priv;
> +			path_found = 1;
> +
> +			list_del(&path_list->node);
> +			kfree(path_list);
> +			break;
> +		}
> +	}
> +

There is a lot of list walking and manipulation in this series and it's
not clear where any locks are being held to prevent list corruption.
I'm assuming list items are being added and removed as part of
loading/unloading the topology data but it looks like we are also
manipulating component lists during DAPM events ?

Liam