June 2015 - Alsa-devel - mailman.alsa-project.org

[alsa-devel] [PATCH] ASoC: rt5677: Avoid recursive locking in the DEADLOCK detector
by Oder Chiou 05 Jun '15

05 Jun '15

The patch is for to avoid recursive locking in the DEADLOCK detector. In the driver, it encountered the warnning message of the recursive locking in the function "regmap_lock_mutex". Signed-off-by: Oder Chiou <oder_chiou(a)realtek.com> --- sound/soc/codecs/rt5677.c | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+) diff --git a/sound/soc/codecs/rt5677.c b/sound/soc/codecs/rt5677.c index 31d969a..ee5b570 100644 --- a/sound/soc/codecs/rt5677.c +++ b/sound/soc/codecs/rt5677.c @@ -4998,6 +4998,22 @@ static const struct regmap_config rt5677_regmap_physical = { .num_ranges = ARRAY_SIZE(rt5677_ranges), }; +static void rt5677_regmap_lock_mutex(void *__lock) +{ + struct mutex *lock = __lock; + + mutex_lock(lock); +} + +static void rt5677_regmap_unlock_mutex(void *__lock) +{ + struct mutex *lock = __lock; + + mutex_unlock(lock); +} + +static struct mutex rt5677_regmap_lock; + static const struct regmap_config rt5677_regmap = { .reg_bits = 8, .val_bits = 16, @@ -5009,6 +5025,9 @@ static const struct regmap_config rt5677_regmap = { .readable_reg = rt5677_readable_register, .reg_read = rt5677_read, .reg_write = rt5677_write, + .lock = rt5677_regmap_lock_mutex, + .unlock = rt5677_regmap_unlock_mutex, + .lock_arg = &rt5677_regmap_lock, .cache_type = REGCACHE_RBTREE, .reg_defaults = rt5677_reg, @@ -5206,6 +5225,8 @@ static int rt5677_i2c_probe(struct i2c_client *i2c, return ret; } + mutex_init(&rt5677_regmap_lock); + regmap_read(rt5677->regmap, RT5677_VENDOR_ID2, &val); if (val != RT5677_DEVICE_ID) { dev_err(&i2c->dev, -- 1.9.1

4 5

[alsa-devel] [PATCH v2] ASoC: dapm: fix prefixed stream name matching in snd_soc_dapm_link_dai_widgets
by Arnaud Mouiche 05 Jun '15

05 Jun '15

commit "ASoC: dapm: Modify widget stream name according to prefix" fixed a part of the problem when dai_w->name and w->sname are equal before being prefixed. Remains the case where w->sname is only a sub string of dai_w->name. For example, TLV320AIC3x codec defines the widget SND_SOC_DAPM_DAC("Left DAC", "Left Playback", DAC_PWR, 7, 0) In snd_soc_dapm_link_dai_widgets, we will failed to match "[prefix] Left Playback" with "[prefix] Playback". Since dai_w and w necessarily belongs to the same dapm when strstr() is called, they necessarily have the same prefix which allow us to compare 'w->sname + prefix_len' with 'dai_w->name + prefix_len' directly without length check. Signed-off-by: Arnaud Mouiche <arnaud.mouiche(a)invoxia.com> --- sound/soc/soc-dapm.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/sound/soc/soc-dapm.c b/sound/soc/soc-dapm.c index e19a676..fc4408b 100644 --- a/sound/soc/soc-dapm.c +++ b/sound/soc/soc-dapm.c @@ -3392,6 +3392,9 @@ int snd_soc_dapm_link_dai_widgets(struct snd_soc_card *card) /* For each DAI widget... */ list_for_each_entry(dai_w, &card->widgets, list) { + const char *prefix = soc_dapm_prefix(dai_w->dapm); + size_t prefix_len = prefix ? strlen(prefix)+1 : 0; + switch (dai_w->id) { case snd_soc_dapm_dai_in: case snd_soc_dapm_dai_out: @@ -3415,7 +3418,8 @@ int snd_soc_dapm_link_dai_widgets(struct snd_soc_card *card) break; } - if (!w->sname || !strstr(w->sname, dai_w->name)) + if (!w->sname || + !strstr(w->sname + prefix_len, dai_w->name + prefix_len)) continue; if (dai_w->id == snd_soc_dapm_dai_in) { -- 1.9.1

1 0

[alsa-devel] [PATCH] ASoC: dapm: fix prefixed stream name matching in snd_soc_dapm_link_dai_widgets
by Arnaud Mouiche 05 Jun '15

05 Jun '15

commit "ASoC: dapm: Modify widget stream name according to prefix" fixed a part of the problem when dai_w->name and w->sname are equal before being prefixed. Remains the case where w->sname is only a sub string of dai_w->name. For example, TLV320AIC3x codec defines the widget SND_SOC_DAPM_DAC("Left DAC", "Left Playback", DAC_PWR, 7, 0) In snd_soc_dapm_link_dai_widgets, we will failed to match "[prefix] Left Playback" with "[prefix] Playback". Since dai_w and w necessarily belongs to the same dapm when strstr() is called, they necessarily have the same prefix which allow us to compare 'w->sname + prefix_len' with 'dai_w->name + prefix_len' directly without length check. Signed-off-by: Arnaud Mouiche <arnaud.mouiche(a)invoxia.com> --- sound/soc/soc-dapm.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/sound/soc/soc-dapm.c b/sound/soc/soc-dapm.c index e19a676..7194df4 100644 --- a/sound/soc/soc-dapm.c +++ b/sound/soc/soc-dapm.c @@ -3392,6 +3392,9 @@ int snd_soc_dapm_link_dai_widgets(struct snd_soc_card *card) /* For each DAI widget... */ list_for_each_entry(dai_w, &card->widgets, list) { + const char *prefix = soc_dapm_prefix(dai_w->dapm); + size_t prefix_len = prefix ? strlen(prefix)+1 : 0; + switch (dai_w->id) { case snd_soc_dapm_dai_in: case snd_soc_dapm_dai_out: @@ -3416,6 +3419,8 @@ int snd_soc_dapm_link_dai_widgets(struct snd_soc_card *card) } if (!w->sname || !strstr(w->sname, dai_w->name)) + if (!w->sname || + !strstr(w->sname + prefix_len, dai_w->name + prefix_len)) continue; if (dai_w->id == snd_soc_dapm_dai_in) { -- 1.9.1

2 1

Re: [alsa-devel] (alsa-lib)pcm_hw.c: Invalid PCM state for chmap_get: OPEN
by Raymond Yau 05 Jun '15

05 Jun '15

>> >> Have you tested surround21? > > Yes, front speakers work fine, however LFE doesn't seem to work. Instead when I try to test LFE (from sound UI) I have weird noise in one of rear speakers. There are no such problems with any other mode though (I see that officially only 5.1 mode is supported, however 4.1, 5.0 and 5.1 all work fine), I decided to leave 2.1 mode for now, not sure whose fault is that. http://git.alsa-project.org/?p=alsa-lib.git;a=commitdiff;h=3c4a22ea49a881cd… It is strange that pcm state is open ( 0.089| 0.001) D: [pulseaudio] alsa-mixer.c: Looking at profile output:analog-surround-21 ( 0.089| 0.000) D: [pulseaudio] alsa-mixer.c: Checking for playback on Analog Surround 2.1 (analog-surround-21) ( 0.089| 0.000) D: [pulseaudio] alsa-util.c: Trying surround21:1 with SND_PCM_NO_AUTO_FORMAT ... ( 0.089| 0.000) I: [pulseaudio] (alsa-lib)pcm_hw.c: Invalid PCM state for chmap_get: OPEN ( 0.089| 0.000) D: [pulseaudio] alsa-util.c: Managed to open surround21:1 ( 0.089| 0.000) I: [pulseaudio] alsa-util.c: Disabling tsched mode since BATCH flag is set ( 0.089| 0.000) D: [pulseaudio] alsa-util.c: Maximum hw buffer size is 1213 ms ( 0.090| 0.000) D: [pulseaudio] alsa-util.c: Set buffer size first (to 4797 samples), period size second (to 1199 samples). ( 0.090| 0.000) I: [pulseaudio] alsa-util.c: Device surround21:1 doesn't support 44100 Hz, changed to 48000 Hz. ( 0.090| 0.000) D: [pulseaudio] alsa-mixer.c: Profile output:analog-surround-21 supported.

1 0

[alsa-devel] [asoc:topic/tas2552 1/8] sound/soc/codecs/tas2552.c:493:27-28: Unneeded semicolon
by kbuild test robot 05 Jun '15

05 Jun '15

tree: git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git topic/tas2552 head: 16bd395259cf3e9966d40478891e0e610da109d4 commit: ea178d1456dcf88875d5edd148f2df8ea0de1794 [1/8] ASoC: tas2552: Make the enable-gpio really optional coccinelle warnings: (new ones prefixed by >>) >> sound/soc/codecs/tas2552.c:493:27-28: Unneeded semicolon vim +493 sound/soc/codecs/tas2552.c 477 { 478 struct device *dev; 479 struct tas2552_data *data; 480 int ret; 481 int i; 482 483 dev = &client->dev; 484 data = devm_kzalloc(&client->dev, sizeof(*data), GFP_KERNEL); 485 if (data == NULL) 486 return -ENOMEM; 487 488 data->enable_gpio = devm_gpiod_get(dev, "enable", GPIOD_OUT_LOW); 489 if (IS_ERR(data->enable_gpio)) { 490 if (PTR_ERR(data->enable_gpio) == -EPROBE_DEFER) 491 return -EPROBE_DEFER; 492 > 493 data->enable_gpio = NULL;; 494 } 495 496 data->tas2552_client = client; 497 data->regmap = devm_regmap_init_i2c(client, &tas2552_regmap_config); 498 if (IS_ERR(data->regmap)) { 499 ret = PTR_ERR(data->regmap); 500 dev_err(&client->dev, "Failed to allocate register map: %d\n", 501 ret); --- 0-DAY kernel test infrastructure Open Source Technology Center http://lists.01.org/mailman/listinfo/kbuild Intel Corporation

2 1

[alsa-devel] [asoc:topic/zx 2/8] sound/soc/zte/zx296702-i2s.c:428:3-8: No need to set .owner here. The core will do it.
by kbuild test robot 05 Jun '15

05 Jun '15

tree: git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git topic/zx head: 69ccc50231eca9a57dc06a5514103c0f17ef402e commit: e5d4cd87800ce12c356e7eb571e565e839ab3a90 [2/8] ASoC: zx: Add ZTE zx296702 I2S DAI driver coccinelle warnings: (new ones prefixed by >>) >> sound/soc/zte/zx296702-i2s.c:428:3-8: No need to set .owner here. The core will do it. Please review and possibly fold the followup patch. --- 0-DAY kernel test infrastructure Open Source Technology Center http://lists.01.org/mailman/listinfo/kbuild Intel Corporation

4 6

[alsa-devel] Reflections on implementing Web MIDI on top of ALSA seq
by Adam Goode 05 Jun '15

05 Jun '15

Hi, Chrome 43 is now in beta, with Web MIDI support. (http://blog.chromium.org/2015/04/chrome-43-beta-web-midi-and-upgrading.html) The Linux (and Chrome OS) version of Chrome uses ALSA seq to implement Web MIDI. I wanted to reflect a bit on some of the issues I discovered while implementing this new API on top of seq. This is a little bit long, so the tl;dr is: * ALSA seq worked pretty well for implementing Web MIDI, but I need a way to get the card number for a given client, before my assumptions about the kernel break. Here is a quick overview of Web MIDI (http://www.w3.org/TR/webmidi/): - provides hotplug events for port connect/disconnect - incoming events are timestamped - outgoing events can be timestamped for future delivery by the system - timestamps are high precision, and use a monotonic clock - the port abstraction contains "name", "manufacturer", and "version" fields - open ports auto-reconnect if the port disappears and reappears, for both send and receive - input and output ports are distinct: there are no duplex ports - uses MIDI bytestreams (not an event structure), but requires full MIDI messages to be sent The initial prototype of Chrome's Web MIDI support was built on top of rawmidi. I rewrote it to use seq instead (to get multiple client and user client access). Here are my observations: - Getting the "manufacturer" is very hard from seq. I needed to join against udev data, which relies on the current implementation of ALSA in the kernel. These udev attributes are also used to match for transparent reconnect. - I could not use the kernel seq timestamp, either for send or receive, since I could not get it to just use a CLOCK_MONOTONIC offset. Instead, timestamping is done in userspace. - Hotplug was tricky, since I needed to listen to both seq events and udev events. I would prefer just to use udev, since I have to anyway. I definitely want to fix the kernel so that I can stop relying on a few implementation details. Here are the current assumptions I am making: - Card based clients start at 16. (I need to know which clients actually have cards) - Clients are in the same order as cards. - There is a 1:1 correspondence between clients and OPL3+rawmidi devices. One way to fix these assumptions would be to fully expose all seq events through sysfs. Right now, there is a seq device in sysfs but it has no information. Here are some ways that the kernel might be extended to simplify the code and/or fix bad assumptions: 1. Expose all seq clients+ports as kobjects, with a symlink to the card if it's a hardware device 2. Expose all subscriptions through sysfs 3. Add a simplified timestamp mechanism that just uses a configurable system clock, with at least CLOCK_MONOTONIC available (something like what sound/core/timer.c does with tread?) The first change would allow me to eliminate all the hardcoded assumptions about which cards correspond to which clients. I believe it would also allow me to drive the hotplug logic directly from udev, instead of both udev and seq. The second change is not strictly necessary, but would remove more need to react to seq events for some uses. The third change would allow me to use the kernel timestamp reliably, since right now I timestamp events with CLOCK_MONOTONIC in userspace. If I had to start today and create a new MIDI kernel interface for ALSA, it would look like this: not-quite-raw-midi: - hotplug events completely driven by sysfs - ability to interoperate with existing seq clients (for kernel and user clients) - non-exclusive access - reads and writes use a simple structured format, with timestamp and a midi message as bytes - no or minimal alsa-lib needed - one device file per port (no subdevices) - some mechanism for creating userspace clients, preferably with some number of key-value attributes (so I can report "manufacturer" and other things if the user client sets it) Thanks for reading these reflections. Comments are welcome. Adam

2 2

[alsa-devel] [PATCH] ASoC: zte: Fix missing dev in devm operation
by Mark Brown 04 Jun '15

04 Jun '15

Signed-off-by: Mark Brown <broonie(a)kernel.org> --- sound/soc/zte/zx296702-spdif.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/soc/zte/zx296702-spdif.c b/sound/soc/zte/zx296702-spdif.c index 4a93bca232ff..11a0e46a1156 100644 --- a/sound/soc/zte/zx296702-spdif.c +++ b/sound/soc/zte/zx296702-spdif.c @@ -309,7 +309,7 @@ static int zx_spdif_probe(struct platform_device *pdev) struct zx_spdif_info *zx_spdif; int ret; - zx_spdif = devm_kzalloc(sizeof(*zx_spdif), GFP_KERNEL); + zx_spdif = devm_kzalloc(&pdev->dev, sizeof(*zx_spdif), GFP_KERNEL); if (!zx_spdif) return -ENOMEM; -- 2.1.4

1 0

[alsa-devel] [PATCH v5 0/4] Support ZTE zx296702 SPDIF/I2S
by Jun Nie 04 Jun '15

04 Jun '15

Changes vs v4: - Fix devm_zalloc argument issue in SPDIF driver and static issue in i2s. Changes vs v3: - remove HDMI stuff and will add it in video side later - Polish SPDIF driver with devm_* Changes vs v2: - remove pcm dma driver and merge the related call into DAI driver - Add zx HDMI codec with direct HDMI function call - Other typo and minor fix Jun Nie (4): dt: Add documentation for the ZTE SPDIF controller dt: Add documentation for the ZTE I2S controller ASoC: zx: Add zx296702 SPDIF support ASoC: zx: Add ZTE zx296702 I2S DAI driver .../devicetree/bindings/sound/zte,zx-i2s.txt | 44 +++ .../devicetree/bindings/sound/zte,zx-spdif.txt | 28 ++ sound/soc/Kconfig | 1 + sound/soc/Makefile | 1 + sound/soc/zte/Kconfig | 17 + sound/soc/zte/Makefile | 2 + sound/soc/zte/zx296702-i2s.c | 437 +++++++++++++++++++++ sound/soc/zte/zx296702-spdif.c | 370 +++++++++++++++++ 8 files changed, 900 insertions(+) create mode 100644 Documentation/devicetree/bindings/sound/zte,zx-i2s.txt create mode 100644 Documentation/devicetree/bindings/sound/zte,zx-spdif.txt create mode 100644 sound/soc/zte/Kconfig create mode 100644 sound/soc/zte/Makefile create mode 100644 sound/soc/zte/zx296702-i2s.c create mode 100644 sound/soc/zte/zx296702-spdif.c -- 1.9.1

2 5

[alsa-devel] Different codecs for playback and capture?
by Ricard Wanderlof 04 Jun '15

04 Jun '15

Hi, I'm developing a machine driver for a system where we have two different codecs for input and output, connected to the same I2S interface. Normally a machine driver specifies which codec the I2S interface is connected to, but in this case there should really be two different ones, one for record and one for playback. I'm working on how to put this together, and just thought I'd try and get some input before going too far down the wrong track. The options I see are: 1. Specify two different codecs in the machine driver. Since one can specify several dai_links this would seem to be doable, however, I'm not sure ALSA can handle two codecs sharing a single CPU DAI in this way? 2. Use two separate machine drivers, one for each codec? Again, sharing a single CPU DAI would seem to be an issue here? 3. Write a special codec driver that is a merge between the two codecs, one for input and one for output. Seems like a bit of a hack, but should be possible. Any spontaneous thoughts? /Ricard -- Ricard Wolf Wanderlöf ricardw(at)axis.com Axis Communications AB, Lund, Sweden www.axis.com Phone +46 46 272 2016 Fax +46 46 13 61 30

2 8