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

Re: [Sound-open-firmware] [PATCH linux-next] ASoC: SOF: intel: remove duplicate include
by Mark Brown 25 Aug '21

25 Aug '21

On Mon, 23 Aug 2021 20:00:15 -0700, CGEL wrote: > From: Changcheng Deng <deng.changcheng(a)zte.com.cn> > > Clean up the following includecheck warning: > > ./sound/soc/sof/intel/pci-tng.c: shim.h is included more than once. > > No functional change. > > [...] Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next Thanks! [1/1] ASoC: SOF: intel: remove duplicate include commit: 0be10d7122ceb8f322086283420a59ee89c1947f 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: [Sound-open-firmware] [PATCH linux-next] ASoC: SOF: intel: remove duplicate include
by Pierre-Louis Bossart 24 Aug '21

24 Aug '21

On 8/23/21 10:00 PM, CGEL wrote: > From: Changcheng Deng <deng.changcheng(a)zte.com.cn> > > Clean up the following includecheck warning: > > ./sound/soc/sof/intel/pci-tng.c: shim.h is included more than once. > > No functional change. > > Reported-by: Zeal Robot <zealci(a)zte.com.cn> > Signed-off-by: Changcheng Deng <deng.changcheng(a)zte.com.cn> Acked-by: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.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" > >

1 0

[Sound-open-firmware] Questions about XTOS & HAL
by Daniel Baluta 20 Aug '21

20 Aug '21

Hi Liam, Where did you get the initial sources for xtos or HAL that can be found in: * src/arch/xtensa/xtos * src/arch/xtensa/hal I wonder if they arrived with some documentation. We are preparing a presentation for Linaro Connect, to describe our effort of switching from XTOS to Zephyr [1] and we like to better understand how SOF uses xtos/hal/etc. So far example we would like to understand: 1) what is the role of HAL and why it is not inside the same binary as the XTOS? 2) what is the role of libreset.a and why it isnt implemented inside libxtos.a 3) in SOF presentations we've seen that the generic micro kernel used by SOF comes with threads, semaphores, workqueus, mutexes. Are these primitives implemented in the XTOS initial code? We couldn't find them in the xtos code that is inside SOF. thanks, Daniel. [1] https://events.pinetool.ai/2231/#sessions/67130?referrer%5Bpathname%5D=%2Fs… Linaro Virtual Connect Fall 2021<https://events.pinetool.ai/2231/#sessions/67130?referrer%5Bpathname%5D=%2Fs…> Linaro Virtual Connect Fall 2021 events.pinetool.ai       

1 0

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