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

Re: [PATCH v6 11/12] ASoC: SOF: Intel: Move binding to display driver outside of deferred probe
by Takashi Iwai 09 Oct '23

09 Oct '23

On Thu, 05 Oct 2023 13:26:18 +0200, Maarten Lankhorst wrote: > > > > On 2023-10-05 12:58, Péter Ujfalusi wrote: > > > > > > On 04/10/2023 19:59, Kai Vehmanen wrote: > >> Hi, > >> > >> I'm good with rest of the series, but one patch requires work. > >> > >> On Wed, 4 Oct 2023, Maarten Lankhorst wrote: > >> > >>> Now that we can use -EPROBE_DEFER, it's no longer required to spin off > >>> the snd_hdac_i915_init into a workqueue. > >>> > >>> Use the -EPROBE_DEFER mechanism instead, which must be returned in the > >>> probe function. > >>> > >>> The previously added probe_early can be used for this, > >>> and we also use the newly added remove_late for unbinding afterwards. > >> [...] > >>> --- a/sound/soc/sof/intel/hda-common-ops.c > >>> +++ b/sound/soc/sof/intel/hda-common-ops.c > >>> @@ -19,6 +19,7 @@ struct snd_sof_dsp_ops sof_hda_common_ops = { > >>> .probe_early = hda_dsp_probe_early, > >>> .probe = hda_dsp_probe, > >>> .remove = hda_dsp_remove, > >>> + .remove_late = hda_dsp_remove_late, > >>> /* Register IO uses direct mmio */ > >>> diff --git a/sound/soc/sof/intel/hda.c > >>> b/sound/soc/sof/intel/hda.c > >>> index 86a2571488bc..4eb7f04b8ae1 100644 > >>> --- a/sound/soc/sof/intel/hda.c > >>> +++ b/sound/soc/sof/intel/hda.c > >>> @@ -1160,6 +1160,7 @@ int hda_dsp_probe_early(struct snd_sof_dev *sdev) > >>> return -ENOMEM; > >>> sdev->pdata->hw_pdata = hdev; > >>> hdev->desc = chip; > >>> + ret = hda_init(sdev); > >>> err: > >>> return ret; > >> > >> I don't think this works. The hda_codec_i915_init() errors are ignored in > >> hda_init() so this never returns -EPROBE_DEFER. > >> > >> So something like this is needed on top (tested quickly on one SOF > >> machine and this blocks SOF load until i915 or xe driver is loaded): > >> > >> --cut-- > >> diff --git a/sound/soc/sof/intel/hda.c b/sound/soc/sof/intel/hda.c > >> index 9025bfaf6a7e..8b17c82dcc89 100644 > >> --- a/sound/soc/sof/intel/hda.c > >> +++ b/sound/soc/sof/intel/hda.c > >> @@ -863,13 +863,20 @@ static int hda_init(struct snd_sof_dev *sdev) > >> /* init i915 and HDMI codecs */ > >> ret = hda_codec_i915_init(sdev); > >> if (ret < 0) > >> - dev_warn(sdev->dev, "init of i915 and HDMI codec > >> failed\n"); > >> + dev_warn(sdev->dev, "init of i915 and HDMI codec failed > >> (%d)\n", ret); > > > > we should not print anything or maximum dev_dbg in case of EPROBE_DEFER. > There's dev_err_probe, which is dev_err on error, or sets the reason > for deferred probe to the arguments if the error is -EPROBE_DEFER. I expect you'll respin v7 for addressing this? I'd love to merge the series for 6.7, and the time ticks... thanks, Takashi

1 0

Re: [PATCH v6 11/12] ASoC: SOF: Intel: Move binding to display driver outside of deferred probe
by Kai Vehmanen 05 Oct '23

05 Oct '23

Hi, I'm good with rest of the series, but one patch requires work. On Wed, 4 Oct 2023, Maarten Lankhorst wrote: > Now that we can use -EPROBE_DEFER, it's no longer required to spin off > the snd_hdac_i915_init into a workqueue. > > Use the -EPROBE_DEFER mechanism instead, which must be returned in the > probe function. > > The previously added probe_early can be used for this, > and we also use the newly added remove_late for unbinding afterwards. [...] > --- a/sound/soc/sof/intel/hda-common-ops.c > +++ b/sound/soc/sof/intel/hda-common-ops.c > @@ -19,6 +19,7 @@ struct snd_sof_dsp_ops sof_hda_common_ops = { > .probe_early = hda_dsp_probe_early, > .probe = hda_dsp_probe, > .remove = hda_dsp_remove, > + .remove_late = hda_dsp_remove_late, > > /* Register IO uses direct mmio */ > > diff --git a/sound/soc/sof/intel/hda.c b/sound/soc/sof/intel/hda.c > index 86a2571488bc..4eb7f04b8ae1 100644 > --- a/sound/soc/sof/intel/hda.c > +++ b/sound/soc/sof/intel/hda.c > @@ -1160,6 +1160,7 @@ int hda_dsp_probe_early(struct snd_sof_dev *sdev) > return -ENOMEM; > sdev->pdata->hw_pdata = hdev; > hdev->desc = chip; > + ret = hda_init(sdev); > > err: > return ret; I don't think this works. The hda_codec_i915_init() errors are ignored in hda_init() so this never returns -EPROBE_DEFER. So something like this is needed on top (tested quickly on one SOF machine and this blocks SOF load until i915 or xe driver is loaded): --cut-- diff --git a/sound/soc/sof/intel/hda.c b/sound/soc/sof/intel/hda.c index 9025bfaf6a7e..8b17c82dcc89 100644 --- a/sound/soc/sof/intel/hda.c +++ b/sound/soc/sof/intel/hda.c @@ -863,13 +863,20 @@ static int hda_init(struct snd_sof_dev *sdev) /* init i915 and HDMI codecs */ ret = hda_codec_i915_init(sdev); if (ret < 0) - dev_warn(sdev->dev, "init of i915 and HDMI codec failed\n"); + dev_warn(sdev->dev, "init of i915 and HDMI codec failed (%d)\n", ret); + + if (ret < 0 && ret != -ENODEV) + goto out; /* get controller capabilities */ ret = hda_dsp_ctrl_get_caps(sdev); if (ret < 0) dev_err(sdev->dev, "error: get caps error\n"); +out: + if (ret < 0) + iounmap(sof_to_bus(sdev)->remap_addr); + return ret; } --cut-- Br, Kai

2 1

Re: [PATCH] ASoC: SOF: Intel: Add error handling in hda_dsp_trace_release
by Pierre-Louis Bossart 03 Oct '23

03 Oct '23

On 9/23/23 05:12, liuhaoran wrote: > This patch adds error-handling for the hda_dsp_stream_put() inside > the hda_dsp_trace_release function in the hda-trace.c file. > > Signed-off-by: liuhaoran <liuhaoran14(a)163.com> > --- > sound/soc/sof/intel/hda-trace.c | 11 ++++++++++- > 1 file changed, 10 insertions(+), 1 deletion(-) > > diff --git a/sound/soc/sof/intel/hda-trace.c b/sound/soc/sof/intel/hda-trace.c > index cbb9bd7770e6..5dcd43b9cbe4 100644 > --- a/sound/soc/sof/intel/hda-trace.c > +++ b/sound/soc/sof/intel/hda-trace.c > @@ -73,13 +73,22 @@ int hda_dsp_trace_release(struct snd_sof_dev *sdev) > { > struct sof_intel_hda_dev *hda = sdev->pdata->hw_pdata; > struct hdac_stream *hstream; > + int ret; > > if (hda->dtrace_stream) { > hstream = &hda->dtrace_stream->hstream; > - hda_dsp_stream_put(sdev, > + ret = hda_dsp_stream_put(sdev, > SNDRV_PCM_STREAM_CAPTURE, > hstream->stream_tag); > + > hda->dtrace_stream = NULL; > + > + if (ret < 0) { > + dev_dbg(sdev->dev, > + "stream put failed: %d\n", ret); > + return ret; > + } > + I don't know if returning an error helps here, this might get in the way of the suspend. Peter, what do you think? > return 0; > } >

1 0

Re: [PATCH v5 10/12] ASoC: Intel: Skylake: Move snd_hdac_i915_init to before probe_work.
by Amadeusz Sławiński 03 Oct '23

03 Oct '23

On 10/2/2023 6:52 PM, Maarten Lankhorst wrote: > Now that we can use -EPROBE_DEFER, it's no longer required to spin off > the snd_hdac_i915_init into a workqueue. It's likely the whole workqueue > can be destroyed, but I don't have the means to test this. > > Removing the workqueue would simplify init even further, but is left > as exercise for the reviewer. > > Signed-off-by: Maarten Lankhorst <maarten.lankhorst(a)linux.intel.com> > Acked-by: Mark Brown <broonie(a)kernel.org> > Reviewed-by: Kai Vehmanen <kai.vehmanen(a)linux.intel.com> > Reviewed-by: Amadeusz Sławiński <amadeuszx.slawinski(a)linux.intel.com> > --- Isn't the convention that your Signed-off should be last when you are sending the patches? Or does it only apply to Signed-off lines themselves and other lines can be anywhere?

1 1

Re: [PATCH][next] ASoC: SOF: ipc4-topology: Use size_add() in call to struct_size()
by Mark Brown 02 Oct '23

02 Oct '23

On Fri, 15 Sep 2023 13:09:11 -0600, Gustavo A. R. Silva wrote: > If, for any reason, the open-coded arithmetic causes a wraparound, > the protection that `struct_size()` adds against potential integer > overflows is defeated. Fix this by hardening call to `struct_size()` > with `size_add()`. > > Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next Thanks! [1/1] ASoC: SOF: ipc4-topology: Use size_add() in call to struct_size() commit: 3746284c233d5cf5f456400e61cd4a46a69c6e8c 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