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

Re: [PATCH][next] ASoC: SOF: ipc4-topology: remove redundant assignment to variable ret
by Mark Brown 14 Nov '24

14 Nov '24

On Wed, 13 Nov 2024 13:08:07 +0000, Colin Ian King wrote: > The variable ret is being assigned a zero value however the value is > never read because ret is being re-assigned later after the end of > the switch statement. The assignment is redundant and can be removed. > > Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next Thanks! [1/1] ASoC: SOF: ipc4-topology: remove redundant assignment to variable ret commit: fb5e67c9d03b4a65fd43acc18cbafffff15bd8f9 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 v3] ASoc: SOF: ipc4-pcm: fix uninit-value in sof_ipc4_pcm_dai_link_fixup_rate
by Mark Brown 11 Nov '24

11 Nov '24

On Thu, 07 Nov 2024 12:06:09 +0530, Suraj Sonawane wrote: > Fix an issue detected by the Smatch tool: > > sound/soc/sof/ipc4-pcm.c: sof_ipc4_pcm_dai_link_fixup_rate() > error: uninitialized symbol 'be_rate'. > > The warning highlights a case where `be_rate` could remain uninitialized > if `num_input_formats` is zero, which would cause undefined behavior > when setting `rate->min` and `rate->max` based on `be_rate`. > > [...] Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next Thanks! [1/1] ASoc: SOF: ipc4-pcm: fix uninit-value in sof_ipc4_pcm_dai_link_fixup_rate commit: 9a59718a5340aa0240a442115eb499de2ed18ee4 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 v2] ASoC: SOF: amd: Fix for incorrect DMA ch status register offset
by Mark Brown 07 Nov '24

07 Nov '24

On Wed, 06 Nov 2024 19:56:57 +0530, Venkata Prasad Potturu wrote: > DMA ch status register offset change in acp7.0 platform > > Incorrect DMA channel status register offset check lead to > firmware boot failure. > > [ 14.432497] snd_sof_amd_acp70 0000:c4:00.5: ------------[ DSP dump start ]------------ > [ 14.432533] snd_sof_amd_acp70 0000:c4:00.5: Firmware boot failure due to timeout > [ 14.432549] snd_sof_amd_acp70 0000:c4:00.5: fw_state: SOF_FW_BOOT_IN_PROGRESS (3) > [ 14.432610] snd_sof_amd_acp70 0000:c4:00.5: invalid header size 0x71c41000. FW oops is bogus > [ 14.432626] snd_sof_amd_acp70 0000:c4:00.5: unexpected fault 0x71c40000 trace 0x71c40000 > [ 14.432642] snd_sof_amd_acp70 0000:c4:00.5: ------------[ DSP dump end ]------------ > [ 14.432657] snd_sof_amd_acp70 0000:c4:00.5: error: failed to boot DSP firmware -5 > [ 14.432672] snd_sof_amd_acp70 0000:c4:00.5: fw_state change: 3 -> 4 > [ 14.433260] dmic-codec dmic-codec: ASoC: Unregistered DAI 'dmic-hifi' > [ 14.433319] snd_sof_amd_acp70 0000:c4:00.5: fw_state change: 4 -> 0 > [ 14.433358] snd_sof_amd_acp70 0000:c4:00.5: error: sof_probe_work failed err: -5 > > [...] Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next Thanks! [1/1] ASoC: SOF: amd: Fix for incorrect DMA ch status register offset commit: 94debe5eaa0adaa24a6de4a8e5f138be7381eb9e 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: Fix for incorrect DMA ch status register offset
by Mark Brown 07 Nov '24

07 Nov '24

On Wed, 06 Nov 2024 15:44:53 +0530, Venkata Prasad Potturu wrote: > DMA ch status register offset change in acp7.0 platform > > Incorrect DMA channel status register offset check lead to > firmware boot failure. > > [ 14.432497] snd_sof_amd_acp70 0000:c4:00.5: ------------[ DSP dump start ]------------ > [ 14.432533] snd_sof_amd_acp70 0000:c4:00.5: Firmware boot failure due to timeout > [ 14.432549] snd_sof_amd_acp70 0000:c4:00.5: fw_state: SOF_FW_BOOT_IN_PROGRESS (3) > [ 14.432610] snd_sof_amd_acp70 0000:c4:00.5: invalid header size 0x71c41000. FW oops is bogus > [ 14.432626] snd_sof_amd_acp70 0000:c4:00.5: unexpected fault 0x71c40000 trace 0x71c40000 > [ 14.432642] snd_sof_amd_acp70 0000:c4:00.5: ------------[ DSP dump end ]------------ > [ 14.432657] snd_sof_amd_acp70 0000:c4:00.5: error: failed to boot DSP firmware -5 > [ 14.432672] snd_sof_amd_acp70 0000:c4:00.5: fw_state change: 3 -> 4 > [ 14.433260] dmic-codec dmic-codec: ASoC: Unregistered DAI 'dmic-hifi' > [ 14.433319] snd_sof_amd_acp70 0000:c4:00.5: fw_state change: 4 -> 0 > [ 14.433358] snd_sof_amd_acp70 0000:c4:00.5: error: sof_probe_work failed err: -5 > > [...] Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next Thanks! [1/1] ASoC: SOF: amd: Fix for incorrect DMA ch status register offset commit: 94debe5eaa0adaa24a6de4a8e5f138be7381eb9e 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 v2] sound: fix uninit-value in sof_ipc4_pcm_dai_link_fixup_rate
by Péter Ujfalusi 04 Nov '24

04 Nov '24

On 03/11/2024 13:37, Suraj Sonawane wrote: > Fix an issue detected by the Smatch tool: > > sound/soc/sof/ipc4-pcm.c: sof_ipc4_pcm_dai_link_fixup_rate() > error: uninitialized symbol 'be_rate'. > > This issue occurred because the variable 'be_rate' could remain > uninitialized if num_input_formats is zero. In such cases, the > loop that assigns a value to 'be_rate' would not execute, > potentially leading to undefined behavior when rate->min and > rate->max are set with an uninitialized 'be_rate'. > > To resolve this, an additional check for num_input_formats > 0 > was added before setting rate->min and rate->max with 'be_rate'. > This ensures that 'be_rate' is assigned only when there are valid > input formats, preventing any use of uninitialized data. > > This solution maintains defined behavior for rate->min and rate->max, > ensuring they are only assigned when valid be_rate data is available. > > Signed-off-by: Suraj Sonawane <surajsonawane0215(a)gmail.com> > --- > V1: Initialize 'be_rate' to 0. > V2: Add conditional assignment based on num_input_formats to ensure > be_rate is used only when assigned. > > sound/soc/sof/ipc4-pcm.c | 7 +++++-- > 1 file changed, 5 insertions(+), 2 deletions(-) > > diff --git a/sound/soc/sof/ipc4-pcm.c b/sound/soc/sof/ipc4-pcm.c > index 4df2be3d3..d5d7ffc69 100644 > --- a/sound/soc/sof/ipc4-pcm.c > +++ b/sound/soc/sof/ipc4-pcm.c > @@ -633,8 +633,11 @@ static int sof_ipc4_pcm_dai_link_fixup_rate(struct snd_sof_dev *sdev, > return -EINVAL; > } > > - rate->min = be_rate; > - rate->max = rate->min; > + /* Set rate only if be_rate was assigned */ > + if (num_input_formats > 0) { By definition the copier must have at least one input and one output format, this check is going to be always true. > + rate->min = be_rate; > + rate->max = rate->min; > + } > } > > return 0; -- Péter

1 0

[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

[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

[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

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

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