December 2016 - Alsa-devel - mailman.alsa-project.org

[alsa-devel] [PATCH 1/2] ASoC: zte: spdif and i2s drivers are not zx296702 specific
by Shawn Guo 08 Dec '16

08 Dec '16

From: Shawn Guo <shawn.guo(a)linaro.org> ZTE ZX SPDIF and I2S drivers can work on not only ZX296702 but also other ZTE ZX family SoCs like ZX296718, which is an arm64 platform. Let's make a few renaming and tweak the Kconfig a bit to get the drivers available for other ZTE ZX platforms. Signed-off-by: Shawn Guo <shawn.guo(a)linaro.org> --- sound/soc/zte/Kconfig | 16 ++++++++-------- sound/soc/zte/Makefile | 4 ++-- sound/soc/zte/{zx296702-i2s.c => zx-i2s.c} | 0 sound/soc/zte/{zx296702-spdif.c => zx-spdif.c} | 0 4 files changed, 10 insertions(+), 10 deletions(-) rename sound/soc/zte/{zx296702-i2s.c => zx-i2s.c} (100%) rename sound/soc/zte/{zx296702-spdif.c => zx-spdif.c} (100%) diff --git a/sound/soc/zte/Kconfig b/sound/soc/zte/Kconfig index c47eb25e441f..6d8a90d36315 100644 --- a/sound/soc/zte/Kconfig +++ b/sound/soc/zte/Kconfig @@ -1,17 +1,17 @@ -config ZX296702_SPDIF - tristate "ZX296702 spdif" - depends on SOC_ZX296702 || COMPILE_TEST +config ZX_SPDIF + tristate "ZTE ZX SPDIF Driver Support" + depends on ARCH_ZX || COMPILE_TEST depends on COMMON_CLK select SND_SOC_GENERIC_DMAENGINE_PCM help Say Y or M if you want to add support for codecs attached to the - zx296702 spdif interface + ZTE ZX SPDIF interface -config ZX296702_I2S - tristate "ZX296702 i2s" - depends on SOC_ZX296702 || COMPILE_TEST +config ZX_I2S + tristate "ZTE ZX I2S Driver Support" + depends on ARCH_ZX || COMPILE_TEST depends on COMMON_CLK select SND_SOC_GENERIC_DMAENGINE_PCM help Say Y or M if you want to add support for codecs attached to the - zx296702 i2s interface + ZTE ZX I2S interface diff --git a/sound/soc/zte/Makefile b/sound/soc/zte/Makefile index 254ed2c8c1a0..77768f5fd10c 100644 --- a/sound/soc/zte/Makefile +++ b/sound/soc/zte/Makefile @@ -1,2 +1,2 @@ -obj-$(CONFIG_ZX296702_SPDIF) += zx296702-spdif.o -obj-$(CONFIG_ZX296702_I2S) += zx296702-i2s.o +obj-$(CONFIG_ZX_SPDIF) += zx-spdif.o +obj-$(CONFIG_ZX_I2S) += zx-i2s.o diff --git a/sound/soc/zte/zx296702-i2s.c b/sound/soc/zte/zx-i2s.c similarity index 100% rename from sound/soc/zte/zx296702-i2s.c rename to sound/soc/zte/zx-i2s.c diff --git a/sound/soc/zte/zx296702-spdif.c b/sound/soc/zte/zx-spdif.c similarity index 100% rename from sound/soc/zte/zx296702-spdif.c rename to sound/soc/zte/zx-spdif.c -- 1.9.1

3 5

[alsa-devel] [PATCH] ASoC: Intel: Skylake: remove unused 'out_fmt' variable
by Kirtika Ruchandani 08 Dec '16

08 Dec '16

Commit 4cd9899f0d16 introduced struct skl_module_fmt* out_fmt without using it. Compiling with W=1 gives the below warning, fix it. sound/soc/intel/skylake/skl-topology.c: In function ‘skl_tplg_update_buffer_size’: sound/soc/intel/skylake/skl-topology.c:301:34: warning: variable ‘out_fmt’ set but not used [-Wunused-but-set-variable] This is a harmless warning and is only being fixed to reduce the noise with W=1 in the kernel. Fixes: 4cd9899f0d16 ("ASoC: Intel: Skylake: Add multiple pin formats") Cc: Hardik T Shah <hardik.t.shah(a)intel.com> Cc: Omair M Abdullah <omair.m.abdullah(a)intel.com> Cc: Jeeja KP <jeeja.kp(a)intel.com> Cc: Subhransu S. Prusty <subhransu.s.prusty(a)intel.com> Cc: Vinod Koul <vinod.koul(a)intel.com> Cc: Mark Brown <broonie(a)kernel.org> Signed-off-by: Kirtika Ruchandani <kirtika(a)chromium.org> --- sound/soc/intel/skylake/skl-topology.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/sound/soc/intel/skylake/skl-topology.c b/sound/soc/intel/skylake/skl-topology.c index bd313c9..4352236a 100644 --- a/sound/soc/intel/skylake/skl-topology.c +++ b/sound/soc/intel/skylake/skl-topology.c @@ -298,7 +298,7 @@ static void skl_tplg_update_buffer_size(struct skl_sst *ctx, struct skl_module_cfg *mcfg) { int multiplier = 1; - struct skl_module_fmt *in_fmt, *out_fmt; + struct skl_module_fmt *in_fmt; int in_rate, out_rate; @@ -306,7 +306,6 @@ static void skl_tplg_update_buffer_size(struct skl_sst *ctx, * change for pin 0 only */ in_fmt = &mcfg->in_fmt[0]; - out_fmt = &mcfg->out_fmt[0]; if (mcfg->m_type == SKL_MODULE_TYPE_SRCINT) multiplier = 5; -- 2.8.0.rc3.226.g39d4020

3 3

[alsa-devel] [PATCH] ASoC: Intel: Skylake: remove unused 'runtime' variable
by Kirtika Ruchandani 08 Dec '16

08 Dec '16

skl_platform_open() defines and sets 'struct snd_pcm_runtime* runtime' but does not use it. Compiling with W=1 gives the following warning, fix it. sound/soc/intel/skylake/skl-pcm.c: In function ‘skl_platform_open’: sound/soc/intel/skylake/skl-pcm.c:941:26: warning: variable ‘runtime’ set but not used [-Wunused-but-set-variable] This was introduced with the initial driver commit a40e693c7f5e ("ASoC: Intel: Add Skylake HDA platform driver"). This is a harmless warning and is only being fixed to reduce the noise with W=1 in the kernel. Fixes: a40e693c7f5e ("ASoC: Intel: Add Skylake HDA platform driver") Cc: Jeeja KP <jeeja.kp(a)intel.com> Cc: Subhransu S. Prusty <subhransu.s.prusty(a)intel.com> Cc: Vinod Koul <vinod.koul(a)intel.com> Cc: Mark Brown <broonie(a)kernel.org> Signed-off-by: Kirtika Ruchandani <kirtika(a)chromium.org> --- sound/soc/intel/skylake/skl-pcm.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/sound/soc/intel/skylake/skl-pcm.c b/sound/soc/intel/skylake/skl-pcm.c index 84b5101..3254507 100644 --- a/sound/soc/intel/skylake/skl-pcm.c +++ b/sound/soc/intel/skylake/skl-pcm.c @@ -938,14 +938,12 @@ static struct snd_soc_dai_driver skl_platform_dai[] = { static int skl_platform_open(struct snd_pcm_substream *substream) { - struct snd_pcm_runtime *runtime; struct snd_soc_pcm_runtime *rtd = substream->private_data; struct snd_soc_dai_link *dai_link = rtd->dai_link; dev_dbg(rtd->cpu_dai->dev, "In %s:%s\n", __func__, dai_link->cpu_dai_name); - runtime = substream->runtime; snd_soc_set_runtime_hwparams(substream, &azx_pcm_hw); return 0; -- 2.8.0.rc3.226.g39d4020

2 1

[alsa-devel] [PATCH v5 00/14] ASoC: add OF graph base simple-card
by Kuninori Morimoto 08 Dec '16

08 Dec '16

Hi Rob, Mark These are v5 of OF graph base simple-card patch-set. I removed new "type" property on v4 patch-set, but I noticed that it is necessary for ALSA SoC binding purpose. Thus, this v5 has it again. For example HDMI case, its DT will has video and sound ports. This DT will be used from HDMI Video driver and HDMI sound driver. HDMI video side can handle all somehow, because it is fully under its control. HDMI sound side will just references it. But it can't know total Video/Sound ports number which is necessary for ALSA SoC side. For example, if HDMI video had 4 ports, sound had 2 ports, this case, HDMI sound ports will be port@4, port@5. Here, ALSA SoC side needs to know total 2 sound port, and, it should be handled as 1st / 2nd port. It is impossible without "type" property. 1) - 7) : OF graph new feature 8) - 14) : OF graph base simple-card Kuninori Morimoto (14): 1) Documentation: of: add type property 2) of_graph: add of_graph_get_remote_endpoint() 3) of_graph: add of_graph_port_type_is() 4) of_graph: add of_graph_get_port_parent() 5) of_graph: add of_graph_get_top_port() 6) of_graph: add for_each_of_port() / for_each_of_endpoint_in_port() 7) of_graph: add of_graph_get_endpoint_count() 8) ASoC: simple-card-utils: adjust for graph on asoc_simple_card_parse_card_name 9) ASoC: simple-card-utils: add asoc_simple_card_parse_graph_dai() 10) ASoC: simple-card-utils: add asoc_simple_card_try_to_probe_graph_card() 11) ASoC: add simple-graph-card document 12) ASoC: add simple-graph-card support 13) ASoC: add simple-graph-scu-card document 14) ASoC: add simple-graph-scu-card support Documentation/devicetree/bindings/graph.txt | 21 + .../bindings/sound/simple-graph-card.txt | 67 +++ .../bindings/sound/simple-graph-scu-card.txt | 69 +++ drivers/of/base.c | 166 +++++++- include/linux/of_graph.h | 67 +++ include/sound/simple_card_utils.h | 13 + sound/soc/generic/Kconfig | 15 + sound/soc/generic/Makefile | 4 + sound/soc/generic/simple-card-utils.c | 98 ++++- sound/soc/generic/simple-card.c | 2 +- sound/soc/generic/simple-graph-card.c | 461 +++++++++++++++++++++ sound/soc/generic/simple-graph-scu-card.c | 441 ++++++++++++++++++++ sound/soc/generic/simple-scu-card.c | 2 +- 13 files changed, 1413 insertions(+), 13 deletions(-) create mode 100644 Documentation/devicetree/bindings/sound/simple-graph-card.txt create mode 100644 Documentation/devicetree/bindings/sound/simple-graph-scu-card.txt create mode 100644 sound/soc/generic/simple-graph-card.c create mode 100644 sound/soc/generic/simple-graph-scu-card.c -- 1.9.1

3 30

[alsa-devel] [PATCH v4 0/2] ALSA controls management using index/device/sub-devices fields
by Arnaud Pouliquen 07 Dec '16

07 Dec '16

Previous discussions summary: - Topic of the patchset: Patch concerns ASoc DAI drivers. Aim is to be able to instantiate PCM control using device field according to the associated PCM char device. For this, a relationship between DAIs PCM control and PCM char device needs to be establish. => Proposal is to add field in DAI driver struct to declare PCM controls that need to be linked to PCM character device on DAI link probing. - Limitation of the patchset: This patchset seems only a first step as 2 concerns are been highlighted: - Patch is limited to "static" DAI-link. This not responds to backend (no_pcm dai links) and some none-DAI codecs, that could register PCm controls. In theses cases it is not possible to establish relationship during probe. => No solution proposed for time beeing. - This patchset does not fix conflict of 2 "identical" PCM controls declared by 2 drivers. For instance, a conflict can exist between a PCM control created in DAI driver and the same control declared in a codec driver. As index field is forced to 0, prefix should be used in codec. => To discuss solution in a separate thread as issue already present without this patchset several approaches seem possible like using index field ( control auto indexation in ASoC) or prefix in Naming. V4: - [PATCH v4 1/2] ASoC: core: allow DAI PCM controls bound to PCM device Fix and rework error management in soc_link_dai_pcm_controls function. - [PATCH v4 2/2] ASoC: sti: bind pcm controls to pcm device. No change since V2. V3: - [PATCH v3 1/2] ASoC: core: allow DAI PCM controls bound to PCM device Code optimization based on Takashi Sakamoto suggestion - [RFC V2 3/3] ASoC: hdmi-codec: Example of PCM control bound to PCM device for multi patch suppressed as it was send as example in previous version. Patch is valid but can have impact on existing drivers as control device field value is updated - [PATCH v3 2/2] ASoC: sti: bind pcm controls to pcm device. No change vs V2 V2: http://www.spinics.net/lists/alsa-devel/msg57045.html Aim of this version is to continue discussion on DAI PCM control focused on ASoC drivers. In this V2 implementation in Soc-core is simplified to limit impact on existing code. Update of the RFC V1 based on discussions: - [RFC 4/4] iecset: allow to select control with device and sub-device numbers no more part of the RFC V2, will be discussed in a separate thread - [RFC 2/4] ALSA: control: increment index field for duplicated control. no more part of the RFC V2, no more need as RFC subject is PCM controls - [RFC V2 1/3] ASoC: core: allow DAI PCM controls bound to PCM device Patch reworked from V1 to simplify implementation - Binding is not done for Dai links tagged with no_pcm (DPCM). - no more possibility to add the controls after the DAI link probing. - [RFC V2 2/3] ASoC: sti: bind PCM controls to PCM device. - [RFC V2 3/3] ASoC: hdmi-codec: Example of PCM control bound to PCM device for multi Example of implementation in STI DAI driver and HDMI-codec drivers V1: http://www.spinics.net/lists/alsa-devel/msg56479.html 1) Alsa-utils patch - iecset: allow to select control with device and sub-device numbers This patch allows to access to 2 iec controls differentiated by device/sub-devices numbers => For me, this patch is mandatory to be able to address the ASoC IEC controls, in case of no fix is implemented to allows index field update in ASoC. 2) Alsa driver patches - ASoC: core: allow PCM control binding to PCM device Add relationship between DAIs PCM controls and PCM device. - ALSA: control: increment index field for duplicated control. Generic implementation of the patch proposed in HDA driver (http://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/commit/?id=ea9b…) - ASoC: sti: use bind_pcm_ctl implementation of bind_pcm_ctl for sti driver. Arnaud Pouliquen (2): ASoC: core: allow DAI PCM controls bound to PCM device ASoC: sti: bind pcm controls to pcm device. include/sound/soc-dai.h | 4 ++++ sound/soc/soc-core.c | 35 +++++++++++++++++++++++++++++++++++ sound/soc/sti/sti_uniperif.c | 33 ++++----------------------------- 3 files changed, 43 insertions(+), 29 deletions(-) -- 1.9.1

3 5

[alsa-devel] [PATCH] speaker-test: Fix chmap wav file selection.
by Arnaud Pouliquen 07 Dec '16

07 Dec '16

The channel selection currently does not work properly when a channel map control is provided but no manual channel map was explicitly requested with "-m". For example, the CEA/HDMI 6ch (surround 5.1) map is: FL, FR, LFE, FC, RL, RR. Tested command: speaker-test -D hdmi -c 6 -t wav Speaker-test tries to play channels in this following order: 0 - Front Left 3 - Front Center 1 - Front Right 5 - Rear Right 4 - Rear Left 2 - LFE But wav file played on associated speakers are not aligned. Here are the real files played: 0- /usr/share/sounds/alsa/Front_Left.wav => OK 3- /usr/share/sounds/alsa/Rear_Right.wav => OK 1- /usr/share/sounds/alsa/Front_Right.wav => OK 5- /usr/share/sounds/alsa/Rear_Center.wav => KO 4- found file /usr/share/sounds/alsa/Front_Center.wav => KO 2- /usr/share/sounds/alsa/Rear_Left.wav => KO Issue is that associated wav files ordering is reworked only if channel_map_set variable is set. Fix consists in allowing wavs re-ordering if a channel mapping as been get or set, i.e. channel_map is not null. Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen(a)st.com> --- speaker-test/speaker-test.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/speaker-test/speaker-test.c b/speaker-test/speaker-test.c index 5b9cbec..46b0589 100644 --- a/speaker-test/speaker-test.c +++ b/speaker-test/speaker-test.c @@ -843,7 +843,7 @@ static int setup_wav_file(int chn) return check_wav_file(chn, given_test_wav_file); #ifdef CONFIG_SUPPORT_CHMAP - if (channel_map_set && chn < channel_map->channels) { + if (channel_map && chn < channel_map->channels) { int channel = channel_map->pos[chn] - SND_CHMAP_FL; if (channel >= 0 && channel < MAX_CHANNELS) return check_wav_file(chn, wavs[channel]); -- 1.9.1

2 1

[alsa-devel] [PATCH] ASoC: rsnd: tidyup ssi->usrcnt counter check in hw_params
by Kuninori Morimoto 07 Dec '16

07 Dec '16

From: Kuninori Morimoto <kuninori.morimoto.gx(a)renesas.com> ssi->usrcnt will be updated on snd_soc_dai_ops::trigger, but snd_pcm_ops::hw_params will be called *before* it. Thus, ssi->usrcnt is still 0 when 1st call. rsnd_ssi_hw_params() needs to check its called count, this means trigger should be if (ssi->usrcnt) instead of if (ssi->usrcnt > 1). Reported-by: Nguyen Viet Dung <nv-dung(a)jinso.co.jp> Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx(a)renesas.com> --- sound/soc/sh/rcar/ssi.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/sound/soc/sh/rcar/ssi.c b/sound/soc/sh/rcar/ssi.c index 932047a..dcb3d0a 100644 --- a/sound/soc/sh/rcar/ssi.c +++ b/sound/soc/sh/rcar/ssi.c @@ -433,11 +433,14 @@ static int rsnd_ssi_hw_params(struct rsnd_mod *mod, int chan = params_channels(params); /* - * Already working. - * It will happen if SSI has parent/child connection. + * snd_pcm_ops::hw_params will be called *before* + * snd_soc_dai_ops::trigger. Thus, ssi->usrcnt is 0 + * in 1st call. */ - if (ssi->usrcnt > 1) { + if (ssi->usrcnt) { /* + * Already working. + * It will happen if SSI has parent/child connection. * it is error if child <-> parent SSI uses * different channels. */ -- 1.9.1

2 1

[alsa-devel] [PATCH 0/2] ASoC: rsnd: fixup Suspend/Resume clock issue
by Kuninori Morimoto 07 Dec '16

07 Dec '16

Hi Mark These patches fixup Renesas sound's clock stopping issue when Suspend/Resume. These are tested on R-Car Gen3 Salvator-X board Kuninori Morimoto (2): ASoC: rsnd: setup BRGCKR/BRRA/BRRB when starting ASoC: rsnd: enable/disable ADG when suspend/resume timing sound/soc/sh/rcar/adg.c | 59 +++++++++++++++++++++++++++++------------------- sound/soc/sh/rcar/core.c | 24 ++++++++++++++++++++ sound/soc/sh/rcar/rsnd.h | 3 +++ 3 files changed, 63 insertions(+), 23 deletions(-) -- 2.7.4

2 4

[alsa-devel] Cherry trail and Nau 88l24 codec
by Joseph Wang 07 Dec '16

07 Dec '16

Hi all, I've been trying to get sound working on my W9S pipo device. The people at Nuvoton have been extraordinarily helpful, but now the issue is writing the machine driver. My work is at https://github.com/joequant/nau8824 I've gotten the drivers to load, but getting timeouts with the firmware.... [ 102.447840] intel_sst_acpi 808622A8:00: Wait timed-out condition:0x0, msg_id:0x2 fw_state 0x3 [ 102.447872] intel_sst_acpi 808622A8:00: fw returned err -16 [ 103.471448] intel_sst_acpi 808622A8:00: Wait timed-out condition:0x0, msg_id:0x2 fw_state 0x3 and then [ 116.820782] intel_sst_acpi 808622A8:00: fw returned err -16 [ 116.938921] intel_sst_acpi 808622A8:00: FW sent error response 0x5000e [ 116.939065] intel_sst_acpi 808622A8:00: FW sent error response 0x5000e [ 116.939579] intel_sst_acpi 808622A8:00: FW sent async error msg: [ 116.939614] (null)00040021 00000000 [ 116.939685] (null)00040021 00000000 [ 116.953260] sst-mfld-platform sst-mfld-platform: Enter: enable=1 port_name=ssp2-port [ 116.953704] intel_sst_acpi 808622A8:00: Alloc for str 3 pipe 0xe [ 116.954062] sst-mfld-sst-mfld-platform: SET_SWM cmd max inputs reached One other path is that ICube has gotten this codec to work on their iwork8 Ultimate android device. They are required to release the source under GPL2, but haven't done so, so if all else fails, it will be a matter of tracking down someone in that company and explaining the issues to them. Since I'm in Hong Kong, I might just find where the things are manufactured, and just show up at their office. But it appears that there are some "magic bits" that are missing. One question that I have is what is the proper DAI to use (i.e. PCM or I2S) for cherry trail. The second question is that looking at the windows driver for nau88l24, there appears to be a test mode that runs the driver against a Realtek rt5645. Should I assume that this means that the initialization is similar? Also I'm quite interested in getting this to work. The W9S Pipo is a perfect netbook that has a big screen that is half the weight of my old laptop. The big thing is that someone realized that instead of putting in a SATA hard disk, that they can use an SD card as main storage, and that cuts down on the weight.

3 10

[alsa-devel] [patch] ALSA: cs46xx: add a new line
by Dan Carpenter 07 Dec '16

07 Dec '16

We accidentally deleted a newline so now the "nreallocated++;" statement is hanging out way off to the right of the screen. Signed-off-by: Dan Carpenter <dan.carpenter(a)oracle.com> diff --git a/sound/pci/cs46xx/dsp_spos.c b/sound/pci/cs46xx/dsp_spos.c index 4a0cbd2241d8..aa61615288ff 100644 --- a/sound/pci/cs46xx/dsp_spos.c +++ b/sound/pci/cs46xx/dsp_spos.c @@ -107,7 +107,8 @@ static int shadow_and_reallocate_code (struct snd_cs46xx * chip, u32 * data, u32 dev_dbg(chip->card->dev, "handle_wideop:[2] %05x:%05x addr %04x\n", - hival, loval, address); nreallocated++; + hival, loval, address); + nreallocated++; } /* wide_opcodes[j] == wide_op */ } /* for */ } /* mod_type == 0 ... */

2 1