mailman.alsa-project.org
Sign In Sign Up
Manage this list Sign In Sign Up

Keyboard Shortcuts

Thread View

  • j: Next unread message
  • k: Previous unread message
  • j a: Jump to all threads
  • j l: Jump to MailingList overview

Sound-open-firmware

Thread Start a new thread
Download
Threads by month
  • ----- 2025 -----
  • May
  • April
  • March
  • February
  • January
  • ----- 2024 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2023 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2022 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2021 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2020 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2019 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2018 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2017 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2016 -----
  • December
  • November
  • October
sound-open-firmware@alsa-project.org

October 2024

  • 4 participants
  • 6 discussions
[PATCH AUTOSEL 6.11 09/32] ASoC: SOF: Intel: hda: Always clean up link DMA during stop
by Sasha Levin 28 Oct '24

28 Oct '24
From: Ranjani Sridharan <ranjani.sridharan(a)linux.intel.com> [ Upstream commit ab5593793e9088abcddce30ba8e376e31b7285fd ] This is required to reset the DMA read/write pointers when the stream is prepared and restarted after a call to snd_pcm_drain()/snd_pcm_drop(). Also, now that the stream is reset during stop, do not save LLP registers in the case of STOP/suspend to avoid erroneous delay reporting. Link: https://github.com/thesofproject/sof/issues/9502 Signed-off-by: Ranjani Sridharan <ranjani.sridharan(a)linux.intel.com> Reviewed-by: Péter Ujfalusi <peter.ujfalusi(a)linux.intel.com> Reviewed-by: Kai Vehmanen <kai.vehmanen(a)linux.intel.com> Signed-off-by: Bard Liao <yung-chuan.liao(a)linux.intel.com> All: stable(a)vger.kernel.org # 6.10.x 6.11.x Link: https://patch.msgid.link/20241016032910.14601-5-yung-chuan.liao@linux.intel… Signed-off-by: Mark Brown <broonie(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- sound/soc/sof/intel/hda-dai-ops.c | 23 ++++++++++------------- sound/soc/sof/intel/hda-dai.c | 1 + 2 files changed, 11 insertions(+), 13 deletions(-) diff --git a/sound/soc/sof/intel/hda-dai-ops.c b/sound/soc/sof/intel/hda-dai-ops.c index 484c761478853..92681ca7f24de 100644 --- a/sound/soc/sof/intel/hda-dai-ops.c +++ b/sound/soc/sof/intel/hda-dai-ops.c @@ -346,20 +346,21 @@ static int hda_trigger(struct snd_sof_dev *sdev, struct snd_soc_dai *cpu_dai, case SNDRV_PCM_TRIGGER_PAUSE_RELEASE: snd_hdac_ext_stream_start(hext_stream); break; - case SNDRV_PCM_TRIGGER_SUSPEND: - case SNDRV_PCM_TRIGGER_STOP: case SNDRV_PCM_TRIGGER_PAUSE_PUSH: - snd_hdac_ext_stream_clear(hext_stream); - /* - * Save the LLP registers in case the stream is - * restarting due PAUSE_RELEASE, or START without a pcm - * close/open since in this case the LLP register is not reset - * to 0 and the delay calculation will return with invalid - * results. + * Save the LLP registers since in case of PAUSE the LLP + * register are not reset to 0, the delay calculation will use + * the saved offsets for compensating the delay calculation. */ hext_stream->pplcllpl = readl(hext_stream->pplc_addr + AZX_REG_PPLCLLPL); hext_stream->pplcllpu = readl(hext_stream->pplc_addr + AZX_REG_PPLCLLPU); + snd_hdac_ext_stream_clear(hext_stream); + break; + case SNDRV_PCM_TRIGGER_SUSPEND: + case SNDRV_PCM_TRIGGER_STOP: + hext_stream->pplcllpl = 0; + hext_stream->pplcllpu = 0; + snd_hdac_ext_stream_clear(hext_stream); break; default: dev_err(sdev->dev, "unknown trigger command %d\n", cmd); @@ -512,7 +513,6 @@ static const struct hda_dai_widget_dma_ops sdw_ipc4_chain_dma_ops = { static int hda_ipc3_post_trigger(struct snd_sof_dev *sdev, struct snd_soc_dai *cpu_dai, struct snd_pcm_substream *substream, int cmd) { - struct hdac_ext_stream *hext_stream = hda_get_hext_stream(sdev, cpu_dai, substream); struct snd_soc_dapm_widget *w = snd_soc_dai_get_widget(cpu_dai, substream->stream); switch (cmd) { @@ -527,9 +527,6 @@ static int hda_ipc3_post_trigger(struct snd_sof_dev *sdev, struct snd_soc_dai *c if (ret < 0) return ret; - if (cmd == SNDRV_PCM_TRIGGER_STOP) - return hda_link_dma_cleanup(substream, hext_stream, cpu_dai); - break; } case SNDRV_PCM_TRIGGER_PAUSE_PUSH: diff --git a/sound/soc/sof/intel/hda-dai.c b/sound/soc/sof/intel/hda-dai.c index 8cccf38967e72..ac505c7ad3429 100644 --- a/sound/soc/sof/intel/hda-dai.c +++ b/sound/soc/sof/intel/hda-dai.c @@ -302,6 +302,7 @@ static int __maybe_unused hda_dai_trigger(struct snd_pcm_substream *substream, i } switch (cmd) { + case SNDRV_PCM_TRIGGER_STOP: case SNDRV_PCM_TRIGGER_SUSPEND: ret = hda_link_dma_cleanup(substream, hext_stream, dai); if (ret < 0) { -- 2.43.0
1 0
0 0
[PATCH AUTOSEL 6.11 07/32] ASoC: SOF: Intel: hda: Handle prepare without close for non-HDA DAI's
by Sasha Levin 28 Oct '24

28 Oct '24
From: Ranjani Sridharan <ranjani.sridharan(a)linux.intel.com> [ Upstream commit 6e38a7e098d32d128b00b42a536151de9ea1340b ] When a PCM is restarted after a snd_pcm_drain/snd_pcm_drop(), the prepare callback will be invoked and the hw_params will be set again. For the HDA DAI's, the hw_params function handles this case already but not for the non-HDA DAI's. So, add the check for link_prepared to verify if the hw_params should be done again or not. Additionally, for SDW DAI's reset the PCMSyCM registers as would be done in the case of a start after a hw_free. Signed-off-by: Ranjani Sridharan <ranjani.sridharan(a)linux.intel.com> Reviewed-by: Péter Ujfalusi <peter.ujfalusi(a)linux.intel.com> Reviewed-by: Kai Vehmanen <kai.vehmanen(a)linux.intel.com> Signed-off-by: Bard Liao <yung-chuan.liao(a)linux.intel.com> All: stable(a)vger.kernel.org # 6.10.x 6.11.x Link: https://patch.msgid.link/20241016032910.14601-3-yung-chuan.liao@linux.intel… Signed-off-by: Mark Brown <broonie(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- sound/soc/sof/intel/hda-dai.c | 36 +++++++++++++++++++++++++++++++---- 1 file changed, 32 insertions(+), 4 deletions(-) diff --git a/sound/soc/sof/intel/hda-dai.c b/sound/soc/sof/intel/hda-dai.c index 1c823f9eea570..8cccf38967e72 100644 --- a/sound/soc/sof/intel/hda-dai.c +++ b/sound/soc/sof/intel/hda-dai.c @@ -370,6 +370,13 @@ static int non_hda_dai_hw_params_data(struct snd_pcm_substream *substream, return -EINVAL; } + sdev = widget_to_sdev(w); + hext_stream = ops->get_hext_stream(sdev, cpu_dai, substream); + + /* nothing more to do if the link is already prepared */ + if (hext_stream && hext_stream->link_prepared) + return 0; + /* use HDaudio stream handling */ ret = hda_dai_hw_params_data(substream, params, cpu_dai, data, flags); if (ret < 0) { @@ -377,7 +384,6 @@ static int non_hda_dai_hw_params_data(struct snd_pcm_substream *substream, return ret; } - sdev = widget_to_sdev(w); if (sdev->dspless_mode_selected) return 0; @@ -482,6 +488,31 @@ int sdw_hda_dai_hw_params(struct snd_pcm_substream *substream, int ret; int i; + ops = hda_dai_get_ops(substream, cpu_dai); + if (!ops) { + dev_err(cpu_dai->dev, "DAI widget ops not set\n"); + return -EINVAL; + } + + sdev = widget_to_sdev(w); + hext_stream = ops->get_hext_stream(sdev, cpu_dai, substream); + + /* nothing more to do if the link is already prepared */ + if (hext_stream && hext_stream->link_prepared) + return 0; + + /* + * reset the PCMSyCM registers to handle a prepare callback when the PCM is restarted + * due to xruns or after a call to snd_pcm_drain/drop() + */ + ret = hdac_bus_eml_sdw_map_stream_ch(sof_to_bus(sdev), link_id, cpu_dai->id, + 0, 0, substream->stream); + if (ret < 0) { + dev_err(cpu_dai->dev, "%s: hdac_bus_eml_sdw_map_stream_ch failed %d\n", + __func__, ret); + return ret; + } + data.dai_index = (link_id << 8) | cpu_dai->id; data.dai_node_id = intel_alh_id; ret = non_hda_dai_hw_params_data(substream, params, cpu_dai, &data, flags); @@ -490,10 +521,7 @@ int sdw_hda_dai_hw_params(struct snd_pcm_substream *substream, return ret; } - ops = hda_dai_get_ops(substream, cpu_dai); - sdev = widget_to_sdev(w); hext_stream = ops->get_hext_stream(sdev, cpu_dai, substream); - if (!hext_stream) return -ENODEV; -- 2.43.0
1 0
0 0
[PATCH AUTOSEL 6.11 06/32] ASoC: SOF: ipc4-topology: Do not set ALH node_id for aggregated DAIs
by Sasha Levin 28 Oct '24

28 Oct '24
From: Ranjani Sridharan <ranjani.sridharan(a)linux.intel.com> [ Upstream commit 9822b4c90d77e3c6555fb21c459c4a61c6a8619f ] For aggregated DAIs, the node ID is set to the group_id during the DAI widget's ipc_prepare op. With the current logic, setting the dai_index for node_id in the dai_config is redundant as it will be overwritten with the group_id anyway. Removing it will also prevent any accidental clearing/resetting of the group_id for aggregated DAIs due to the dai_config calls could that happen before the allocated group_id is freed. Signed-off-by: Ranjani Sridharan <ranjani.sridharan(a)linux.intel.com> Reviewed-by: Péter Ujfalusi <peter.ujfalusi(a)linux.intel.com> Reviewed-by: Kai Vehmanen <kai.vehmanen(a)linux.intel.com> Signed-off-by: Bard Liao <yung-chuan.liao(a)linux.intel.com> All: stable(a)vger.kernel.org # 6.10.x 6.11.x Link: https://patch.msgid.link/20241016032910.14601-2-yung-chuan.liao@linux.intel… Signed-off-by: Mark Brown <broonie(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- sound/soc/sof/ipc4-topology.c | 15 +++++++++++++-- 1 file changed, 13 insertions(+), 2 deletions(-) diff --git a/sound/soc/sof/ipc4-topology.c b/sound/soc/sof/ipc4-topology.c index 87be7f16e8c2b..240fee2166d12 100644 --- a/sound/soc/sof/ipc4-topology.c +++ b/sound/soc/sof/ipc4-topology.c @@ -3129,9 +3129,20 @@ static int sof_ipc4_dai_config(struct snd_sof_dev *sdev, struct snd_sof_widget * * group_id during copier's ipc_prepare op. */ if (flags & SOF_DAI_CONFIG_FLAGS_HW_PARAMS) { + struct sof_ipc4_alh_configuration_blob *blob; + + blob = (struct sof_ipc4_alh_configuration_blob *)ipc4_copier->copier_config; ipc4_copier->dai_index = data->dai_node_id; - copier_data->gtw_cfg.node_id &= ~SOF_IPC4_NODE_INDEX_MASK; - copier_data->gtw_cfg.node_id |= SOF_IPC4_NODE_INDEX(data->dai_node_id); + + /* + * no need to set the node_id for aggregated DAI's. These will be assigned + * a group_id during widget ipc_prepare + */ + if (blob->alh_cfg.device_count == 1) { + copier_data->gtw_cfg.node_id &= ~SOF_IPC4_NODE_INDEX_MASK; + copier_data->gtw_cfg.node_id |= + SOF_IPC4_NODE_INDEX(data->dai_node_id); + } } break; -- 2.43.0
1 0
0 0
Re: [PATCH 1/4] dt-bindings: remoteproc: fsl,imx-rproc: add new compatible
by Rob Herring 24 Oct '24

24 Oct '24
On Thu, Oct 24, 2024 at 01:47:53PM +0300, Laurentiu Mihalcea wrote: > > > On 10/24/2024 10:45 AM, Krzysztof Kozlowski wrote: > > On Wed, Oct 23, 2024 at 12:21:11PM -0400, Laurentiu Mihalcea wrote: > >> From: Laurentiu Mihalcea <laurentiu.mihalcea(a)nxp.com> > >> > >> Add new compatible for imx95's CM7 with SOF. > >> > >> Signed-off-by: Laurentiu Mihalcea <laurentiu.mihalcea(a)nxp.com> > >> --- > >> .../bindings/remoteproc/fsl,imx-rproc.yaml | 58 +++++++++++++++++-- > >> 1 file changed, 53 insertions(+), 5 deletions(-) > >> > >> diff --git a/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml b/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml > >> index 57d75acb0b5e..ab0d8e017965 100644 > >> --- a/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml > >> +++ b/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml > >> @@ -28,6 +28,15 @@ properties: > >> - fsl,imx8qxp-cm4 > >> - fsl,imx8ulp-cm33 > >> - fsl,imx93-cm33 > >> + - fsl,imx95-cm7-sof > >> + > >> + reg: > >> + maxItems: 2 > >> + > >> + reg-names: > >> + items: > >> + - const: dram > >> + - const: mailbox > > That's quite different programming model. Are you sure these are devices > > from similar class/type? > Yep, these are all Cortex-M cores. It's just that their usage differs quite a lot. > > > > Your big if:then: block suggests this could be separate binding. > Ideally I would have wanted to place the compatible inside dsp/fsl,dsp.yaml as the > programming model would have been more similar. > > Unfortunately, these are different physical devices (HiFi DSP core vs CM core) even > though they're all used for DSP purposes so I'm not sure this is entirely appropriate. That doesn't matter too much. trivial-devices.yaml is a bunch of completely unrelated devices which happen to have the same binding. We could probably take that farther with things like trivial clock providers for example. Having 'reg' vs not is pretty clearly something that should be different binding. > > Alternatively, if you think grouping these devices (i.e: those represented by the -dsp compatibles > from fsl,dsp and the one represented by the compatible introduced here) under the same binding > is alright we can just branch off from fsl,dsp and fsl,imx-rproc and create a new binding for > these devices. I'm expecting this to be relatively clean as they have the same programming > model. If it's just add a compatible and nothing else somewhere, I'd do that. If it's more than that, then I'd make a new binding doc. Rob
1 0
0 0
Re: [PATCH 1/4] dt-bindings: remoteproc: fsl,imx-rproc: add new compatible
by Mathieu Poirier 24 Oct '24

24 Oct '24
Good day, On Wed, Oct 23, 2024 at 12:21:11PM -0400, Laurentiu Mihalcea wrote: > From: Laurentiu Mihalcea <laurentiu.mihalcea(a)nxp.com> > > Add new compatible for imx95's CM7 with SOF. > > Signed-off-by: Laurentiu Mihalcea <laurentiu.mihalcea(a)nxp.com> > --- > .../bindings/remoteproc/fsl,imx-rproc.yaml | 58 +++++++++++++++++-- > 1 file changed, 53 insertions(+), 5 deletions(-) > > diff --git a/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml b/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml > index 57d75acb0b5e..ab0d8e017965 100644 > --- a/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml > +++ b/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml > @@ -28,6 +28,15 @@ properties: > - fsl,imx8qxp-cm4 > - fsl,imx8ulp-cm33 > - fsl,imx93-cm33 > + - fsl,imx95-cm7-sof Why is this added in the remoteproc bindings when the driver is sound/soc/sof/imx/imx95.c? > + > + reg: > + maxItems: 2 > + > + reg-names: > + items: > + - const: dram > + - const: mailbox > > clocks: > maxItems: 1 > @@ -38,10 +47,8 @@ properties: > Phandle to syscon block which provide access to System Reset Controller > > mbox-names: > - items: > - - const: tx > - - const: rx > - - const: rxdb > + minItems: 1 > + maxItems: 4 > > mboxes: > description: > @@ -49,7 +56,7 @@ properties: > List of <&phandle type channel> - 1 channel for TX, 1 channel for RX, 1 channel for RXDB. > (see mailbox/fsl,mu.yaml) > minItems: 1 > - maxItems: 3 > + maxItems: 4 > > memory-region: > description: > @@ -84,6 +91,10 @@ properties: > This property is to specify the resource id of the remote processor in SoC > which supports SCFW > > + port: > + $ref: /schemas/sound/audio-graph-port.yaml# > + unevaluatedProperties: false > + > required: > - compatible > > @@ -114,6 +125,43 @@ allOf: > properties: > power-domains: false > > + - if: > + properties: > + compatible: > + contains: > + const: fsl,imx95-cm7-sof > + then: > + properties: > + mboxes: > + minItems: 4 > + mbox-names: > + items: > + - const: txdb0 > + - const: txdb1 > + - const: rxdb0 > + - const: rxdb1 > + memory-region: > + maxItems: 1 > + required: > + - reg > + - reg-names > + - mboxes > + - mbox-names > + - memory-region > + - port > + else: > + properties: > + reg: false > + reg-names: false > + mboxes: > + maxItems: 3 > + mbox-names: > + items: > + - const: tx > + - const: rx > + - const: rxdb > + port: false > + > additionalProperties: false > > examples: > -- > 2.34.1 >
1 0
0 0
Re: [PATCH 1/2] ASoC: SOF: amd: Add error log for DSP firmware validation failure
by Mark Brown 08 Oct '24

08 Oct '24
On Tue, 08 Oct 2024 14:43:44 +0530, Venkata Prasad Potturu wrote: > Add dev_err to print ACP_SHA_DSP_FW_QUALIFIER and ACP_SHA_PSP_ACK > register values for PSP firmware validation failure case. > > Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next Thanks! [1/2] ASoC: SOF: amd: Add error log for DSP firmware validation failure commit: 0a5c40393b123f3f08e428143985ab0c5ddb4d28 [2/2] ASoC: SOF: amd: Fix for ACP SRAM addr for acp7.0 platform commit: 494ddacd4a2ae5fd1c46ea49364eaab4fc1e5461 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
0 0

HyperKitty Powered by HyperKitty version 1.3.8.