All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ranjani Sridharan <ranjani.sridharan@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, pierre-louis.bossart@linux.intel.com,
	hdegoede@redhat.com, broonie@kernel.org,
	amadeuszx.slawinski@linux.intel.com, cujomalainey@chromium.org,
	lma@semihalf.com
Subject: Re: [PATCH v3 07/17] ASoC: Intel: avs: Add module management requests
Date: Fri, 04 Mar 2022 08:21:35 -0800	[thread overview]
Message-ID: <0e7e51e94157c6ca43957b27a13fd4cf058bfc33.camel@linux.intel.com> (raw)
In-Reply-To: <20220304145755.2844173-8-cezary.rojewski@intel.com>

On Fri, 2022-03-04 at 15:57 +0100, Cezary Rojewski wrote:
> Firmware modules implement processing algorithms. Their lifecycle,
> similarly to pipelines is being controlled by IPCs: initialization,
> deletion and (un)binding.
> 
> Modules can be configured at runtime - runtime parameters. This is
> done
> with help of LARGE_CONFIG IPCs: getter and setter.
> 
> Signed-off-by: Amadeusz Sławiński <
> amadeuszx.slawinski@linux.intel.com>
> Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com>
> ---
>  sound/soc/intel/avs/ipc.c      |   8 +-
>  sound/soc/intel/avs/messages.c | 262
> +++++++++++++++++++++++++++++++++
>  sound/soc/intel/avs/messages.h |  53 +++++++
>  3 files changed, 322 insertions(+), 1 deletion(-)
> 
> diff --git a/sound/soc/intel/avs/ipc.c b/sound/soc/intel/avs/ipc.c
> index c0722f8b195f..9770368a898e 100644
> --- a/sound/soc/intel/avs/ipc.c
> +++ b/sound/soc/intel/avs/ipc.c
> @@ -21,9 +21,15 @@ static void avs_dsp_receive_rx(struct avs_dev
> *adev, u64 header)
>  
>  	ipc->rx.header = header;
>  	/* Abort copying payload if request processing was
> unsuccessful. */
> -	if (!msg.status)
> +	if (!msg.status) {
> +		/* update size in case of LARGE_CONFIG_GET */
> +		if (msg.msg_target == AVS_MOD_MSG &&
> +		    msg.global_msg_type == AVS_MOD_LARGE_CONFIG_GET)
> +			ipc->rx.size =
> msg.ext.large_config.data_off_size;
> +
>  		memcpy_fromio(ipc->rx.data, avs_uplink_addr(adev),
>  			      ipc->rx.size);
> +	}
>  }
>  
>  static void avs_dsp_process_notification(struct avs_dev *adev, u64
> header)
> diff --git a/sound/soc/intel/avs/messages.c
> b/sound/soc/intel/avs/messages.c
> index de2d50f8c6b4..613c9452226d 100644
> --- a/sound/soc/intel/avs/messages.c
> +++ b/sound/soc/intel/avs/messages.c
> @@ -6,6 +6,7 @@
>  //          Amadeusz Slawinski <amadeuszx.slawinski@linux.intel.com>
>  //
>  
> +#include <linux/slab.h>
>  #include "avs.h"
>  #include "messages.h"
>  
> @@ -139,3 +140,264 @@ int avs_ipc_get_pipeline_state(struct avs_dev
> *adev, u8 instance_id,
>  	*state = reply.rsp.ext.get_ppl_state.state;
>  	return ret;
>  }
> +
> +/*
> + * avs_ipc_init_instance - Initialize module instance
> + *
> + * @adev: Driver context
> + * @module_id: Module-type id
> + * @instance_id: Unique module instance id
> + * @ppl_id: Parent pipeline id
> + * @core_id: DSP core to allocate module on
> + * @domain: Processing domain (low latency or data processing)
> + * @param: Module-type specific configuration
> + * @param_size: Size of @param in bytes
> + *
> + * Argument verification, as well as pipeline state checks are done
> by the
> + * firmware.
> + *
> + * Note: @ppl_id and @core_id are independent of each other as
> single pipeline
> + * can be composed of module instances located on different DSP
> cores.
> + */
> +int avs_ipc_init_instance(struct avs_dev *adev, u16 module_id, u8
> instance_id,
> +			  u8 ppl_id, u8 core_id, u8 domain,
> +			  void *param, u32 param_size)
> +{
> +	union avs_module_msg msg = AVS_MODULE_REQUEST(INIT_INSTANCE);
> +	struct avs_ipc_msg request;
> +	int ret;
> +
> +	msg.module_id = module_id;
> +	msg.instance_id = instance_id;
> +	/* firmware expects size provided in dwords */
> +	msg.ext.init_instance.param_block_size =
> +			DIV_ROUND_UP(param_size, sizeof(u32));
> +	msg.ext.init_instance.ppl_instance_id = ppl_id;
> +	msg.ext.init_instance.core_id = core_id;
> +	msg.ext.init_instance.proc_domain = domain;
> +
> +	request.header = msg.val;
> +	request.data = param;
> +	request.size = param_size;
> +
> +	ret = avs_dsp_send_msg(adev, &request, NULL);
> +	if (ret)
> +		avs_ipc_err(adev, &request, "init instance", ret);
> +
> +	return ret;
> +}
> +
> +/*
> + * avs_ipc_delete_instance - Delete module instance
> + *
> + * @adev: Driver context
> + * @module_id: Module-type id
> + * @instance_id: Unique module instance id
> + *
> + * Argument verification, as well as pipeline state checks are done
> by the
> + * firmware.
> + *
> + * Note: only standalone modules i.e. without a parent pipeline
> shall be
> + * deleted using this IPC message. In all other cases, pipeline
> owning the
> + * modules peforms cleanup automatically when it is deleted.
Can you please provide an example of such stand-alone modules? If they
aren't part of any pipeline, how do they get scheduled?

> + */
> +int avs_ipc_delete_instance(struct avs_dev *adev, u16 module_id, u8
> instance_id)
> +{
> +	union avs_module_msg msg = AVS_MODULE_REQUEST(DELETE_INSTANCE);
> +	struct avs_ipc_msg request = {{0}};
> +	int ret;
> +
> +	msg.module_id = module_id;
> +	msg.instance_id = instance_id;
> +	request.header = msg.val;
> +
> +	ret = avs_dsp_send_msg(adev, &request, NULL);
> +	if (ret)
> +		avs_ipc_err(adev, &request, "delete instance", ret);
> +
> +	return ret;
> +}
> +
> +/*
> + * avs_ipc_bind - Bind two module instances
> + *
> + * @adev: Driver context
> + * @module_id: Source module-type id
> + * @instance_id: Source module instance id
> + * @dst_module_id: Sink module-type id
> + * @dst_instance_id: Sink module instance id
> + * @dst_queue: Sink module pin to bind @src_queue with
> + * @src_queue: Source module pin to bind @dst_queue with
> + */
> +int avs_ipc_bind(struct avs_dev *adev, u16 module_id, u8
> instance_id,
> +		 u16 dst_module_id, u8 dst_instance_id,
> +		 u8 dst_queue, u8 src_queue)
> +{
> +	union avs_module_msg msg = AVS_MODULE_REQUEST(BIND);
> +	struct avs_ipc_msg request = {{0}};
> +	int ret;
> +
> +	msg.module_id = module_id;
> +	msg.instance_id = instance_id;
> +	msg.ext.bind_unbind.dst_module_id = dst_module_id;
> +	msg.ext.bind_unbind.dst_instance_id = dst_instance_id;
> +	msg.ext.bind_unbind.dst_queue = dst_queue;
> +	msg.ext.bind_unbind.src_queue = src_queue;
> +	request.header = msg.val;
> +
> +	ret = avs_dsp_send_msg(adev, &request, NULL);
> +	if (ret)
> +		avs_ipc_err(adev, &request, "bind modules", ret);
> +
> +	return ret;
> +}
> +
> +/*
> + * avs_ipc_unbind - Unbind two module instances
> + *
> + * @adev: Driver context
> + * @module_id: Source module-type id
> + * @instance_id: Source module instance id
> + * @dst_module_id: Sink module-type id
> + * @dst_instance_id: Sink module instance id
> + * @dst_queue: Sink module pin to unbind @src_queue from
> + * @src_queue: Source module pin to unbind @dst_queue from
> + */
Are there any rules for unbinding? For example if you have 2 modules
connected to a mixer? Can you unbind the module belonging to the host
pipeline that is getting stopped while the mixer is still active?

> +int avs_ipc_unbind(struct avs_dev *adev, u16 module_id, u8
> instance_id,
> +		   u16 dst_module_id, u8 dst_instance_id,
> +		   u8 dst_queue, u8 src_queue)
> +{
> +	union avs_module_msg msg = AVS_MODULE_REQUEST(UNBIND);
> +	struct avs_ipc_msg request = {{0}};
> +	int ret;
> +
> +	msg.module_id = module_id;
> +	msg.instance_id = instance_id;
> +	msg.ext.bind_unbind.dst_module_id = dst_module_id;
> +	msg.ext.bind_unbind.dst_instance_id = dst_instance_id;
> +	msg.ext.bind_unbind.dst_queue = dst_queue;
> +	msg.ext.bind_unbind.src_queue = src_queue;
> +	request.header = msg.val;
> +
> +	ret = avs_dsp_send_msg(adev, &request, NULL);
> +	if (ret)
> +		avs_ipc_err(adev, &request, "unbind modules", ret);
> +
> +	return ret;
> +}
> +
> +static int __avs_ipc_set_large_config(struct avs_dev *adev, u16
> module_id, u8 instance_id,
> +				      u8 param_id, bool init_block,
> bool final_block,
> +				      u8 *request_data, size_t
> request_size, size_t off_size)
> +{
> +	union avs_module_msg msg =
> AVS_MODULE_REQUEST(LARGE_CONFIG_SET);
> +	struct avs_ipc_msg request;
> +	int ret;
> +
> +	msg.module_id = module_id;
> +	msg.instance_id = instance_id;
> +	msg.ext.large_config.data_off_size = off_size;
> +	msg.ext.large_config.large_param_id = param_id;
> +	msg.ext.large_config.final_block = final_block;
> +	msg.ext.large_config.init_block = init_block;
> +
> +	request.header = msg.val;
> +	request.data = request_data;
> +	request.size = request_size;
> +
> +	ret = avs_dsp_send_msg(adev, &request, NULL);
> +	if (ret)
> +		avs_ipc_err(adev, &request, "large config set", ret);
> +
> +	return ret;
> +}
> +
> +int avs_ipc_set_large_config(struct avs_dev *adev, u16 module_id,
> +			     u8 instance_id, u8 param_id,
> +			     u8 *request, size_t request_size)
> +{
> +	size_t remaining, tx_size;
> +	bool final;
> +	int ret;
> +
> +	remaining = request_size;
> +	tx_size = min_t(size_t, AVS_MAILBOX_SIZE, remaining);
> +	final = (tx_size == remaining);
> +
> +	/* Initial request states total payload size. */
> +	ret = __avs_ipc_set_large_config(adev, module_id, instance_id,
> +					 param_id, 1, final, request,
> tx_size,
> +					 request_size);
> +	if (ret)
> +		return ret;
> +
> +	remaining -= tx_size;
> +
> +	/* Loop the rest only when payload exceeds mailbox's size. */
> +	while (remaining) {
> +		size_t offset;
> +
> +		offset = request_size - remaining;
> +		tx_size = min_t(size_t, AVS_MAILBOX_SIZE, remaining);
> +		final = (tx_size == remaining);
> +
> +		ret = __avs_ipc_set_large_config(adev, module_id,
> instance_id,
> +						 param_id, 0, final,
> +						 request + offset,
> tx_size,
> +						 offset);
> +		if (ret)
> +			return ret;
> +
> +		remaining -= tx_size;
> +	}
> +
> +	return 0;
> +}
> +
> +int avs_ipc_get_large_config(struct avs_dev *adev, u16 module_id, u8
> instance_id,
> +			     u8 param_id, u8 *request_data, size_t
> request_size,
> +			     u8 **reply_data, size_t *reply_size)
> +{
> +	union avs_module_msg msg =
> AVS_MODULE_REQUEST(LARGE_CONFIG_GET);
> +	struct avs_ipc_msg request;
> +	struct avs_ipc_msg reply = {{0}};
> +	size_t size;
> +	void *buf;
> +	int ret;
> +
> +	reply.data = kzalloc(AVS_MAILBOX_SIZE, GFP_KERNEL);
> +	if (!reply.data)
> +		return -ENOMEM;
> +
> +	msg.module_id = module_id;
> +	msg.instance_id = instance_id;
> +	msg.ext.large_config.data_off_size = request_size;
> +	msg.ext.large_config.large_param_id = param_id;
> +	/* final_block is always 0 on request. Updated by fw on reply.
> */
> +	msg.ext.large_config.final_block = 0;
> +	msg.ext.large_config.init_block = 1;
> +
> +	request.header = msg.val;
> +	request.data = request_data;
> +	request.size = request_size;
> +	reply.size = AVS_MAILBOX_SIZE;
> +
> +	ret = avs_dsp_send_msg(adev, &request, &reply);
> +	if (ret) {
> +		avs_ipc_err(adev, &request, "large config get", ret);
> +		kfree(reply.data);
> +		return ret;
> +	}
How come you dont have a loop here? What if the rec'd data size if
larger than the max size of IP payload?
Thanks,Ranjani


  reply	other threads:[~2022-03-04 16:22 UTC|newest]

Thread overview: 65+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-04 14:57 [PATCH v3 00/17] ASoC: Intel: AVS - Audio DSP for cAVS Cezary Rojewski
2022-03-04 14:57 ` [PATCH v3 01/17] ALSA: hda: Add helper macros for DSP capable devices Cezary Rojewski
2022-03-04 14:57 ` [PATCH v3 02/17] ASoC: Export DAI register and widget ctor and dctor functions Cezary Rojewski
2022-03-04 14:57 ` [PATCH v3 03/17] ASoC: Intel: Introduce AVS driver Cezary Rojewski
2022-03-04 15:51   ` Ranjani Sridharan
2022-03-04 16:43     ` Cezary Rojewski
2022-03-04 14:57 ` [PATCH v3 04/17] ASoC: Intel: avs: Inter process communication Cezary Rojewski
2022-03-04 16:09   ` Ranjani Sridharan
2022-03-04 17:11     ` Cezary Rojewski
2022-03-07 16:15       ` Ranjani Sridharan
2022-03-07 16:23         ` Cezary Rojewski
2022-03-04 14:57 ` [PATCH v3 05/17] ASoC: Intel: avs: Add code loading requests Cezary Rojewski
2022-03-04 14:57 ` [PATCH v3 06/17] ASoC: Intel: avs: Add pipeline management requests Cezary Rojewski
2022-03-04 16:13   ` Ranjani Sridharan
2022-03-04 17:15     ` Cezary Rojewski
2022-03-04 14:57 ` [PATCH v3 07/17] ASoC: Intel: avs: Add module " Cezary Rojewski
2022-03-04 16:21   ` Ranjani Sridharan [this message]
2022-03-04 17:21     ` Cezary Rojewski
2022-03-07 16:39       ` Ranjani Sridharan
2022-03-07 16:58         ` Cezary Rojewski
2022-03-07 17:05           ` Ranjani Sridharan
2022-03-07 17:27             ` Cezary Rojewski
2022-03-07 17:47               ` Pierre-Louis Bossart
2022-03-04 14:57 ` [PATCH v3 08/17] ASoC: Intel: avs: Add power " Cezary Rojewski
2022-03-04 16:24   ` Ranjani Sridharan
2022-03-04 17:30     ` Cezary Rojewski
2022-03-04 14:57 ` [PATCH v3 09/17] ASoC: Intel: avs: Add ROM requests Cezary Rojewski
2022-03-04 16:26   ` Ranjani Sridharan
2022-03-04 17:33     ` Cezary Rojewski
2022-03-04 14:57 ` [PATCH v3 10/17] ASoC: Intel: avs: Add basefw runtime-parameter requests Cezary Rojewski
2022-03-04 16:31   ` Ranjani Sridharan
2022-03-04 17:37     ` Cezary Rojewski
2022-03-07 16:41       ` Ranjani Sridharan
2022-03-07 17:02         ` Cezary Rojewski
2022-03-07 17:06           ` Ranjani Sridharan
2022-03-07 17:28             ` Cezary Rojewski
2022-03-04 14:57 ` [PATCH v3 11/17] ASoC: Intel: avs: Firmware resources management utilities Cezary Rojewski
2022-03-04 16:41   ` Ranjani Sridharan
2022-03-04 18:02     ` Cezary Rojewski
2022-03-07 16:46       ` Ranjani Sridharan
2022-03-07 17:13         ` Cezary Rojewski
2022-03-07 17:30           ` Ranjani Sridharan
2022-03-08 16:57             ` Cezary Rojewski
2022-03-08 17:22               ` Ranjani Sridharan
2022-03-08 18:07                 ` Cezary Rojewski
2022-03-08 18:26                   ` Ranjani Sridharan
2022-03-08 18:31                     ` Cezary Rojewski
2022-03-08 19:42                       ` Pierre-Louis Bossart
2022-03-09 17:23                         ` Cezary Rojewski
2022-03-04 14:57 ` [PATCH v3 12/17] ASoC: Intel: avs: Declare module configuration types Cezary Rojewski
2022-03-04 16:43   ` Ranjani Sridharan
2022-03-04 18:10     ` Cezary Rojewski
2022-03-04 14:57 ` [PATCH v3 13/17] ASoC: Intel: avs: Dynamic firmware resources management Cezary Rojewski
2022-03-04 16:47   ` Ranjani Sridharan
2022-03-04 18:15     ` Cezary Rojewski
2022-03-04 14:57 ` [PATCH v3 14/17] ASoC: Intel: avs: General code loading flow Cezary Rojewski
2022-03-04 16:54   ` Ranjani Sridharan
2022-03-04 18:29     ` Cezary Rojewski
2022-03-04 14:57 ` [PATCH v3 15/17] ASoC: Intel: avs: Implement CLDMA transfer Cezary Rojewski
2022-03-04 14:57 ` [PATCH v3 16/17] ASoC: Intel: avs: Code loading over CLDMA Cezary Rojewski
2022-03-04 14:57 ` [PATCH v3 17/17] ASoC: Intel: avs: Code loading over HDA Cezary Rojewski
2022-03-04 16:59   ` Ranjani Sridharan
2022-03-04 18:44     ` Cezary Rojewski
2022-03-04 18:56       ` Pierre-Louis Bossart
2022-03-07 14:31         ` 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=0e7e51e94157c6ca43957b27a13fd4cf058bfc33.camel@linux.intel.com \
    --to=ranjani.sridharan@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=pierre-louis.bossart@linux.intel.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.