July 2017 - Alsa-devel - mailman.alsa-project.org

[alsa-devel] Issue on Linux 4.12-rc7 on iMX6 based board
by gianluca 03 Jul '17

03 Jul '17

Hello list, I have some issue using the sgtl5000 on two custom boards based with iMX6. One board has iMX6DL and the other has iMX6QP. The issue is I have a (dramatically high) strange value on mixer settings (looks like a int32 limit or similar) This is the output of amixer: > # amixer > Simple mixer control 'Headphone',0 > Capabilities: pvolume pswitch pswitch-joined > Playback channels: Front Left - Front Right > Limits: Playback 0 - 127 > Mono: > Front Left: Playback 0 [2147483647%] [-51.50dB] [on] > Front Right: Playback 0 [2147483647%] [-51.50dB] [on] > Simple mixer control 'Headphone Mux',0 > Capabilities: enum > Items: 'DAC' 'LINE_IN' > Item0: 'DAC' > Simple mixer control 'Headphone Playback ZC',0 > Capabilities: pswitch pswitch-joined > Playback channels: Mono > Mono: Playback [on] > Simple mixer control 'PCM',0 > Capabilities: pvolume > Playback channels: Front Left - Front Right > Limits: Playback 0 - 192 > Mono: > Front Left: Playback 1 [2147483647%] > Front Right: Playback 0 [2147483647%] > Simple mixer control 'Lineout',0 > Capabilities: pvolume pswitch pswitch-joined > Playback channels: Front Left - Front Right > Limits: Playback 0 - 31 > Mono: > Front Left: Playback 18 [2147483647%] [-6.50dB] [on] > Front Right: Playback 18 [2147483647%] [-6.50dB] [on] > Simple mixer control 'Mic',0 > Capabilities: volume volume-joined > Playback channels: Mono > Capture channels: Mono > Limits: 0 - 3 > Mono: 0 [2147483647%] [0.00dB] > Simple mixer control 'Capture',0 > Capabilities: cvolume > Capture channels: Front Left - Front Right > Limits: Capture 0 - 15 > Front Left: Capture 0 [2147483647%] > Front Right: Capture 0 [2147483647%] > Simple mixer control 'Capture Attenuate Switch (-6dB)',0 > Capabilities: pswitch pswitch-joined > Playback channels: Mono > Mono: Playback [off] > Simple mixer control 'Capture Mux',0 > Capabilities: enum > Items: 'MIC_IN' 'LINE_IN' > Item0: 'MIC_IN' > Simple mixer control 'Capture ZC',0 > Capabilities: pswitch pswitch-joined > Playback channels: Mono > Mono: Playback [on] > In attachment there is a screenshot of alsamixer All audio stuff are not hear at all.... :-( After the output of the sgtl5000 I have a audio-booster and it is set at the maximum level. I have another board based on the iMX28, SGTL5000 and the same audio booster and everything is working good. So I can suppose something related the initialization of the codec. Any help? Best Regards, Gianluca Renzi -- Eurek s.r.l. | Electronic Engineering | http://www.eurek.it via Celletta 8/B, 40026 Imola, Italy | Phone: +39-(0)542-609120 p.iva 00690621206 - c.f. 04020030377 | Fax: +39-(0)542-609212

2 11

[alsa-devel] [PATCH] aplay: Fix header for raw format
by Ion-Horia Petrisor 03 Jul '17

03 Jul '17

Raw format has no header, so use 0 when calling playback_go. Signed-off-by: Ion-Horia Petrisor <ion-horia.petrisor(a)nxp.com> --- aplay/aplay.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/aplay/aplay.c b/aplay/aplay.c index 00af662..fe274ed 100644 --- a/aplay/aplay.c +++ b/aplay/aplay.c @@ -2831,7 +2831,7 @@ static void playback(char *name) /* should be raw data */ init_raw_data(); pbrec_count = calc_count(); - playback_go(fd, dta, pbrec_count, FORMAT_RAW, name); + playback_go(fd, 0, pbrec_count, FORMAT_RAW, name); } __end: if (fd != 0) -- 2.7.4

3 6

[alsa-devel] [PATCH] ALSA: hda/realtek - Remove GPIO_MASK
by Kai-Heng Feng 03 Jul '17

03 Jul '17

GPIO_MASK was introduced in commit "df694daa3c01 [ALSA] hda-codec - Add the support of ALC262,ALC883,ALC885,ALC861" but it's not being used. So we can simply remove it. Signed-off-by: Kai-Heng Feng <kai.heng.feng(a)canonical.com> --- sound/pci/hda/patch_realtek.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c index c79491a1cd47..425a4abd8ad0 100644 --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -41,9 +41,6 @@ /* keep halting ALC5505 DSP, for power saving */ #define HALT_REALTEK_ALC5505 -/* for GPIO Poll */ -#define GPIO_MASK 0x03 - /* extra amp-initialization sequence types */ enum { ALC_INIT_NONE, -- 2.13.2

2 1

[alsa-devel] I sent hardware informations with the script about a MEDION laptop with Intel devices
by fulgor fulgor 03 Jul '17

03 Jul '17

Is there any news about a module for this laptop ? fulgor

2 1

[alsa-devel] [PATCH] ALSA: hda/realtek - Fix typo
by Shih-Yuan Lee (FourDollars) 03 Jul '17

03 Jul '17

The PIN number for Dell headset mode of ALC3271 is wrong. Signed-off-by: Shih-Yuan Lee (FourDollars) <sylee(a)canonical.com> --- sound/pci/hda/patch_realtek.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c index c39bc49..d0cf1f3 100644 --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -6553,7 +6553,7 @@ static const struct snd_hda_pin_quirk alc269_pin_fixup_tbl[] = { SND_HDA_PIN_QUIRK(0x10ec0299, 0x1028, "Dell", ALC269_FIXUP_DELL4_MIC_NO_PRESENCE, ALC225_STANDARD_PINS, {0x12, 0xb7a60130}, - {0x13, 0xb8a60140}, + {0x13, 0xb8a61140}, {0x17, 0x90170110}), {} }; -- 2.7.4

2 1

[alsa-devel] [v2 0/4] Add debugfs support for skylake driver
by Guneshwor Singh 03 Jul '17

03 Jul '17

This series introduces debugfs support for skylake driver. It helps in debugging by providing module configurations which is loaded from topology. It also allows to read the firmware registers which are a part of SRAM memory area accessible by host CPU through a memory window. Guneshwor Singh (1): ASoC: Intel: common: Add sram address to sst_addr structure Sodhi, VunnyX (1): ASoC: Intel: Skylake: Add support to read firmware registers Vinod Koul (2): ASoC: Intel: Skylake: Add debugfs support ASoC: Intel: Skylake: Debugfs facility to dump module config Changes in v2: - Re-ordered patch and squashed platform changes Guneshwor Singh (1): ASoC: Intel: common: Add sram address to sst_addr structure Sodhi, VunnyX (1): ASoC: Intel: Skylake: Add support to read firmware registers Vinod Koul (2): ASoC: Intel: Skylake: Add debugfs support ASoC: Intel: Skylake: Debugfs facility to dump module config sound/soc/intel/common/sst-dsp-priv.h | 4 + sound/soc/intel/skylake/Makefile | 4 + sound/soc/intel/skylake/bxt-sst.c | 4 + sound/soc/intel/skylake/skl-debug.c | 269 +++++++++++++++++++++++++++++++++ sound/soc/intel/skylake/skl-sst.c | 5 + sound/soc/intel/skylake/skl-topology.c | 3 + sound/soc/intel/skylake/skl.c | 5 + sound/soc/intel/skylake/skl.h | 26 ++++ 8 files changed, 320 insertions(+) create mode 100644 sound/soc/intel/skylake/skl-debug.c -- 2.13.0

5 11

[alsa-devel] [asoc:topic/intel 37/40] sound/soc/intel/skylake/skl-debug.c:53:1-6: WARNING: invalid free of devm_ allocated data (fwd)
by Julia Lawall 03 Jul '17

03 Jul '17

This doesn't show enough of the context to see the allocation, but please check. thanks, julia ---------- Forwarded message ---------- Date: Sat, 1 Jul 2017 02:40:21 +0800 From: kbuild test robot <fengguang.wu(a)intel.com> To: kbuild(a)01.org Cc: Julia Lawall <julia.lawall(a)lip6.fr> Subject: [asoc:topic/intel 37/40] sound/soc/intel/skylake/skl-debug.c:53:1-6: WARNING: invalid free of devm_ allocated data tree: https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git topic/intel head: bdd0384a5ada8bb5745e5f29c10a5ba88827efad commit: 5cdf6c09ca9de3f037ba2d770206f3374459602d [37/40] ASoC: Intel: Skylake: Add debugfs support :::::: branch date: 6 hours ago :::::: commit date: 6 hours ago >> sound/soc/intel/skylake/skl-debug.c:53:1-6: WARNING: invalid free of devm_ allocated data git remote add asoc https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git git remote update asoc git checkout 5cdf6c09ca9de3f037ba2d770206f3374459602d vim +53 sound/soc/intel/skylake/skl-debug.c 5cdf6c09 Vinod Koul 2017-06-30 37 skl->platform->component.debugfs_root); 5cdf6c09 Vinod Koul 2017-06-30 38 if (IS_ERR(d->fs) || !d->fs) { 5cdf6c09 Vinod Koul 2017-06-30 39 dev_err(&skl->pci->dev, "debugfs root creation failed\n"); 5cdf6c09 Vinod Koul 2017-06-30 40 return NULL; 5cdf6c09 Vinod Koul 2017-06-30 41 } 5cdf6c09 Vinod Koul 2017-06-30 42 5cdf6c09 Vinod Koul 2017-06-30 43 d->skl = skl; 5cdf6c09 Vinod Koul 2017-06-30 44 d->dev = &skl->pci->dev; 5cdf6c09 Vinod Koul 2017-06-30 45 5cdf6c09 Vinod Koul 2017-06-30 46 return d; 5cdf6c09 Vinod Koul 2017-06-30 47 } 5cdf6c09 Vinod Koul 2017-06-30 48 5cdf6c09 Vinod Koul 2017-06-30 49 void skl_debugfs_exit(struct skl_debug *d) 5cdf6c09 Vinod Koul 2017-06-30 50 { 5cdf6c09 Vinod Koul 2017-06-30 51 debugfs_remove_recursive(d->fs); 5cdf6c09 Vinod Koul 2017-06-30 52 5cdf6c09 Vinod Koul 2017-06-30 @53 kfree(d); 5cdf6c09 Vinod Koul 2017-06-30 54 5cdf6c09 Vinod Koul 2017-06-30 55 } --- 0-DAY kernel test infrastructure Open Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation

2 1

[alsa-devel] [PATCH v2] ALSA: pcm: add a documentation for tracepoints
by Takashi Sakamoto 02 Jul '17

02 Jul '17

In PCM interface/protocol for userspace, parameters of runtime for PCM substream is decided by an interaction between applications and ALSA PCM core. In former commits, some tracepoints were added to probe a part of the interaction. This commit adds a documentation about the interaction and the tracepoints. Signed-off-by: Takashi Sakamoto <o-takashi(a)sakamocchi.jp> --- Documentation/sound/designs/index.rst | 1 + Documentation/sound/designs/tracepoints.rst | 172 ++++++++++++++++++++++++++++ 2 files changed, 173 insertions(+) create mode 100644 Documentation/sound/designs/tracepoints.rst diff --git a/Documentation/sound/designs/index.rst b/Documentation/sound/designs/index.rst index 04dcdae3e4f2..f0749943ccb2 100644 --- a/Documentation/sound/designs/index.rst +++ b/Documentation/sound/designs/index.rst @@ -9,6 +9,7 @@ Designs and Implementations compress-offload timestamping jack-controls + tracepoints procfile powersave oss-emulation diff --git a/Documentation/sound/designs/tracepoints.rst b/Documentation/sound/designs/tracepoints.rst new file mode 100644 index 000000000000..d2e481c6da37 --- /dev/null +++ b/Documentation/sound/designs/tracepoints.rst @@ -0,0 +1,172 @@ +=================== +Tracepoints in ALSA +=================== + +2017/07/02 +Takasahi Sakamoto + +Tracepoints in ALSA PCM core +============================ + +ALSA PCM core registers ``snd_pcm`` subsystem to kernel tracepoint system. +This subsystem includes two categories of tracepoints; for state of PCM buffer +and for processing of PCM hardware parameters. These tracepoints are available +when corresponding kernel configurations are enabled. When ``CONFIG_SND_DEBUG`` +is enabled, the latter tracepoints are available. When additional +``SND_PCM_XRUN_DEBUG`` is enabled too, the former trace points are enabled. + +Tracepoints for state of PCM buffer +------------------------------------ + +This category includes four tracepoints; ``hwptr``, ``applptr``, ``xrun`` and +``hw_ptr_error``. + +Tracepoints for processing of PCM hardware parameters +----------------------------------------------------- + +This category includes two tracepoints; ``hw_mask_param`` and +``hw_interval_param``. + +In a design of ALSA PCM core, data transmission is abstracted as PCM substream. +Applications manage PCM substream to maintain data transmission for PCM frames. +Before starting the data transmission, applications need to configure PCM +substream. In this procedure, PCM hardware parameters are decided by +interaction between applications and ALSA PCM core. Once decided, runtime of +the PCM substream keeps the parameters. + +The parameters are described in :c:type:`struct snd_pcm_hw_params`. This +structure includes several types of parameters. Applications set preferable +value to these parameters, then execute ioctl(2) with SNDRV_PCM_IOCTL_HW_REFINE +or SNDRV_PCM_IOCTL_HW_PARAMS. The former is used just for refining available +set of parameters. The latter is used for an actual decision of the parameters. + +The :c:type:`struct snd_pcm_hw_params` structure has below members: + +``flags`` + Configurable. ALSA PCM core and some drivers handle this flag to select + convenient parameters or change their behaviour. +``masks`` + Configurable. This type of parameter is described in + :c:type:`struct snd_mask` and represent mask values. As of PCM protocol + v2.0.13, three types are defined. + + - SNDRV_PCM_HW_PARAM_ACCESS + - SNDRV_PCM_HW_PARAM_FORMAT + - SNDRV_PCM_HW_PARAM_SUBFORMAT +``intervals`` + Configurable. This type of parameter is described in + :c:type:`struct snd_interval` and represent values with a range. As of + PCM protocol v2.0.13, twelve types are defined. + + - SNDRV_PCM_HW_PARAM_SAMPLE_BITS + - SNDRV_PCM_HW_PARAM_FRAME_BITS + - SNDRV_PCM_HW_PARAM_CHANNELS + - SNDRV_PCM_HW_PARAM_RATE + - SNDRV_PCM_HW_PARAM_PERIOD_TIME + - SNDRV_PCM_HW_PARAM_PERIOD_SIZE + - SNDRV_PCM_HW_PARAM_PERIOD_BYTES + - SNDRV_PCM_HW_PARAM_PERIODS + - SNDRV_PCM_HW_PARAM_BUFFER_TIME + - SNDRV_PCM_HW_PARAM_BUFFER_SIZE + - SNDRV_PCM_HW_PARAM_BUFFER_BYTES + - SNDRV_PCM_HW_PARAM_TICK_TIME +``rmask`` + Configurable. This is evaluated at ioctl(2) with + SNDRV_PCM_IOCTL_HW_REFINE only. Applications can select which + mask/interval parameter can be changed by ALSA PCM core. For + SNDRV_PCM_IOCTL_HW_PARAMS, this mask is ignored and all of parameters + are going to be changed. +``cmask`` + Read-only. After returning from ioctl(2), buffer in user space for + :c:type:`struct snd_pcm_hw_params` includes result of each operation. + This mask represents which mask/interval parameter is actually changed. +``info`` + Read-only. This represents hardware/driver capabilities as bit flags + with SNDRV_PCM_INFO_XXX. Typically, applications execute ioctl(2) with + SNDRV_PCM_IOCTL_HW_REFINE to retrieve this flag, then decide candidates + of parameters and execute ioctl(2) with SNDRV_PCM_IOCTL_HW_PARAMS to + configure PCM substream. +``msbits`` + Read-only. This value represents available bit width in MSB side of + a PCM sample. When a parameter of SNDRV_PCM_HW_PARAM_SAMPLE_BITS was + decided as a fixed number, this value is also calculated according to + it. Else, zero. But this behaviour depends on implementations in driver + side. +``rate_num`` + Read-only. This value represents numerator of sampling rate in fraction + notation. Basically, when a parameter of SNDRV_PCM_HW_PARAM_RATE was + decided as a single value, this value is also calculated according to + it. Else, zero. But this behaviour depends on implementations in driver + side. +``rate_den`` + Read-only. This value represents denominator of sampling rate in + fraction notation. Basically, when a parameter of + SNDRV_PCM_HW_PARAM_RATE was decided as a single value, this value is + also calculated according to it. Else, zero. But this behaviour depends + on implementations in driver side. +``fifo_size`` + Read-only. This value represents the size of FIFO in serial sound + interface of hardware. Basically, each driver can assigns a proper + value to this parameter but some drivers intentionally set zero with + a care of hardware design or data transmission protocol. + +ALSA PCM core handles buffer of :c:type:`struct snd_pcm_hw_params` when +applications execute ioctl(2) with SNDRV_PCM_HW_REFINE or SNDRV_PCM_HW_PARAMS. +Parameters in the buffer are changed according to +:c:type:`struct snd_pcm_hardware` and rules of constraints in the runtime. The +structure describes capabilities of handled hardware. The rules describes +dependencies on which a parameter is decided according to several parameters. +A rule has a callback function, and drivers can register arbitrary functions +to compute the target parameter. ALSA PCM core registers some rules to the +runtime as a default. + +Each driver can join in the interaction as long as it prepared for two stuffs +in a callback of :c:type:`struct snd_pcm_ops.open`. + +1. In the callback, drivers are expected to change a member of + :c:type:`struct snd_pcm_hardware` type in the runtime, according to + capacities of corresponding hardware. +2. In the same callback, drivers are also expected to register additional rules + of constraints into the runtime when several parameters have dependencies + due to hardware design. + +The driver can refers to result of the interaction in a callback of +:c:type:`struct snd_pcm_ops.hw_params`, however it should not change the +content. + +Tracepoints in this category are designed to trace changes of the +mask/interval parameters. When ALSA PCM core changes them, ``hw_mask_param`` or +``hw_interval_param`` event is probed according to type of the changed parameter. + +ALSA PCM core also has a pretty print format for each of the tracepoints. Below +is an example for ``hw_mask_param``. + +:: + + hw_mask_param: pcmC0D0p 001/023 FORMAT 00000000000000000000001000000044 00000000000000000000001000000044 + + +Below is an example for ``hw_interval_param``. + +:: + + hw_interval_param: pcmC0D0p 000/023 BUFFER_SIZE 0 0 [0 4294967295] 0 1 [0 4294967295] + +The first three fields are common. They represent name of ALSA PCM character +device, rules of constraint and name of the changed parameter, in order. The +field for rules of constraint consists of two sub-fields; index of applied rule +and total number of rules added to the runtime. As an exception, the index 000 +means that the parameter is changed by ALSA PCM core, regardless of the rules. + +The rest of field represent state of the parameter before/after changing. These +fields are different according to type of the parameter. For parameters of mask +type, the fields represent hexadecimal dump of content of the parameter. For +parameters of interval type, the fields represent values of each member of +``empty``, ``integer``, ``openmin``, ``min``, ``max``, ``openmax`` in +:c:type:`struct snd_interval` in this order. + +Tracepoints in drivers +====================== + +Some drivers have tracepoints for developers' convenience. For them, please +refer to each documentation or implementation. -- 2.11.0

2 1

[alsa-devel] [PATCH] ALSA: atmel: ac97c: fix error return code in atmel_ac97c_probe()
by Gustavo A. R. Silva 01 Jul '17

01 Jul '17

platform_get_irq() returns an error code, but the ac97c driver ignores it and always returns -ENXIO. This is not correct, and prevents -EPROBE_DEFER from being propagated properly. Notice that platform_get_irq() no longer returns 0 on error. Print and propagate the return value of platform_get_irq on failure. Signed-off-by: Gustavo A. R. Silva <garsilva(a)embeddedor.com> --- sound/atmel/ac97c.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/sound/atmel/ac97c.c b/sound/atmel/ac97c.c index 65e6948..9d2c9d9 100644 --- a/sound/atmel/ac97c.c +++ b/sound/atmel/ac97c.c @@ -774,8 +774,8 @@ static int atmel_ac97c_probe(struct platform_device *pdev) irq = platform_get_irq(pdev, 0); if (irq < 0) { - dev_dbg(&pdev->dev, "could not get irq\n"); - return -ENXIO; + dev_dbg(&pdev->dev, "could not get irq: %d\n", irq); + return irq; } pclk = clk_get(&pdev->dev, "ac97_clk"); -- 2.5.0

2 1