All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
To: Cezary Rojewski <cezary.rojewski@intel.com>, alsa-devel@alsa-project.org
Cc: upstream@semihalf.com, harshapriya.n@intel.com, rad@semihalf.com,
	tiwai@suse.com, hdegoede@redhat.com, broonie@kernel.org,
	amadeuszx.slawinski@linux.intel.com, cujomalainey@chromium.org,
	lma@semihalf.com
Subject: Re: [RFC 07/13] ASoC: Intel: avs: Add topology loading operations
Date: Fri, 25 Feb 2022 13:17:19 -0600	[thread overview]
Message-ID: <361a3139-400a-b86f-9690-a8e06d0890b8@linux.intel.com> (raw)
In-Reply-To: <20220207132532.3782412-8-cezary.rojewski@intel.com>



On 2/7/22 07:25, Cezary Rojewski wrote:
> AVS topology is split into two major parts: dictionaries - found within
> ASoC topology manifest - and path templates - found within DAPM widget
> private data. 

Well, one would hope that the path templates are initially represented
in the topology and set when parsing the topology.

If not, who defines that those 'path templates' are?

It's also unclear which 'DAPM widget' you are referring to?


> +static int avs_route_load(struct snd_soc_component *comp, int index,
> +			  struct snd_soc_dapm_route *route)

I have to ask: what is the difference between stream, path, path
template, route?

> +{
> +	struct snd_soc_acpi_mach *mach = dev_get_platdata(comp->card->dev);
> +	size_t len = SNDRV_CTL_ELEM_ID_NAME_MAXLEN;
> +	char buf[SNDRV_CTL_ELEM_ID_NAME_MAXLEN];
> +	u32 port;
> +
> +	/* See parse_link_formatted_string() for dynamic naming when(s). */
> +	if (hweight_long(mach->link_mask) == 1) {
> +		port = __ffs(mach->link_mask);
> +
> +		snprintf(buf, len, route->source, port);
> +		strncpy((char *)route->source, buf, len);
> +		snprintf(buf, len, route->sink, port);
> +		strncpy((char *)route->sink, buf, len);
> +		if (route->control) {
> +			snprintf(buf, len, route->control, port);
> +			strncpy((char *)route->control, buf, len);
> +		}
> +	}
> +
> +	return 0;
> +}
> +
> +static int avs_widget_load(struct snd_soc_component *comp, int index,
> +			   struct snd_soc_dapm_widget *w,
> +			   struct snd_soc_tplg_dapm_widget *dw)
> +{
> +	struct snd_soc_acpi_mach *mach;
> +	struct avs_tplg_path_template *template;
> +	struct avs_soc_component *acomp = to_avs_soc_component(comp);
> +	struct avs_tplg *tplg;
> +
> +	if (!le32_to_cpu(dw->priv.size))
> +		return 0;
> +
> +	tplg = acomp->tplg;
> +	mach = dev_get_platdata(comp->card->dev);
> +
> +	/* See parse_link_formatted_string() for dynamic naming when(s). */
> +	if (hweight_long(mach->link_mask) == 1) {
> +		kfree(w->name);
> +		/* ->name is freed later by soc_tplg_dapm_widget_create() */

->name? missing something here
w->name?

> +		w->name = kasprintf(GFP_KERNEL, dw->name, __ffs(mach->link_mask));
> +		if (!w->name)
> +			return -ENOMEM;
> +	}
> +
> +	template = avs_tplg_path_template_create(comp, tplg, dw->priv.array,
> +						 le32_to_cpu(dw->priv.size));
> +	if (IS_ERR(template)) {
> +		dev_err(comp->dev, "widget %s load failed: %ld\n", dw->name,
> +			PTR_ERR(template));
> +		return PTR_ERR(template);
> +	}
> +
> +	w->priv = template; /* link path information to widget */
> +	list_add_tail(&template->node, &tplg->path_tmpl_list);
> +	return 0;
> +}
> +
> +static int avs_dai_load(struct snd_soc_component *comp, int index,
> +			struct snd_soc_dai_driver *dai_drv, struct snd_soc_tplg_pcm *pcm,
> +			struct snd_soc_dai *dai)
> +{
> +	if (pcm)
> +		dai_drv->ops = &avs_dai_fe_ops;
> +	return 0;
> +}
> +
> +static int avs_link_load(struct snd_soc_component *comp, int index, struct snd_soc_dai_link *link,
> +			 struct snd_soc_tplg_link_config *cfg)
> +{
> +	/* Stream control handled by IPCs. */
> +	link->nonatomic = true;

if this routine also takes care of BE dailinks, then it's not quite
correct to set nonatomic here.

Should this be set only within the test below?

> +
> +	if (!link->no_pcm) {
> +		/* Open LINK (BE) pipes last and close them first to prevent xruns. */
> +		link->trigger[0] = SND_SOC_DPCM_TRIGGER_PRE;
> +		link->trigger[1] = SND_SOC_DPCM_TRIGGER_PRE;
> +	}
> +
> +	return 0;
> +}


  reply	other threads:[~2022-02-25 20:54 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-07 13:25 [RFC 00/13] ASoC: Intel: avs: Topology and path management Cezary Rojewski
2022-02-07 13:25 ` [RFC 01/13] ASoC: Intel: avs: Declare vendor tokens Cezary Rojewski
2022-02-07 13:25 ` [RFC 02/13] ASoC: Intel: avs: Add topology parsing infrastructure Cezary Rojewski
2022-02-25 17:20   ` Pierre-Louis Bossart
2022-03-21 10:25     ` Cezary Rojewski
2022-02-07 13:25 ` [RFC 03/13] ASoC: Intel: avs: Parse module-extension tuples Cezary Rojewski
2022-02-25 17:24   ` Pierre-Louis Bossart
2022-03-21 10:33     ` Cezary Rojewski
2022-02-07 13:25 ` [RFC 04/13] ASoC: Intel: avs: Parse pplcfg and binding tuples Cezary Rojewski
2022-02-25 17:40   ` Pierre-Louis Bossart
2022-03-21 10:53     ` Cezary Rojewski
2022-02-07 13:25 ` [RFC 05/13] ASoC: Intel: avs: Parse pipeline and module tuples Cezary Rojewski
2022-02-25 18:51   ` Pierre-Louis Bossart
2022-03-21 15:14     ` Cezary Rojewski
2022-02-07 13:25 ` [RFC 06/13] ASoC: Intel: avs: Parse path and path templates tuples Cezary Rojewski
2022-02-25 19:09   ` Pierre-Louis Bossart
2022-03-21 16:15     ` Cezary Rojewski
2022-02-07 13:25 ` [RFC 07/13] ASoC: Intel: avs: Add topology loading operations Cezary Rojewski
2022-02-25 19:17   ` Pierre-Louis Bossart [this message]
2022-03-21 16:28     ` Cezary Rojewski
2022-02-07 13:25 ` [RFC 08/13] ASoC: Intel: avs: Declare path and its components Cezary Rojewski
2022-02-25 19:25   ` Pierre-Louis Bossart
2022-03-21 17:01     ` Cezary Rojewski
2022-03-21 18:14       ` Pierre-Louis Bossart
2022-02-07 13:25 ` [RFC 09/13] ASoC: Intel: avs: Path creation and freeing Cezary Rojewski
2022-02-25 19:36   ` Pierre-Louis Bossart
2022-03-21 17:19     ` Cezary Rojewski
2022-03-21 17:53       ` Cezary Rojewski
2022-02-07 13:25 ` [RFC 10/13] ASoC: Intel: avs: Path state management Cezary Rojewski
2022-02-25 19:42   ` Pierre-Louis Bossart
2022-03-21 17:31     ` Cezary Rojewski
2022-02-07 13:25 ` [RFC 11/13] ASoC: Intel: avs: Arm paths after creating them Cezary Rojewski
2022-02-07 13:25 ` [RFC 12/13] ASoC: Intel: avs: Prepare modules before bindings them Cezary Rojewski
2022-02-07 13:25 ` [RFC 13/13] ASoC: Intel: avs: Configure modules according to their type Cezary Rojewski
2022-02-25 21:35 ` [RFC 00/13] ASoC: Intel: avs: Topology and path management Pierre-Louis Bossart
2022-02-26  0:22   ` Mark Brown

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=361a3139-400a-b86f-9690-a8e06d0890b8@linux.intel.com \
    --to=pierre-louis.bossart@linux.intel.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=amadeuszx.slawinski@linux.intel.com \
    --cc=broonie@kernel.org \
    --cc=cezary.rojewski@intel.com \
    --cc=cujomalainey@chromium.org \
    --cc=harshapriya.n@intel.com \
    --cc=hdegoede@redhat.com \
    --cc=lma@semihalf.com \
    --cc=rad@semihalf.com \
    --cc=tiwai@suse.com \
    --cc=upstream@semihalf.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.