From: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
To: Cezary Rojewski <cezary.rojewski@intel.com>,
alsa-devel@alsa-project.org, broonie@kernel.org
Cc: upstream@semihalf.com, harshapriya.n@intel.com, rad@semihalf.com,
tiwai@suse.com, hdegoede@redhat.com,
amadeuszx.slawinski@linux.intel.com, cujomalainey@chromium.org,
lma@semihalf.com
Subject: Re: [PATCH 02/14] ASoC: Intel: avs: Generic soc component driver
Date: Tue, 26 Apr 2022 16:33:16 -0500 [thread overview]
Message-ID: <988b37aa-a7ce-af9a-76b0-3c4036ba7884@linux.intel.com> (raw)
In-Reply-To: <20220426172346.3508411-3-cezary.rojewski@intel.com>
> +struct avs_dma_data {
> + struct avs_tplg_path_template *template;
> + struct avs_path *path;
> + /*
> + * link stream is stored within substream's runtime
> + * private_data to fulfill the needs of codec BE path
> + *
> + * host stream assigned
not able to parse that comment, what are you trying to say?
> + */
> + struct hdac_ext_stream *host_stream;
> +};
> +
> +static ssize_t topology_name_read(struct file *file, char __user *user_buf, size_t count,
> + loff_t *ppos)
> +{
> + struct snd_soc_component *component = file->private_data;
> + struct snd_soc_card *card = component->card;
> + struct snd_soc_acpi_mach *mach = dev_get_platdata(card->dev);
> + char buf[64];
> + size_t len;
> +
> + len = snprintf(buf, sizeof(buf), "%s/%s\n", component->driver->topology_name_prefix,
> + mach->tplg_filename);
> +
> + return simple_read_from_buffer(user_buf, count, ppos, buf, len);
> +}
> +
> +static const struct file_operations topology_name_fops = {
> + .open = simple_open,
> + .read = topology_name_read,
> + .llseek = default_llseek,
> +};
can you clarify why this is needed?
> +
> +static int avs_component_load_libraries(struct avs_soc_component *acomp)
> +{
> + struct avs_tplg *tplg = acomp->tplg;
> + struct avs_dev *adev = to_avs_dev(acomp->base.dev);
> + int ret;
> +
> + if (!tplg->num_libs)
> + return 0;
> +
> + /* Parent device may be asleep and library loading involves IPCs. */
> + ret = pm_runtime_get_sync(adev->dev);
> + if (ret < 0 && ret != -EACCES) {
> + pm_runtime_put_noidle(adev->dev);
> + return ret;
> + }
Mark recommends the use of pm_runtime_resume_and_get(), see patches from today.
> +
> + avs_hda_clock_gating_enable(adev, false);
> + avs_hda_l1sen_enable(adev, false);
> +
> + ret = avs_dsp_load_libraries(adev, tplg->libs, tplg->num_libs);
> +
> + avs_hda_l1sen_enable(adev, true);
> + avs_hda_clock_gating_enable(adev, true);
> +
> + if (!ret)
> + ret = avs_module_info_init(adev, false);
> +
> + pm_runtime_mark_last_busy(adev->dev);
> + pm_runtime_put_autosuspend(adev->dev);
> +
> + return ret;
> +}
> +
> +static int avs_component_probe(struct snd_soc_component *component)
> +{
> + struct snd_soc_card *card = component->card;
> + struct snd_soc_acpi_mach *mach;
> + struct avs_soc_component *acomp;
> + struct avs_dev *adev;
> + char *filename;
> + int ret;
> +
> + dev_dbg(card->dev, "probing %s card %s\n", component->name, card->name);
> + mach = dev_get_platdata(card->dev);
> + acomp = to_avs_soc_component(component);
> + adev = to_avs_dev(component->dev);
> +
> + acomp->tplg = avs_tplg_new(component);
> + if (!acomp->tplg)
> + return -ENOMEM;
> +
> + if (!mach->tplg_filename)
> + goto finalize;
> +
> + /* Load specified topology and create sysfs for it. */
> + filename = kasprintf(GFP_KERNEL, "%s/%s", component->driver->topology_name_prefix,
> + mach->tplg_filename);
what is the link between topology and sysfs?
> + if (!filename)
> + return -ENOMEM;
> +
> + ret = avs_load_topology(component, filename);
> + kfree(filename);
> + if (ret < 0)
> + return ret;
> +
> + ret = avs_component_load_libraries(acomp);
> + if (ret < 0) {
> + dev_err(card->dev, "libraries loading failed: %d\n", ret);
> + goto err_load_libs;
> + }
> +
> +finalize:
> + debugfs_create_file("topology_name", 0444, component->debugfs_root, component,
> + &topology_name_fops);
that's debugfs here, is this to make it possible to select an alternate topology file? If yes, a comment earlier wouldn't hurt.
> +
> + mutex_lock(&adev->comp_list_mutex);
> + list_add_tail(&acomp->node, &adev->comp_list);
> + mutex_unlock(&adev->comp_list_mutex);
> +
> + return 0;
> +
> +err_load_libs:
> + avs_remove_topology(component);
> + return ret;
> +}
> +
> +static const struct snd_soc_component_driver avs_component_driver = {
> + .name = "avs-pcm",
> + .probe = avs_component_probe,
> + .remove = avs_component_remove,
> + .open = avs_component_open,
> + .pointer = avs_component_pointer,
> + .mmap = avs_component_mmap,
> + .pcm_construct = avs_component_construct,
> + .module_get_upon_open = 1, /* increment refcount when a pcm is opened */
> + .topology_name_prefix = "intel/avs",
is this intentional that the firmware binaries and topologies will be stored in the same intel/avs directory?
> + .non_legacy_dai_naming = true,
is this needed? we've never used this for Intel?
> +};
> +
next prev parent reply other threads:[~2022-04-26 22:24 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-26 17:23 [PATCH 00/14] ASoC: Intel: avs: Driver core and PCM operations Cezary Rojewski
2022-04-26 17:23 ` [PATCH 01/14] ASoC: Intel: avs: Account for libraries when booting basefw Cezary Rojewski
2022-04-26 21:21 ` Pierre-Louis Bossart
2022-05-01 9:45 ` Cezary Rojewski
2022-05-06 15:25 ` Piotr Maziarz
2022-05-06 15:47 ` Pierre-Louis Bossart
2022-04-26 17:23 ` [PATCH 02/14] ASoC: Intel: avs: Generic soc component driver Cezary Rojewski
2022-04-26 21:33 ` Pierre-Louis Bossart [this message]
2022-05-01 10:45 ` Cezary Rojewski
2022-04-26 17:23 ` [PATCH 03/14] ASoC: Intel: avs: Generic PCM FE operations Cezary Rojewski
2022-04-26 17:23 ` [PATCH 04/14] ASoC: Intel: avs: non-HDA PCM BE operations Cezary Rojewski
2022-04-26 21:40 ` Pierre-Louis Bossart
2022-05-01 10:48 ` Cezary Rojewski
2022-04-26 17:23 ` [PATCH 05/14] ASoC: Intel: avs: HDA " Cezary Rojewski
2022-04-26 21:45 ` Pierre-Louis Bossart
2022-05-01 10:55 ` Cezary Rojewski
2022-04-26 17:23 ` [PATCH 06/14] ASoC: Intel: avs: Coredump and recovery flow Cezary Rojewski
2022-04-26 21:53 ` Pierre-Louis Bossart
2022-05-01 15:32 ` Cezary Rojewski
2022-05-02 13:53 ` Pierre-Louis Bossart
2022-04-26 17:23 ` [PATCH 07/14] ASoC: Intel: avs: Prepare for firmware tracing Cezary Rojewski
2022-04-26 17:23 ` [PATCH 08/14] ASoC: Intel: avs: D0ix power state support Cezary Rojewski
2022-04-26 21:58 ` Pierre-Louis Bossart
2022-04-29 14:19 ` Cezary Rojewski
2022-04-29 14:33 ` Cezary Rojewski
2022-04-26 17:23 ` [PATCH 09/14] ASoC: Intel: avs: Event tracing Cezary Rojewski
2022-04-26 17:23 ` [PATCH 10/14] ASoC: Intel: avs: Machine board registration Cezary Rojewski
2022-04-26 22:12 ` Pierre-Louis Bossart
2022-04-29 14:01 ` Cezary Rojewski
2022-05-04 9:41 ` Amadeusz Sławiński
2022-05-04 11:12 ` Cezary Rojewski
2022-05-04 11:26 ` Péter Ujfalusi
2022-05-04 12:33 ` Cezary Rojewski
2022-04-26 17:23 ` [PATCH 11/14] ASoC: Intel: avs: PCI driver implementation Cezary Rojewski
2022-04-26 17:23 ` [PATCH 12/14] ASoC: Intel: avs: Power management Cezary Rojewski
2022-04-26 22:18 ` Pierre-Louis Bossart
2022-04-29 13:44 ` Cezary Rojewski
2022-04-26 17:23 ` [PATCH 13/14] ASoC: Intel: avs: SKL-based platforms support Cezary Rojewski
2022-04-26 17:23 ` [PATCH 14/14] ASoC: Intel: avs: APL-based " Cezary Rojewski
2022-04-27 8:15 ` [PATCH 00/14] ASoC: Intel: avs: Driver core and PCM operations Cezary Rojewski
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=988b37aa-a7ce-af9a-76b0-3c4036ba7884@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox