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

[alsa-devel] [PATCH 0/2] Relax bitclk computation when using PLL
by Daniel Baluta 25 Apr '17

25 Apr '17

Using strict bitclk requirements we cannot support all promised rates and formats. For this reason we relax bitclk computation by choosing the best available bitclk. First patch in the series is based on Arnd's patch: http://mailman.alsa-project.org/pipermail/alsa-devel/2017-April/119899.html Second one does the actual bitclk relaxation. Daniel Baluta (2): ASoC: codec: wm9860: avoid maybe-uninitialized warning ASoC: codec: wm8960: Relax bit clock computation when using PLL sound/soc/codecs/wm8960.c | 29 ++++++++++++++++++++--------- 1 file changed, 20 insertions(+), 9 deletions(-) -- 2.7.4

3 7

[alsa-devel] PM issue with Intel SST Atom driver
by Takashi Iwai 25 Apr '17

25 Apr '17

Hi, I noticed that the unstable PM behavior on my Cherrytrail laptop actually comes from the sound driver. First off, the atom/sst/sst.c has the following suspend code: static int intel_sst_suspend(struct device *dev) { .... /* * check if any stream is active and running * they should already by suspend by soc_suspend */ for (i = 1; i <= ctx->info.max_streams; i++) { struct stream_info *stream = &ctx->streams[i]; if (stream->status == STREAM_RUNNING) { dev_err(dev, "stream %d is running, can't suspend, abort\n", i); return -EBUSY; } } This doesn't look good, and I actually hit this when I tried to suspend while playing something. In general, the driver shouldn't reject at this point, because this is the PM suspend callback, i.e. the user wants to suspend the device inevitably. The driver should return an error only when it faces to a fatal error. But I wondered why this happened at all, and noticed that the machine driver (in my case bytcr_rt5640) has no its own PM ops. But hooking the snd_soc_pm_ops there seems causing a hang up at suspend by some reason. Maybe this wasn't a big problem until now since the BYT/CHT didn't support the suspend/resume properly in the past. But now PM suspend is supported on these devices, so the problem surfaced more often. Could you guys check the status of these drivers? thanks, Takashi

3 15

[alsa-devel] [PATCH] ASoC: intel: Fix PM and non-atomic crash in bytcr drivers
by Takashi Iwai 25 Apr '17

25 Apr '17

The FE setups of Intel SST bytcr_rt5640 and bytcr_rt5651 drivers carry the ignore_suspend flag, and this prevents the suspend/resume working properly while the stream is running, since SST core code has the check of the running streams and returns -EBUSY. Drop these superfluous flags for fixing the behavior. Also, the bytcr_rt5640 driver lacks of nonatomic flag in some FE definitions, which leads to the kernel Oops at suspend/resume like: BUG: scheduling while atomic: systemd-sleep/3144/0x00000003 Call Trace: dump_stack+0x5c/0x7a __schedule_bug+0x55/0x70 __schedule+0x63c/0x8c0 schedule+0x3d/0x90 schedule_timeout+0x16b/0x320 ? del_timer_sync+0x50/0x50 ? sst_wait_timeout+0xa9/0x170 [snd_intel_sst_core] ? sst_wait_timeout+0xa9/0x170 [snd_intel_sst_core] ? remove_wait_queue+0x60/0x60 ? sst_prepare_and_post_msg+0x275/0x960 [snd_intel_sst_core] ? sst_pause_stream+0x9b/0x110 [snd_intel_sst_core] .... This patch addresses these appropriately, too. Cc: <stable(a)vger.kernel.org> # v4.1+ Signed-off-by: Takashi Iwai <tiwai(a)suse.de> --- sound/soc/intel/boards/bytcr_rt5640.c | 4 ++-- sound/soc/intel/boards/bytcr_rt5651.c | 2 -- 2 files changed, 2 insertions(+), 4 deletions(-) diff --git a/sound/soc/intel/boards/bytcr_rt5640.c b/sound/soc/intel/boards/bytcr_rt5640.c index 5c7219fb3aa8..9e2a3404a836 100644 --- a/sound/soc/intel/boards/bytcr_rt5640.c +++ b/sound/soc/intel/boards/bytcr_rt5640.c @@ -621,7 +621,7 @@ static struct snd_soc_dai_link byt_rt5640_dais[] = { .codec_dai_name = "snd-soc-dummy-dai", .codec_name = "snd-soc-dummy", .platform_name = "sst-mfld-platform", - .ignore_suspend = 1, + .nonatomic = true, .dynamic = 1, .dpcm_playback = 1, .dpcm_capture = 1, @@ -634,7 +634,6 @@ static struct snd_soc_dai_link byt_rt5640_dais[] = { .codec_dai_name = "snd-soc-dummy-dai", .codec_name = "snd-soc-dummy", .platform_name = "sst-mfld-platform", - .ignore_suspend = 1, .nonatomic = true, .dynamic = 1, .dpcm_playback = 1, @@ -661,6 +660,7 @@ static struct snd_soc_dai_link byt_rt5640_dais[] = { | SND_SOC_DAIFMT_CBS_CFS, .be_hw_params_fixup = byt_rt5640_codec_fixup, .ignore_suspend = 1, + .nonatomic = true, .dpcm_playback = 1, .dpcm_capture = 1, .init = byt_rt5640_init, diff --git a/sound/soc/intel/boards/bytcr_rt5651.c b/sound/soc/intel/boards/bytcr_rt5651.c index 3186f015939f..8164bec63bf1 100644 --- a/sound/soc/intel/boards/bytcr_rt5651.c +++ b/sound/soc/intel/boards/bytcr_rt5651.c @@ -235,7 +235,6 @@ static struct snd_soc_dai_link byt_rt5651_dais[] = { .codec_dai_name = "snd-soc-dummy-dai", .codec_name = "snd-soc-dummy", .platform_name = "sst-mfld-platform", - .ignore_suspend = 1, .nonatomic = true, .dynamic = 1, .dpcm_playback = 1, @@ -249,7 +248,6 @@ static struct snd_soc_dai_link byt_rt5651_dais[] = { .codec_dai_name = "snd-soc-dummy-dai", .codec_name = "snd-soc-dummy", .platform_name = "sst-mfld-platform", - .ignore_suspend = 1, .nonatomic = true, .dynamic = 1, .dpcm_playback = 1, -- 2.11.1

4 6

[alsa-devel] [PATCH v2] ASoC: imx-wm8962: Remove global variables
by Fabio Estevam 24 Apr '17

24 Apr '17

From: Fabio Estevam <fabio.estevam(a)nxp.com> Currently the following variables are global: - card_priv, sample_rate and sample_format ,which is not a good idea as it prevents the usage of multiple instances. Make sample_rate and sample_format part of the imx_priv structure and allocate imx_priv via the standard devm_kzalloc() mechanism inside the probe function. Signed-off-by: Fabio Estevam <fabio.estevam(a)nxp.com> --- Changes since v1: - Keep the original variable types for sample_rate and sample_format. sound/soc/fsl/imx-wm8962.c | 31 +++++++++++++++++++------------ 1 file changed, 19 insertions(+), 12 deletions(-) diff --git a/sound/soc/fsl/imx-wm8962.c b/sound/soc/fsl/imx-wm8962.c index 52659fa..206b898 100644 --- a/sound/soc/fsl/imx-wm8962.c +++ b/sound/soc/fsl/imx-wm8962.c @@ -38,8 +38,9 @@ struct imx_wm8962_data { struct imx_priv { struct platform_device *pdev; + int sample_rate; + snd_pcm_format_t sample_format; }; -static struct imx_priv card_priv; static const struct snd_soc_dapm_widget imx_wm8962_dapm_widgets[] = { SND_SOC_DAPM_HP("Headphone Jack", NULL), @@ -48,14 +49,14 @@ static const struct snd_soc_dapm_widget imx_wm8962_dapm_widgets[] = { SND_SOC_DAPM_MIC("DMIC", NULL), }; -static int sample_rate = 44100; -static snd_pcm_format_t sample_format = SNDRV_PCM_FORMAT_S16_LE; - static int imx_hifi_hw_params(struct snd_pcm_substream *substream, struct snd_pcm_hw_params *params) { - sample_rate = params_rate(params); - sample_format = params_format(params); + struct snd_soc_pcm_runtime *rtd = substream->private_data; + struct imx_priv *priv = snd_soc_card_get_drvdata(rtd->card); + + priv->sample_rate = params_rate(params); + priv->sample_format = params_format(params); return 0; } @@ -70,7 +71,7 @@ static int imx_wm8962_set_bias_level(struct snd_soc_card *card, { struct snd_soc_pcm_runtime *rtd; struct snd_soc_dai *codec_dai; - struct imx_priv *priv = &card_priv; + struct imx_priv *priv = snd_soc_card_get_drvdata(card); struct imx_wm8962_data *data = snd_soc_card_get_drvdata(card); struct device *dev = &priv->pdev->dev; unsigned int pll_out; @@ -84,10 +85,10 @@ static int imx_wm8962_set_bias_level(struct snd_soc_card *card, switch (level) { case SND_SOC_BIAS_PREPARE: if (dapm->bias_level == SND_SOC_BIAS_STANDBY) { - if (sample_format == SNDRV_PCM_FORMAT_S24_LE) - pll_out = sample_rate * 384; + if (priv->sample_format == SNDRV_PCM_FORMAT_S24_LE) + pll_out = priv->sample_rate * 384; else - pll_out = sample_rate * 256; + pll_out = priv->sample_rate * 256; ret = snd_soc_dai_set_pll(codec_dai, WM8962_FLL, WM8962_FLL_MCLK, data->clk_frequency, @@ -139,7 +140,7 @@ static int imx_wm8962_late_probe(struct snd_soc_card *card) { struct snd_soc_pcm_runtime *rtd; struct snd_soc_dai *codec_dai; - struct imx_priv *priv = &card_priv; + struct imx_priv *priv = snd_soc_card_get_drvdata(card); struct imx_wm8962_data *data = snd_soc_card_get_drvdata(card); struct device *dev = &priv->pdev->dev; int ret; @@ -159,14 +160,20 @@ static int imx_wm8962_probe(struct platform_device *pdev) struct device_node *np = pdev->dev.of_node; struct device_node *ssi_np, *codec_np; struct platform_device *ssi_pdev; - struct imx_priv *priv = &card_priv; struct i2c_client *codec_dev; struct imx_wm8962_data *data; + struct imx_priv *priv; struct clk *codec_clk; int int_port, ext_port; int ret; + priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL); + if (!priv) + return -ENOMEM; + priv->pdev = pdev; + priv->sample_rate = 44100; + priv->sample_format = SNDRV_PCM_FORMAT_S16_LE; ret = of_property_read_u32(np, "mux-int-port", &int_port); if (ret) { -- 2.7.4

2 1

[alsa-devel] [PATCH 1/2] ASoC: Provide a dummy wrapper of snd_soc_set_dmi_name()
by Takashi Iwai 24 Apr '17

24 Apr '17

For systems without DMI, it makes no sense to have the code. Signed-off-by: Takashi Iwai <tiwai(a)suse.de> --- include/sound/soc.h | 8 ++++++++ sound/soc/soc-core.c | 2 ++ 2 files changed, 10 insertions(+) diff --git a/include/sound/soc.h b/include/sound/soc.h index cdfb55f7aede..915c06cb2b32 100644 --- a/include/sound/soc.h +++ b/include/sound/soc.h @@ -497,7 +497,15 @@ void snd_soc_runtime_deactivate(struct snd_soc_pcm_runtime *rtd, int stream); int snd_soc_runtime_set_dai_fmt(struct snd_soc_pcm_runtime *rtd, unsigned int dai_fmt); +#ifdef CONFIG_DMI int snd_soc_set_dmi_name(struct snd_soc_card *card, const char *flavour); +#else +static inline int snd_soc_set_dmi_name(struct snd_soc_card *card, + const char *flavour) +{ + return 0; +} +#endif /* Utility functions to get clock rates from various things */ int snd_soc_calc_frame_size(int sample_size, int channels, int tdm_slots); diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c index 2722bb0c5573..aac73ff8a92a 100644 --- a/sound/soc/soc-core.c +++ b/sound/soc/soc-core.c @@ -1918,6 +1918,7 @@ int snd_soc_runtime_set_dai_fmt(struct snd_soc_pcm_runtime *rtd, EXPORT_SYMBOL_GPL(snd_soc_runtime_set_dai_fmt); +#ifdef CONFIG_DMI /* Trim special characters, and replace '-' with '_' since '-' is used to * separate different DMI fields in the card long name. Only number and * alphabet characters and a few separator characters are kept. @@ -2049,6 +2050,7 @@ int snd_soc_set_dmi_name(struct snd_soc_card *card, const char *flavour) return 0; } EXPORT_SYMBOL_GPL(snd_soc_set_dmi_name); +#endif /* CONFIG_DMI */ static int snd_soc_instantiate_card(struct snd_soc_card *card) { -- 2.11.1

5 6

[alsa-devel] [PATCH v2 0/2] ASoC: Give prettier longname based on DMI
by Takashi Iwai 24 Apr '17

24 Apr '17

Hi, this is the revised patchset to set the card longname based on DMI so that a unique UCM profile can be picked up. v1->v2: Fix the missnig NULL argument in the function call Takashi === Takashi Iwai (2): ASoC: Provide a dummy wrapper of snd_soc_set_dmi_name() ASoC: Call snd_soc_set_dmi_name() unconditionally include/sound/soc.h | 8 ++++++++ sound/soc/intel/boards/broadwell.c | 3 --- sound/soc/soc-core.c | 5 +++++ 3 files changed, 13 insertions(+), 3 deletions(-) -- 2.11.1

3 4

[alsa-devel] [PATCH v3] ASoC: bytcr_rt5640: Allow quirk set via module option
by Takashi Iwai 24 Apr '17

24 Apr '17

The bytcr-rt5640 driver has a few quirk setups depending on the board, where the quirk value is set by DMI matching. When you have a new device to add the support, you often experience to try the different quirk by trial-and-error. Or, you may have a development model that still has no proper DMI string. In either case, you'd need to compile the driver at each time. This patch introduces a module option to override the quirk value on the fly. User can boot like snd-soc-sst-bytcr-rt5640.quirk=0x4004 to override the default value without recompilation. It's a raw value, so user needs to check the source code for the meaning of each bit. Signed-off-by: Takashi Iwai <tiwai(a)suse.de> --- v1->v2: override the quirk value completely v2->v3: print the override information sound/soc/intel/boards/bytcr_rt5640.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/sound/soc/intel/boards/bytcr_rt5640.c b/sound/soc/intel/boards/bytcr_rt5640.c index 5c7219fb3aa8..0ac32788f216 100644 --- a/sound/soc/intel/boards/bytcr_rt5640.c +++ b/sound/soc/intel/boards/bytcr_rt5640.c @@ -19,6 +19,7 @@ #include <linux/init.h> #include <linux/module.h> +#include <linux/moduleparam.h> #include <linux/platform_device.h> #include <linux/acpi.h> #include <linux/device.h> @@ -58,6 +59,9 @@ struct byt_rt5640_private { }; static unsigned long byt_rt5640_quirk = BYT_RT5640_MCLK_EN; +static unsigned int quirk_override; +module_param_named(quirk, quirk_override, int, 0444); +MODULE_PARM_DESC(quirk, "Board-specific quirk override"); static void log_quirks(struct device *dev) { @@ -806,6 +810,11 @@ static int snd_byt_rt5640_mc_probe(struct platform_device *pdev) /* check quirks before creating card */ dmi_check_system(byt_rt5640_quirk_table); + if (quirk_override) { + dev_info(&pdev->dev, "Overriding quirk %0x => 0x%x\n", + (unsigned int)byt_rt5640_quirk, quirk_override); + byt_rt5640_quirk = quirk_override; + } log_quirks(&pdev->dev); if ((byt_rt5640_quirk & BYT_RT5640_SSP2_AIF2) || -- 2.11.1

3 2

[alsa-devel] [PATCH] ASoC: wm5100: fix spelling mistake: "micropone" -> "microphone"
by Colin King 24 Apr '17

24 Apr '17

From: Colin Ian King <colin.king(a)canonical.com> Trivial fix to spelling mistake in dev_err message Signed-off-by: Colin Ian King <colin.king(a)canonical.com> --- sound/soc/codecs/wm5100.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/soc/codecs/wm5100.c b/sound/soc/codecs/wm5100.c index 560575000cc5..138a84efdd54 100644 --- a/sound/soc/codecs/wm5100.c +++ b/sound/soc/codecs/wm5100.c @@ -2014,7 +2014,7 @@ static void wm5100_micd_irq(struct wm5100_priv *wm5100) ret = regmap_read(wm5100->regmap, WM5100_MIC_DETECT_3, &val); if (ret != 0) { - dev_err(wm5100->dev, "Failed to read micropone status: %d\n", + dev_err(wm5100->dev, "Failed to read microphone status: %d\n", ret); return; } -- 2.11.0

4 3

[alsa-devel] [PATCH] ASoC: fix odd_ptr_err.cocci warnings (fwd)
by Julia Lawall 24 Apr '17

24 Apr '17

I don't think the patch is correct, so I haven't bothered signing off on it. Probably the & is not correct in the IS_ERR call? julia ---------- Forwarded message ---------- Date: Sat, 22 Apr 2017 06:09:26 +0800 From: kbuild test robot <fengguang.wu(a)intel.com> To: kbuild(a)01.org Cc: Julia Lawall <julia.lawall(a)lip6.fr> Subject: [PATCH] ASoC: fix odd_ptr_err.cocci warnings PTR_ERR should access the value just tested by IS_ERR Semantic patch information: There can be false positives in the patch case, where it is the call to IS_ERR that is wrong. Generated by: scripts/coccinelle/tests/odd_ptr_err.cocci CC: Simon Ho <simon.ho(a)conexant.com> Signed-off-by: Fengguang Wu <fengguang.wu(a)intel.com> --- Please take the patch only if it's a positive warning. Thanks! cx2072x.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/sound/soc/codecs/cx2072x.c +++ b/sound/soc/codecs/cx2072x.c @@ -2183,7 +2183,7 @@ static int cx2072x_i2c_probe(struct i2c_ &cx2072x_regmap); if (IS_ERR(&cx2072x->regmap)) { - ret = PTR_ERR(cx2072x->regmap); + ret = PTR_ERR(&cx2072x->regmap); dev_err(&i2c->dev, "Failed to init regmap: %d\n", ret); return ret; }

3 2

[alsa-devel] Status of ALSA firewire stack at Linux v4.12 development period
by Takashi Sakamoto 24 Apr '17

24 Apr '17

Hi, We are now in the last week of development period for Linux v4.12. All of my patches were already merged into 'for-next' branch on maintainer's repository. This is a digest for the subject. ## New drivers Two drivers were newly added to sound subsystem: * A driver for MOTU FireWire series (snd-firewire-motu) * http://mailman.alsa-project.org/pipermail/alsa-devel/2017-March/119055.html * A driver for RME Fireface series (snd-fireface) * http://mailman.alsa-project.org/pipermail/alsa-devel/2017-March/119360.html Although both drivers support a part of units on each series, I won't work for the other units by my self anymore. I wish users are going to work for enhancement of support for more units. ## Changes for existent drivers Additionally, below drivers were widely changed: * A driver for Digidesign Digi00x series (snd-firewire-dg00x) * http://mailman.alsa-project.org/pipermail/alsa-devel/2017-April/119397.html * A driver for TASCAM FireWire series (snd-firewire-tascam) * http://mailman.alsa-project.org/pipermail/alsa-devel/2017-April/119748.html Purpose of the changes is mainly for maintenance. Especially, digi00x driver now got a proper support for its console models. Correspondingly, some feature of firewire-lib move to firewire-tascam driver. ## Additional Tracepoints Furthermore, ALSA firewire stack newly supports additional tracepoints: * snd_firewire_lib subsystem * in_packet_without_header/out_packet_without_header * snd_firewire_motu subsystem * in_data_block_sph/out_data_block_sph * in_data_block_message/out_data_block_mesasge These tracepoints are available to debug behaviours of drivers newly added in this development period. Of cource, below tracepoints are still available for existent drivers: * snd_firewire_lib subsystem * in_packet/out_packet These tracepoints are available via tracefs or perf_event_open(2). Please refer to proper documentation. ## Known issues As known issues of IEC 61883-1/6 engine on ALSA firewire stack, the engine takes target units to generate sound with periodical short noise. This can be observed except for units based on BeBoB or Fireface series, and this can not be observed every time of packet streaming. The tracepoints declare that the cause does _not_ come from packet queueing timing and throughput of the amount of data blocks. Thus, It comes from protocol implementation itself. When consider about a fact that this depends on the timing to start packet streaming, the cause is that each unit has a strong demand about sequence of the number of data blocks in a packet. It might tight on actual isochronous cycle and the other time clock somehow. Additionally, as I have reported, some of units based on Dice don't transfer/receive exactly the same number of total data block as sampling transmission frequency. In detail, seee: http://mailman.alsa-project.org/pipermail/alsa-devel/2016-May/107715.html ## Useful stuffs For Linux kernel 4.4 or later, backported code is available in my github repository: https://github.com/takaswie/snd-firewire-improve Drivers in ALSA firewire stack support ALSA HwDep interface. There's a sample implementation for user space; libhinawa: https://github.com/takaswie/libhinawa In detail, please refer to documentation of the library. Some functionalities of supported units are controllable by tools in hinawa-utils. This is a sample application of the libhinawa with GOject Introspection support: https://github.com/takaswie/hinawa-utils Currently, they're maintained to assist my work for ALSA firewire stack. Although it can not satisfy all demands from usual users, I'm welcome to receive PRs to integrate the tools. $ git diff --shortstat v4.11-rc1.. sound/firewire/ 43 files changed, 5791 insertions(+), 502 deletions(-) Regards Takashi Sakamoto

1 0