January 2020 - Alsa-devel - mailman.alsa-project.org

[alsa-devel] [PATCH v3 00/11] ASoC: SOF: Data probing
by Cezary Rojewski 31 Jan '20

31 Jan '20

This set of patches achieves few goals in order to enable data probing feature for audio DSP. First, provide new and alter existing interfaces (page allocation, runtime flow adjustments) to make them compress friendly. For HDA part, work has been done to account for compress streams when servicing IRQs, setting up BDLs and assigning DMAs. Finally, the end goal which are the probe APIs and usage itself. Probes can be treated as endpoints which allow for data extraction from or injection to target module - a great ally when debugging problematic audio issues such as distortions, glitches or gaps. Compress streams are a weapon of choice here to provide a lightweight implementation. While all available IPCs have been defined, current implementation covers extraction only, with injection scheduled for a later date. Initial review and development of probes can be found under: https://github.com/thesofproject/linux/pull/1276 with the hda-compress-enable set of patches being separated and reviewed on: https://github.com/thesofproject/linux/pull/1571 Tested on CML-U with rt5682 i2s board. Changes in v3: - Addressed sparse and all doc related warnings as reported by Pierre - Moved _DEBUG_PROBES config outside of _DEVELOPER_SUPPORT block - Renamed 'extractor' field to 'extractor_stream_tag' as requested - Relocated 'extractor_stream_tag' declaration from patch 07 to 08 Changes in v2: - No changes to ALSA core and hda patches - Removed "ASoC: Intel: sof_rt5682: Add compress probe DAI links" from the patchset list as requested by Pierre - updated copyright header for newly added files (dates) - probes over HDA no longer require SND_SOC_SOF_HDA_LINK enabled - renamed debugfs probe functions as requested by Pierre - probe IPC API has been updated to align with newest SOF FW & probe debug app (struct_size macro has been enlisted to make the size calculations transparent). This targets only "ASoC: SOF: Implement Probe IPC API" patch Cezary Rojewski (11): ALSA: hda: Allow for compress stream to hdac_ext_stream assignment ALSA: hda: Prepare for compress stream support ALSA: hda: Interrupt servicing and BDL setup for compress streams ALSA: core: Expand DMA buffer information ALSA: core: Implement compress page allocation and free routines ASoC: SOF: Intel: Account for compress streams when servicing IRQs ASoC: SOF: Implement Probe IPC API ASoC: SOF: Generic probe compress operations ASoC: SOF: Intel: Probe compress operations ASoC: SOF: Provide probe debugfs support ASoC: SOF: Intel: Add Probe compress CPU DAIs include/sound/compress_driver.h | 40 +++- include/sound/hdaudio.h | 2 + include/sound/hdaudio_ext.h | 2 + include/sound/sof/header.h | 11 ++ sound/core/compress_offload.c | 42 +++++ sound/hda/ext/hdac_ext_stream.c | 49 ++++- sound/hda/hdac_controller.c | 4 +- sound/hda/hdac_stream.c | 52 ++++-- sound/soc/sof/Kconfig | 9 + sound/soc/sof/Makefile | 3 +- sound/soc/sof/compress.c | 140 ++++++++++++++ sound/soc/sof/compress.h | 29 +++ sound/soc/sof/debug.c | 208 +++++++++++++++++++++ sound/soc/sof/intel/Kconfig | 9 + sound/soc/sof/intel/Makefile | 1 + sound/soc/sof/intel/apl.c | 9 + sound/soc/sof/intel/cnl.c | 9 + sound/soc/sof/intel/hda-compress.c | 132 +++++++++++++ sound/soc/sof/intel/hda-dai.c | 28 +++ sound/soc/sof/intel/hda-ipc.c | 4 +- sound/soc/sof/intel/hda-stream.c | 26 ++- sound/soc/sof/intel/hda.h | 30 +++ sound/soc/sof/ops.h | 43 +++++ sound/soc/sof/pcm.c | 11 +- sound/soc/sof/probe.c | 286 +++++++++++++++++++++++++++++ sound/soc/sof/probe.h | 85 +++++++++ sound/soc/sof/sof-priv.h | 24 +++ 27 files changed, 1247 insertions(+), 41 deletions(-) create mode 100644 sound/soc/sof/compress.c create mode 100644 sound/soc/sof/compress.h create mode 100644 sound/soc/sof/intel/hda-compress.c create mode 100644 sound/soc/sof/probe.c create mode 100644 sound/soc/sof/probe.h -- 2.17.1

7 30

[alsa-devel] [PATCH] ASoC: rt5659: add S32_LE format
by Sameer Pujar 31 Jan '20

31 Jan '20

ALC5659 supports maximum data length of 24-bit. Currently driver supports S24_LE which is a 32-bit container with valid data in [23:0] and 0s in MSB. S24_3LE is not commonly used and is hard to find audio streams with this format. Also many SoC HW do not support S24_LE and S32_LE is used in general. The 24-bit data can be represented in S32_LE [31:8] and 0s are padded in LSB. This patch adds S32_LE to ALC5659 driver and data length for this is set to 24 as per codec's maximum data length support. This helps to play 24-bit audio, packed in S32_LE, on HW which do not support S24_LE. Signed-off-by: Sameer Pujar <spujar(a)nvidia.com> --- sound/soc/codecs/rt5659.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/sound/soc/codecs/rt5659.c b/sound/soc/codecs/rt5659.c index fc74dd63..f910ddf 100644 --- a/sound/soc/codecs/rt5659.c +++ b/sound/soc/codecs/rt5659.c @@ -3339,6 +3339,7 @@ static int rt5659_hw_params(struct snd_pcm_substream *substream, val_len |= RT5659_I2S_DL_20; break; case 24: + case 32: val_len |= RT5659_I2S_DL_24; break; case 8: @@ -3733,7 +3734,8 @@ static int rt5659_resume(struct snd_soc_component *component) #define RT5659_STEREO_RATES SNDRV_PCM_RATE_8000_192000 #define RT5659_FORMATS (SNDRV_PCM_FMTBIT_S16_LE | SNDRV_PCM_FMTBIT_S20_3LE | \ - SNDRV_PCM_FMTBIT_S24_LE | SNDRV_PCM_FMTBIT_S8) + SNDRV_PCM_FMTBIT_S24_LE | SNDRV_PCM_FMTBIT_S32_LE | \ + SNDRV_PCM_FMTBIT_S8) static const struct snd_soc_dai_ops rt5659_aif_dai_ops = { .hw_params = rt5659_hw_params, -- 2.7.4

2 4

[alsa-devel] no period wakeup support
by sylvain.bertrand＠gmail.com 31 Jan '20

31 Jan '20

Hi, Nowadays, is this reasonable to consider disabling the period wakeup as default instead of expecting period wakeup by default? regards, -- Sylvain (sorry to post here, but sourceforge mailing lists are now using the google braindamaged javascript _only_ recaptcha)

4 6

Re: [alsa-devel] [CX2075] No sound after suspend/resume from front speaker
by Takashi Iwai 30 Jan '20

30 Jan '20

On Thu, 30 Jan 2020 12:42:01 +0100, Roman Šmakal wrote: > > Dne středa 29. ledna 2020 12:33:06 CET jste napsal(a): > > On Sat, 25 Jan 2020 23:30:32 +0100, > > > > Roman Šmakal wrote: > > > Hi, > > > > > > this still seem to be an issue. After startup everything works well until > > > the laptop goes to suspend. > > > > > > Tried pretty much everything basic user can do (unmutes, rmmods and so > > > on), > > > still no way to wake the output. ALSA seems to be thinking, that output is > > > active, you can set volume and stuff, but nothing happens. > > > > > > ALSA info: > > > http://alsa-project.org/db/?f=9d1ee81fe037acb53ca381f2de27be420f83a373 > > > > > > Related links: > > > https://www.reddit.com/r/archlinux/comments/4nwzua/ > > > no_sound_after_suspend_killing_or_restarting/ > > > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1612916 > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=851404 > > > > The first thing to check is to compare alsa-info.sh outputs before and > > after the suspend. > > > > Also pass snd_hda_codec.dump_coef=1 module option to enable the COEF > > dump. This will give more information in alsa-info.sh outputs. > > > > > > Takashi > > Okay, i did some comparing with module option enabled. > > > Sound working > http://alsa-project.org/db/?f=adfb0b3ad5d9b8d88289ac7e35b742254beb7588 > > Sound not working: > http://alsa-project.org/db/?f=c796b14df0efb0079aef1df5f70764194cff8d4d > > What's wierd to me is, that on the row 521 there is change in aplay Subdevices > from 1/1 to 0/1. > > Also, state.PCH control 18 shows change in playback channel map. > > Any other thing i can check or try to dofor debuging? You passed a wrong option. The option is for snd_hda_codec module. So either create a modprobe.d/*.conf file containing: options snd_hda_codec dump_coef=1 or pass snd_hda_codec.dump_coef=1 at boot cmdline option. BTW, it'd be better to get the outputs with --no-upload option of alsa-info.sh, and attach them. Last but not least, please don't drop Cc to ML unless you need to do so. thanks, Takashi

2 7

[alsa-devel] [PATCH 0/3] ASoC: Intel: add sof_pcm512x machine driver
by Pierre-Louis Bossart 30 Jan '20

30 Jan '20

This is an overdue upstream contribution for a platform used by nearly all SOF developers at Intel as well as the SOF CI. While I was the initial author in 2018, these patches were updated and improved by Xiuli Pan, Ranjani Sridharan, Kai Vehmanen and Guennadi Liakhovetski who worked on the last clean-ups. Thanks y'all. Full disclosure on the Cherrytrail/Up support: the board will only be detected with specific pin-configurations that are not handled by the mainline kernel just yet. Pierre-Louis Bossart (3): ASoC: Intel: sof_pcm512x: add support for SOF platforms with pcm512x ASoC: Intel: BXT: switch pcm512x based boards to sof_pcm512x ASoC: Intel: CHT: add support for pcm512x boards sound/soc/intel/boards/Kconfig | 14 + sound/soc/intel/boards/Makefile | 2 + sound/soc/intel/boards/sof_pcm512x.c | 428 ++++++++++++++++++ .../intel/common/soc-acpi-intel-bxt-match.c | 2 +- .../intel/common/soc-acpi-intel-cht-match.c | 7 + 5 files changed, 452 insertions(+), 1 deletion(-) create mode 100644 sound/soc/intel/boards/sof_pcm512x.c -- 2.20.1

2 7

[alsa-devel] [RESEND PATCH] ASoC: atmel: fix atmel_ssc_set_audio link failure
by Codrin Ciubotariu 30 Jan '20

30 Jan '20

From: Arnd Bergmann <arnd(a)arndb.de> The ssc audio driver can call into both pdc and dma backends. With the latest rework, the logic to do this in a safe way avoiding link errors was removed, bringing back link errors that were fixed long ago in commit 061981ff8cc8 ("ASoC: atmel: properly select dma driver state") such as sound/soc/atmel/atmel_ssc_dai.o: In function `atmel_ssc_set_audio': atmel_ssc_dai.c:(.text+0xac): undefined reference to `atmel_pcm_pdc_platform_register' Fix it this time using Makefile hacks and a comment to prevent this from accidentally getting removed again rather than Kconfig hacks. Fixes: 18291410557f ("ASoC: atmel: enable SOC_SSC_PDC and SOC_SSC_DMA in Kconfig") Signed-off-by: Arnd Bergmann <arnd(a)arndb.de> --- This patch applies fine to me on asoc/for-next, so this is just a resend. sound/soc/atmel/Kconfig | 4 ++-- sound/soc/atmel/Makefile | 10 ++++++++-- 2 files changed, 10 insertions(+), 4 deletions(-) diff --git a/sound/soc/atmel/Kconfig b/sound/soc/atmel/Kconfig index d1dc8e6366dc..71f2d42188c4 100644 --- a/sound/soc/atmel/Kconfig +++ b/sound/soc/atmel/Kconfig @@ -10,11 +10,11 @@ config SND_ATMEL_SOC if SND_ATMEL_SOC config SND_ATMEL_SOC_PDC - tristate + bool depends on HAS_DMA config SND_ATMEL_SOC_DMA - tristate + bool select SND_SOC_GENERIC_DMAENGINE_PCM config SND_ATMEL_SOC_SSC diff --git a/sound/soc/atmel/Makefile b/sound/soc/atmel/Makefile index 1f6890ed3738..c7d2989791be 100644 --- a/sound/soc/atmel/Makefile +++ b/sound/soc/atmel/Makefile @@ -6,8 +6,14 @@ snd-soc-atmel_ssc_dai-objs := atmel_ssc_dai.o snd-soc-atmel-i2s-objs := atmel-i2s.o snd-soc-mchp-i2s-mcc-objs := mchp-i2s-mcc.o -obj-$(CONFIG_SND_ATMEL_SOC_PDC) += snd-soc-atmel-pcm-pdc.o -obj-$(CONFIG_SND_ATMEL_SOC_DMA) += snd-soc-atmel-pcm-dma.o +# pdc and dma need to both be built-in if any user of +# ssc is built-in. +ifdef CONFIG_SND_ATMEL_SOC_PDC +obj-$(CONFIG_SND_ATMEL_SOC_SSC) += snd-soc-atmel-pcm-pdc.o +endif +ifdef CONFIG_SND_ATMEL_SOC_DMA +obj-$(CONFIG_SND_ATMEL_SOC_SSC) += snd-soc-atmel-pcm-dma.o +endif obj-$(CONFIG_SND_ATMEL_SOC_SSC) += snd-soc-atmel_ssc_dai.o obj-$(CONFIG_SND_ATMEL_SOC_I2S) += snd-soc-atmel-i2s.o obj-$(CONFIG_SND_MCHP_SOC_I2S_MCC) += snd-soc-mchp-i2s-mcc.o -- 2.20.1

2 1

[alsa-devel] Managing resources of DSP from arm core side
by Daniel Baluta 30 Jan '20

30 Jan '20

Hi Peter, Liam mentioned that at some point (when working for OMAP) you might have had the same challenge I'm facing now. I'm trying to figure out how to properly manage resources needed by the IPs configured by DSP. On i.MX8 we the following scenario: - Application processor (arm64) exposes an ALSA sound card to applications - DSP (Hifi4) does the processing DSP has direct access to DAI registers but it doesn't have (easily) access to other resources like: pinctrl, power-domain, clocks, etc. I was wondering how did you tackled this for OMAP? I have already created a dummy CPU DAI on Linux that it will take care of this [1]. It is a part of a Back End link like this (simplified view): links[i].cpus->name = "dummy_dai"; links[i].platforms->name = "dsp"; links[i].codecs->name = "cs42888"; links[i].no_pcm = 1; It works pretty well for basic playback / capture. thanks, Daniel. [1] https://marc.info/?l=alsa-devel&m=158022296519597&w=2

2 2

[alsa-devel] [PATCH v2] dmaengine: Fix return value for dma_requrest_chan() in case of failure
by Marek Szyprowski 30 Jan '20

30 Jan '20

Commit 71723a96b8b1 ("dmaengine: Create symlinks between DMA channels and slaves") changed the dma_request_chan() function flow in such a way that it always returns EPROBE_DEFER in case of channels that cannot be found. This break the operation of the devices which have optional DMA channels as it puts their drivers in endless deferred probe loop. Fix this by propagating the proper error value. Fixes: 71723a96b8b1 ("dmaengine: Create symlinks between DMA channels and slaves") Signed-off-by: Marek Szyprowski <m.szyprowski(a)samsung.com> --- drivers/dma/dmaengine.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/dma/dmaengine.c b/drivers/dma/dmaengine.c index f3ef4edd4de1..7b1cefc3213a 100644 --- a/drivers/dma/dmaengine.c +++ b/drivers/dma/dmaengine.c @@ -759,7 +759,7 @@ struct dma_chan *dma_request_chan(struct device *dev, const char *name) if (!IS_ERR_OR_NULL(chan)) goto found; - return ERR_PTR(-EPROBE_DEFER); + return chan ? chan : ERR_PTR(-EPROBE_DEFER); found: chan->slave = dev; -- 2.17.1

3 2

[alsa-devel] [PATCH] ALSA: uapi: Fix sparse warning
by Ranjani Sridharan 29 Jan '20

29 Jan '20

Fix the following sparse warning generated due to 64-bit compat type having fields defined explicitly with __32: sound/soc/sof/sof-audio.c:46:31: warning: incorrect type in assignment (different base types) sound/soc/sof/sof-audio.c:46:31: expected restricted snd_pcm_state_t [usertype] state sound/soc/sof/sof-audio.c:46:31: got signed int [usertype] state Reported-by: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com> Suggested-by: Takashi Iwai <tiwai(a)suse.de> Signed-off-by: Ranjani Sridharan <ranjani.sridharan(a)linux.intel.com> --- include/uapi/sound/asound.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/include/uapi/sound/asound.h b/include/uapi/sound/asound.h index 30ebb2a42983..535a7229e1d9 100644 --- a/include/uapi/sound/asound.h +++ b/include/uapi/sound/asound.h @@ -564,13 +564,13 @@ typedef char __pad_after_uframe[sizeof(__u64) - sizeof(snd_pcm_uframes_t)]; #endif struct __snd_pcm_mmap_status64 { - __s32 state; /* RO: state - SNDRV_PCM_STATE_XXXX */ + snd_pcm_state_t state; /* RO: state - SNDRV_PCM_STATE_XXXX */ __u32 pad1; /* Needed for 64 bit alignment */ __pad_before_uframe __pad1; snd_pcm_uframes_t hw_ptr; /* RO: hw ptr (0...boundary-1) */ __pad_after_uframe __pad2; struct __snd_timespec64 tstamp; /* Timestamp */ - __s32 suspended_state; /* RO: suspended stream state */ + snd_pcm_state_t suspended_state;/* RO: suspended stream state */ __u32 pad3; /* Needed for 64 bit alignment */ struct __snd_timespec64 audio_tstamp; /* sample counter or wall clock */ }; -- 2.17.1

2 1

[alsa-devel] Question about the correct license to use with debugfs in SOF
by Sridharan, Ranjani 29 Jan '20

29 Jan '20

Hi Greg, Can I please bother you with you quick question about the right license to use for the debug.c file in the SOF directory? Currently, it is dual licensed with GPLv2.0 and BSD. But Pierre brought up a concern about this conflicting with all the exports in the file being GPLv2.0. Should this be fixed to change the license to GPLv2.0 only? Appreciate your help in this regard. Thanks, Ranjani

3 4