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

[alsa-devel] [PATCH] ASoC: Intel: Atom: Fix message handling during drop stream
by Harsha Priya 31 Aug '16

31 Aug '16

If a stream is being dropped, the period_elapsed received then after need not be processed. Processing of the period_elapsed message causes a time out in drop stream response processing. This patch adds a condition to skip period_elapsed message processing if the stream is in INIT state. Signed-off-by: Harsha Priya <harshapriya.n(a)intel.com> Signed-off-by: Naveen M <naveen.m(a)intel.com> --- sound/soc/intel/atom/sst/sst_ipc.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/sound/soc/intel/atom/sst/sst_ipc.c b/sound/soc/intel/atom/sst/sst_ipc.c index 8afa6fe..bfc8899 100644 --- a/sound/soc/intel/atom/sst/sst_ipc.c +++ b/sound/soc/intel/atom/sst/sst_ipc.c @@ -267,6 +267,9 @@ static void process_fw_async_msg(struct intel_sst_drv *sst_drv_ctx, "Period elapsed rcvd for pipe id 0x%x\n", pipe_id); stream = &sst_drv_ctx->streams[str_id]; + /* If stream is dropped, skip processing this message*/ + if (stream->status == STREAM_INIT) + break; if (stream->period_elapsed) stream->period_elapsed(stream->pcm_substream); if (stream->compr_cb) -- 1.9.1

2 1

[alsa-devel] [PATCH v2] ASoC: Remove deprecated create_singlethread_workqueue
by Bhaktipriya Shridhar 30 Aug '16

30 Aug '16

The workqueue "dac33_wq" queues a single work item &dac33->work and hence doesn't require ordering. Also, it is not being used on a memory reclaim path. Hence, it has been converted to use system_wq. The work item has been flushed in dac33_soc_remove to ensure that there are no pending tasks while disconnecting the driver. The workqueue "post_msg_wq" queues a single work item &drv->ipc_post_msg_wq and hence doesn't require ordering. Also, it is not being used on a memory reclaim path. Hence, it has been converted to use system_wq. The work item has been flushed in sst_context_cleanup to ensure that there are no pending tasks while disconnecting the driver. System workqueues have been able to handle high level of concurrency for a long time now and hence it's not required to have a singlethreaded workqueue just to gain concurrency. Unlike a dedicated per-cpu workqueue created with create_singlethread_workqueue(), system_wq allows multiple work items to overlap executions even on the same CPU; however, a per-cpu workqueue doesn't have any CPU locality or global ordering guarantee unless the target CPU is explicitly specified and thus the increase of local concurrency shouldn't make any difference. Signed-off-by: Bhaktipriya Shridhar <bhaktipriya96(a)gmail.com> --- Changes in v2: - Fixed heading to indicate that changes were made in sound/soc sound/soc/codecs/tlv320dac33.c | 17 ++++------------- sound/soc/intel/atom/sst/sst.c | 14 +++++--------- 2 files changed, 9 insertions(+), 22 deletions(-) diff --git a/sound/soc/codecs/tlv320dac33.c b/sound/soc/codecs/tlv320dac33.c index f7a6ce7..6822ac1 100644 --- a/sound/soc/codecs/tlv320dac33.c +++ b/sound/soc/codecs/tlv320dac33.c @@ -90,7 +90,6 @@ static const char *dac33_supply_names[DAC33_NUM_SUPPLIES] = { struct tlv320dac33_priv { struct mutex mutex; - struct workqueue_struct *dac33_wq; struct work_struct work; struct snd_soc_codec *codec; struct regulator_bulk_data supplies[DAC33_NUM_SUPPLIES]; @@ -771,7 +770,7 @@ static irqreturn_t dac33_interrupt_handler(int irq, void *dev) /* Do not schedule the workqueue in Mode7 */ if (dac33->fifo_mode != DAC33_FIFO_MODE7) - queue_work(dac33->dac33_wq, &dac33->work); + schedule_work(&dac33->work); return IRQ_HANDLED; } @@ -1127,7 +1126,7 @@ static int dac33_pcm_trigger(struct snd_pcm_substream *substream, int cmd, case SNDRV_PCM_TRIGGER_PAUSE_RELEASE: if (dac33->fifo_mode) { dac33->state = DAC33_PREFILL; - queue_work(dac33->dac33_wq, &dac33->work); + schedule_work(&dac33->work); } break; case SNDRV_PCM_TRIGGER_STOP: @@ -1135,7 +1134,7 @@ static int dac33_pcm_trigger(struct snd_pcm_substream *substream, int cmd, case SNDRV_PCM_TRIGGER_PAUSE_PUSH: if (dac33->fifo_mode) { dac33->state = DAC33_FLUSH; - queue_work(dac33->dac33_wq, &dac33->work); + schedule_work(&dac33->work); } break; default: @@ -1410,14 +1409,6 @@ static int dac33_soc_probe(struct snd_soc_codec *codec) dac33->irq = -1; } if (dac33->irq != -1) { - /* Setup work queue */ - dac33->dac33_wq = - create_singlethread_workqueue("tlv320dac33"); - if (dac33->dac33_wq == NULL) { - free_irq(dac33->irq, codec); - return -ENOMEM; - } - INIT_WORK(&dac33->work, dac33_work); } } @@ -1437,7 +1428,7 @@ static int dac33_soc_remove(struct snd_soc_codec *codec) if (dac33->irq >= 0) { free_irq(dac33->irq, dac33->codec); - destroy_workqueue(dac33->dac33_wq); + flush_work(&dac33->work); } return 0; } diff --git a/sound/soc/intel/atom/sst/sst.c b/sound/soc/intel/atom/sst/sst.c index a4b458e..8cfd0cf 100644 --- a/sound/soc/intel/atom/sst/sst.c +++ b/sound/soc/intel/atom/sst/sst.c @@ -76,7 +76,7 @@ static irqreturn_t intel_sst_interrupt_mrfld(int irq, void *context) spin_unlock(&drv->ipc_spin_lock); /* we can send more messages to DSP so trigger work */ - queue_work(drv->post_msg_wq, &drv->ipc_post_msg_wq); + schedule_work(&drv->ipc_post_msg_wq); retval = IRQ_HANDLED; } @@ -212,10 +212,6 @@ static int sst_workqueue_init(struct intel_sst_drv *ctx) INIT_WORK(&ctx->ipc_post_msg_wq, sst_process_pending_msg); init_waitqueue_head(&ctx->wait_queue); - ctx->post_msg_wq = - create_singlethread_workqueue("sst_post_msg_wq"); - if (!ctx->post_msg_wq) - return -EBUSY; return 0; } @@ -318,7 +314,6 @@ int sst_context_init(struct intel_sst_drv *ctx) return 0; do_free_mem: - destroy_workqueue(ctx->post_msg_wq); return ret; } EXPORT_SYMBOL_GPL(sst_context_init); @@ -330,7 +325,7 @@ void sst_context_cleanup(struct intel_sst_drv *ctx) sst_unregister(ctx->dev); sst_set_fw_state_locked(ctx, SST_SHUTDOWN); flush_scheduled_work(); - destroy_workqueue(ctx->post_msg_wq); + flush_work(&ctx->ipc_post_msg_wq); pm_qos_remove_request(ctx->qos); kfree(ctx->fw_sg_list.src); kfree(ctx->fw_sg_list.dst); @@ -414,7 +409,7 @@ static int intel_sst_runtime_suspend(struct device *dev) sst_set_fw_state_locked(ctx, SST_RESET); synchronize_irq(ctx->irq_num); - flush_workqueue(ctx->post_msg_wq); + flush_work(&ctx->ipc_post_msg_wq); ctx->ops->reset(ctx); /* save the shim registers because PMC doesn't save state */ @@ -445,8 +440,9 @@ static int intel_sst_suspend(struct device *dev) return -EBUSY; } } + synchronize_irq(ctx->irq_num); - flush_workqueue(ctx->post_msg_wq); + flush_work(ctx->ipc_post_msg_wq); /* Move the SST state to Reset */ sst_set_fw_state_locked(ctx, SST_RESET); -- 2.1.4

1 0

[alsa-devel] [PATCH v9 0/2] sun4i-codec: Add Line-In, FM-In, Mic 2, Capture Source, Differential Line-In
by Danny Milosavljevic 30 Aug '16

30 Aug '16

This patch adds support for some mixer controls: * Line-In * FM-In * Mic 2 * Capture Source * Differential Line-In v9 changes compared to v8 are: - added Line Differential Capture Switch. - split Capture Source into Left Capture Select, Right Capture Select. - added Line Capture Volume. - rename "sun4i_codec_widgets" to "sun4i_codec_controls" for consistency with the struct field it's used in. - rename "Line-In" to "Line". - rename "Power Amplifier Playback Volume" to "Headphone Playback Volume". v8 changes compared to v7 are: - fixed the routes for line and mic capturing. v7 changes compared to v6 are: - preparation for different A20, A10 controls is now in an extra patch. - all register definitions are now at the top. - sun7i-specific things (A20-specific things) are now less grouped-together. - rename "Power Amplifier Volume" to "Power Amplifier Playback Volume". v6 changes compared to v5 are: - Mic preamplifier special cases for A20 and A10 now are now not icky: There are two different _widget arrays and the probe() function now selects the right one to pass to snd_soc_register_codec() unmodified. - sun7i-specific things (A20-specific things) are now grouped together. v5 changes compared to v4 are: - Mic preamplifier controls have more common names now. - Mic preamplifier scale has a 0 dB entry as well now, as documented in the A20 user manual. - Mic preamplifier has special cases for A20 and A10 now. - Gain controls have "Gain" in the name now. v4 changes compared to v3 are: - names of the input are not uppercase anymore. - bit index constants are now named as in the A20 user manual v1.4. - added Mic1-In, Mac2-In. - added Mic1 and Mic2 Pre-Amplifiers. v3 changes compared to v2 are: - added DAPM routes. v2 changes compared to v1 are: - moved Line-In and FM-In playback switches to their respective sun4i_codec_*_mixer_controls. v1 changes: - added linein, fmin output volumes and switches. Danny Milosavljevic (2): ASoC: sun4i-codec: Distinguish sun4i from sun7i Add mixer controls: Line-In, FM-In, Mic 2, Capture Source, Differential Line-In. sound/soc/sunxi/sun4i-codec.c | 278 +++++++++++++++++++++++++++++++++++++++--- 1 file changed, 259 insertions(+), 19 deletions(-)

3 6

Re: [alsa-devel] Questions about thinkpad_helper
by Takashi Iwai 30 Aug '16

30 Aug '16

[Changed Cc to proper alsa-devel ML] On Tue, 30 Aug 2016 12:02:56 +0200, Dennis Wassenberg wrote: > > Hi all, > > I wrote a driver which handles the function / special keys for > ThinKeyboard of Lenovo ThinkPad X1 Tablet 2016 including LED control. > This Keyboard is connected via USB to the Tablet. I added the driver to > hid-lenovo.c file because there are HID drivers included for different > Lenovo devices. > > For example this driver is able to handle LED control for mute and mic > mute keys. Now I want to make the other direction working. If someone > sets mute or mic mute at amixer, I want to control the mute and mic mute > LEDs. At other Thinkpad devices this is done by thinkpad_helper.c. The > thinkpad_helper let the thinkpad_apci driver to control the LEDs. > > Now I think about how to make this working for Lenovo Thinkpad X1 Tablet > 2016. There it is not possible to use the thinkpad_acpi driver. Instead > we have to use the hid-lenovo driver to make this working. > > Should I add this to thinkpad_helper because this is a thinkpad device > too or should I make a new helper? Can I use the same API than > thinkpad_acpi (static int (*led_set_func)(int, bool)) or should I make a > new one (e.g. in combination with LED triggers)? > > For the first shot I made something at > https://github.com/dwassenberg/linux/tree/development/hid-rmi > (dc05de0add955775434d18d4fe096ea78d1e63bd..5a88c66f2ae8db04147bb75ecf84a4f52e0da1df) > this shot is based on using the thinkpad_helper and the same API. Please > tell me your opinion. > > Maybe one additional remark. In case of using the USB connected > ThinKeyboard there is one additional effort to make this working at the > initial state if the Tablet is finished booting and after that the > ThinKeyboard is connected. So either there is an additional trigger > needed which tells the helper to publish the current mute and mic mute > state when the keyboard is connected. Or an other approach is to update > the hid-lenovo driver even when this keyboard is not connected such that > the hid-lenovo driver always knows the current state and is able to set > this if the keyboard is connected. Or is there there an other solution? I think your changes are OK. A slight concern I found while looking quickly through the git commits is the cosmetic build issues, either only one of CONFIG_THINKPAD_ACPI and CONFIG_HID_LENOVO is enabled. But other than that, it looks straightforward. Of course, another option would be leave everything to user-space. But I don't think it would work fluently on the current desktop, even in near future. So considering practically, we'll likely go to the kernel hook way, I suppose. thanks, Takashi

1 0

[alsa-devel] [PATCH] ASoC: Intel: Atom: Fix message handling during drop stream
by Harsha Priya 30 Aug '16

30 Aug '16

If a stream is being dropped, the period_elapsed received then after need not be processed. Processing of the period_elapsed message causes a time out in drop stream response processing. This patch adds a condition to skip period_elapsed message processing if the stream is in INIT state. Signed-off-by: Harsha Priya <harshapriya.n(a)intel.com> Signed-off-by: Naveen M <naveen.m(a)intel.com> --- sound/soc/intel/atom/sst/sst_ipc.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/sound/soc/intel/atom/sst/sst_ipc.c b/sound/soc/intel/atom/sst/sst_ipc.c index 8afa6fe..bfc8899 100644 --- a/sound/soc/intel/atom/sst/sst_ipc.c +++ b/sound/soc/intel/atom/sst/sst_ipc.c @@ -267,6 +267,9 @@ static void process_fw_async_msg(struct intel_sst_drv *sst_drv_ctx, "Period elapsed rcvd for pipe id 0x%x\n", pipe_id); stream = &sst_drv_ctx->streams[str_id]; + /* If stream is dropped, skip processing this message*/ + if (stream->status == STREAM_INIT) + break; if (stream->period_elapsed) stream->period_elapsed(stream->pcm_substream); if (stream->compr_cb) -- 1.9.1

2 1

Re: [alsa-devel] [PATCH] ALSA: usb-audio: Add sample rate inquiry quirk for B850V3 CP2114
by Akshay Bhat 30 Aug '16

30 Aug '16

Hi, On Fri, Aug 12, 2016 at 2:08 PM, Akshay Bhat <akshay.bhat(a)timesys.com> wrote: > From: Ken Lin <ken.lin(a)advantech.com.tw> > > Avoid getting sample rate on B850V3 CP2114 as it is unsupported and > causes noisy "current rate is different from the runtime rate" messages > when playback starts. > > Signed-off-by: Ken Lin <ken.lin(a)advantech.com.tw> > Signed-off-by: Akshay Bhat <akshay.bhat(a)timesys.com> > --- Any feedback on the patch? If not can it be applied? Thanks.

2 5

[alsa-devel] [PATCH] ASoC: hdac_hdmi: fix spelling mistake "montior" -> "monitor"
by Colin King 30 Aug '16

30 Aug '16

From: Colin Ian King <colin.king(a)canonical.com> Trivial fix to spelling mistake in dev_warn message. Signed-off-by: Colin Ian King <colin.king(a)canonical.com> --- sound/soc/codecs/hdac_hdmi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/soc/codecs/hdac_hdmi.c b/sound/soc/codecs/hdac_hdmi.c index 4e181b2..c602c49 100644 --- a/sound/soc/codecs/hdac_hdmi.c +++ b/sound/soc/codecs/hdac_hdmi.c @@ -614,7 +614,7 @@ static int hdac_hdmi_pcm_open(struct snd_pcm_substream *substream, (!pin->eld.eld_valid)) { dev_warn(&hdac->hdac.dev, - "Failed: montior present? %d ELD valid?: %d for pin: %d\n", + "Failed: monitor present? %d ELD valid?: %d for pin: %d\n", pin->eld.monitor_present, pin->eld.eld_valid, pin->nid); return 0; -- 2.9.3

2 1

[alsa-devel] sound: deadlock snd_rawmidi_kernel_open/check_and_subscribe_port
by Dmitry Vyukov 30 Aug '16

30 Aug '16

Hello, While running syzkaller fuzzer on f31494bd05b06b0cdb4da6aebe92eaafab970df6 (Aug 12), I've got the following deadlock report: ====================================================== [ INFO: possible circular locking dependency detected ] 4.8.0-rc1+ #11 Not tainted ------------------------------------------------------- syz-executor/7154 is trying to acquire lock: (register_mutex#5){+.+.+.}, at: [<ffffffff84fd6d4b>] snd_rawmidi_kernel_open+0x4b/0x260 sound/core/rawmidi.c:341 but task is already holding lock: (&grp->list_mutex){++++.+}, at: [<ffffffff850138bb>] check_and_subscribe_port+0x5b/0x5c0 sound/core/seq/seq_ports.c:495 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (&grp->list_mutex){++++.+}: [<ffffffff8147a3a8>] lock_acquire+0x208/0x430 kernel/locking/lockdep.c:3746 [<ffffffff863f6199>] down_read+0x49/0xc0 kernel/locking/rwsem.c:22 [< inline >] deliver_to_subscribers sound/core/seq/seq_clientmgr.c:681 [<ffffffff85005c5e>] snd_seq_deliver_event+0x35e/0x890 sound/core/seq/seq_clientmgr.c:822 [<ffffffff85006e96>] snd_seq_kernel_client_dispatch+0x126/0x170 sound/core/seq/seq_clientmgr.c:2418 [<ffffffff85012c52>] snd_seq_system_broadcast+0xb2/0xf0 sound/core/seq/seq_system.c:101 [<ffffffff84fff70a>] snd_seq_create_kernel_client+0x24a/0x330 sound/core/seq/seq_clientmgr.c:2297 [< inline >] snd_virmidi_dev_attach_seq sound/core/seq/seq_virmidi.c:383 [<ffffffff8502d29f>] snd_virmidi_dev_register+0x29f/0x750 sound/core/seq/seq_virmidi.c:450 [<ffffffff84fd208c>] snd_rawmidi_dev_register+0x30c/0xd40 sound/core/rawmidi.c:1645 [<ffffffff84f816d3>] __snd_device_register.part.0+0x63/0xc0 sound/core/device.c:164 [< inline >] __snd_device_register sound/core/device.c:162 [<ffffffff84f8235d>] snd_device_register_all+0xad/0x110 sound/core/device.c:212 [<ffffffff84f7546f>] snd_card_register+0xef/0x6c0 sound/core/init.c:749 [<ffffffff85040b7f>] snd_virmidi_probe+0x3ef/0x590 sound/drivers/virmidi.c:123 [<ffffffff833ebf7b>] platform_drv_probe+0x8b/0x170 drivers/base/platform.c:564 [< inline >] really_probe drivers/base/dd.c:377 [<ffffffff833e5993>] driver_probe_device+0x563/0xcc0 drivers/base/dd.c:499 [<ffffffff833e653d>] __device_attach_driver+0x21d/0x2e0 drivers/base/dd.c:594 [<ffffffff833df38f>] bus_for_each_drv+0x13f/0x1d0 drivers/base/bus.c:463 [<ffffffff833e51ef>] __device_attach+0x1ef/0x300 drivers/base/dd.c:651 [<ffffffff833e669a>] device_initial_probe+0x1a/0x20 drivers/base/dd.c:698 [<ffffffff833e2999>] bus_probe_device+0x1e9/0x290 drivers/base/bus.c:557 [<ffffffff833dc459>] device_add+0xc49/0x14c0 drivers/base/core.c:1120 [<ffffffff833eb629>] platform_device_add+0x2f9/0x7b0 drivers/base/platform.c:403 [<ffffffff833ed3b2>] platform_device_register_full+0x392/0x4b0 drivers/base/platform.c:536 [< inline >] platform_device_register_resndata ./include/linux/platform_device.h:111 [< inline >] platform_device_register_simple ./include/linux/platform_device.h:140 [<ffffffff8870fabd>] alsa_card_virmidi_init+0x104/0x1da sound/drivers/virmidi.c:172 [<ffffffff81002330>] do_one_initcall+0xa0/0x2b0 init/main.c:778 [< inline >] do_initcall_level init/main.c:843 [< inline >] do_initcalls init/main.c:851 [< inline >] do_basic_setup init/main.c:869 [<ffffffff88604d11>] kernel_init_freeable+0x47b/0x534 init/main.c:1016 [<ffffffff863e2f53>] kernel_init+0x13/0x180 init/main.c:942 [<ffffffff863fbdcf>] ret_from_fork+0x1f/0x40 arch/x86/entry/entry_64.S:393 -> #0 (register_mutex#5){+.+.+.}: [< inline >] check_prev_add kernel/locking/lockdep.c:1829 [< inline >] check_prevs_add kernel/locking/lockdep.c:1939 [< inline >] validate_chain kernel/locking/lockdep.c:2266 [<ffffffff814791f4>] __lock_acquire+0x4d44/0x4d80 kernel/locking/lockdep.c:3335 [<ffffffff8147a3a8>] lock_acquire+0x208/0x430 kernel/locking/lockdep.c:3746 [< inline >] __mutex_lock_common kernel/locking/mutex.c:521 [<ffffffff863f0ef1>] mutex_lock_nested+0xb1/0xa20 kernel/locking/mutex.c:621 [<ffffffff84fd6d4b>] snd_rawmidi_kernel_open+0x4b/0x260 sound/core/rawmidi.c:341 [<ffffffff8502e7c7>] midisynth_subscribe+0xf7/0x350 sound/core/seq/seq_midi.c:188 [< inline >] subscribe_port sound/core/seq/seq_ports.c:427 [<ffffffff85013cc7>] check_and_subscribe_port+0x467/0x5c0 sound/core/seq/seq_ports.c:510 [<ffffffff85015da9>] snd_seq_port_connect+0x2c9/0x500 sound/core/seq/seq_ports.c:579 [<ffffffff850079b8>] snd_seq_ioctl_subscribe_port+0x1d8/0x2b0 sound/core/seq/seq_clientmgr.c:1480 [<ffffffff84ffe9e4>] snd_seq_do_ioctl+0x184/0x1e0 sound/core/seq/seq_clientmgr.c:2225 [<ffffffff84ffeae8>] snd_seq_kernel_client_ctl+0xa8/0x110 sound/core/seq/seq_clientmgr.c:2440 [<ffffffff85027664>] snd_seq_oss_midi_open+0x3b4/0x610 sound/core/seq/oss/seq_oss_midi.c:375 [<ffffffff85023d67>] snd_seq_oss_synth_setup_midi+0x107/0x4c0 sound/core/seq/oss/seq_oss_synth.c:281 [<ffffffff8501b0a8>] snd_seq_oss_open+0x748/0x8d0 sound/core/seq/oss/seq_oss_init.c:274 [<ffffffff85019d8a>] odev_open+0x6a/0x90 sound/core/seq/oss/seq_oss.c:138 [<ffffffff84f7040f>] soundcore_open+0x30f/0x640 sound/sound_core.c:639 [<ffffffff818069ea>] chrdev_open+0x22a/0x4c0 fs/char_dev.c:392 [<ffffffff817f146f>] do_dentry_open+0x69f/0xca0 fs/open.c:736 [<ffffffff817f4aa5>] vfs_open+0x105/0x220 fs/open.c:849 [< inline >] do_last fs/namei.c:3374 [<ffffffff8182c35d>] path_openat+0x1efd/0x2f60 fs/namei.c:3497 [<ffffffff81830b6e>] do_filp_open+0x18e/0x250 fs/namei.c:3532 [<ffffffff817f53c1>] do_sys_open+0x201/0x420 fs/open.c:1036 [< inline >] SYSC_open fs/open.c:1054 [<ffffffff817f560d>] SyS_open+0x2d/0x40 fs/open.c:1049 [<ffffffff863fbb80>] entry_SYSCALL_64_fastpath+0x23/0xc1 arch/x86/entry/entry_64.S:207 other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&grp->list_mutex); lock(register_mutex#5); lock(&grp->list_mutex); lock(register_mutex#5); *** DEADLOCK *** 2 locks held by syz-executor/7154: #0: (register_mutex#4){+.+.+.}, at: [<ffffffff85019d7f>] odev_open+0x5f/0x90 sound/core/seq/oss/seq_oss.c:137 #1: (&grp->list_mutex){++++.+}, at: [<ffffffff850138bb>] check_and_subscribe_port+0x5b/0x5c0 sound/core/seq/seq_ports.c:495 stack backtrace: CPU: 0 PID: 7154 Comm: syz-executor Not tainted 4.8.0-rc1+ #11 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 ffffffff878b7680 ffff880038b670f0 ffffffff82a5f719 ffffffff00000000 fffffbfff0f16ed0 ffffffff8901a0d0 ffffffff8901a0d0 ffffffff890191a0 ffff88003da2cf08 ffff88003da2c6c0 ffff880038b67140 ffffffff814708a8 Call Trace: [< inline >] __dump_stack lib/dump_stack.c:15 [<ffffffff82a5f719>] dump_stack+0x12e/0x185 lib/dump_stack.c:51 [<ffffffff814708a8>] print_circular_bug+0x288/0x340 kernel/locking/lockdep.c:1202 [< inline >] check_prev_add kernel/locking/lockdep.c:1829 [< inline >] check_prevs_add kernel/locking/lockdep.c:1939 [< inline >] validate_chain kernel/locking/lockdep.c:2266 [<ffffffff814791f4>] __lock_acquire+0x4d44/0x4d80 kernel/locking/lockdep.c:3335 [<ffffffff8147a3a8>] lock_acquire+0x208/0x430 kernel/locking/lockdep.c:3746 [< inline >] __mutex_lock_common kernel/locking/mutex.c:521 [<ffffffff863f0ef1>] mutex_lock_nested+0xb1/0xa20 kernel/locking/mutex.c:621 [<ffffffff84fd6d4b>] snd_rawmidi_kernel_open+0x4b/0x260 sound/core/rawmidi.c:341 [<ffffffff8502e7c7>] midisynth_subscribe+0xf7/0x350 sound/core/seq/seq_midi.c:188 [< inline >] subscribe_port sound/core/seq/seq_ports.c:427 [<ffffffff85013cc7>] check_and_subscribe_port+0x467/0x5c0 sound/core/seq/seq_ports.c:510 [<ffffffff85015da9>] snd_seq_port_connect+0x2c9/0x500 sound/core/seq/seq_ports.c:579 [<ffffffff850079b8>] snd_seq_ioctl_subscribe_port+0x1d8/0x2b0 sound/core/seq/seq_clientmgr.c:1480 [<ffffffff84ffe9e4>] snd_seq_do_ioctl+0x184/0x1e0 sound/core/seq/seq_clientmgr.c:2225 [<ffffffff84ffeae8>] snd_seq_kernel_client_ctl+0xa8/0x110 sound/core/seq/seq_clientmgr.c:2440 [<ffffffff85027664>] snd_seq_oss_midi_open+0x3b4/0x610 sound/core/seq/oss/seq_oss_midi.c:375 [<ffffffff85023d67>] snd_seq_oss_synth_setup_midi+0x107/0x4c0 sound/core/seq/oss/seq_oss_synth.c:281 [<ffffffff8501b0a8>] snd_seq_oss_open+0x748/0x8d0 sound/core/seq/oss/seq_oss_init.c:274 [<ffffffff85019d8a>] odev_open+0x6a/0x90 sound/core/seq/oss/seq_oss.c:138 [<ffffffff84f7040f>] soundcore_open+0x30f/0x640 sound/sound_core.c:639 [<ffffffff818069ea>] chrdev_open+0x22a/0x4c0 fs/char_dev.c:392 [<ffffffff817f146f>] do_dentry_open+0x69f/0xca0 fs/open.c:736 [<ffffffff817f4aa5>] vfs_open+0x105/0x220 fs/open.c:849 [< inline >] do_last fs/namei.c:3374 [<ffffffff8182c35d>] path_openat+0x1efd/0x2f60 fs/namei.c:3497 [<ffffffff81830b6e>] do_filp_open+0x18e/0x250 fs/namei.c:3532 [<ffffffff817f53c1>] do_sys_open+0x201/0x420 fs/open.c:1036 [< inline >] SYSC_open fs/open.c:1054 [<ffffffff817f560d>] SyS_open+0x2d/0x40 fs/open.c:1049 [<ffffffff863fbb80>] entry_SYSCALL_64_fastpath+0x23/0xc1 arch/x86/entry/entry_64.S:207

2 4

[alsa-devel] [PATCH 0/2] Support non-ssi cpu-dai for sgtl5000
by Winter Wang 30 Aug '16

30 Aug '16

These patches support sgtl5000 to be attached to other non-ssi cpu-dais like SAI. Winter Wang (2): ASoC: imx-sgtl5000: Support non-ssi cpu-dai ARM: dts: modify sgtl5000 property to support non-ssi cpu-dai .../bindings/sound/imx-audio-sgtl5000.txt | 4 +-- arch/arm/boot/dts/imx25-pdk.dts | 2 +- arch/arm/boot/dts/imx51-babbage.dts | 2 +- arch/arm/boot/dts/imx53-m53evk.dts | 2 +- arch/arm/boot/dts/imx53-mba53.dts | 2 +- arch/arm/boot/dts/imx53-qsb-common.dtsi | 2 +- arch/arm/boot/dts/imx53-tx53.dtsi | 2 +- arch/arm/boot/dts/imx53-voipac-bsb.dts | 2 +- arch/arm/boot/dts/imx6dl-riotboard.dts | 2 +- arch/arm/boot/dts/imx6q-bx50v3.dtsi | 2 +- arch/arm/boot/dts/imx6q-gw5400-a.dts | 2 +- arch/arm/boot/dts/imx6q-h100.dts | 2 +- arch/arm/boot/dts/imx6q-icore-rqs.dts | 2 +- arch/arm/boot/dts/imx6q-tbs2910.dts | 2 +- arch/arm/boot/dts/imx6qdl-apalis.dtsi | 2 +- arch/arm/boot/dts/imx6qdl-apf6dev.dtsi | 2 +- arch/arm/boot/dts/imx6qdl-gw52xx.dtsi | 2 +- arch/arm/boot/dts/imx6qdl-gw53xx.dtsi | 2 +- arch/arm/boot/dts/imx6qdl-gw54xx.dtsi | 2 +- arch/arm/boot/dts/imx6qdl-hummingboard.dtsi | 2 +- arch/arm/boot/dts/imx6qdl-nit6xlite.dtsi | 2 +- arch/arm/boot/dts/imx6qdl-nitrogen6_max.dtsi | 2 +- arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi | 2 +- arch/arm/boot/dts/imx6qdl-rex.dtsi | 2 +- arch/arm/boot/dts/imx6qdl-sabrelite.dtsi | 2 +- arch/arm/boot/dts/imx6qdl-tx6.dtsi | 2 +- arch/arm/boot/dts/imx6qdl-wandboard.dtsi | 2 +- sound/soc/fsl/imx-sgtl5000.c | 41 ++++++++++++++-------- 28 files changed, 55 insertions(+), 42 deletions(-) -- 1.9.1

3 4

[alsa-devel] [PATCH v6 0/2] amidi delay option
by Felipe F. Tonello 30 Aug '16

30 Aug '16

Small improvement to amidi, adding useful functionality. changes from v5: * wait until MIDI message is competely sent to sleep changes from v4: * simplified code changes from v3: * fixed a bug if memchr() returns NULL changes from v2: * only check of end of sysex (0xf7) * use memchr() instead of direct loop approach * fixed commit message changes from v1: * remove delay in between any MIDI message, only SysEx * added patch to use getopt_long() arguments Felipe F. Tonello (2): amidi: add delay option amidi: use GNU getopt_long() proper argument names amidi/amidi.1 | 14 ++++++++++ amidi/amidi.c | 82 ++++++++++++++++++++++++++++++++++++++++++++++------------- 2 files changed, 79 insertions(+), 17 deletions(-) -- 2.9.3

3 6