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

Re: [alsa-devel] [PATCH 2/4] hid-lenovo: Add support for X1 Tablet cover LED control
by Dennis Wassenberg 19 Dec '16

19 Dec '16

Hi Jiri, Thanks for your comments. I added comments in-lined. Best regards, Dennis On 19.12.2016 10:54, Jiri Kosina wrote: > Hi Dennis, > > thanks a lot for the patch. > > On Fri, 9 Dec 2016, Dennis Wassenberg wrote: > >> +int hid_lenovo_led_set(enum hid_lenovo_led_type led, bool on) >> +{ >> + struct led_classdev *dev = NULL; >> + struct lenovo_led_list_entry *entry; >> + >> + if (led >= HID_LENOVO_LED_MAX) >> + return -EINVAL; >> + >> + hid_lenovo_initial_leds[led] = on ? LED_FULL : LED_OFF; >> + >> + list_for_each_entry(entry, &hid_lenovo_leds, list) { >> + if (entry->type == led) { >> + dev = entry->dev; >> + break; >> + } >> + } > > How exactly is this synchronized against lenovo_remove_tpx1cover()? > In case of that the tpx1cover is disconnected it will be removed from hid_lenovo_leds list. That means not included at the hid_lenovo_leds list. In this case dev is still NULL and the function will return -ENODEV. The static array hid_lenovo_initial_leds is still set to store the current state of a LED type. This is used to set the LED appropriately if the tpx1cover is replugged. Maybe I should add a mutex to protect the hid_lenovo_leds list operations in hid-lenovo.c to fix the case if a unplug occurred concurrently to setting an led?! >> + >> + if (!dev) >> + return -ENODEV; >> + >> + if (!dev->brightness_set) >> + return -ENODEV; >> + >> + dev->brightness_set(dev, on ? LED_FULL : LED_OFF); >> + >> + return 0; >> +} >> +EXPORT_SYMBOL_GPL(hid_lenovo_led_set); > > Does this really need to be exported to the whole universe? (I guess this > will be further discussed in 4/4). No, it is sufficient if thinkpad-helper can access it. >

1 0

[alsa-devel] [PATCH 0/2] ASoC: Add driver for CX2072X CODEC
by simon.ho.cnxt＠gmail.com 17 Dec '16

17 Dec '16

From: Simon Ho <simon.ho(a)conexant.com> Re-send the patch because my previous email was sent by a non-member email account and are being held. So please disregard my previous email if you saw it. Sorry if I caused any trouble. This patch adds support for Conexant CX2072X codec driver. The CX2072X is a ultra low power stereo audio codec supports I2S/TDM host interface with EQ, DRC features in playback mode. Featues of CX2072X codec: * Two 24 bits DACs and DACs. * Stereo Headphone AMP. * 2.8W per channel class-D output. * Integrated seven bands per channel EQ and DRC. * Fully integrated headset support with detect/switch. * Stereo digital microphone for array applications. * S/PDIF output. * Bi-directional GPIOs. * Support analog and digital PC Beeep. * One headset button support. * Supports a wide variety of host interfaces. -wide variety of I2S and similar bit-stream formats with word lengths of up to 24 bits. -TDM stream supports up to 4 channels. * AEC loopback support. Simon Ho (2): ASoC: cx2072x: Add DT bingings documentation for CX2072X CODEC ASoC: cx2072x Add driver for CX2072X CODEC .../devicetree/bindings/sound/cx2072x.txt | 36 + sound/soc/codecs/Kconfig | 5 + sound/soc/codecs/Makefile | 2 + sound/soc/codecs/cx2072x.c | 2080 ++++++++++++++++++++ sound/soc/codecs/cx2072x.h | 322 +++ 5 files changed, 2445 insertions(+) create mode 100644 Documentation/devicetree/bindings/sound/cx2072x.txt create mode 100644 sound/soc/codecs/cx2072x.c create mode 100644 sound/soc/codecs/cx2072x.h -- 2.7.4

1 1

[alsa-devel] USB Driver Development Sinn 7 Status 24|96 (0x200c:0x1006)
by Marc Streckfuß 17 Dec '16

17 Dec '16

Hello Guys, I apologize in advance if this is the wrong mailing list (In general I am new to Mailing Lists), but I thought since I plan to develop a driver this might fit, I'm just not completely done. == Device Information The Device in Question is from the Brand "Sinn 7" with the name "Status 24|96", it's a relatively unknown recording interface design to be used in DAWs on Windows using Steinberg's Proprietary ASIO Interface. This is to provide a low-latency interface on Windows but it seems to be support a regular interface as well (at least you can use it as regular windows speaker and have different options there). It seems to be manufactured by Reloop, since that's the vendorId 0x200c. I tried the snd-usb-audio quirk for the Reloop Play already, but it didn't work (Applying the Quirk seemed to fail, due to endpoint mismatch, etc). >From reverse engineering the windows driver a bit I found the name " usb-audio.de". It's a website of the Pylotec GmbH which seems to provide the base boards for USB Audio Hardware used in many Interfaces (They have a page where they mention what is using their usb audio driver) The interesting lsusb output is this (I omitted the "empty" altsetting 0 for both interfaces, all classes are 0xFF == Vendor Specific): Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 1 bNumEndpoints 3 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 0 bInterfaceProtocol 0 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes 5 Transfer Type Isochronous Synch Type Asynchronous Usage Type Data wMaxPacketSize 0x0004 1x 4 bytes bInterval 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x83 EP 3 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x05 EP 5 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 1 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 1 bNumEndpoints 1 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 0 bInterfaceProtocol 0 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x86 EP 6 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 1 == My Findings So after days of trying out different quirks, building my own version of the snd-usb-audio and endless research I found out some stuff. A) I have captured the init sequence and I am able to redo it using libusb B) It turns out that there are 3 permanent communication types, even when I disable the device in Windows: There are writes to the Isochronous Endpoint 0x2 containing 32 Sub-Packets, so that is 128 Bytes of 0x0. Oddly enough that isn't the Audio data!! There are writes to the Bulk Endpoint 0x5 containing a variable size ranging roughly from ~16kB to 20kB. These are filled mostly with 0x0, but periodically (every 200h Bytes?) I had a 0xFD 0xFF Sequence. Those actually contain the Audio Data. I was able to produce some knocking sound when sending random values (either 0x0 or 0x1!) here. [I was expecting a white noise, though] => This is where I am stuck. I understand the idea of PCM in General, but I would expect it to send [0, 0xFF] values and not just 0x0 or 0x1, since that is a bandwidth waste. This and I would also expect a constant packet size. If it is variable, does that mean that the Sample Rate changes? (Note: I confirmed the 0x0..0x1 and the variable packet size both: By using libusb/pyUSB and by sniffing the traffic of a virtual windows box with Wireshark) There are reads from the Bulk Endpoint 0x86 (Note: Different InterfaceNumber, but it seems to work without changing the interface??) which result in an array of values ranging from 0x0 to 0x3. (Maybe that would apply to the output as well and during sniffing I just had the test sound too low gained?). Most of the time their size seems to be in line with the output bulk packets. Some of the sent sizes (data fields only) are: 19'986Bytes, 16'384 Bytes, 12'800 Bytes however most of the time it's 16k, whereas the output tends to go to 19k and the input to 12k (I have nothing attached to the input connectors). Now what I actually want to know: Does that protocol sound familiar to you? Do you have a clue on how to patch it in as a simple quirk? I was thinking maybe I can use a setup quirk and then let the FIXED_ENDPOINT do the rest? However I am stuck with the Format, I don't know whether that really is a known format or if I need some conversion and how it is with some synchronization clock and such. Basically I need information on how to proceed. - Marc Streckfuß

1 0

[alsa-devel] 1.1.3 release?
by Takashi Iwai 16 Dec '16

16 Dec '16

Hi Jaroslav, shall we release v1.1.3 now? We've gathered quite a lot of changes since the last release. thanks, Takashi

4 5

[alsa-devel] [alsa-lib][PATCH] ASoC: hdmi-codec: use unsigned type to structure members with bit-field instead of signed type
by Takashi Sakamoto 16 Dec '16

16 Dec '16

This is a fix for Linux 4.10-rc1. In C language specification, a bit-field is interpreted as a signed or unsigned integer type consisting of the specified number of bits. In GCC manual, the range of a signed bit field of N bits is from -(2^N) / 2 to ((2^N) / 2) - 1 https://www.gnu.org/software/gnu-c-manual/gnu-c-manual.html#Bit-Fields Therefore, when defined as 1 bit-field with signed type, variables can represents -1 and 0. The snd-soc-hdmi-codec module includes a structure which has signed type members with bit-fields. Codes of this module assign 0 and 1 to the members. This seems to result in implementation-dependent behaviours. As of v4.10-rc1 merge window, outside of sound subsystem, this structure is referred by below GPU modules. - tda998x - sti-drm - mediatek-drm-hdmi - msm As long as I review their codes relevant to the structure, the structure members are used just for condition statements and printk formats. My proposal of change is a bit intrusive to the printk formats but this may be acceptable. Totally, it's reasonable to use unsigned type for the structure members. This bug is detected by Sparse, static code analyzer with below warnings. ./include/sound/hdmi-codec.h:39:26: error: dubious one-bit signed bitfield ./include/sound/hdmi-codec.h:40:28: error: dubious one-bit signed bitfield ./include/sound/hdmi-codec.h:41:29: error: dubious one-bit signed bitfield ./include/sound/hdmi-codec.h:42:31: error: dubious one-bit signed bitfield CC: Jyri Sarha <jsarha(a)ti.com> CC: Jie Qiu <jie.qiu(a)mediatek.com> CC: Arnaud Pouliquen <arnaud.pouliquen(a)st.com> CC: Srinivas Kandagatla <srinivas.kandagatla(a)linaro.org> CC: dri-devel(a)lists.freedesktop.org CC: stable(a)vger.kernel.org Fixes: 09184118a8ab ("ASoC: hdmi-codec: Add hdmi-codec for external HDMI-encoders") Signed-off-by: Takashi Sakamoto <o-takashi(a)sakamocchi.jp> --- include/sound/hdmi-codec.h | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/include/sound/hdmi-codec.h b/include/sound/hdmi-codec.h index 530c57b..915c435 100644 --- a/include/sound/hdmi-codec.h +++ b/include/sound/hdmi-codec.h @@ -36,10 +36,10 @@ struct hdmi_codec_daifmt { HDMI_AC97, HDMI_SPDIF, } fmt; - int bit_clk_inv:1; - int frame_clk_inv:1; - int bit_clk_master:1; - int frame_clk_master:1; + unsigned int bit_clk_inv:1; + unsigned int frame_clk_inv:1; + unsigned int bit_clk_master:1; + unsigned int frame_clk_master:1; }; /* -- 2.9.3

3 4

[alsa-devel] [PATCH] ASoC: da7218: Set DAI output pin high impedance when not in use
by Adam Thomson 16 Dec '16

16 Dec '16

For TDM mode, the I2S data out line can be shared between mutliple codecs. In this scenario, only the active codec should be using the line, and all others should be high impedance. However, currently in the driver this configuration isn't set when capture is inactive, and the line remains driven. This patch updates the AIF_OUT widget to set the DAI output pin of the device as high impedance when not in use. Signed-off-by: Adam Thomson <Adam.Thomson.Opensource(a)diasemi.com> --- sound/soc/codecs/da7218.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/sound/soc/codecs/da7218.c b/sound/soc/codecs/da7218.c index c69e976..d256ebf 100644 --- a/sound/soc/codecs/da7218.c +++ b/sound/soc/codecs/da7218.c @@ -1634,7 +1634,8 @@ static int da7218_hp_pga_event(struct snd_soc_dapm_widget *w, SND_SOC_DAPM_POST_PMU | SND_SOC_DAPM_POST_PMD), /* DAI */ - SND_SOC_DAPM_AIF_OUT("DAIOUT", "Capture", 0, SND_SOC_NOPM, 0, 0), + SND_SOC_DAPM_AIF_OUT("DAIOUT", "Capture", 0, DA7218_DAI_TDM_CTRL, + DA7218_DAI_OE_SHIFT, DA7218_NO_INVERT), SND_SOC_DAPM_AIF_IN("DAIIN", "Playback", 0, SND_SOC_NOPM, 0, 0), /* Output Mixers */ -- 1.9.3

2 1

[alsa-devel] [PATCH] tinycompress: rename crec usages
by Vinod Koul 16 Dec '16

16 Dec '16

The creord utility help listed crec as the utility name, change that to crecord and also update the program explanation text. Signed-off-by: Vinod Koul <vinod.koul(a)intel.com> --- src/utils/crecord.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/src/utils/crecord.c b/src/utils/crecord.c index 8d5b7b0b2c30..1ba54d70e89c 100644 --- a/src/utils/crecord.c +++ b/src/utils/crecord.c @@ -1,7 +1,7 @@ /* * BSD LICENSE * - * crec command line recorder for compress audio record in alsa + * crecord command line recorder for compress audio record in alsa * Copyright (c) 2011-2012, Intel Corporation * Copyright (c) 2013-2014, Wolfson Microelectronic Ltd. * All rights reserved. @@ -35,7 +35,7 @@ * * LGPL LICENSE * - * crec command line recorder for compress audio record in alsa + * crecord command line recorder for compress audio record in alsa * Copyright (c) 2011-2012, Intel Corporation * Copyright (c) 2013-2014, Wolfson Microelectronic Ltd. * @@ -153,7 +153,7 @@ static void size_wave_header(struct wave_header *header, uint32_t size) static void usage(void) { - fprintf(stderr, "usage: crec [OPTIONS] [filename]\n" + fprintf(stderr, "usage: crecord [OPTIONS] [filename]\n" "-c\tcard number\n" "-d\tdevice node\n" "-b\tbuffer size\n" @@ -167,8 +167,8 @@ static void usage(void) "If filename is not given the output is\n" "written to stdout\n\n" "Example:\n" - "\tcrec -c 1 -d 2 test.wav\n" - "\tcrec -f 5 test.wav\n", + "\tcrecord -c 1 -d 2 test.wav\n" + "\tcrecord -f 5 test.wav\n", DEFAULT_CHANNELS, DEFAULT_RATE); exit(EXIT_FAILURE); -- 1.9.1

1 0

[alsa-devel] [PATCH] tinycompress: rename crec.c
by Vinod Koul 16 Dec '16

16 Dec '16

Since the compress recorder utility is called crecord, it makes it apt to have src file named crecord.c. Reported-by: Richard Fitzgerald <rf(a)opensource.wolfsonmicro.com> Signed-off-by: Vinod Koul <vinod.koul(a)intel.com> --- src/utils/Makefile.am | 2 +- src/utils/{crec.c => crecord.c} | 0 2 files changed, 1 insertion(+), 1 deletion(-) rename src/utils/{crec.c => crecord.c} (100%) diff --git a/src/utils/Makefile.am b/src/utils/Makefile.am index 5f685e3b2ffe..1b996d430f21 100644 --- a/src/utils/Makefile.am +++ b/src/utils/Makefile.am @@ -1,7 +1,7 @@ bin_PROGRAMS = cplay crecord cplay_SOURCES = cplay.c -crecord_SOURCES = crec.c +crecord_SOURCES = crecord.c cplay_CFLAGS = -I$(top_srcdir)/include crecord_CFLAGS = -I$(top_srcdir)/include diff --git a/src/utils/crec.c b/src/utils/crecord.c similarity index 100% rename from src/utils/crec.c rename to src/utils/crecord.c -- 1.9.1

1 0

[alsa-devel] [PATCH v2] ASoC: Intel: bytcr_rt5640: fallback mechanism if MCLK is not enabled
by Pierre-Louis Bossart 16 Dec '16

16 Dec '16

Commit df1a2776a795 ("ASoC: Intel: bytcr_rt5640: add MCLK support") was merged but the corresponding clock framework patches have not, after being bumped from audio to clock to x86 domains. The missing clock-related patches result in a regression starting with 4.9 with the audio card not being created. Rather than reverting this commit and all following updates already queued up for 4.10, handle run-time dependency on MCLK and fall back to the previous bit-clock mode. This provides the same functionality as in 4.8 for Baytrail devices. On Baytrail-CR most devices remain silent with this fallback but additional patches are needed anyway. As suggested by Mark Brown, the fallback is only allowed with -ENOENT, all other run-time errors, including -EPROBE_DEFER, will stop the probe with no sound card registered. This patch should be applied to -stable as well as ASoC 4.10 fixes Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com> --- sound/soc/intel/boards/bytcr_rt5640.c | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-) diff --git a/sound/soc/intel/boards/bytcr_rt5640.c b/sound/soc/intel/boards/bytcr_rt5640.c index 507a86a..7d66127 100644 --- a/sound/soc/intel/boards/bytcr_rt5640.c +++ b/sound/soc/intel/boards/bytcr_rt5640.c @@ -825,10 +825,20 @@ static int snd_byt_rt5640_mc_probe(struct platform_device *pdev) if ((byt_rt5640_quirk & BYT_RT5640_MCLK_EN) && (is_valleyview())) { priv->mclk = devm_clk_get(&pdev->dev, "pmc_plt_clk_3"); if (IS_ERR(priv->mclk)) { + ret_val = PTR_ERR(priv->mclk); + dev_err(&pdev->dev, "Failed to get MCLK from pmc_plt_clk_3: %ld\n", - PTR_ERR(priv->mclk)); - return PTR_ERR(priv->mclk); + ret_val); + + /* + * Fall back to bit clock usage for -ENOENT (clock not + * available likely due to missing dependencies), bail + * for all other errors, including -EPROBE_DEFER + */ + if (ret_val != -ENOENT) + return ret_val; + byt_rt5640_quirk &= ~BYT_RT5640_MCLK_EN; } } -- 2.7.4

2 2

[alsa-devel] [bug report] ASoC: rsnd: call missing snd_ctl_remove()
by Dan Carpenter 16 Dec '16

16 Dec '16

Hello Kuninori Morimoto, The patch d1f83d6ef43b: "ASoC: rsnd: call missing snd_ctl_remove()" from Feb 2, 2015, leads to the following static checker warning: sound/soc/sh/rcar/core.c:1034 __rsnd_kctrl_new() error: double free of 'kctrl' sound/soc/sh/rcar/core.c 1026 int ret; 1027 1028 kctrl = snd_ctl_new1(&knew, mod); 1029 if (!kctrl) 1030 return -ENOMEM; 1031 1032 ret = snd_ctl_add(card, kctrl); 1033 if (ret < 0) { 1034 snd_ctl_free_one(kctrl); The snd_ctl_add() function frees kctrl on error. It's a confusing layering violation IMHO but there are a lot of callers so I'm too lazy to clean this up myself... 1035 return ret; 1036 } 1037 regards, dan carpenter

2 1