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

Re: [Sound-open-firmware] [RFC PATCH 2/2] ASoC: SOF: trigger re-probing of deferred devices from workqueue
by Pierre-Louis Bossart 18 Aug '21

18 Aug '21

On 8/18/21 7:07 AM, Mark Brown wrote: > On Tue, Aug 17, 2021 at 02:00:57PM -0500, Pierre-Louis Bossart wrote: > >> +++ b/sound/soc/sof/core.c >> @@ -251,6 +251,9 @@ static int sof_probe_continue(struct snd_sof_dev *sdev) >> >> sdev->probe_completed = true; >> >> + /* kick-off re-probing of deferred devices */ >> + driver_deferred_probe_trigger(); >> + > > I think we should move this into snd_soc_register_component() - the same > issue could occur with any other component, the only other thing I can > see kicking in here is the machine driver registration but that ought to > kick probe itself anyway. Or is there some other case here? Thanks for the suggestion Mark, it would be more consistent indeed to kick a re-evaluation of the deferred probe list when ASoC components are successfully registered with something like this: diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c index c830e96afba2..9d6feea7719c 100644 --- a/sound/soc/soc-core.c +++ b/sound/soc/soc-core.c @@ -2677,7 +2677,14 @@ int snd_soc_register_component(struct device *dev, if (ret < 0) return ret; - return snd_soc_add_component(component, dai_drv, num_dai); + ret = snd_soc_add_component(component, dai_drv, num_dai); + if (ret < 0) + return ret; + + /* kick-off re-probing of deferred devices */ + driver_deferred_probe_trigger(); + + return 0; } EXPORT_SYMBOL_GPL(snd_soc_register_component); In the case of this SOF driver, it'd be completely equivalent to what this patch suggested, the snd_soc_register_component() is what we do last in the workqueue. In the case of 'regular' drivers, the component registration is typically done last as well before the end of the probe. This would result in 2 evaluations (one on successful ASoC component registration and one on successful probe), and maybe on the second evaluation there's nothing to do. I can't think of any negative side-effects.

1 0

[Sound-open-firmware] [RFC PATCH 2/2] ASoC: SOF: trigger re-probing of deferred devices from workqueue
by Pierre-Louis Bossart 17 Aug '21

17 Aug '21

Audio drivers such as HDaudio legacy and SOF rely on a workqueue to split the probe into two, with a first pass returning success immediately, and the second pass taking a lot more time due to the use of request_module() and the DSP initializations. This workqueue-based solution helps deal with conflicting requirements a) other drivers should not be blocked by a long probe b) a PROBE_PREFER_ASYNCHRONOUS probe_type is explicitly not allowed to avoid a deadlock when request_module() is used. This patch makes sure the deferred probe framework is triggered when the provider of resources successfully completes its initialization. Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com> --- sound/soc/sof/core.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/sound/soc/sof/core.c b/sound/soc/sof/core.c index 3e4dd4a86363..cecc0e914807 100644 --- a/sound/soc/sof/core.c +++ b/sound/soc/sof/core.c @@ -251,6 +251,9 @@ static int sof_probe_continue(struct snd_sof_dev *sdev) sdev->probe_completed = true; + /* kick-off re-probing of deferred devices */ + driver_deferred_probe_trigger(); + return 0; fw_trace_err: -- 2.25.1

1 0

[Sound-open-firmware] Default branch for rimage repo
by Daniel Baluta 04 Aug '21

04 Aug '21

Hi Liam and Marc, What is the default branch used by SOF project for rimage submodule? I think the sof build system still uses master branch while we pushed our PR on main. Is that true? Also, should we manually update the rimage repo to look for changes or cmake build scripts do this automatically. Daniel.

2 2

[Sound-open-firmware] Dynamic module loading
by Daniel Baluta 30 Jul '21

30 Jul '21

Hi Rander, Regarding your patch: https://github.com/thesofproject/sof/pull/4536/commits/12ca2c956e5be4949e61… We've seen this new IPC: case SOF_IPC4_GLB_LOAD_MULTIPLE_MODULES: case SOF_IPC4_GLB_UNLOAD_MULTIPLE_MODULES: tr_err(&ipc_tr, "not implemented ipc message type %d", type); ret = IPC4_UNAVAILABLE; Is this loading a new binary module for SOF to later use? Is there any documentation about this? Or a pointer in the converged-modules repo? We are working on implementing a similar feature and we could use and work previously done. thanks, Daniel.

2 2

[Sound-open-firmware] EQ component documentation
by Daniel Baluta 23 Jul '21

23 Jul '21

Hi Seppo, Is there any documentation on how to use the Equalizer component for SOF? Is there any way to dynamically change the coefficients at runtime?

3 3

[Sound-open-firmware] question: status sound on Intel NUC M15
by Gilles van Eeden 12 Jul '21

12 Jul '21

Hi, hopefully this is the right place for this question. I've fruitlessly been trying to get sound to work on the Intel NUC M15 <https://linux-hardware.org/?probe=93690f8eec>. A fitting topology for this platform seems lacking, among other things. Is there any work ongoing on this? I will gladly provide diagnostic data from my system, if so desired. Best regards, Gilles

2 1

[Sound-open-firmware] [PATCH AUTOSEL 5.13 025/114] ASoC: SOF: topology: fix assignment to use le32_to_cpu
by Sasha Levin 10 Jul '21

10 Jul '21

From: Jaska Uimonen <jaska.uimonen(a)linux.intel.com> [ Upstream commit ccaea61a8d1b8180cc3c470e383381884e4bc1f2 ] Fix sparse warning by using le32_to_cpu. Signed-off-by: Jaska Uimonen <jaska.uimonen(a)linux.intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan(a)linux.intel.com> Signed-off-by: Kai Vehmanen <kai.vehmanen(a)linux.intel.com> Link: https://lore.kernel.org/r/20210521092804.3721324-6-kai.vehmanen@linux.intel… Signed-off-by: Mark Brown <broonie(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- sound/soc/sof/topology.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/soc/sof/topology.c b/sound/soc/sof/topology.c index 59abcfc9bd55..cb16b2bd8c21 100644 --- a/sound/soc/sof/topology.c +++ b/sound/soc/sof/topology.c @@ -3335,7 +3335,7 @@ static int sof_link_load(struct snd_soc_component *scomp, int index, /* Copy common data to all config ipc structs */ for (i = 0; i < num_conf; i++) { config[i].hdr.cmd = SOF_IPC_GLB_DAI_MSG | SOF_IPC_DAI_CONFIG; - config[i].format = hw_config[i].fmt; + config[i].format = le32_to_cpu(hw_config[i].fmt); config[i].type = common_config.type; config[i].dai_index = common_config.dai_index; } -- 2.30.2

1 0

[Sound-open-firmware] Query regarding Sound Open Firmware
by Srivally Munnangi 24 Jun '21

24 Jun '21

Hi Team Myself Srivally, from Hyderabad, India. I have recently come across sound open firmware . I have a query regarding the same. Can you please let me know whether SOF can be installed on Windows PCs? Thanks Srivally

1 0

Re: [Sound-open-firmware] [PATCH] ASoC: SOF: Intel: Remove duplicate include of shim.h
by Ranjani Sridharan 03 Jun '21

03 Jun '21

On Thu, 2021-06-03 at 10:59 +0800, Wan Jiabing wrote: > shim.h is included twice. > As shim.h is not related to later header file, > keep one which has comment and remove the former one. > > Signed-off-by: Wan Jiabing <wanjiabing(a)vivo.com> > --- > sound/soc/sof/intel/pci-tng.c | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/sound/soc/sof/intel/pci-tng.c b/sound/soc/sof/intel/pci- > tng.c > index 4ee1da3..4bded66 100644 > --- a/sound/soc/sof/intel/pci-tng.c > +++ b/sound/soc/sof/intel/pci-tng.c > @@ -15,7 +15,6 @@ > #include <sound/sof.h> > #include "../ops.h" > #include "atom.h" > -#include "shim.h" > #include "../sof-pci-dev.h" > #include "../sof-audio.h" > Thanks for the patch. Reviewed-by: Ranjani Sridharan <ranjani.sridharan(a)linux.intel.com>

1 0

[Sound-open-firmware] Commit c80270e7e49 (" ipc: structures should all be aligned on 4 bytes") causes issues on i.MX8
by Daniel Baluta 11 May '21

11 May '21

Hi Liam, I noticed this SOF commit: commit c80270e7e49d26a34fe284d1868e7d9cb80104f1 Author: Liam Girdwood <liam.r.girdwood(a)linux.intel.com> Date: Sat Apr 3 21:22:21 2021 +0100 ipc: structures should all be aligned on 4 bytes Give the compiler a chance to further optimise IPC data access since it's all on a 4 byte alignment. Signed-off-by: Liam Girdwood <liam.r.girdwood(a)linux.intel.com> It looks like it triggers some issues on i.MX8. Is there any equivalent for Linux kernel? Some structures are shared with the kernel and on arm64 it assumes default alignment as 8 hence I get a mismatch at least when printing DAI / Host position + dev_info(sdev->dev, "posn : host 0x%llx dai 0x%llx wall 0x%llx no_per %d\n", + posn.host_posn, posn.dai_posn, posn.wallclock, stream->substream->runtime->no_period_wakeup); thanks, Daniel.

3 4