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

[alsa-devel] [RFC v2 0/6] ASoC: Add mediatek HDMI codec support
by Philipp Zabel 05 Mar '16

05 Mar '16

Hi, this time we add an interface for Jyri's generic hdmi-codec driver [1] to the mediatek hdmi bridge driver. In place of a separate machine driver, the existing mt8173-rt5650-rt5676 driver is extended to link to the hdmi-codec instance provided by the hdmi bridge driver. The alsa jack support, previously implemented by the custom mediatek hdmi codec and machine drivers, is bolted on top of hdmi-codec using Russell's HDMI notifier prototype. It's all still a bit rough, but I could use some feedback at this point. Have we achieved consensus to go forward with the hdmi-codec approach? Is it ok to use an alsa jack for HDMI HPD status reporting? The mediatek drm patches apply on top of https://patchwork.kernel.org/patch/7949021/ ("drm/mediatek: Add HDMI support") the asoc patches depend on these two patches: https://patchwork.kernel.org/patch/7215121/ ("ALSA: pcm: add IEC958 channel status helper for hw_params") [1] https://patchwork.kernel.org/patch/7215271/ ("ASoC: hdmi-codec: Add hdmi-codec for external HDMI-encoders") best regards Philipp Koro Chen (1): ASoC: mediatek: Add HDMI dai-links in the machine driver Philipp Zabel (5): drm/mediatek: hdmi: Add audio interface to the hdmi-codec driver ASoC: mediatek: address dai link array entries by enum video: rmk's HDMI notification prototype drm/mediatek: hdmi: issue notifications ASoC: hdmi-codec: Use HDMI notifications to add jack support .../bindings/sound/mt8173-rt5650-rt5676.txt | 5 +- drivers/gpu/drm/mediatek/Kconfig | 1 + drivers/gpu/drm/mediatek/mtk_cec.c | 5 + drivers/gpu/drm/mediatek/mtk_drm_hdmi_drv.c | 192 +++++++++++++++++++++ drivers/gpu/drm/mediatek/mtk_hdmi.c | 26 +++ drivers/gpu/drm/mediatek/mtk_hdmi.h | 4 + drivers/video/Makefile | 2 +- drivers/video/hdmi-not.c | 61 +++++++ include/linux/hdmi-not.h | 39 +++++ include/sound/hdmi-codec.h | 6 + sound/soc/codecs/hdmi-codec.c | 72 +++++++- sound/soc/mediatek/mt8173-rt5650-rt5676.c | 66 ++++++- 12 files changed, 470 insertions(+), 9 deletions(-) create mode 100644 drivers/video/hdmi-not.c create mode 100644 include/linux/hdmi-not.h -- 2.6.2

5 18

[alsa-devel] [PATCH v2 0/2] ASoC: ads117x: Add device tree support for TI ADS117x
by Florian Vaussard 05 Mar '16

05 Mar '16

Hello, This series adds device tree support for Texas Instruments ADS117x ADC chip. The first patch adds the binding documentation, while the second patch adds the compatible string into the driver. No further properties are necessary. Best regards, Florian --- Since v1: - Updated topic for the documentation patch - Removed wildcard in compatible string --- Florian Vaussard (2): ASoC: ads117x: Add bindings documentation for TI ADS117x ADC ASoC: ads117x: Add device tree compatible string Documentation/devicetree/bindings/sound/ti,ads117x.txt | 11 +++++++++++ sound/soc/codecs/ads117x.c | 12 ++++++++++++ 2 files changed, 23 insertions(+) create mode 100644 Documentation/devicetree/bindings/sound/ti,ads117x.txt -- 2.1.0

3 7

[alsa-devel] [PATCH] ASoC: dapm: Remove unneeded variable ret returning 0
by Rajan Vaja 05 Mar '16

05 Mar '16

This patch fixes coccicheck report: Unneeded variable: "ret". Return "0" on line 2817 Remove unneccesary variable ret created to return zero. Signed-off-by: Rajan Vaja <rajan.vaja(a)gmail.com> --- sound/soc/soc-dapm.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/sound/soc/soc-dapm.c b/sound/soc/soc-dapm.c index 5a2812f..8dc395f 100644 --- a/sound/soc/soc-dapm.c +++ b/sound/soc/soc-dapm.c @@ -2805,7 +2805,7 @@ EXPORT_SYMBOL_GPL(snd_soc_dapm_add_routes); int snd_soc_dapm_del_routes(struct snd_soc_dapm_context *dapm, const struct snd_soc_dapm_route *route, int num) { - int i, ret = 0; + int i; mutex_lock_nested(&dapm->card->dapm_mutex, SND_SOC_DAPM_CLASS_INIT); for (i = 0; i < num; i++) { @@ -2814,7 +2814,7 @@ int snd_soc_dapm_del_routes(struct snd_soc_dapm_context *dapm, } mutex_unlock(&dapm->card->dapm_mutex); - return ret; + return 0; } EXPORT_SYMBOL_GPL(snd_soc_dapm_del_routes); -- 1.7.9.5

2 1

[alsa-devel] I created a wiki page about bug reporting, review requested
by Tanu Kaskinen 05 Mar '16

05 Mar '16

Hi, When talking with PulseAudio users, I sometimes need to tell people to file ALSA bugs, and it would be nice to have a web page that explains how to do that. (Also, I found that the alsa packages in OpenEmbedded point to a non-functional bug tracker, and I wanted to fix the packages, but I couldn't find a substitute link.) Therefore I created a wiki page: http://alsa-project.org/main/index.php/Bug_Tracking The Bug_Tracking wiki page points to another new page, explaining alsa- info.sh: http://alsa-project.org/main/index.php/AlsaInfo Are the ALSA maintainers happy with the contents? I'm not really an expert on how you prefer bugs to be reported. Also, the "Bug Tracker" link in the wiki sidebar points to https://bugtrack.alsa-project.org/alsa-bug which doesn't work. I think that link should be changed to point to the new wiki page, but I don't have edit rights for the sidebar. -- Tanu

2 2

[alsa-devel] [PATCH 0/6] ASoC: rsnd: add CTU support
by Kuninori Morimoto 05 Mar '16

05 Mar '16

Hi Mark These patches adds CTU (= Channel Transfer Unit) support to Renesas R-Car sound driver. It can exchange channel order ex) channel {0,1,2,3} -> channel {3,2,1,0} And it can add/reduce each channels sound ex) (input 0th ch x 0.5) + (input 2nd ch x 0.5) = output 1st ch You need to check R-Car datasheet for each detail settings, or check 6) patch Kuninori Morimoto (6): 1) ASoC: rsnd: don't call update callback if it was NULL 2) ASoC: rsrc-card: add convert channels support 3) ASoC: rsnd: tidyup rsnd_ssiu_init_gen2() 4) ASoC: rsnd: add CTU basic support 5) ASoC: rsnd: add rsnd_runtime_channel_xxx() 6) ASoC: rsnd: add CTU support Documentation/devicetree/bindings/sound/renesas,rsrc-card.txt | 1 + sound/soc/sh/rcar/core.c | 71 ++++++++++++++---------- sound/soc/sh/rcar/ctu.c | 287 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-------------- sound/soc/sh/rcar/dvc.c | 2 +- sound/soc/sh/rcar/mix.c | 2 +- sound/soc/sh/rcar/rsnd.h | 9 +++- sound/soc/sh/rcar/rsrc-card.c | 22 +++++--- sound/soc/sh/rcar/src.c | 2 +- sound/soc/sh/rcar/ssi.c | 15 +++--- sound/soc/sh/rcar/ssiu.c | 11 ++-- 10 files changed, 330 insertions(+), 92 deletions(-) Best regards --- Kuninori Morimoto

3 14

[alsa-devel] [PATCH] ASoC: wm8994: codec driver should manage its own MCLK
by Zidan Wang 05 Mar '16

05 Mar '16

codec driver should manage its own master clock, MCLK1 and MCLK2. When bias_level change from standby to prepare, enable codec MCLK. When bias_level change from prepare to standby, disable codec MCLK. Signed-off-by: Zidan Wang <zidan.wang(a)freescale.com> --- drivers/mfd/wm8994-core.c | 7 +++++++ include/linux/mfd/wm8994/pdata.h | 3 +++ sound/soc/codecs/wm8994.c | 17 +++++++++++++++-- 3 files changed, 25 insertions(+), 2 deletions(-) diff --git a/drivers/mfd/wm8994-core.c b/drivers/mfd/wm8994-core.c index 7eec619..ace2cea 100644 --- a/drivers/mfd/wm8994-core.c +++ b/drivers/mfd/wm8994-core.c @@ -14,6 +14,7 @@ #include <linux/kernel.h> #include <linux/module.h> +#include <linux/clk.h> #include <linux/slab.h> #include <linux/i2c.h> #include <linux/err.h> @@ -270,6 +271,7 @@ static int wm8994_set_pdata_from_of(struct wm8994 *wm8994) { struct device_node *np = wm8994->dev->of_node; struct wm8994_pdata *pdata = &wm8994->pdata; + char tmp[8]; int i; if (!np) @@ -310,6 +312,11 @@ static int wm8994_set_pdata_from_of(struct wm8994 *wm8994) if (pdata->ldo[1].enable < 0) pdata->ldo[1].enable = 0; + for (i = 0; i < WM8994_NUM_MCLK; i++) { + sprintf(tmp, "MCLK%d", i + 1); + pdata->mclk[i] = devm_clk_get(wm8994->dev, tmp); + } + return 0; } #else diff --git a/include/linux/mfd/wm8994/pdata.h b/include/linux/mfd/wm8994/pdata.h index 90c6052..657a828 100644 --- a/include/linux/mfd/wm8994/pdata.h +++ b/include/linux/mfd/wm8994/pdata.h @@ -18,6 +18,7 @@ #define WM8994_NUM_LDO 2 #define WM8994_NUM_GPIO 11 #define WM8994_NUM_AIF 3 +#define WM8994_NUM_MCLK 2 struct wm8994_ldo_pdata { /** GPIOs to enable regulator, 0 or less if not available */ @@ -233,6 +234,8 @@ struct wm8994_pdata { * GPIO for the IRQ pin if host only supports edge triggering */ int irq_gpio; + + struct clk *mclk[WM8994_NUM_MCLK]; }; #endif diff --git a/sound/soc/codecs/wm8994.c b/sound/soc/codecs/wm8994.c index 2ccbb32..7379eae 100644 --- a/sound/soc/codecs/wm8994.c +++ b/sound/soc/codecs/wm8994.c @@ -17,6 +17,7 @@ #include <linux/delay.h> #include <linux/pm.h> #include <linux/gcd.h> +#include <linux/clk.h> #include <linux/i2c.h> #include <linux/platform_device.h> #include <linux/pm_runtime.h> @@ -2474,6 +2475,8 @@ static int wm8994_set_bias_level(struct snd_soc_codec *codec, { struct wm8994_priv *wm8994 = snd_soc_codec_get_drvdata(codec); struct wm8994 *control = wm8994->wm8994; + struct wm8994_pdata *pdata = &control->pdata; + int i; wm_hubs_set_bias_level(codec, level); @@ -2495,8 +2498,13 @@ static int wm8994_set_bias_level(struct snd_soc_codec *codec, break; } - if (snd_soc_codec_get_bias_level(codec) == SND_SOC_BIAS_STANDBY) + if (snd_soc_codec_get_bias_level(codec) == SND_SOC_BIAS_STANDBY) { active_reference(codec); + + for (i = 0; i < WM8994_NUM_MCLK; i++) + if (!IS_ERR(pdata->mclk[i])) + clk_prepare_enable(pdata->mclk[i]); + } break; case SND_SOC_BIAS_STANDBY: @@ -2524,8 +2532,13 @@ static int wm8994_set_bias_level(struct snd_soc_codec *codec, WM8994_LINEOUT2_DISCH); } - if (snd_soc_codec_get_bias_level(codec) == SND_SOC_BIAS_PREPARE) + if (snd_soc_codec_get_bias_level(codec) == SND_SOC_BIAS_PREPARE) { + for (i = 0; i < WM8994_NUM_MCLK; i++) + if (!IS_ERR(pdata->mclk[i])) + clk_disable_unprepare(pdata->mclk[i]); + active_dereference(codec); + } /* MICBIAS into bypass mode on newer devices */ switch (control->type) { -- 1.9.1

3 2

[alsa-devel] [PATCH] ALSA: compress: fix more typos
by Vinod Koul 04 Mar '16

04 Mar '16

More inspection of code revealed few more typos so fix them as well Signed-off-by: Vinod Koul <vinod.koul(a)intel.com> --- sound/core/compress_offload.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/sound/core/compress_offload.c b/sound/core/compress_offload.c index c4b14b5f1b35..7d59dbda8897 100644 --- a/sound/core/compress_offload.c +++ b/sound/core/compress_offload.c @@ -703,7 +703,7 @@ static int snd_compress_wait_for_drain(struct snd_compr_stream *stream) /* * We are called with lock held. So drop the lock while we wait for - * drain complete notfication from the driver + * drain complete notification from the driver * * It is expected that driver will notify the drain completion and then * stream will be moved to SETUP state, even if draining resulted in an @@ -758,7 +758,7 @@ static int snd_compr_next_track(struct snd_compr_stream *stream) if (stream->runtime->state != SNDRV_PCM_STATE_RUNNING) return -EPERM; - /* you can signal next track isf this is intended to be a gapless stream + /* you can signal next track if this is intended to be a gapless stream * and current track metadata is set */ if (stream->metadata_set == false) -- 1.9.1

2 1

Re: [alsa-devel] [PATCH v3] ASoC: imx-wm8958: add imx-wm8958 machine driver
by Nicolin Chen 04 Mar '16

04 Mar '16

On Fri, Mar 04, 2016 at 08:54:10AM +0000, Zidan Wang wrote: > On Friday, March 04, 2016 3:40 PM, Nicolin Chen wrote: > > > > > cpu-dai1 : The phandle of an CPU DAI controller for AIF1 > > > > cpu-dai2 : The phandle of an CPU DAI controller for AIF2 > > > > cpu-dai3 : The phandle of an CPU DAI controller for AIF3 > > > > > > > > > + data->card.num_links = DAI_LINK_NUM; > > > > > + data->card.dai_link = data->dai_link; > > > > > > > > Then, rather than hard coding the total DAI link number and creating > > > > useless dummy links, you may create the links dynamically according > > > > to the presence of the three properties above. > > > > > > I don't know how to using cpu-dai1/2/3. There don't have voice and bt > > controller on the IMX cpu, don't have such cpu nodes. > > > Do you means our hardware connection are wrong, and we must have voice > > and bt controller on the cpu? > > > > Okay. I was trying to give you an excuse to have all three aifs included, > > as I thought you might eventually need them to *connect* something via DT. > > If you think you don't have any idea to pre-allocate these links, you > > probably should ignore my suggestion here and just follow Mark's comments: > > I am just confused by our hardward connection. If dummy cpu dai is not ok, I think I should follow your suggestion. > > If we want to keep our hardware connection, which bt and voice directly connect to codec, and don't have bt and voice controller. > What's the best way? The only way to keep them while not having BT and voice controllers is just what I suggested you to make it through DT. Devicetree is a script to reflect your exact hardware connections. You can dis-link them for now in the DT as they are not "connected" in your current design and then link them whenever you get them connected -- I think there should be connections since you are using a validation board. You just don't have the extension board or something. So you may try to reach your hardware team, especially designer, for detail. The idea here is similar to the ASRC links in fsl-asoc-card driver: users can drop ASRC by merely removing the asrc phandle in the DT, depending on their board design or requirement. The drawback of this way is that you need to figure out an accurate DT binding: you might need to figure out a better name rather than "cpu-dai" because it sounds like WM8958 may not act as a Codec at all when it connects your BT route. That means WM8958 will become a cpu-dai somehow? You can send a patch with a decent DT binding. I believe Mark will give some better advice.

1 0

[alsa-devel] [PATCH 0/4] Fix headphone detection on Acer Chromebook 13
by Jonathan Tinkham 04 Mar '16

04 Mar '16

Headphone output works, but headphone detection does not. The problem is improper inversion of the jack gpio, and improper naming of the DAPM switch. With these changes, headphone insertion and removal is picked up by userspace, and the switch properly toggled. Jonathan Tinkham (4): soc/sound: tegra_max98090: do not invert headphone jack sound/soc: tegra_max98090: rename headphone jack DAPM sound/soc: tegra_max98090: document headphone jack rename soc/sound: tegra_max98090: update dts affected by rename .../devicetree/bindings/sound/nvidia,tegra-audio-max98090.txt | 6 +++--- arch/arm/boot/dts/tegra124-nyan.dtsi | 4 ++-- arch/arm/boot/dts/tegra124-venice2.dts | 4 ++-- sound/soc/tegra/tegra_max98090.c | 10 +++++----- 4 files changed, 12 insertions(+), 12 deletions(-) -- 2.7.0

4 37

[alsa-devel] CM6206-LX usb sound card
by Nikita Orlov 04 Mar '16

04 Mar '16

Hello! First I sent these questions to alsa-user, but I think this mailing list is more proper place to ask such questions. I have cheap chinese usb audio card, based on CM6206-LX chip from CMEDIA. CM6206-LX is similar to CM6206, but not 7.1 channels output, it is 5.1 channels. I use ubuntu 15.* with kernel 4.2.0-30-generic. dmesg show me some warnings about sound card: [31010.394487] usb 1-1: new full-speed USB device number 24 using xhci_hcd [31010.523953] usb 1-1: New USB device found, idVendor=0d8c, idProduct=0102 [31010.523956] usb 1-1: New USB device strings: Mfr=0, Product=2, SerialNumber=0 [31010.523957] usb 1-1: Product: USB Sound Device [31010.526235] input: USB Sound Device as /devices/pci0000:00/0000:00:14.0/usb1/1-1/1-1:1.3/0003:0D8C:0102.0010/input/input33 [31010.578876] hid-generic 0003:0D8C:0102.0010: input,hidraw0: USB HID v1.00 Device [USB Sound Device ] on usb-0000:00:14.0-1/input3 [31010.643908] usb 1-1: current rate 30464 is different from the runtime rate 96000 [31010.646123] usb 1-1: Warning! Unlikely big volume range (=8065), cval->res is probably wrong. [31010.646126] usb 1-1: [9] FU [Mic Playback Volume] ch = 2, val = -6144/1921/1 [31010.646485] usb 1-1: Warning! Unlikely big volume range (=8065), cval->res is probably wrong. [31010.646486] usb 1-1: [11] FU [Line Playback Volume] ch = 2, val = -6144/1921/1 [31010.647884] usb 1-1: Warning! Unlikely big volume range (=6928), cval->res is probably wrong. [31010.647887] usb 1-1: [8] FU [Mic Capture Volume] ch = 2, val = -4096/2832/1 [31010.648291] usb 1-1: Warning! Unlikely big volume range (=6928), cval->res is probably wrong. [31010.648295] usb 1-1: [15] FU [Line Capture Volume] ch = 2, val = -4096/2832/1 [31010.648662] usb 1-1: Warning! Unlikely big volume range (=6928), cval->res is probably wrong. [31010.648664] usb 1-1: [2] FU [PCM Capture Volume] ch = 2, val = -4096/2832/1 [31010.648887] usbcore: registered new interface driver snd-usb-audio There are two types of errors, first that current rate 30464 is different from the runtime rate 96000. Unfortunately I have no idea about this warning. And warnings like Unlikely big volume range (=8065), cval->res is probably wrong. As I understand it is because auto value range for some mixers are not proper detected. I have test capturing with simple test app. It seems only one avalible sample rate is 48000 Hz. printf("Sample rate = %d\n", SampleRate); snd_pcm_hw_params_set_rate_near(Handle, params, &SampleRate, &dir); printf("Sample rate = %d\n", SampleRate); After calling these function SampleRate becomes 48000, even if before it was 44100. Maybe it is related to first error in dmesg. Anybody knows? But, according to cat /proc/asound/card2/stream0 USB Sound Device at usb-0000:00:14.0-1, full speed : USB Audio Playback: Status: Stop Interface 1 Altset 1 Format: S16_LE Channels: 8 Endpoint: 6 OUT (ADAPTIVE) Rates: 44100, 48000 Interface 1 Altset 2 Format: S16_LE Channels: 2 Endpoint: 6 OUT (ADAPTIVE) Rates: 44100, 48000 Interface 1 Altset 3 Format: S16_LE Channels: 4 Endpoint: 6 OUT (ADAPTIVE) Rates: 44100, 48000 Interface 1 Altset 4 Format: S16_LE Channels: 6 Endpoint: 6 OUT (ADAPTIVE) Rates: 44100, 48000 Interface 1 Altset 5 Format: S16_LE Channels: 2 Endpoint: 6 OUT (ADAPTIVE) Rates: 96000 Capture: Status: Stop Interface 2 Altset 1 Format: S16_LE Channels: 2 Endpoint: 5 IN (ASYNC) Rates: 44100, 48000 It is able to capture 44100. I have tried to capture via arecord: arecord -D hw:2,0 -f cd -c 2 > ./test2.wav and VLC said it is 44100, but I don`t have microphone at the moment to test is there proper sound recorded or not. I will try it later. I have found that init of sound card is related to snd_usb_audio.ko module and learn a bit how it works. There is a quirk that write internal registers. According to mailing list archives dated in 2009, values were found by usb traffic sniffing under Windows. I have found CM6206 datasheet and check description of internal registers. http://wenku.baidu.com/link?url=vkQLGhKUuvVmHC7vyobjKlF0yixpjn3ueAdD81OO6Ul… It is link to datasheet. Website is chinese, but datasheet itsel is in english. To see it after 3rd page click 下载文档到电脑，查找使用更方便. But there are no interesting things about registers and mostly values that are exist in current snd_usb_audio must work ok. Also in datasheet there some info about values of volume ranges that can be related to second dmesg warnings. I have uploaded images of related info from datasheet here https://yadi.sk/d/1kdCFs7Gpv8L8 I have try with mixer.c in sound/usb/ dir of kernel tree (4.2.0) and tried to add experimental code in volume_control_quirks function. But it seems function is not called for my device for some reason. It is more complicated that I think first. So another question is how to make quirk for proper mixer values? -- Nikita Orlov Skype: nik_stet QQ: 2717846083

1 0