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

[alsa-devel] [PATCH v6 1/2] mfd: Add DT bindings documentation for Samsung Exynos LPASS
by Sylwester Nawrocki 31 Aug '16

31 Aug '16

This patch adds documentation of the DT bindings for the Samsung Exynos SoC Low Power Audio Subsystem. Signed-off-by: Sylwester Nawrocki <s.nawrocki(a)samsung.com> Acked-by: Rob Herring <robh(a)kernel.org> --- Changes since v5: - none. Changes since v4: - text reformatting, added VIC to the list of sub-devices, relative paths used for the reference DT binding documentation files, added example dts. Changes since v3: - moved to Documentation/devicetree/bindings/mfd, - added #address-cells, #size-cells, ranges as required properties, - added description of the IP block subnodes and links to their binding's documentation. Changes since v2: - none. --- .../bindings/mfd/samsung,exynos5433-lpass.txt | 70 ++++++++++++++++++++++ 1 file changed, 70 insertions(+) create mode 100644 Documentation/devicetree/bindings/mfd/samsung,exynos5433-lpass.txt diff --git a/Documentation/devicetree/bindings/mfd/samsung,exynos5433-lpass.txt b/Documentation/devicetree/bindings/mfd/samsung,exynos5433-lpass.txt new file mode 100644 index 0000000..c110e11 --- /dev/null +++ b/Documentation/devicetree/bindings/mfd/samsung,exynos5433-lpass.txt @@ -0,0 +1,70 @@ +Samsung Exynos SoC Low Power Audio Subsystem (LPASS) + +Required properties: + + - compatible : "samsung,exynos5433-lpass" + - reg : should contain the LPASS top SFR region location + and size + - samsung,pmu-syscon : the phandle to the Power Management Unit node + - #address-cells : should be 1 + - #size-cells : should be 1 + - ranges : must be present + +Each IP block of the Low Power Audio Subsystem should be specified as +an optional sub-node. For "samsung,exynos5433-lpass" compatible this includes: +UART, SLIMBUS, PCM, I2S, DMAC, Timers 0...4, VIC, WDT 0...1 devices. + +Bindings of the sub-nodes are described in: + ../serial/samsung_uart.txt + ../sound/samsung-i2s.txt + ../dma/arm-pl330.txt + + +Example: + +audio-subsystem { + compatible = "samsung,exynos5433-lpass"; + reg = <0x11400000 0x100>, <0x11500000 0x08>; + samsung,pmu-syscon = <&pmu_system_controller>; + #address-cells = <1>; + #size-cells = <1>; + ranges; + + adma: adma@11420000 { + compatible = "arm,pl330", "arm,primecell"; + reg = <0x11420000 0x1000>; + interrupts = <0 73 0>; + clocks = <&cmu_aud CLK_ACLK_DMAC>; + clock-names = "apb_pclk"; + #dma-cells = <1>; + #dma-channels = <8>; + #dma-requests = <32>; + }; + + i2s0: i2s0@11440000 { + compatible = "samsung,exynos7-i2s"; + reg = <0x11440000 0x100>; + dmas = <&adma 0 &adma 2>; + dma-names = "tx", "rx"; + interrupts = <0 70 0>; + clocks = <&cmu_aud CLK_PCLK_AUD_I2S>, + <&cmu_aud CLK_SCLK_AUD_I2S>, + <&cmu_aud CLK_SCLK_I2S_BCLK>; + clock-names = "iis", "i2s_opclk0", "i2s_opclk1"; + pinctrl-names = "default"; + pinctrl-0 = <&i2s0_bus>; + status = "disabled"; + }; + + serial_3: serial@11460000 { + compatible = "samsung,exynos5433-uart"; + reg = <0x11460000 0x100>; + interrupts = <0 67 0>; + clocks = <&cmu_aud CLK_PCLK_AUD_UART>, + <&cmu_aud CLK_SCLK_AUD_UART>; + clock-names = "uart", "clk_uart_baud0"; + pinctrl-names = "default"; + pinctrl-0 = <&uart_aud_bus>; + status = "disabled"; + }; + }; -- 1.9.1

3 4

[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