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

[alsa-devel] Sound: BUG: KASAN: use-after-free in kill_fasync
by Baozeng Ding 05 Apr '16

05 Apr '16

Hi all, I've got the following report (use-after-free in kill_fasync) while running syzkaller. Unfortunately no reproducer.The kernel version is 4.5 (on Mar 16 commit 09fd671ccb2475436bd5f597f751ca4a7d177aea). ================================================================== BUG: KASAN: use-after-free in kill_fasync+0x3fb/0x420 at addr ffff880067691d88 Read of size 8 by task swapper/2/0 ============================================================================= BUG kmalloc-2048 (Not tainted): kasan: bad access detected ----------------------------------------------------------------------------- Disabling lock debugging due to kernel taint INFO: Allocated in 0xbbbbbbbbbbbbbbbb age=18446678412249576073 cpu=2245704320 pid=-1 [< inline >] kmalloc /kernel/include/linux/slab.h:472 [< inline >] kzalloc /kernel/include/linux/slab.h:616 [< none >] snd_pcm_attach_substream+0x3b4/0xb10 /kernel/sound/core/pcm.c:966 [< none >] ___slab_alloc+0x4c7/0x500 /kernel/mm/slub.c:2446 [< none >] __slab_alloc+0x4c/0x90 /kernel/mm/slub.c:2475 [< inline >] slab_alloc_node /kernel/mm/slub.c:2538 [< inline >] slab_alloc /kernel/mm/slub.c:2580 [< none >] kmem_cache_alloc_trace+0x262/0x300 /kernel/mm/slub.c:2597 [< inline >] kmalloc /kernel/include/linux/slab.h:472 [< inline >] kzalloc /kernel/include/linux/slab.h:616 [< none >] snd_pcm_attach_substream+0x3b4/0xb10 /kernel/sound/core/pcm.c:966 [< none >] snd_pcm_open_substream+0x84/0x450 /kernel/sound/core/pcm_native.c:2262 [< inline >] snd_pcm_oss_open_file /kernel/sound/core/oss/pcm_oss.c:2346 [< none >] snd_pcm_oss_open.part.17+0x5a4/0x1100 /kernel/sound/core/oss/pcm_oss.c:2428 [< none >] snd_pcm_oss_open+0x35/0x50 /kernel/sound/core/oss/pcm_oss.c:2392 [< none >] soundcore_open+0x30f/0x640 /kernel/sound/sound_core.c:639 [< none >] chrdev_open+0x22a/0x4c0 /kernel/fs/char_dev.c:388 [< none >] do_dentry_open+0x6a2/0xcb0 /kernel/fs/open.c:736 [< none >] vfs_open+0x17b/0x1f0 /kernel/fs/open.c:853 [< inline >] do_last /kernel/fs/namei.c:3258 [< none >] path_openat+0x4837/0x5830 /kernel/fs/namei.c:3394 [< none >] do_filp_open+0x18e/0x250 /kernel/fs/namei.c:3429 [< none >] do_sys_open+0x201/0x420 /kernel/fs/open.c:1022 [< inline >] SYSC_open /kernel/fs/open.c:1040 [< none >] SyS_open+0x2d/0x40 /kernel/fs/open.c:1035 INFO: Freed in 0x10000b076 age=18446678416544543380 cpu=0 pid=0 [< none >] snd_pcm_detach_substream+0x134/0x280 /kernel/sound/core/pcm.c:1017 [< none >] __slab_free+0x1e8/0x300 /kernel/mm/slub.c:2657 [< inline >] slab_free /kernel/mm/slub.c:2810 [< none >] kfree+0x24e/0x2d0 /kernel/mm/slub.c:3661 [< none >] snd_pcm_detach_substream+0x134/0x280 /kernel/sound/core/pcm.c:1017 [< none >] snd_pcm_release_substream.part.38+0x219/0x2f0 /kernel/sound/core/pcm_native.c:2250 [< none >] snd_pcm_release_substream+0x59/0x70 /kernel/sound/core/pcm_native.c:2251 [< none >] snd_pcm_oss_release_file+0x45/0xb0 /kernel/sound/core/oss/pcm_oss.c:2305 [< none >] snd_pcm_oss_release+0xfa/0x250 /kernel/sound/core/oss/pcm_oss.c:2485 [< none >] __fput+0x236/0x780 /kernel/fs/file_table.c:208 [< none >] ____fput+0x15/0x20 /kernel/fs/file_table.c:244 [< none >] task_work_run+0x16b/0x200 /kernel/kernel/task_work.c:115 [< inline >] exit_task_work /kernel/include/linux/task_work.h:21 [< none >] do_exit+0x87f/0x2c90 /kernel/kernel/exit.c:748 [< none >] do_group_exit+0x108/0x330 /kernel/kernel/exit.c:878 [< inline >] SYSC_exit_group /kernel/kernel/exit.c:889 [< none >] SyS_exit_group+0x1d/0x20 /kernel/kernel/exit.c:887 [< none >] entry_SYSCALL_64_fastpath+0x23/0xc1 /kernel/arch/x86/entry/entry_64.S:207 INFO: Slab 0xffffea00019da400 objects=13 used=8 fp=0xffff880067691be0 flags=0x5fffc0000004080 INFO: Object 0xffff880067691bd8 @offset=7128 fp=0xbbbbbbbbbbbbbbbb Call Trace: <IRQ> [< inline >] __dump_stack /kernel/lib/dump_stack.c:15 <IRQ> [<ffffffff82945051>] dump_stack+0xb3/0x112 /kernel/lib/dump_stack.c:51 [<ffffffff817009ad>] print_trailer+0x10d/0x190 /kernel/mm/slub.c:668 [<ffffffff817074af>] object_err+0x2f/0x40 /kernel/mm/slub.c:675 [< inline >] print_address_description /kernel/mm/kasan/report.c:138 [<ffffffff81709ca5>] kasan_report_error+0x215/0x530 /kernel/mm/kasan/report.c:236 [< inline >] ? spin_lock /kernel/include/linux/spinlock.h:302 [<ffffffff84a1c550>] ? snd_pcm_stream_lock+0x80/0xd0 /kernel/sound/core/pcm_native.c:104 [< inline >] kasan_report /kernel/mm/kasan/report.c:259 [<ffffffff8170a0be>] __asan_report_load8_noabort+0x3e/0x40 /kernel/mm/kasan/report.c:280 [<ffffffff81792a0b>] ? kill_fasync+0x3fb/0x420 /kernel/fs/fcntl.c:729 [<ffffffff81792a0b>] kill_fasync+0x3fb/0x420 /kernel/fs/fcntl.c:729 [<ffffffff84a36e08>] snd_pcm_period_elapsed+0x1c8/0x230 /kernel/sound/core/pcm_lib.c:1890 [<ffffffff84b6e2e0>] ? get_bound_vga.isra.21.part.22+0x140/0x140 /kernel/sound/pci/hda/hda_intel.c:1327 [<ffffffff84b0637d>] stream_update+0xad/0xe0 /kernel/sound/pci/hda/hda_controller.c:923 [<ffffffff84c1583e>] snd_hdac_bus_handle_stream_irq+0x24e/0x350 /kernel/sound/hda/hdac_controller.c:449 [<ffffffff84b062d0>] ? azx_init_chip+0x100/0x100 /kernel/sound/pci/hda/hda_controller.c:890 [<ffffffff84b04d24>] ? azx_interrupt+0x14/0x4d0 /kernel/sound/pci/hda/hda_controller.c:929 [<ffffffff84b04eee>] azx_interrupt+0x1de/0x4d0 /kernel/sound/pci/hda/hda_controller.c:954 [<ffffffff84b04d10>] ? azx_stop_chip+0x20/0x20 /kernel/sound/pci/hda/hda_controller.c:908 [<ffffffff8143d9e3>] handle_irq_event_percpu+0xf3/0x790 /kernel/kernel/irq/handle.c:145 [<ffffffff8143e127>] handle_irq_event+0xa7/0x140 /kernel/kernel/irq/handle.c:192 [<ffffffff81447f81>] handle_edge_irq+0x1e1/0x8d0 /kernel/kernel/irq/chip.c:623 [< inline >] generic_handle_irq_desc /kernel/include/linux/irqdesc.h:146 [<ffffffff811ad739>] handle_irq+0x109/0x2a0 /kernel/arch/x86/kernel/irq_64.c:78 [< inline >] ? rcu_lock_release /kernel/include/linux/rcupdate.h:491 [< inline >] ? rcu_read_unlock /kernel/include/linux/rcupdate.h:926 [< inline >] ? __atomic_notifier_call_chain /kernel/kernel/notifier.c:184 [<ffffffff81369c4f>] ? atomic_notifier_call_chain+0xbf/0x140 /kernel/kernel/notifier.c:193 [<ffffffff81369b90>] ? __atomic_notifier_call_chain+0x150/0x150 /kernel/include/linux/rcupdate.h:922 [<ffffffff811ac36d>] do_IRQ+0x7d/0x1a0 /kernel/arch/x86/kernel/irq.c:240 [<ffffffff85dac40c>] common_interrupt+0x8c/0x8c /kernel/arch/x86/entry/entry_64.S:454 <EOI> [<ffffffff812245c6>] ? native_safe_halt+0x6/0x10 /kernel/./arch/x86/include/asm/irqflags.h:49 [<ffffffff81405ced>] ? trace_hardirqs_on+0xd/0x10 /kernel/kernel/locking/lockdep.c:2635 [< inline >] arch_safe_halt /kernel/./arch/x86/include/asm/paravirt.h:117 [<ffffffff811bf152>] default_idle+0x22/0x2d0 /kernel/arch/x86/kernel/process.c:307 [<ffffffff811c053a>] arch_cpu_idle+0xa/0x10 /kernel/arch/x86/kernel/process.c:298 [<ffffffff813eb618>] default_idle_call+0x48/0x70 /kernel/kernel/sched/idle.c:93 [< inline >] cpuidle_idle_call /kernel/kernel/sched/idle.c:151 [< inline >] cpu_idle_loop /kernel/kernel/sched/idle.c:242 [<ffffffff813ebaa7>] cpu_startup_entry+0x467/0x600 /kernel/kernel/sched/idle.c:291 [<ffffffff81201432>] start_secondary+0x2b2/0x380 /kernel/arch/x86/kernel/smpboot.c:259 [<ffffffff81201180>] ? set_cpu_sibling_map+0x18a0/0x18a0 /kernel/include/linux/topology.h:80 Memory state around the buggy address: ffff880067691c80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff880067691d00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff880067691d80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff880067691e00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff880067691e80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ================================================================== It seems that in function snd_pcm_detach_substream, when freeing runtime structure, it did not handle its fasync data pointer. Any ideas? Thanks. Best Regards, Baozeng Ding

2 1

[alsa-devel] [PATCH v2 0/2] conf: topology: Add the conf for SKL-rt286
by Vinod Koul 05 Apr '16

05 Apr '16

From: Shreyas NC <shreyas.nc(a)intel.com> The SKL RT286 I2S topology conf is provided here. The first patch adds that along with binary data for modules. The Second patch provides source of those binayy blobs and allows them to be recompiled. Shreyas NC (2): conf: topology: Add Skylake i2s conf conf: topology: Generate Private data binary blobs configure.ac | 1 + src/conf/topology/Makefile.am | 2 +- src/conf/topology/sklrt286/Makefile.am | 4 + src/conf/topology/sklrt286/codec0_in-cpr-1.bin | Bin 0 -> 4268 bytes src/conf/topology/sklrt286/codec0_in-mi.bin | Bin 0 -> 4268 bytes src/conf/topology/sklrt286/codec0_out-cpr-4.bin | Bin 0 -> 4268 bytes src/conf/topology/sklrt286/codec0_out-mo.bin | Bin 0 -> 4268 bytes src/conf/topology/sklrt286/codec1_out-cpr-5.bin | Bin 0 -> 4268 bytes src/conf/topology/sklrt286/codec1_out-mo.bin | Bin 0 -> 4268 bytes src/conf/topology/sklrt286/data/Makefile.am | 4 + src/conf/topology/sklrt286/data/README | 2 + src/conf/topology/sklrt286/data/compile_local | 16 + src/conf/topology/sklrt286/data/configure.ac | 30 + src/conf/topology/sklrt286/data/pvt.c | 1815 ++++++++++++++++++++ src/conf/topology/sklrt286/data/pvt_data.c | 90 + src/conf/topology/sklrt286/data/pvt_data_local.h | 115 ++ .../topology/sklrt286/dmic01_hifi_in-cpr-3.bin | Bin 0 -> 4268 bytes src/conf/topology/sklrt286/dmic01_hifi_in-mi.bin | Bin 0 -> 4268 bytes src/conf/topology/sklrt286/hdmi1_pt_out-cpr-7.bin | Bin 0 -> 4268 bytes src/conf/topology/sklrt286/hdmi1_pt_out-cpr-8.bin | Bin 0 -> 4268 bytes src/conf/topology/sklrt286/hdmi2_pt_out-cpr-10.bin | Bin 0 -> 4268 bytes src/conf/topology/sklrt286/hdmi2_pt_out-cpr-9.bin | Bin 0 -> 4268 bytes src/conf/topology/sklrt286/hdmi3_pt_out-cpr-11.bin | Bin 0 -> 4268 bytes src/conf/topology/sklrt286/hdmi3_pt_out-cpr-12.bin | Bin 0 -> 4268 bytes src/conf/topology/sklrt286/media0_in-cpr-0.bin | Bin 0 -> 4268 bytes src/conf/topology/sklrt286/media0_in-mi.bin | Bin 0 -> 4268 bytes src/conf/topology/sklrt286/media0_out-cpr-6.bin | Bin 0 -> 4268 bytes src/conf/topology/sklrt286/media0_out-mo.bin | Bin 0 -> 4268 bytes src/conf/topology/sklrt286/skl_i2s.conf | 342 ++++ 29 files changed, 2420 insertions(+), 1 deletion(-) create mode 100644 src/conf/topology/sklrt286/Makefile.am create mode 100644 src/conf/topology/sklrt286/codec0_in-cpr-1.bin create mode 100644 src/conf/topology/sklrt286/codec0_in-mi.bin create mode 100644 src/conf/topology/sklrt286/codec0_out-cpr-4.bin create mode 100644 src/conf/topology/sklrt286/codec0_out-mo.bin create mode 100644 src/conf/topology/sklrt286/codec1_out-cpr-5.bin create mode 100644 src/conf/topology/sklrt286/codec1_out-mo.bin create mode 100644 src/conf/topology/sklrt286/data/Makefile.am create mode 100644 src/conf/topology/sklrt286/data/README create mode 100755 src/conf/topology/sklrt286/data/compile_local create mode 100644 src/conf/topology/sklrt286/data/configure.ac create mode 100644 src/conf/topology/sklrt286/data/pvt.c create mode 100644 src/conf/topology/sklrt286/data/pvt_data.c create mode 100644 src/conf/topology/sklrt286/data/pvt_data_local.h create mode 100644 src/conf/topology/sklrt286/dmic01_hifi_in-cpr-3.bin create mode 100644 src/conf/topology/sklrt286/dmic01_hifi_in-mi.bin create mode 100644 src/conf/topology/sklrt286/hdmi1_pt_out-cpr-7.bin create mode 100644 src/conf/topology/sklrt286/hdmi1_pt_out-cpr-8.bin create mode 100644 src/conf/topology/sklrt286/hdmi2_pt_out-cpr-10.bin create mode 100644 src/conf/topology/sklrt286/hdmi2_pt_out-cpr-9.bin create mode 100644 src/conf/topology/sklrt286/hdmi3_pt_out-cpr-11.bin create mode 100644 src/conf/topology/sklrt286/hdmi3_pt_out-cpr-12.bin create mode 100644 src/conf/topology/sklrt286/media0_in-cpr-0.bin create mode 100644 src/conf/topology/sklrt286/media0_in-mi.bin create mode 100644 src/conf/topology/sklrt286/media0_out-cpr-6.bin create mode 100644 src/conf/topology/sklrt286/media0_out-mo.bin create mode 100644 src/conf/topology/sklrt286/skl_i2s.conf -- 2.4.11

1 0

[alsa-devel] Getting rid of inside_vm in intel8x0
by Andy Lutomirski 04 Apr '16

04 Apr '16

Would it be possible to revert: commit 228cf79376f13b98f2e1ac10586311312757675c Author: Konstantin Ozerkov <kozerkov(a)parallels.com> Date: Wed Oct 26 19:11:01 2011 +0400 ALSA: intel8x0: Improve performance in virtual environment Presumably one or more of the following is true: a) The inside_vm == true case is just an optimization and should apply unconditionally. b) The inside_vm == true case is incorrect and should be fixed or disabled. c) The inside_vm == true case is a special case that makes sense then IO is very very slow but doesn't make sense when IO is fast. If so, why not literally measure the time that the IO takes and switch over to the "inside VM" path when IO is slow? There are a pile of nonsensical "are we in a VM" checks of various sorts scattered throughout the kernel, they're all a mess to maintain (there are lots of kinds of VMs in the world, and Linux may not even know it's a guest), and, in most cases, it appears that the correct solution is to delete the checks. I just removed a nasty one in the x86_32 entry asm, and this one is written in C so it should be a piece of cake :) --Andy

5 11

[alsa-devel] [PATCH v3] ALSA: hda - Update chmap tlv to report sink's capability
by Subhransu S. Prusty 04 Apr '16

04 Apr '16

The existing TLV callback implementation copies all of the cea_channel_speaker_allocation map table to the TLV container irrespective of what is reported by sink. This is of little use to the userspace application. With this patch, it parses the spk_alloc block as queried from the ELD, and copies only the corresponding mapping channel allocation entries from the cea channel speaker allocation table. Thus the user can parse the TLV container to identify sink's capability and set the channel map accordingly. It shouldn't impact the behavior in AMD chipset, as this makes use of already parsed spk alloc block to calculate the channel map. Signed-off-by: Subhransu S. Prusty <subhransu.s.prusty(a)intel.com> Signed-off-by: Vinod Koul <vinod.koul(a)intel.com> --- changes in v3: Copy all possible channel map entries w.r.t. sink's capability include/sound/hda_chmap.h | 2 ++ sound/hda/hdmi_chmap.c | 44 ++++++++++++++++++++++++++++++++++++++++---- sound/pci/hda/patch_hdmi.c | 13 +++++++++++++ 3 files changed, 55 insertions(+), 4 deletions(-) diff --git a/include/sound/hda_chmap.h b/include/sound/hda_chmap.h index e20d219..babd445 100644 --- a/include/sound/hda_chmap.h +++ b/include/sound/hda_chmap.h @@ -36,6 +36,8 @@ struct hdac_chmap_ops { int (*chmap_validate)(struct hdac_chmap *hchmap, int ca, int channels, unsigned char *chmap); + int (*get_spk_alloc)(struct hdac_device *hdac, int pcm_idx); + void (*get_chmap)(struct hdac_device *hdac, int pcm_idx, unsigned char *chmap); void (*set_chmap)(struct hdac_device *hdac, int pcm_idx, diff --git a/sound/hda/hdmi_chmap.c b/sound/hda/hdmi_chmap.c index d7ec862..c6c75e7 100644 --- a/sound/hda/hdmi_chmap.c +++ b/sound/hda/hdmi_chmap.c @@ -625,13 +625,30 @@ static void hdmi_cea_alloc_to_tlv_chmap(struct hdac_chmap *hchmap, WARN_ON(count != channels); } +static int spk_mask_from_spk_alloc(int spk_alloc) +{ + int i; + int spk_mask = eld_speaker_allocation_bits[0]; + + for (i = 0; i < ARRAY_SIZE(eld_speaker_allocation_bits); i++) { + if (spk_alloc & (1 << i)) + spk_mask |= eld_speaker_allocation_bits[i]; + } + + return spk_mask; +} + static int hdmi_chmap_ctl_tlv(struct snd_kcontrol *kcontrol, int op_flag, unsigned int size, unsigned int __user *tlv) { struct snd_pcm_chmap *info = snd_kcontrol_chip(kcontrol); struct hdac_chmap *chmap = info->private_data; + int pcm_idx = kcontrol->private_value; unsigned int __user *dst; int chs, count = 0; + unsigned long max_chs; + int type; + int spk_alloc, spk_mask; if (size < 8) return -ENOMEM; @@ -639,40 +656,59 @@ static int hdmi_chmap_ctl_tlv(struct snd_kcontrol *kcontrol, int op_flag, return -EFAULT; size -= 8; dst = tlv + 2; - for (chs = 2; chs <= chmap->channels_max; chs++) { + + spk_alloc = chmap->ops.get_spk_alloc(chmap->hdac, pcm_idx); + spk_mask = spk_mask_from_spk_alloc(spk_alloc); + + max_chs = hweight_long(spk_mask); + + for (chs = 2; chs <= max_chs; chs++) { int i; struct hdac_cea_channel_speaker_allocation *cap; cap = channel_allocations; for (i = 0; i < ARRAY_SIZE(channel_allocations); i++, cap++) { int chs_bytes = chs * 4; - int type = chmap->ops.chmap_cea_alloc_validate_get_type( - chmap, cap, chs); unsigned int tlv_chmap[8]; - if (type < 0) + if (cap->channels != chs) + continue; + + if (!(cap->spk_mask == (spk_mask & cap->spk_mask))) continue; + + type = chmap->ops.chmap_cea_alloc_validate_get_type( + chmap, cap, chs); + if (type < 0) + return -ENODEV; if (size < 8) return -ENOMEM; + if (put_user(type, dst) || put_user(chs_bytes, dst + 1)) return -EFAULT; + dst += 2; size -= 8; count += 8; + if (size < chs_bytes) return -ENOMEM; + size -= chs_bytes; count += chs_bytes; chmap->ops.cea_alloc_to_tlv_chmap(chmap, cap, tlv_chmap, chs); + if (copy_to_user(dst, tlv_chmap, chs_bytes)) return -EFAULT; dst += chs; } } + if (put_user(count, tlv + 1)) return -EFAULT; + return 0; } diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c index 5af372d..dd25f2c 100644 --- a/sound/pci/hda/patch_hdmi.c +++ b/sound/pci/hda/patch_hdmi.c @@ -1838,6 +1838,18 @@ static const struct hda_pcm_ops generic_ops = { .cleanup = generic_hdmi_playback_pcm_cleanup, }; +static int hdmi_get_spk_alloc(struct hdac_device *hdac, int pcm_idx) +{ + struct hda_codec *codec = container_of(hdac, struct hda_codec, core); + struct hdmi_spec *spec = codec->spec; + struct hdmi_spec_per_pin *per_pin = pcm_idx_to_pin(spec, pcm_idx); + + if (!per_pin) + return 0; + + return per_pin->sink_eld.info.spk_alloc; +} + static void hdmi_get_chmap(struct hdac_device *hdac, int pcm_idx, unsigned char *chmap) { @@ -2249,6 +2261,7 @@ static int patch_generic_hdmi(struct hda_codec *codec) spec->chmap.ops.get_chmap = hdmi_get_chmap; spec->chmap.ops.set_chmap = hdmi_set_chmap; spec->chmap.ops.is_pcm_attached = is_hdmi_pcm_attached; + spec->chmap.ops.get_spk_alloc = hdmi_get_spk_alloc, codec->spec = spec; hdmi_array_init(spec, 4); -- 1.9.1

2 1

[alsa-devel] [PATCH] ALSA: usb-audio: Add a sample rate quirk for Phoenix Audio TMX320
by Takashi Iwai 04 Apr '16

04 Apr '16

Phoenix Audio TMX320 gives the similar error when the sample rate is asked: usb 2-1.3: 2:1: cannot get freq at ep 0x85 usb 2-1.3: 1:1: cannot get freq at ep 0x2 .... Add the corresponding USB-device ID (1de7:0014) to snd_usb_get_sample_rate_quirk() list. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=110221 Cc: <stable(a)vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai(a)suse.de> --- sound/usb/quirks.c | 1 + 1 file changed, 1 insertion(+) diff --git a/sound/usb/quirks.c b/sound/usb/quirks.c index 6178bb5d0731..24c7c2311b47 100644 --- a/sound/usb/quirks.c +++ b/sound/usb/quirks.c @@ -1137,6 +1137,7 @@ bool snd_usb_get_sample_rate_quirk(struct snd_usb_audio *chip) case USB_ID(0x047F, 0xAA05): /* Plantronics DA45 */ case USB_ID(0x04D8, 0xFEEA): /* Benchmark DAC1 Pre */ case USB_ID(0x074D, 0x3553): /* Outlaw RR2150 (Micronas UAC3553B) */ + case USB_ID(0x1de7, 0x0014): /* Phoenix Audio TMX320 */ case USB_ID(0x21B4, 0x0081): /* AudioQuest DragonFly */ return true; } -- 2.7.4

1 0

Re: [alsa-devel] Getting rid of inside_vm in intel8x0
by Takashi Iwai 04 Apr '16

04 Apr '16

On Mon, 04 Apr 2016 11:05:43 +0200, George Dunlap wrote: > > On 02/04/16 13:57, Andy Lutomirski wrote: > > On Fri, Apr 1, 2016 at 10:33 PM, Takashi Iwai <tiwai(a)suse.de> wrote: > >> On Sat, 02 Apr 2016 00:28:31 +0200, > >> Luis R. Rodriguez wrote: > >>> If the former, could a we somehow detect an emulated device other than through > >>> this type of check ? Or could we *add* a capability of some sort to detect it > >>> on the driver ? This would not address the removal, but it could mean finding a > >>> way to address emulation issues. > >>> > >>> If its an IO issue -- exactly what is the causing the delays in IO ? > >> > >> Luis, there is no problem about emulation itself. It's rather an > >> optimization to lighten the host side load, as I/O access on a VM is > >> much heavier. > >> > >>>>>> This is satisfied mostly only on VM, and can't > >>>>>> be measured easily unlike the IO read speed. > >>>>> > >>>>> Interesting, note the original patch claimed it was for KVM and > >>>>> Parallels hypervisor only, but since the code uses: > >>>>> > >>>>> +#if defined(__i386__) || defined(__x86_64__) > >>>>> + inside_vm = inside_vm || boot_cpu_has(X86_FEATURE_HYPERVISOR); > >>>>> +#endif > >>>>> > >>>>> This makes it apply also to Xen as well, this makes this hack more > >>>>> broad, but does is it only applicable when an emulated device is > >>>>> used ? What about if a hypervisor is used and PCI passthrough is > >>>>> used ? > >>>> > >>>> A good question. Xen was added there at the time from positive > >>>> results by quick tests, but it might show an issue if it's running on > >>>> a very old chip with PCI passthrough. But I'm not sure whether PCI > >>>> passthrough would work on such old chipsets at all. > >>> > >>> If it did have an issue then that would have to be special cased, that > >>> is the module parameter would not need to be enabled for such type of > >>> systems, and heuristics would be needed. As you note, fortunately this > >>> may not be common though... > >> > >> Actually this *is* module parametered. If set to a boolean value, it > >> can be applied / skipped forcibly. So, if there has been a problem on > >> Xen, this should have been reported. That's why I wrote it's no > >> common case. This comes from the real experience. > >> > >>> but if this type of work around may be > >>> taken as a precedent to enable other types of hacks in other drivers > >>> I'm very fearful of more hacks later needing these considerations as > >>> well. > >>> > >>>>>>> There are a pile of nonsensical "are we in a VM" checks of various > >>>>>>> sorts scattered throughout the kernel, they're all a mess to maintain > >>>>>>> (there are lots of kinds of VMs in the world, and Linux may not even > >>>>>>> know it's a guest), and, in most cases, it appears that the correct > >>>>>>> solution is to delete the checks. I just removed a nasty one in the > >>>>>>> x86_32 entry asm, and this one is written in C so it should be a piece > >>>>>>> of cake :) > >>>>>> > >>>>>> This cake looks sweet, but a worm is hidden behind the cream. > >>>>>> The loop in the code itself is already a kludge for the buggy hardware > >>>>>> where the inconsistent read happens not so often (only at the boundary > >>>>>> and in a racy way). It would be nice if we can have a more reliably > >>>>>> way to know the hardware buggyness, but it's difficult, > >>>>>> unsurprisingly. > >>>>> > >>>>> The concern here is setting precedents for VM cases sprinkled in the kernel. > >>>>> The assumption here is such special cases are really paper'ing over another > >>>>> type of issue, so its best to ultimately try to root cause the issue in > >>>>> a more generalized fashion. > >>>> > >>>> Well, it's rather bare metal that shows the buggy behavior, thus we > >>>> need to paper over it. In that sense, it's other way round; we don't > >>>> tune for VM. The VM check we're discussing is rather for skipping the > >>>> strange workaround. > >>> > >>> What is it exactly about a VM that enables this work around to be skipped? > >>> I don't quite get it yet. > >> > >> VM -- at least the full one with the sound hardware emulation -- > >> doesn't have the hardware bug. So, the check isn't needed. > > > > Here's the issue, though: asking "am I in a VM" is not a good way to > > learn properties of hardware. Just off the top of my head, here are > > some types of VM and what they might imply about hardware: > > > > Intel Kernel Guard: your sound card is passed through from real hardware. > > > > Xen: could go either way. In dom0, it's likely passed through. In > > domU, it could be passed through or emulated, and I believe this is > > the case for all of the Xen variants. > > > > KVM: Probably emulated, but could be passed through. > > I'm not sure exactly why I was CC'd into this thread, but this is an > important point -- even if you're running in a VM, you may actually have > direct un-emulated IO access to a real (buggy) piece of hardware; in > which case it sounds like you still need the work-around. So > boot_cpu_has(X86_FEATURE_HYPERVISOR) is probably not the right check. The VM check is kept there only to show a kernel message; in case where a similar issue is seen on another VM, user may notice more easily by that. The VM check itself doesn't change any kernel behavior any longer. Takashi

1 0

[alsa-devel] [PATCH v2] ALSA: hda - Update chmap tlv to report sink's capability
by Subhransu S. Prusty 04 Apr '16

04 Apr '16

The existing TLV callback implementation copies all of the cea_channel_speaker_allocation map table to the TLV container irrespective of what is reported by sink. This is of little use to the userspace application. With this patch, it parses the spk_alloc block as queried from the ELD, and copies only the corresponding channel map from the cea channel speaker allocation table. Thus the user can parse the TLV container to identify sink's capability and set the channel map accordingly. It shouldn't impact the behavior in AMD chipset, as this makes use of already parsed spk alloc block to calculate the channel map. Signed-off-by: Subhransu S. Prusty <subhransu.s.prusty(a)intel.com> Signed-off-by: Vinod Koul <vinod.koul(a)intel.com> --- changes in v2: Updated the commit message to make it more understandable. include/sound/hda_chmap.h | 2 ++ sound/hda/hdmi_chmap.c | 90 +++++++++++++++++++++++++++++----------------- sound/pci/hda/patch_hdmi.c | 13 +++++++ 3 files changed, 72 insertions(+), 33 deletions(-) diff --git a/include/sound/hda_chmap.h b/include/sound/hda_chmap.h index e20d219..babd445 100644 --- a/include/sound/hda_chmap.h +++ b/include/sound/hda_chmap.h @@ -36,6 +36,8 @@ struct hdac_chmap_ops { int (*chmap_validate)(struct hdac_chmap *hchmap, int ca, int channels, unsigned char *chmap); + int (*get_spk_alloc)(struct hdac_device *hdac, int pcm_idx); + void (*get_chmap)(struct hdac_device *hdac, int pcm_idx, unsigned char *chmap); void (*set_chmap)(struct hdac_device *hdac, int pcm_idx, diff --git a/sound/hda/hdmi_chmap.c b/sound/hda/hdmi_chmap.c index d7ec862..9406203 100644 --- a/sound/hda/hdmi_chmap.c +++ b/sound/hda/hdmi_chmap.c @@ -625,13 +625,40 @@ static void hdmi_cea_alloc_to_tlv_chmap(struct hdac_chmap *hchmap, WARN_ON(count != channels); } +static struct hdac_cea_channel_speaker_allocation *get_cap_from_spk_alloc( + int spk_alloc) +{ + int i, spk_mask = 0; + + if (!spk_alloc) + return &channel_allocations[0]; + + for (i = 0; i < ARRAY_SIZE(eld_speaker_allocation_bits); i++) { + if (spk_alloc & (1 << i)) + spk_mask |= eld_speaker_allocation_bits[i]; + } + + /* Get num channels using spk mask */ + for (i = 0; i < ARRAY_SIZE(channel_allocations); i++) { + if ((spk_mask & channel_allocations[i].spk_mask) == spk_mask) + return &channel_allocations[i]; + } + + return &channel_allocations[0]; +} + static int hdmi_chmap_ctl_tlv(struct snd_kcontrol *kcontrol, int op_flag, unsigned int size, unsigned int __user *tlv) { struct snd_pcm_chmap *info = snd_kcontrol_chip(kcontrol); struct hdac_chmap *chmap = info->private_data; + int pcm_idx = kcontrol->private_value; unsigned int __user *dst; - int chs, count = 0; + int chs, count = 0, chs_bytes; + int type; + unsigned int tlv_chmap[8]; + int spk_alloc; + struct hdac_cea_channel_speaker_allocation *cap; if (size < 8) return -ENOMEM; @@ -639,40 +666,37 @@ static int hdmi_chmap_ctl_tlv(struct snd_kcontrol *kcontrol, int op_flag, return -EFAULT; size -= 8; dst = tlv + 2; - for (chs = 2; chs <= chmap->channels_max; chs++) { - int i; - struct hdac_cea_channel_speaker_allocation *cap; - - cap = channel_allocations; - for (i = 0; i < ARRAY_SIZE(channel_allocations); i++, cap++) { - int chs_bytes = chs * 4; - int type = chmap->ops.chmap_cea_alloc_validate_get_type( - chmap, cap, chs); - unsigned int tlv_chmap[8]; - - if (type < 0) - continue; - if (size < 8) - return -ENOMEM; - if (put_user(type, dst) || - put_user(chs_bytes, dst + 1)) - return -EFAULT; - dst += 2; - size -= 8; - count += 8; - if (size < chs_bytes) - return -ENOMEM; - size -= chs_bytes; - count += chs_bytes; - chmap->ops.cea_alloc_to_tlv_chmap(chmap, cap, - tlv_chmap, chs); - if (copy_to_user(dst, tlv_chmap, chs_bytes)) - return -EFAULT; - dst += chs; - } - } + + if (size < 8) + return -ENOMEM; + + spk_alloc = chmap->ops.get_spk_alloc(chmap->hdac, pcm_idx); + cap = get_cap_from_spk_alloc(spk_alloc); + chs = cap->channels; + + chs_bytes = chs * 4; + type = chmap->ops.chmap_cea_alloc_validate_get_type(chmap, cap, chs); + if (type < 0) + return -ENODEV; + + if (put_user(type, dst) || + put_user(chs_bytes, dst + 1)) + return -EFAULT; + + dst += 2; + size -= 8; + count += 8; + if (size < chs_bytes) + return -ENOMEM; + + count += chs_bytes; + chmap->ops.cea_alloc_to_tlv_chmap(chmap, cap, tlv_chmap, chs); + if (copy_to_user(dst, tlv_chmap, chs_bytes)) + return -EFAULT; + if (put_user(count, tlv + 1)) return -EFAULT; + return 0; } diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c index 5af372d..dd25f2c 100644 --- a/sound/pci/hda/patch_hdmi.c +++ b/sound/pci/hda/patch_hdmi.c @@ -1838,6 +1838,18 @@ static const struct hda_pcm_ops generic_ops = { .cleanup = generic_hdmi_playback_pcm_cleanup, }; +static int hdmi_get_spk_alloc(struct hdac_device *hdac, int pcm_idx) +{ + struct hda_codec *codec = container_of(hdac, struct hda_codec, core); + struct hdmi_spec *spec = codec->spec; + struct hdmi_spec_per_pin *per_pin = pcm_idx_to_pin(spec, pcm_idx); + + if (!per_pin) + return 0; + + return per_pin->sink_eld.info.spk_alloc; +} + static void hdmi_get_chmap(struct hdac_device *hdac, int pcm_idx, unsigned char *chmap) { @@ -2249,6 +2261,7 @@ static int patch_generic_hdmi(struct hda_codec *codec) spec->chmap.ops.get_chmap = hdmi_get_chmap; spec->chmap.ops.set_chmap = hdmi_set_chmap; spec->chmap.ops.is_pcm_attached = is_hdmi_pcm_attached; + spec->chmap.ops.get_spk_alloc = hdmi_get_spk_alloc, codec->spec = spec; hdmi_array_init(spec, 4); -- 1.9.1

2 3

[alsa-devel] [PATCH 0/3] ASoC: hdac_hdmi: Fix codec power state in S3
by Subhransu S. Prusty 02 Apr '16

02 Apr '16

With this series, the codec power is turned OFF when entering suspend if the playback is already in progress. And during resume the power is restored. Codec driver registers the S3 callbacks with prepare/complete to synchronize with Jack notification from display driver. Codec driver takes care of putting the AFG node to proper power state during S3 and controller driver takes care of managing the codec power. Also setting the power state for AFG node is optimized by removing the timeout loop. The driver instead uses a codec_read, which sets the power state and waits for response before the codec power is turned OFF. Subhransu S. Prusty (3): ASoC: hdac_hdmi: Fix to use dev_pm ops instead soc pm ASoC: hdac_hdmi: Fix codec power state in S3 during playback ASoC: Intel: Skylake: Fix to turn OFF codec power when entering S3 sound/soc/codecs/hdac_hdmi.c | 94 +++++++++++++++++++------------------------ sound/soc/intel/skylake/skl.c | 15 ++++++- 2 files changed, 55 insertions(+), 54 deletions(-) -- 1.9.1

2 6

[alsa-devel] [PATCH v2] ASoC: mediatek: Add second I2S on mt8173-rt5650 machine driver
by PC Liao 02 Apr '16

02 Apr '16

This patch adds second I2S connection to rt5650 codec for capture path on mt8173-rt5650 machine driver. Signed-off-by: PC Liao <pc.liao(a)mediatek.com> --- Changes since v1: Use codec dai name to determine the capture path. --- .../devicetree/bindings/sound/mt8173-rt5650.txt | 6 +++ sound/soc/mediatek/mt8173-rt5650.c | 39 ++++++++++++++++++-- 2 files changed, 41 insertions(+), 4 deletions(-) diff --git a/Documentation/devicetree/bindings/sound/mt8173-rt5650.txt b/Documentation/devicetree/bindings/sound/mt8173-rt5650.txt index fe5a5ef..383cba9 100644 --- a/Documentation/devicetree/bindings/sound/mt8173-rt5650.txt +++ b/Documentation/devicetree/bindings/sound/mt8173-rt5650.txt @@ -5,11 +5,17 @@ Required properties: - mediatek,audio-codec: the phandles of rt5650 codecs - mediatek,platform: the phandle of MT8173 ASoC platform +Optional properties: +- mediatek,audio-codec-dai-capture: audio codec dai on capture path + rt5645-aif1: Default setting. Connect rt5650 I2S1 for capture + rt5645-aif2: Connect rt5650 I2S2 for capture + Example: sound { compatible = "mediatek,mt8173-rt5650"; mediatek,audio-codec = <&rt5650>; mediatek,platform = <&afe>; + mediatek,audio-codec-dai-capture = "rt5645-aif2"; }; diff --git a/sound/soc/mediatek/mt8173-rt5650.c b/sound/soc/mediatek/mt8173-rt5650.c index bb09bb1..fd2ca66 100644 --- a/sound/soc/mediatek/mt8173-rt5650.c +++ b/sound/soc/mediatek/mt8173-rt5650.c @@ -85,12 +85,26 @@ static int mt8173_rt5650_init(struct snd_soc_pcm_runtime *runtime) { struct snd_soc_card *card = runtime->card; struct snd_soc_codec *codec = runtime->codec_dais[0]->codec; + const char *codec_dai_name_capture = runtime->codec_dais[1]->name; int ret; rt5645_sel_asrc_clk_src(codec, - RT5645_DA_STEREO_FILTER | - RT5645_AD_STEREO_FILTER, - RT5645_CLK_SEL_I2S1_ASRC); + RT5645_DA_STEREO_FILTER, + RT5645_CLK_SEL_I2S1_ASRC); + + if (!strcmp(codec_dai_name_capture, "rt5645-aif1")) { + rt5645_sel_asrc_clk_src(codec, + RT5645_AD_STEREO_FILTER, + RT5645_CLK_SEL_I2S1_ASRC); + } else if (!strcmp(codec_dai_name_capture, "rt5645-aif2")) { + rt5645_sel_asrc_clk_src(codec, + RT5645_AD_STEREO_FILTER, + RT5645_CLK_SEL_I2S2_ASRC); + } else { + dev_err(card->dev, "Can't get the right codec dai\n"); + return -EINVAL; + } + /* enable jack detection */ ret = snd_soc_card_jack_new(card, "Headset Jack", SND_JACK_HEADPHONE | SND_JACK_MICROPHONE | @@ -110,6 +124,11 @@ static int mt8173_rt5650_init(struct snd_soc_pcm_runtime *runtime) static struct snd_soc_dai_link_component mt8173_rt5650_codecs[] = { { + /* Playback */ + .dai_name = "rt5645-aif1", + }, + { + /* Capture */ .dai_name = "rt5645-aif1", }, }; @@ -149,7 +168,7 @@ static struct snd_soc_dai_link mt8173_rt5650_dais[] = { .cpu_dai_name = "I2S", .no_pcm = 1, .codecs = mt8173_rt5650_codecs, - .num_codecs = 1, + .num_codecs = 2, .init = mt8173_rt5650_init, .dai_fmt = SND_SOC_DAIFMT_I2S | SND_SOC_DAIFMT_NB_NF | SND_SOC_DAIFMT_CBS_CFS, @@ -177,6 +196,7 @@ static int mt8173_rt5650_dev_probe(struct platform_device *pdev) { struct snd_soc_card *card = &mt8173_rt5650_card; struct device_node *platform_node; + const char *codec_dai_name_capture; int i, ret; platform_node = of_parse_phandle(pdev->dev.of_node, @@ -199,6 +219,17 @@ static int mt8173_rt5650_dev_probe(struct platform_device *pdev) "Property 'audio-codec' missing or invalid\n"); return -EINVAL; } + mt8173_rt5650_codecs[1].of_node = mt8173_rt5650_codecs[0].of_node; + + if (device_property_present(&pdev->dev, + "mediatek,audio-codec-dai-capture")) { + device_property_read_string(&pdev->dev, + "mediatek,audio-codec-dai-capture", + &codec_dai_name_capture); + + mt8173_rt5650_codecs[1].dai_name = codec_dai_name_capture; + } + card->dev = &pdev->dev; platform_set_drvdata(pdev, card); -- 1.7.9.5

2 1

[alsa-devel] [PATCH v2 0/2] ASoC: codecs: add support for TAS5720 digital amplifier
by Andreas Dannenberg 02 Apr '16

02 Apr '16

Driver for TI's TAS5720L/M digital audio amplifiers. The driver should be pretty standard except the optional interrupt-based fault reporting. Some background on the fault reporting since that might be a discussion of interest. The code should have that documented rather well but I wanted to bring it up right away. The TAS5720 devices can report conditions such as over-current (short), over temp, and others that can be important to know in a real-world system. However the device lacks a way to mask the generation of fault interrupts except by shutting it down, which can lead to cases where the device generates SAIF-fault host interrupts every 300us! This is clearly a lot of overhead to be thrown at the SoC (and my bench testing has demonstrated that) so after trying different things to tame this behavior I ended up implementing method to disable/enable the interrupts in the driver itself in combination with rate-limiting the processing of those events. The fact of processing interrupts in a threaded fashion (IRQF_ONESHOT) alone was not enough under certain conditions to prevent the SoC from not being able to get to all interrupts even with an empty threaded handler, and it would freeze and eventually the Kernel would disable the interrupt ("no one cared"). The scheme currently implemented seems to work reliably cycling different audio files over hours also forcing error conditions. But if anybody has a "cleaner" idea how to rate-limit IRQs on a very low level (currently done in the IRQ handler function) I'm absolutely open to suggestions. This all may not be an issue at all when using a faster/lower-latency SoC than what I'm using (BeagleBone Black) but the fact that IRQF_ONESHOT alone was not enough to prevent the system to be brought to its knees (again, even with an empty threaded handler) was a bit of a surprise to me. -- Andreas Dannenberg Texas Instruments Inc Changes since v1: - Simplified DT interrupt documentation (Thanks Rob Herring) - Fixed potential race condition during codec probe where deferred work that's used by the threaded IRQ handler was setup after the IRQ was initialized (would lead to an issue when the TAS5720 was already throwing interrupts at the time of probe) Andreas Dannenberg (2): ASoC: codecs: add TA5720 digital amplifier DT bindings ASoC: codecs: add support for TAS5720 digital amplifier .../devicetree/bindings/sound/tas5720.txt | 37 ++ sound/soc/codecs/Kconfig | 10 + sound/soc/codecs/Makefile | 2 + sound/soc/codecs/tas5720.c | 734 +++++++++++++++++++++ sound/soc/codecs/tas5720.h | 90 +++ 5 files changed, 873 insertions(+) create mode 100644 Documentation/devicetree/bindings/sound/tas5720.txt create mode 100644 sound/soc/codecs/tas5720.c create mode 100644 sound/soc/codecs/tas5720.h -- 2.6.4

3 8