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,
	ranjani.sridharan@linux.intel.com,
	amadeuszx.slawinski@linux.intel.com, cujomalainey@chromium.org,
	lma@semihalf.com
Subject: Re: [PATCH v4 11/17] ASoC: Intel: avs: Firmware resources management utilities
Date: Wed, 9 Mar 2022 16:36:06 -0600	[thread overview]
Message-ID: <5e47e4dd-bef1-8c3c-ba28-d651fc2dae9a@linux.intel.com> (raw)
In-Reply-To: <20220309204029.89040-12-cezary.rojewski@intel.com>


>   /*
>    * struct avs_dev - Intel HD-Audio driver data
>    *
>    * @dev: PCI device
>    * @dsp_ba: DSP bar address
>    * @spec: platform-specific descriptor
> + * @fw_cfg: Firmware configuration, obtained through FW_CONFIG message
> + * @hw_cfg: Hardware configuration, obtained through HW_CONFIG message
> + * @mods_info: Available module-types, obtained through MODULES_INFO message

is this just for the base firmware? If this includes the extensions, how 
are the module types defined?

> + * @mod_idas: Module instance ID pool, one per module-type
> + * @modres_mutex: For synchronizing any @mods_info updates
> + * @ppl_ida: Pipeline instance ID pool
> + * @fw_list: List of libraries loaded, including base firmware
>    */
>   struct avs_dev {
>   	struct hda_bus base;
> @@ -68,6 +82,14 @@ struct avs_dev {
>   	const struct avs_spec *spec;
>   	struct avs_ipc *ipc;
>   
> +	struct avs_fw_cfg fw_cfg;
> +	struct avs_hw_cfg hw_cfg;
> +	struct avs_mods_info *mods_info;
> +	struct ida **mod_idas;
> +	struct mutex modres_mutex;
> +	struct ida ppl_ida;
> +	struct list_head fw_list;
> +
>   	struct completion fw_ready;
>   };

> +/* Caller responsible for holding adev->modres_mutex. */
> +static int
> +avs_module_ida_alloc(struct avs_dev *adev, struct avs_mods_info *newinfo, bool purge)
> +{
> +	struct avs_mods_info *oldinfo = adev->mods_info;
> +	struct ida **ida_ptrs;
> +	u32 tocopy_count = 0;
> +	int i;
> +
> +	if (!purge && oldinfo) {
> +		if (oldinfo->count >= newinfo->count)
> +			dev_warn(adev->dev, "refreshing %d modules info with %d\n",
> +				 oldinfo->count, newinfo->count);
> +		tocopy_count = oldinfo->count;
> +	}
> +
> +	ida_ptrs = kcalloc(newinfo->count, sizeof(*ida_ptrs), GFP_KERNEL);
> +	if (!ida_ptrs)
> +		return -ENOMEM;
> +
> +	if (tocopy_count)
> +		memcpy(ida_ptrs, adev->mod_idas, tocopy_count * sizeof(*ida_ptrs));
> +
> +	for (i = tocopy_count; i < newinfo->count; i++) {
> +		ida_ptrs[i] = kzalloc(sizeof(**ida_ptrs), GFP_KERNEL);
> +		if (!ida_ptrs[i]) {
> +			while (i--)
> +				kfree(ida_ptrs[i]);

it's a bit hairy to play with the loop counter, I would jump to an error 
handling label to make it clearer.
> +
> +			kfree(ida_ptrs);
> +			return -ENOMEM;
> +		}
> +
> +		ida_init(ida_ptrs[i]);
> +	}
> +
> +	/* If old elements have been reused, don't wipe them. */

the comment is very odd, there's either a free() or a destroy() 
happening below...

> +	if (tocopy_count)
> +		kfree(adev->mod_idas);
> +	else
> +		avs_module_ida_destroy(adev);
> +
> +	adev->mod_idas = ida_ptrs;
> +	return 0;
> +}

> +int avs_module_id_alloc(struct avs_dev *adev, u16 module_id)
> +{
> +	int ret, idx, max_id;
> +
> +	mutex_lock(&adev->modres_mutex);
> +
> +	idx = avs_module_id_entry_index(adev, module_id);
> +	if (idx == -ENOENT) {
> +		WARN(1, "invalid module id: %d", module_id);

dev_err() seems to be more than enough, why would you add a complete 
call trace?

> +		ret = -EINVAL;
> +		goto exit;
> +	}
> +	max_id = adev->mods_info->entries[idx].instance_max_count - 1;
> +	ret = ida_alloc_max(adev->mod_idas[idx], max_id, GFP_KERNEL);
> +exit:
> +	mutex_unlock(&adev->modres_mutex);
> +	return ret;
> +}
> +
> +void avs_module_id_free(struct avs_dev *adev, u16 module_id, u8 instance_id)
> +{
> +	int idx;
> +
> +	mutex_lock(&adev->modres_mutex);
> +
> +	idx = avs_module_id_entry_index(adev, module_id);
> +	if (idx == -ENOENT) {
> +		WARN(1, "invalid module id: %d", module_id);

same WARN is over-engineered.

> +		goto exit;
> +	}
> +
> +	ida_free(adev->mod_idas[idx], instance_id);
> +exit:
> +	mutex_unlock(&adev->modres_mutex);
> +}
> +
> +/*

I am running out of time and will resume this review next week.

  reply	other threads:[~2022-03-09 22:39 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-09 20:40 [PATCH v4 00/17] ASoC: Intel: AVS - Audio DSP for cAVS Cezary Rojewski
2022-03-09 20:40 ` [PATCH v4 01/17] ALSA: hda: Add helper macros for DSP capable devices Cezary Rojewski
2022-03-10 13:30   ` Takashi Iwai
2022-03-09 20:40 ` [PATCH v4 02/17] ASoC: Export DAI register and widget ctor and dctor functions Cezary Rojewski
2022-03-09 20:40 ` [PATCH v4 03/17] ASoC: Intel: Introduce AVS driver Cezary Rojewski
2022-03-09 21:58   ` Pierre-Louis Bossart
2022-03-11 15:32     ` Cezary Rojewski
2022-03-09 20:40 ` [PATCH v4 04/17] ASoC: Intel: avs: Inter process communication Cezary Rojewski
2022-03-09 22:10   ` Pierre-Louis Bossart
2022-03-11 15:40     ` Cezary Rojewski
2022-03-09 20:40 ` [PATCH v4 05/17] ASoC: Intel: avs: Add code loading requests Cezary Rojewski
2022-03-09 20:40 ` [PATCH v4 06/17] ASoC: Intel: avs: Add pipeline management requests Cezary Rojewski
2022-03-09 20:40 ` [PATCH v4 07/17] ASoC: Intel: avs: Add module " Cezary Rojewski
2022-03-09 22:16   ` Pierre-Louis Bossart
2022-03-11 15:40     ` Cezary Rojewski
2022-03-09 20:40 ` [PATCH v4 08/17] ASoC: Intel: avs: Add power " Cezary Rojewski
2022-03-09 20:40 ` [PATCH v4 09/17] ASoC: Intel: avs: Add ROM requests Cezary Rojewski
2022-03-09 20:40 ` [PATCH v4 10/17] ASoC: Intel: avs: Add basefw runtime-parameter requests Cezary Rojewski
2022-03-09 22:20   ` Pierre-Louis Bossart
2022-03-09 20:40 ` [PATCH v4 11/17] ASoC: Intel: avs: Firmware resources management utilities Cezary Rojewski
2022-03-09 22:36   ` Pierre-Louis Bossart [this message]
2022-03-10 17:11     ` Cezary Rojewski
2022-03-11 12:10       ` Mark Brown
2022-03-11 15:28         ` Cezary Rojewski
2022-03-11 15:46     ` Cezary Rojewski
2022-03-11 15:59       ` Pierre-Louis Bossart
2022-03-11 17:20         ` Cezary Rojewski
2022-03-11 20:30           ` Pierre-Louis Bossart
2022-03-14 17:59             ` Cezary Rojewski
2022-03-09 20:40 ` [PATCH v4 12/17] ASoC: Intel: avs: Declare module configuration types Cezary Rojewski
2022-03-09 20:40 ` [PATCH v4 13/17] ASoC: Intel: avs: Dynamic firmware resources management Cezary Rojewski
2022-03-09 20:40 ` [PATCH v4 14/17] ASoC: Intel: avs: General code loading flow Cezary Rojewski
2022-03-09 20:40 ` [PATCH v4 15/17] ASoC: Intel: avs: Implement CLDMA transfer Cezary Rojewski
2022-03-09 20:40 ` [PATCH v4 16/17] ASoC: Intel: avs: Code loading over CLDMA Cezary Rojewski
2022-03-09 20:40 ` [PATCH v4 17/17] ASoC: Intel: avs: Code loading over HDA 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=5e47e4dd-bef1-8c3c-ba28-d651fc2dae9a@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=ranjani.sridharan@linux.intel.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.