June 2023 - Sound-open-firmware - mailman.alsa-project.org

Re: (subset) [PATCH 1/2] ASoC: SOF: amd: add revision check for sending sha dma completion command
by Mark Brown 30 Jun '23

30 Jun '23

On Fri, 30 Jun 2023 12:35:42 +0530, Mastan Katragadda wrote: > ACP driver should send SHA DMA completion command to PSP module for RN > platform only. > Add a revision check for RN platform. > > Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next Thanks! [1/2] ASoC: SOF: amd: add revision check for sending sha dma completion command commit: b1db244c716fe300e36428aeb0874913d2e0a91d All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark

1 0

Re: [PATCH] ASoC: SOF: amd: Add support for IPC with a reply_size set to zero
by Mark Brown 14 Jun '23

14 Jun '23

On Wed, 14 Jun 2023 16:07:05 +0530, Venkata Prasad Potturu wrote: > Add support for IPC tx_message with a reply_size set to zero, > return zero when message reply_size is zero at acp_dsp_ipc_get_reply(). > > Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next Thanks! [1/1] ASoC: SOF: amd: Add support for IPC with a reply_size set to zero commit: fd01a15164a15328fd96f9ce820f0fc9f700f00b All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark

1 0

Re: [PATCH] ASoC: SOF: ipc4-topology: Improve unlocking of a mutex in sof_ipc4_widget_free()
by Pierre-Louis Bossart 12 Jun '23

12 Jun '23

On 6/10/23 06:36, Markus Elfring wrote: > From: Markus Elfring <elfring(a)users.sourceforge.net> > Date: Sat, 10 Jun 2023 12:40:09 +0200 > > Add a jump target so that a call of the function “mutex_unlock” > is stored only once in this function implementation. > > Signed-off-by: Markus Elfring <elfring(a)users.sourceforge.net> > --- > sound/soc/sof/ipc4-topology.c | 5 ++--- > 1 file changed, 2 insertions(+), 3 deletions(-) > > diff --git a/sound/soc/sof/ipc4-topology.c b/sound/soc/sof/ipc4-topology.c > index a4e1a70b607d..f0fd1dfa384e 100644 > --- a/sound/soc/sof/ipc4-topology.c > +++ b/sound/soc/sof/ipc4-topology.c > @@ -2300,8 +2300,7 @@ static int sof_ipc4_widget_free(struct snd_sof_dev *sdev, struct snd_sof_widget > if (pipeline->use_chain_dma) { > dev_warn(sdev->dev, "use_chain_dma set for scheduler %s", > swidget->widget->name); > - mutex_unlock(&ipc4_data->pipeline_state_mutex); > - return 0; > + goto unlock; > } > > header = SOF_IPC4_GLB_PIPE_INSTANCE_ID(swidget->instance_id); > @@ -2326,7 +2325,7 @@ static int sof_ipc4_widget_free(struct snd_sof_dev *sdev, struct snd_sof_widget > if (!pipeline->use_chain_dma) > ida_free(&fw_module->m_ida, swidget->instance_id); > } > - > +unlock: > mutex_unlock(&ipc4_data->pipeline_state_mutex); > > return ret; The change looks good but I am wondering if we need to print a dev_warn log which is already done on the sof_ipc4_widget_setup() path. This seems redundant. Ranjani, can we simplify?

1 0

[PATCH] ASoC: SOF: ipc4-topology: Use size_t for variable passed to kzalloc()
by Christophe JAILLET 02 Jun '23

02 Jun '23

struct_size() checks for overflow, but assigning its result to just a u32 may still overflow after a successful check. Use a size_t instead in order to be cleaner. Signed-off-by: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr> --- Based on analysis from Dan Carpenter on another patch (see [1]). [1]: https://lore.kernel.org/all/00e84595-e2c9-48ea-8737-18da34eaafbf@kili.mount… --- sound/soc/sof/ipc4-topology.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/soc/sof/ipc4-topology.c b/sound/soc/sof/ipc4-topology.c index db64e0cb8663..50faa4c88b97 100644 --- a/sound/soc/sof/ipc4-topology.c +++ b/sound/soc/sof/ipc4-topology.c @@ -881,7 +881,7 @@ static int sof_ipc4_widget_setup_comp_process(struct snd_sof_widget *swidget) /* allocate memory for base config extension if needed */ if (process->init_config == SOF_IPC4_MODULE_INIT_CONFIG_TYPE_BASE_CFG_WITH_EXT) { struct sof_ipc4_base_module_cfg_ext *base_cfg_ext; - u32 ext_size = struct_size(base_cfg_ext, pin_formats, + size_t ext_size = struct_size(base_cfg_ext, pin_formats, swidget->num_input_pins + swidget->num_output_pins); base_cfg_ext = kzalloc(ext_size, GFP_KERNEL); -- 2.34.1

3 3

[PATCH v3 0/1] ASoC: SOF: add mt8188 audio support
by Trevor Wu 01 Jun '23

01 Jun '23

This series adds mt8188 audio support and dbg_dump callback for mt8186 and mt8188. Changes since v2: - resend the correct patch for adsp debug dump Changes since v1: - fix typo - adopt reviewer's suggestion Trevor Wu (1): ASoC: SOF: mediatek: add adsp debug dump sound/soc/sof/mediatek/mt8186/mt8186.c | 22 ++++++++++++++++++++++ sound/soc/sof/mediatek/mt8186/mt8186.h | 5 +++++ 2 files changed, 27 insertions(+) -- 2.18.0

2 2

Re: [PATCH v2 2/2] ASoC: SOF: mediatek: add adsp debug dump
by Trevor Wu (吳文良) 01 Jun '23

01 Jun '23

On Tue, 2023-05-30 at 15:12 +0100, Mark Brown wrote: > On Tue, May 23, 2023 at 10:59:33AM +0800, Trevor Wu wrote: > > Add mt8188 and mt8186 .dbg_dump callback to print some information > > when > > DSP panic occurs. > > This breaks an x86_64 allmodconfig build: > > /build/stage/linux/sound/soc/sof/mediatek/mt8186/mt8186.c: In > function ‘mt8186_adsp_dump’: > /build/stage/linux/sound/soc/sof/mediatek/mt8186/mt8186.c:483:56: > error: ‘DSP_PDEBUGDATA’ undeclared (first use in this function); did > you mean ‘DSP_PDEBUGPC’? > 483 | dbg_data = snd_sof_dsp_read(sdev, DSP_REG_BAR, > DSP_PDEBUGDATA); > | ^~~~~~ > ~~~~~~~~ > | DSP_PD > EBUGPC > /build/stage/linux/sound/soc/sof/mediatek/mt8186/mt8186.c:483:56: > note: each undeclared identifier is reported only once for each > function it appears in > /build/stage/linux/sound/soc/sof/mediatek/mt8186/mt8186.c:484:56: > error: ‘DSP_PDEBUGINST’ undeclared (first use in this function); did > you mean ‘DSP_PDEBUGPC’? > 484 | dbg_inst = snd_sof_dsp_read(sdev, DSP_REG_BAR, > DSP_PDEBUGINST); > | ^~~~~~ > ~~~~~~~~ > | DSP_PD > EBUGPC > /build/stage/linux/sound/soc/sof/mediatek/mt8186/mt8186.c:485:59: > error: ‘DSP_PDEBUGLS0STAT’ undeclared (first use in this function) > 485 | dbg_ls0stat = snd_sof_dsp_read(sdev, DSP_REG_BAR, > DSP_PDEBUGLS0STAT); > | ^~~ > ~~~~~~~~~~~~~~ > /build/stage/linux/sound/soc/sof/mediatek/mt8186/mt8186.c:486:58: > error: ‘DSP_PDEBUGSTATUS’ undeclared (first use in this function); > did you mean ‘DSP_PDEBUGPC’? > 486 | dbg_status = snd_sof_dsp_read(sdev, DSP_REG_BAR, > DSP_PDEBUGSTATUS); > | ^~~~ > ~~~~~~~~~~~~ > | DSP_ > PDEBUGPC > /build/stage/linux/sound/soc/sof/mediatek/mt8186/mt8186.c:487:57: > error: ‘DSP_PFAULTINFO’ undeclared (first use in this function) > 487 | faultinfo = snd_sof_dsp_read(sdev, DSP_REG_BAR, > DSP_PFAULTINFO); > | ^~~~~ > ~~~~~~~~~ Sorry, I didn't notice that I missed the header which possibly caused by the wrong format-patch command. I checked the same patch in v1, and the header was included in the series. I will send v3 to resolve the problem. Thanks, Trevor

1 0

Re: [PATCH 1/2] ASoC: SOF: mediatek: add mt8188 audio support
by Pierre-Louis Bossart 01 Jun '23

01 Jun '23

On 5/15/23 10:05, Mark Brown wrote: > On Mon, May 15, 2023 at 01:25:44PM +0200, AngeloGioacchino Del Regno wrote: >> Il 15/05/23 07:25, Trevor Wu ha scritto: > >>> +{ >>> + /* common defaults */ >>> + memcpy(&sof_mt8188_ops, &sof_mt8186_ops, sizeof(struct snd_sof_dsp_ops)); > >> Never use sizeof(type), always use destination var size! Anyway, there's more. >> >> I don't think we need to perform this memcpy: we'll never see an instance of >> both mt8186 and mt8188 drivers on the same machine, so you can safely just use >> sof_mt8186_ops for mt8188... > >>> + sof_mt8188_ops.drv = mt8188_dai; > >> ...which obviously means that this becomes > >> sof_mt8186_ops.drv = mt8188_dai; > > This does have the issue that it then means the ops struct isn't const > which isn't ideal. It's also not the end of the world though so I don't > have super strong feelings. We do the same for Intel devices, we have a common structure which is copied and only the members that differ in specific SOCs are updated. You're right that it's not constant, but it avoids copy-paste of a rather large structure just to change a couple of lines.

2 2