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

[alsa-devel] [PATCH] ALSA: dice: add support for M-Audio Profire 610 and perhaps 2626
by Takashi Sakamoto 09 May '16

09 May '16

M-Audio Profire 610 has an unexpected value in version field of its config ROM, thus ALSA dice driver is not assigned to the model due to a mismatch of modalias. This commit adds an entry to support the model. I expect the entry is also for Profire 2626. I note that Profire 610 uses TCD2220 (so-called Dice Jr.), and supports a part of Extended Application Protocol (EAP). $ cd linux-firewire-utils/src $ ./crpp < /sys/bus/firewire/devices/fw1/config_rom ROM header and bus information block ------------------------------------------------------------ 400 04047689 bus_info_length 4, crc_length 4, crc 30345 404 31333934 bus_name "1394" 408 e0ff8112 irmc 1, cmc 1, isc 1, bmc 0, pmc 0, cyc_clk_acc 255, max_rec 8 (512), max_rom 1, gen 1, spd 2 (S400) 40c 000d6c04 company_id 000d6c | 410 04400002 device_id 0404400002 | EUI-64 000d6c0404400002 root directory ------------------------------------------------------------ 414 000695fe directory_length 6, crc 38398 418 03000d6c vendor 41c 8100000a --> descriptor leaf at 444 420 17000011 model 424 8100000d --> descriptor leaf at 458 428 0c0087c0 node capabilities per IEEE 1394 42c d1000001 --> unit directory at 430 unit directory at 430 ------------------------------------------------------------ 430 0004fb14 directory_length 4, crc 64276 434 12000d6c specifier id 438 130100d1 version 43c 17000011 model 440 8100000c --> descriptor leaf at 470 descriptor leaf at 444 ------------------------------------------------------------ 444 0004b8e4 leaf_length 4, crc 47332 448 00000000 textual descriptor 44c 00000000 minimal ASCII 450 4d2d4175 "M-Au" 454 64696f00 "dio" descriptor leaf at 458 ------------------------------------------------------------ 458 00053128 leaf_length 5, crc 12584 45c 00000000 textual descriptor 460 00000000 minimal ASCII 464 50726f46 "ProF" 468 69726520 "ire " 46c 36313000 "610" descriptor leaf at 470 ------------------------------------------------------------ 470 00053128 leaf_length 5, crc 12584 474 00000000 textual descriptor 478 00000000 minimal ASCII 47c 50726f46 "ProF" 480 69726520 "ire " 484 36313000 "610" $ cat /proc/asound/card1/dice sections: global: offset 10, size 90 tx: offset 100, size 142 rx: offset 242, size 282 ext_sync: offset 524, size 4 unused2: offset 0, size 0 global: owner: ffc0:000100000000 notification: 00000040 nick name: FW610 clock select: internal 48000 enable: 1 status: locked 48000 ext status: 00000040 sample rate: 48000 version: 1.0.4.0 clock caps: 32000 44100 48000 88200 96000 176400 192000 aes1 aes4 aes adat tdif wc arx1 arx2 internal clock source names: SPDIF\AES34\AES56\TOS\AES_ANY\ADAT\ADAT_AUX\Word Clock\Unused\Unused\Unused\Unused\Internal\\ ... Signed-off-by: Takashi Sakamoto <o-takashi(a)sakamocchi.jp> --- sound/firewire/dice/dice.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/sound/firewire/dice/dice.c b/sound/firewire/dice/dice.c index 96fe68f4..25e9f77 100644 --- a/sound/firewire/dice/dice.c +++ b/sound/firewire/dice/dice.c @@ -317,6 +317,13 @@ static const struct ieee1394_device_id dice_id_table[] = { .match_flags = IEEE1394_MATCH_VERSION, .version = DICE_INTERFACE, }, + /* M-Audio Profire 610/2626 has a different value in version field. */ + { + .match_flags = IEEE1394_MATCH_VENDOR_ID | + IEEE1394_MATCH_SPECIFIER_ID, + .vendor_id = 0x000d6c, + .specifier_id = 0x000d6c, + }, { } }; MODULE_DEVICE_TABLE(ieee1394, dice_id_table); -- 2.7.4

2 4

[alsa-devel] [PATCH 0/6] topology: complete PCM parsing and code refactoring
by mengdong.lin＠linux.intel.com 08 May '16

08 May '16

From: Mengdong Lin <mengdong.lin(a)linux.intel.com> There is no ABI change in this series. This series fixes bugs and missing info of PCM (Front-end DAI & DAI link) defined by the text conf file. There is also some code refactoring, as a preparation for Back-end DAI support and ABI update which is under internal test and review atm. Mengdong Lin (6): topology: Set manifest size for ABI topology: Refactor functions to parse and build streams topology: Use generic pointer to realloc buffer for private data topology: Fix pcm ID & name parsing topology: Parse front-end DAI name and ID for the PCM topology: Update PCM configurations in Broadwell text conf file include/sound/asoc.h | 2 +- include/topology.h | 4 + src/conf/topology/broadwell/broadwell.conf | 34 ++++++--- src/topology/data.c | 24 ++---- src/topology/parser.c | 4 +- src/topology/pcm.c | 119 ++++++++++++++++++++++------- src/topology/tplg_local.h | 2 +- 7 files changed, 131 insertions(+), 58 deletions(-) -- 2.5.0

5 11

[alsa-devel] sound: deadlock involving snd_hrtimer_callback
by Dmitry Vyukov 08 May '16

08 May '16

Hi Takashi, I've incorporated your hrtimer fixes (but also updated to ddce192106e4f984123884f8e878f66ace94b573) and now I am seeing lots of the following deadlock messages: [ INFO: possible circular locking dependency detected ] 4.6.0-rc4+ #351 Not tainted ------------------------------------------------------- swapper/0/0 is trying to acquire lock: (&(&timer->lock)->rlock){-.-...}, at: [<ffffffff8537a749>] snd_timer_interrupt+0xa9/0xd30 sound/core/timer.c:701 but task is already holding lock: (&(&stime->lock)->rlock){-.....}, at: [<ffffffff85383d3f>] snd_hrtimer_callback+0x4f/0x2b0 sound/core/hrtimer.c:54 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (&(&stime->lock)->rlock){-.....}: [<ffffffff81477693>] lock_acquire+0x1e3/0x460 kernel/locking/lockdep.c:3677 [< inline >] __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:112 [<ffffffff867c005f>] _raw_spin_lock_irqsave+0x9f/0xd0 kernel/locking/spinlock.c:159 [<ffffffff85383baa>] snd_hrtimer_start+0x4a/0xf0 sound/core/hrtimer.c:112 [<ffffffff85379c74>] snd_timer_start1+0x2b4/0x5a0 sound/core/timer.c:457 [<ffffffff8537d33d>] snd_timer_start+0x5d/0xa0 sound/core/timer.c:571 [< inline >] seq_timer_start sound/core/seq/seq_timer.c:393 [<ffffffff853fc260>] snd_seq_timer_start+0x1a0/0x2b0 sound/core/seq/seq_timer.c:405 [< inline >] snd_seq_queue_process_event sound/core/seq/seq_queue.c:687 [<ffffffff853f6f14>] snd_seq_control_queue+0x304/0x8b0 sound/core/seq/seq_queue.c:748 [<ffffffff853fcbb5>] event_input_timer+0x25/0x30 sound/core/seq/seq_system.c:118 [<ffffffff853ef7d4>] snd_seq_deliver_single_event.constprop.11+0x3f4/0x740 sound/core/seq/seq_clientmgr.c:636 [<ffffffff853efc38>] snd_seq_deliver_event+0x118/0x800 sound/core/seq/seq_clientmgr.c:833 [<ffffffff853f1026>] snd_seq_kernel_client_dispatch+0x126/0x170 sound/core/seq/seq_clientmgr.c:2418 [<ffffffff85405c2b>] send_timer_event.isra.0+0x10b/0x150 sound/core/seq/oss/seq_oss_timer.c:153 [<ffffffff8540615a>] snd_seq_oss_timer_start+0x1ca/0x310 sound/core/seq/oss/seq_oss_timer.c:174 [< inline >] old_event sound/core/seq/oss/seq_oss_event.c:125 [<ffffffff854095ff>] snd_seq_oss_process_event+0xa1f/0x2ce0 sound/core/seq/oss/seq_oss_event.c:100 [< inline >] insert_queue sound/core/seq/oss/seq_oss_rw.c:179 [<ffffffff8540c201>] snd_seq_oss_write+0x321/0x810 sound/core/seq/oss/seq_oss_rw.c:148 [<ffffffff85403f99>] odev_write+0x59/0xa0 sound/core/seq/oss/seq_oss.c:177 [<ffffffff817f3fc3>] __vfs_write+0x113/0x4b0 fs/read_write.c:529 [<ffffffff817f5a97>] vfs_write+0x167/0x4a0 fs/read_write.c:578 [< inline >] SYSC_write fs/read_write.c:625 [<ffffffff817f98d1>] SyS_write+0x111/0x220 fs/read_write.c:617 [<ffffffff867c0440>] entry_SYSCALL_64_fastpath+0x23/0xc1 arch/x86/entry/entry_64.S:207 -> #0 (&(&timer->lock)->rlock){-.-...}: [< inline >] check_prev_add kernel/locking/lockdep.c:1823 [< inline >] check_prevs_add kernel/locking/lockdep.c:1933 [< inline >] validate_chain kernel/locking/lockdep.c:2238 [<ffffffff81474035>] __lock_acquire+0x3625/0x4d00 kernel/locking/lockdep.c:3298 [<ffffffff81477693>] lock_acquire+0x1e3/0x460 kernel/locking/lockdep.c:3677 [< inline >] __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:112 [<ffffffff867c005f>] _raw_spin_lock_irqsave+0x9f/0xd0 kernel/locking/spinlock.c:159 [<ffffffff8537a749>] snd_timer_interrupt+0xa9/0xd30 sound/core/timer.c:701 [<ffffffff85383e75>] snd_hrtimer_callback+0x185/0x2b0 sound/core/hrtimer.c:59 [< inline >] __run_hrtimer kernel/time/hrtimer.c:1242 [<ffffffff814d1071>] __hrtimer_run_queues+0x331/0xe90 kernel/time/hrtimer.c:1306 [<ffffffff814d3a42>] hrtimer_interrupt+0x182/0x430 kernel/time/hrtimer.c:1340 [<ffffffff8125aa52>] local_apic_timer_interrupt+0x72/0xe0 arch/x86/kernel/apic/apic.c:907 [<ffffffff867c2d59>] smp_apic_timer_interrupt+0x79/0xa0 arch/x86/kernel/apic/apic.c:931 [<ffffffff867c10ac>] apic_timer_interrupt+0x8c/0xa0 arch/x86/entry/entry_64.S:454 [< inline >] arch_safe_halt ./arch/x86/include/asm/paravirt.h:118 [<ffffffff8120f402>] default_idle+0x52/0x370 arch/x86/kernel/process.c:307 [<ffffffff81210bba>] arch_cpu_idle+0xa/0x10 arch/x86/kernel/process.c:298 [<ffffffff81454c28>] default_idle_call+0x48/0xa0 kernel/sched/idle.c:93 [< inline >] cpuidle_idle_call kernel/sched/idle.c:151 [< inline >] cpu_idle_loop kernel/sched/idle.c:242 [<ffffffff8145520f>] cpu_startup_entry+0x58f/0x7b0 kernel/sched/idle.c:291 [<ffffffff8679ac6d>] rest_init+0x18d/0x1a0 init/main.c:408 [<ffffffff88ce7759>] start_kernel+0x63a/0x660 init/main.c:661 [<ffffffff88ce6364>] x86_64_start_reservations+0x38/0x3a arch/x86/kernel/head64.c:195 [<ffffffff88ce64be>] x86_64_start_kernel+0x158/0x167 arch/x86/kernel/head64.c:176 other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&(&stime->lock)->rlock); lock(&(&timer->lock)->rlock); lock(&(&stime->lock)->rlock); lock(&(&timer->lock)->rlock); *** DEADLOCK *** 1 lock held by swapper/0/0: #0: (&(&stime->lock)->rlock){-.....}, at: [<ffffffff85383d3f>] snd_hrtimer_callback+0x4f/0x2b0 sound/core/hrtimer.c:54 stack backtrace: CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.6.0-rc4+ #351 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 ffffffff87eb25c0 ffff88003ec07a50 ffffffff82c8f92f ffffffff00000000 fffffbfff0fd64b8 ffffffff8997bad0 ffffffff8997bad0 ffffffff8998aa70 ffffffff87e27510 ffffffff87e26d00 ffff88003ec07aa0 ffffffff8146cf58 Call Trace: <IRQ> [< inline >] __dump_stack lib/dump_stack.c:15 <IRQ> [<ffffffff82c8f92f>] dump_stack+0x12e/0x18f lib/dump_stack.c:51 [<ffffffff8146cf58>] print_circular_bug+0x288/0x340 kernel/locking/lockdep.c:1196 [< inline >] check_prev_add kernel/locking/lockdep.c:1823 [< inline >] check_prevs_add kernel/locking/lockdep.c:1933 [< inline >] validate_chain kernel/locking/lockdep.c:2238 [<ffffffff81474035>] __lock_acquire+0x3625/0x4d00 kernel/locking/lockdep.c:3298 [<ffffffff81477693>] lock_acquire+0x1e3/0x460 kernel/locking/lockdep.c:3677 [< inline >] __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:112 [<ffffffff867c005f>] _raw_spin_lock_irqsave+0x9f/0xd0 kernel/locking/spinlock.c:159 [<ffffffff8537a749>] snd_timer_interrupt+0xa9/0xd30 sound/core/timer.c:701 [<ffffffff85383e75>] snd_hrtimer_callback+0x185/0x2b0 sound/core/hrtimer.c:59 [< inline >] __run_hrtimer kernel/time/hrtimer.c:1242 [<ffffffff814d1071>] __hrtimer_run_queues+0x331/0xe90 kernel/time/hrtimer.c:1306 [<ffffffff814d3a42>] hrtimer_interrupt+0x182/0x430 kernel/time/hrtimer.c:1340 [<ffffffff8125aa52>] local_apic_timer_interrupt+0x72/0xe0 arch/x86/kernel/apic/apic.c:907 [<ffffffff867c2d59>] smp_apic_timer_interrupt+0x79/0xa0 arch/x86/kernel/apic/apic.c:931 [<ffffffff867c10ac>] apic_timer_interrupt+0x8c/0xa0 arch/x86/entry/entry_64.S:454 [< inline >] arch_safe_halt ./arch/x86/include/asm/paravirt.h:118 [<ffffffff8120f402>] default_idle+0x52/0x370 arch/x86/kernel/process.c:307 [<ffffffff81210bba>] arch_cpu_idle+0xa/0x10 arch/x86/kernel/process.c:298 [<ffffffff81454c28>] default_idle_call+0x48/0xa0 kernel/sched/idle.c:93 [< inline >] cpuidle_idle_call kernel/sched/idle.c:151 [< inline >] cpu_idle_loop kernel/sched/idle.c:242 [<ffffffff8145520f>] cpu_startup_entry+0x58f/0x7b0 kernel/sched/idle.c:291 [<ffffffff8679ac6d>] rest_init+0x18d/0x1a0 init/main.c:408 [<ffffffff88ce7759>] start_kernel+0x63a/0x660 init/main.c:661 [<ffffffff88ce6364>] x86_64_start_reservations+0x38/0x3a arch/x86/kernel/head64.c:195 [<ffffffff88ce64be>] x86_64_start_kernel+0x158/0x167 arch/x86/kernel/head64.c:176 They are also followed by rcu stalls and actual spinlock lockups: BUG: spinlock lockup suspected on CPU#3, syz-fuzzer/7040 lock: 0xffff880032ae2bd8, .magic: dead4ead, .owner: syz-executor/11206, .owner_cpu: 0 CPU: 3 PID: 7040 Comm: syz-fuzzer Not tainted 4.6.0-rc4+ #351 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 ffffffff87eb25c0 ffff88006d507c40 ffffffff82c8f92f ffffffff2c963698 fffffbfff0fd64b8 ffff880032ae2bd8 ffff88002c963040 ffff880061238040 ffff880032ae2be0 000000009a9d0630 ffff88006d507c78 ffffffff8147f58d Call Trace: <IRQ> [< inline >] __dump_stack lib/dump_stack.c:15 <IRQ> [<ffffffff82c8f92f>] dump_stack+0x12e/0x18f lib/dump_stack.c:51 [<ffffffff8147f58d>] spin_dump+0x14d/0x280 kernel/locking/spinlock_debug.c:67 [< inline >] __spin_lock_debug kernel/locking/spinlock_debug.c:117 [<ffffffff8147f8ad>] do_raw_spin_lock+0x15d/0x2b0 kernel/locking/spinlock_debug.c:137 [< inline >] __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:119 [<ffffffff867c0067>] _raw_spin_lock_irqsave+0xa7/0xd0 kernel/locking/spinlock.c:159 [<ffffffff8537a749>] snd_timer_interrupt+0xa9/0xd30 sound/core/timer.c:701 [<ffffffff85383e75>] snd_hrtimer_callback+0x185/0x2b0 sound/core/hrtimer.c:59 [< inline >] __run_hrtimer kernel/time/hrtimer.c:1242 [<ffffffff814d1071>] __hrtimer_run_queues+0x331/0xe90 kernel/time/hrtimer.c:1306 [<ffffffff814d3a42>] hrtimer_interrupt+0x182/0x430 kernel/time/hrtimer.c:1340 [<ffffffff8125aa52>] local_apic_timer_interrupt+0x72/0xe0 arch/x86/kernel/apic/apic.c:907 [<ffffffff867c2d59>] smp_apic_timer_interrupt+0x79/0xa0 arch/x86/kernel/apic/apic.c:931 [<ffffffff867c10ac>] apic_timer_interrupt+0x8c/0xa0 arch/x86/entry/entry_64.S:454 <EOI>

2 11

[alsa-devel] Unlikely big volume range Plantronics BT300
by Dennis Kadioglu 08 May '16

08 May '16

Hi, when I connect the bluetooth BT300 of my Plantronics Headset I can see the following warning: [172855.985539] usb 2-1.3: Warning! Unlikely big volume range (=720), cval->res is probably wrong. [172855.985544] usb 2-1.3: [5] FU [PCM Playback Volume] ch = 1, val = -10240/1280/16 As far as I understand it, the problem may be solved by applying a quirk which is already applied for Logitech webcams. Can somebody help me in finding out the correct value for cval->res. I have no clue which calculations are necessary for that. Thanks in advance. Dennis Kadioglu

2 2

[alsa-devel] [PATCH 0/7] ASoC: Mediatek: Add support for MT2701 SOC
by Garlic Tseng 06 May '16

06 May '16

This patch adds basic support for Mediatek AFE for MT2701 SoC. The patch is based on broonie tree "for-next" branch. Change since RFC v2: add BT function refine Kconfig and Makefile add prefix 'mt8173' and 'mt2701' for relative drivers. Garlic Tseng (7): ASoC: mediatek: Refine mt8173 driver and change config option ASoC: mediatek: add documents for mt2701 ASoC: mediatek: add clock and irq control for 2701 platform driver ASoC: mediatek: add mt2701 platform driver implementation. ASoC: bt-sco: extend rate and add a general compatible string ASoC: mediatek: add BT implementation ASoC: mediatek: Add mt2701-cs42448 driver and config option. Documentation/devicetree/bindings/sound/bt-sco.txt | 2 +- .../devicetree/bindings/sound/mt2701-afe-pcm.txt | 150 ++ .../devicetree/bindings/sound/mt2701-cs42448.txt | 43 + sound/soc/codecs/bt-sco.c | 5 +- sound/soc/mediatek/Kconfig | 35 +- sound/soc/mediatek/Makefile | 9 +- sound/soc/mediatek/mt2701/Makefile | 20 + sound/soc/mediatek/mt2701/mt2701-afe-clock-ctrl.c | 344 ++++ sound/soc/mediatek/mt2701/mt2701-afe-clock-ctrl.h | 33 + sound/soc/mediatek/mt2701/mt2701-afe-common.h | 228 +++ sound/soc/mediatek/mt2701/mt2701-afe-pcm.c | 1825 ++++++++++++++++++++ sound/soc/mediatek/mt2701/mt2701-cs42448.c | 412 +++++ sound/soc/mediatek/mt2701/mt2701-irq.c | 74 + sound/soc/mediatek/mt2701/mt2701-irq.h | 26 + sound/soc/mediatek/mt2701/mt2701-reg.h | 195 +++ sound/soc/mediatek/mt8173/Makefile | 7 + sound/soc/mediatek/mt8173/mt8173-afe-common.h | 101 ++ .../{mtk-afe-pcm.c => mt8173/mt8173-afe-pcm.c} | 488 +++--- sound/soc/mediatek/{ => mt8173}/mt8173-max98090.c | 2 +- .../mediatek/{ => mt8173}/mt8173-rt5650-rt5514.c | 2 +- .../mediatek/{ => mt8173}/mt8173-rt5650-rt5676.c | 4 +- sound/soc/mediatek/{ => mt8173}/mt8173-rt5650.c | 2 +- sound/soc/mediatek/mtk-afe-common.h | 101 -- 23 files changed, 3740 insertions(+), 368 deletions(-) create mode 100644 Documentation/devicetree/bindings/sound/mt2701-afe-pcm.txt create mode 100644 Documentation/devicetree/bindings/sound/mt2701-cs42448.txt create mode 100644 sound/soc/mediatek/mt2701/Makefile create mode 100644 sound/soc/mediatek/mt2701/mt2701-afe-clock-ctrl.c create mode 100644 sound/soc/mediatek/mt2701/mt2701-afe-clock-ctrl.h create mode 100644 sound/soc/mediatek/mt2701/mt2701-afe-common.h create mode 100644 sound/soc/mediatek/mt2701/mt2701-afe-pcm.c create mode 100644 sound/soc/mediatek/mt2701/mt2701-cs42448.c create mode 100644 sound/soc/mediatek/mt2701/mt2701-irq.c create mode 100644 sound/soc/mediatek/mt2701/mt2701-irq.h create mode 100644 sound/soc/mediatek/mt2701/mt2701-reg.h create mode 100644 sound/soc/mediatek/mt8173/Makefile create mode 100644 sound/soc/mediatek/mt8173/mt8173-afe-common.h rename sound/soc/mediatek/{mtk-afe-pcm.c => mt8173/mt8173-afe-pcm.c} (67%) rename sound/soc/mediatek/{ => mt8173}/mt8173-max98090.c (99%) rename sound/soc/mediatek/{ => mt8173}/mt8173-rt5650-rt5514.c (99%) rename sound/soc/mediatek/{ => mt8173}/mt8173-rt5650-rt5676.c (99%) rename sound/soc/mediatek/{ => mt8173}/mt8173-rt5650.c (99%) delete mode 100644 sound/soc/mediatek/mtk-afe-common.h -- 1.9.1

3 13

[alsa-devel] [PATCH 0/2 v6] Add I2S audio support for ARC AXS10x boards
by Jose Abreu 04 May '16

04 May '16

ARC AXS10x platforms consist of a mainboard with several peripherals. One of those peripherals is an HDMI output port controlled by the ADV7511 transmitter. This patch set adds I2S audio for the AXS10x platform. Changes v5 -> v6 * Use SNDRV_DMA_TYPE_CONTINUOUS Changes v4 -> v5 * Resolve undefined references when compiling as module * Dropped adv7511 audio patches * Use DMA properties in I2S to check which mode to use: PIO or DMA (as suggested by Lars-Peter Clausen) Changes v3 -> v4: * Reintroduced custom PCM driver (see note below) * Use DT boolean to switch between ALSA DMA engine PCM or custom PCM * Use fifo depth to program I2S FCR * Update I2S documentation Changes v2 -> v3: * Removed pll_config functions (as suggested by Alexey Brodkin) * Removed HDMI start at adv7511_core (as suggested by Archit Taneja) * Use NOP functions for adv7511_audio (as suggested by Archit Taneja) * Added adv7511_audio_exit() function (as suggested by Archit Taneja) * Moved adv7511 to its own folder (as suggested by Archit Taneja) * Separated file rename of adv7511_core (as suggested by Emil Velikov) * Compile adv7511 as module if ALSA SoC is compiled as module * Load adv7511 audio only if declared in device tree (as suggested by Laurent Pinchart) * Dropped custom platform driver, using now ALSA DMA engine * Dropped IRQ handler for I2S Changes v1 -> v2: * DT bindings moved to separate patch (as suggested by Alexey Brodkin) * Removed defconfigs entries (as suggested by Alexey Brodkin) NOTE: Although the mainline I2S driver uses ALSA DMA engine, this controller can be built without DMA support so it was necessary to add this custom platform driver so that HDMI audio works in AXS boards. Cc: Carlos Palminha <palminha(a)synopsys.com> Cc: Mark Brown <broonie(a)kernel.org> Cc: Liam Girdwood <lgirdwood(a)gmail.com> Cc: Jaroslav Kysela <perex(a)perex.cz> Cc: Takashi Iwai <tiwai(a)suse.com> Cc: Rob Herring <robh(a)kernel.org> Cc: Alexey Brodkin <abrodkin(a)synopsys.com> Cc: linux-snps-arc(a)lists.infradead.org Cc: alsa-devel(a)alsa-project.org Cc: devicetree(a)vger.kernel.org Cc: linux-kernel(a)vger.kernel.org Jose Abreu (2): ASoC: dwc: Add custom PCM driver ASoC: dwc: Update DOCUMENTATION for I2S Driver .../devicetree/bindings/sound/designware-i2s.txt | 9 +- sound/soc/dwc/Kconfig | 9 + sound/soc/dwc/Makefile | 1 + sound/soc/dwc/designware.h | 71 +++++++ sound/soc/dwc/designware_i2s.c | 94 ++++++--- sound/soc/dwc/designware_pcm.c | 228 +++++++++++++++++++++ 6 files changed, 383 insertions(+), 29 deletions(-) create mode 100644 sound/soc/dwc/designware.h create mode 100644 sound/soc/dwc/designware_pcm.c -- 1.9.1

2 9

[alsa-devel] [PATCH v6 0/4] Propagate errors out from compressed streams
by Charles Keepax 04 May '16

04 May '16

If the DSP suffers an unrecoverable error, the driver likely knows about this, however the framework may not get informed because errors returned from pointer requests are ignored within the framework. Things work out fine if user-space is doing a read as reads return error status back to user-space so the user can find out that things have gone bad. However, if user-space is doing an avail request there is no path for the error to come back up to user-space. The pointer request returns zero available data, so a read never happens and we basically just end up sitting waiting for data on a stream that we know full well has died. This patch set attempts to address this and ensure that errors are fully propagated to user-space and we don't ever end up wait for data that will never come. Changes since v5: - Add a debug print to note which state we transition to in snd_compr_stop_error It might be easiest to put the ASoC changes through Mark's tree as there are some merge conflicts otherwise, as such I have based this series on Mark's tree. Thanks, Charles Charles Keepax (4): ALSA: compress: Replace complex if statement with switch ALSA: compress: Add function to indicate the stream has gone bad ASoC: wm_adsp: Use new snd_compr_stop_error to signal stream failure ASoC: compress: Pass error out of soc_compr_pointer include/sound/compress_driver.h | 5 +++ sound/core/compress_offload.c | 81 ++++++++++++++++++++++++++++++++++++++--- sound/soc/codecs/wm_adsp.c | 11 +++++- sound/soc/soc-compress.c | 5 ++- 4 files changed, 93 insertions(+), 9 deletions(-) -- 2.1.4

1 6

[alsa-devel] [PATCH v3 0/6] ASoC: fsl_ssi: Fixing various channel slips and bad samples insertions
by Arnaud Mouiche 03 May '16

03 May '16

This series of patch is an attempt to fix the fsl_ssi driver to use it in TDM mode (DSP A or B) with a large number of channels/slots. Version 3: - rebase + fix + test on top of linux 4.4 + 'for-next' Version 2: - fixing a missing patch - checkpatch.pl - ... well, learning how to send a patchset. Sorry. Bugs are detected and fixed on a imx6sl platform with linux 4.4 + 'for-next' branch, where 2 SSI interfaces are used. SSI3 configured as a master of the bus, SSI2 as a slave. Similar tests were done on a imx6solo platform by Caleb Crome (He will propose a patch concerning fifo depth to fix DMA xrun at highest bitrates) Various loopback scenario are tested: * scenario 1: SSI3 (master) with TXD to RXD loopback | |---> TXD --\ SSI3 |<--- RXD --/ (master) |---> SYNC |---> BCLK | * scenario 2: SSI3 connected to SSI2 | |---> TXD --------\ SSI3 |<--- RXD -----\ | (master) |---> SYNC --\ | | |---> BCLK | | | | | | | | | | | | | |<--- BCLK | | | SSI2 |<--- SYNC --/ | | (slave) |---> TXD ------/ | |<--- RXD --------/ | A test software (called atest) was developed and available. [1] It basically generate/check specials frames with S16_LE sequence samples NNN0, NNN1, NNN2 ... NNNC with NNN = frame number, and C the number of channels-1 Patch 1: Limitation fix. Prerequisite to use the fsl_ssi driver with up to 32 channels / slots Patch 2: Bug fix. Prerequisite to setup a relative high bitclk for our tests in 8ch / 16bits / 48kHz Patch 3: Simply save a 'dev' reference inside ssi_private for dev_err() purpose. (ssi_private is only available in lot of places, and ssi_private->pdev is deprecated and NULL indeed) Patch 4: Fix playback samples being dropped because the TX fifo was not ready at the time the DMA starts filling (only in case where playback is started AFTER the capture) Detected in loopback scenario 1, with following script (> 80 % of reproducibility) $ atest -D SSI3 -c 8 -r 48000 capture play dbg: set period size: 960 dbg: SSI3: capture_start dbg: SSI3: playback_start err: invalid frame after 1 null frames err: 0000 0000 0013 0014 0015 0016 0017 0020 dbg: SIGINT total number of sequence errors: 21119 here we see that samples 0000 0001 ... 0012 are not present in the output. In addition, this the number of samples dropped is not a multiple of the number of channel, we have a a channel slip. Patch 5: This is the Caleb Crome's case [2], where the SSI starts to generate samples while the TX FIFO is not filled by the DMA yet. Void samples can be inserted before DMA streaming. Detected in loopback scenario 2, with following script (reproducibility < 1%) $ atest -D SSI3 -c 8 -r 48000 capture & $ sleep 0.2 $ atest -d 1 -D SSI2 -c 8 -r 48000 play dbg: SSI3: capture_start dbg: set period size: 960 dbg: SSI2: playback_start dbg: start a 1 seconds duration timer err: invalid frame after 11568 null frames err: 0000 0010 0011 0012 0013 0014 0015 0016 err: 0017 0020 0021 0022 0023 0024 0025 0026 Patch 6: Deals with Capture restart whereas Playback is still running (or the opposite, Playback restart whereas Capture is till running). Capture restart whereas Playback case is detected in loopback scenario 1 (reproducibility 100%). A playback session is running in background, and 2 consecutive Captures are performed. The first is fine, the second fails. We see at the 2nd capture startup that we receive 15 samples still pending in the RX FIFO from the previous capture session. => We are receiving invalid samples + slips the channels $ atest -D SSI3 -c 8 -r 48000 play & dbg: SSI3: playback_start $ atest -d 1 -D SSI3 -c 8 -r 48000 capture dbg: SSI3: capture_start dbg: start a 1 seconds duration timer warn: Valid frame after 1 null frames warn: 3a90 3a91 3a92 3a93 3a94 3a95 3a96 3a97 total number of sequence errors: 0 $ atest -I 5 -d 1 -D SSI3 -c 8 -r 48000 capture # restart the capture dbg: SSI3: capture_start dbg: start a 1 seconds duration timer err: invalid frame after 1 null frames err: 8dd6 8dd7 8de0 8de1 8de2 8de3 8de4 8de5 err: 8de6 8de7 8df0 8df1 8df2 8df3 8df4 c0c0 err: c0c1 c0c2 c0c3 c0c4 c0c5 c0c6 c0c7 c0d0 err: c0d1 c0d2 c0d3 c0d4 c0d5 c0d6 c0d7 c0e0 err: c0e1 c0e2 c0e3 c0e4 c0e5 c0e6 c0e7 c0f0 Playback restart whereas Capture case is also detected with loopback scenario 1 (reproducibility 100%), capturing continuously, and playing by periods of time. $ atest -a -D SSI3 -c 8 -r 48000 capture play -r 1000,200 dbg: SSI3: capture_start dbg: SSI3: playback_start dbg: SSI3: will stop every 1000 ms during 200 ms warn: Valid frame after 4 null frames warn: 0010 0011 0012 0013 0014 0015 0016 0017 warn: SSI3: PT_W4_STOP warn: SSI3: PT_W4_RESTART err: invalid frame after 1602 null frames err: eaa1 eaa2 eaa3 eaa4 eaa5 eaa6 eaa7 eab0 err: eab1 eab2 eab3 eab4 5810 5811 5812 5813 dbg: stop on first error total number of sequence errors: 143 Both cases are resolved by using the mostly undocumented SOR.RX_CLR and SOR TX_CLR (we can find the documentation in IMX51 reference manual at section 56.3.3.15). Arnaud [1] https://github.com/amouiche/atest [2] http://mailman.alsa-project.org/pipermail/alsa-devel/2015-October/099221.ht… Arnaud Mouiche (6): ASoC: fsl_ssi: Real hardware channels max number is 32 ASoC: fsl_ssi: The IPG/5 limitation concerns the bitclk, not the sysclk. ASoC: fsl_ssi: Save a dev reference for dev_err() purpose. ASoC: fsl_ssi: Fix samples being dropped as Playback startup ASoC: fsl_ssi: Fix channel slipping in Playback at startup ASoC: fsl_ssi: Fix channel slipping on capture (or playback) restart in full duplex. sound/soc/fsl/fsl_ssi.c | 81 ++++++++++++++++++++++++++++++++++++++++++------- 1 file changed, 70 insertions(+), 11 deletions(-) -- 1.9.1

6 20

[alsa-devel] iMX6UL EVK with kernel 4.6
by Petr Kulhavy 02 May '16

02 May '16

Hi, I'm trying to run the latest mainline kernel 4.6 on the iMX6UL EVK. The board mostly works and the only problem is audio. Even though the sound card is detected and the ALSA mixer can be controlled there is no MCLK coming out of the SAI2 interface. All the related peripherals in the DTS (pinmux, SAI2, sound card, codec) seem to be set-up correctly, I also tried out various things like disabling the ASRC, but without success and I'm slowly running out of ideas. Could somebody give me a hint please, what is different to the Freescale kernel branch where the MCLK works? By the way, why aren't the Freescale patches merged to the mainline kernel? Thanks Petr

2 14

Re: [alsa-devel] bytcr_rt5640.c:(.text+0x1593b4): undefined reference to `sst_acpi_find_name_from_hid'
by Randy Dunlap 02 May '16

02 May '16

On 03/29/16 07:21, Borislav Petkov wrote: > Hi guys, > > I'm seeing a bunch of those errors today on randconfig builds: > > sound/built-in.o: In function `snd_byt_rt5640_mc_probe': > bytcr_rt5640.c:(.text+0x1593b4): undefined reference to `sst_acpi_find_name_from_hid' > make: *** [vmlinux] Error 1 > > ERROR: "sst_acpi_find_name_from_hid" [sound/soc/intel/boards/snd-soc-sst-bytcr-rt5640.ko] undefined! > make[1]: *** [__modpost] Error 1 > make: *** [modules] Error 2 > make: *** Waiting for unfinished jobs.... > > Some of the failing configs attached. > I have 2 patches for this. I'll send them right away. -- ~Randy

2 1