user/sven/linux.git/sound, branch v3.2.65

ALSA: hda - Limit 40bit DMA for AMD HDMI controllers

2014-12-14T16:24:00Z

commit 413cbf469a19e7662ba5025695bf5a573927105a upstream. AMD/ATI HDMI controller chip models, we already have a filter to lower to 32bit DMA, but the rest are supposed to be working with 64bit although the hardware doesn't really work with 63bit but only with 40 or 48bit DMA. In this patch, we take 40bit DMA for safety for the AMD/ATI controllers as the graphics drivers does. Signed-off-by: Takashi Iwai Signed-off-by: Benjamin Herrenschmidt [bwh: Backported to 3.2: - Adjust context - s/AZX_GCAP_64OK/ICH6_GCAP_64OK/] Signed-off-by: Ben Hutchings

ASoC: sgtl5000: Fix SMALL_POP bit definition

2014-12-14T16:23:56Z

commit c251ea7bd7a04f1f2575467e0de76e803cf59149 upstream. On a mx28evk with a sgtl5000 codec we notice a loud 'click' sound to happen 5 seconds after the end of a playback. The SMALL_POP bit should fix this, but its definition is incorrect: according to the sgtl5000 manual it is bit 0 of CHIP_REF_CTRL register, not bit 1. Fix the definition accordingly and enable the bit as intended per the code comment. After applying this change, no loud 'click' sound is heard after playback Signed-off-by: Fabio Estevam Signed-off-by: Mark Brown Signed-off-by: Ben Hutchings

ALSA: usb-audio: Fix device_del() sysfs warnings at disconnect

2014-12-14T16:23:55Z

commit 0725dda207e95ff25f1aa01432250323e0ec49d6 upstream. Some USB-audio devices show weird sysfs warnings at disconnecting the devices, e.g. usb 1-3: USB disconnect, device number 3 ------------[ cut here ]------------ WARNING: CPU: 0 PID: 973 at fs/sysfs/group.c:216 device_del+0x39/0x180() sysfs group ffffffff8183df40 not found for kobject 'midiC1D0' Call Trace: [] ? dump_stack+0x49/0x71 [] ? warn_slowpath_common+0x82/0xb0 [] ? warn_slowpath_fmt+0x45/0x50 [] ? device_del+0x39/0x180 [] ? device_unregister+0x9/0x20 [] ? device_destroy+0x34/0x40 [] ? snd_unregister_device+0x7f/0xd0 [snd] [] ? snd_rawmidi_dev_disconnect+0xce/0x100 [snd_rawmidi] [] ? snd_device_disconnect+0x62/0x90 [snd] [] ? snd_device_disconnect_all+0x3c/0x60 [snd] [] ? snd_card_disconnect+0x124/0x1a0 [snd] [] ? usb_audio_disconnect+0x88/0x1c0 [snd_usb_audio] [] ? usb_unbind_interface+0x5e/0x1b0 [usbcore] [] ? __device_release_driver+0x79/0xf0 [] ? device_release_driver+0x25/0x40 [] ? bus_remove_device+0xf1/0x130 [] ? device_del+0x109/0x180 [] ? usb_disable_device+0x95/0x1f0 [usbcore] [] ? usb_disconnect+0x8f/0x190 [usbcore] [] ? hub_thread+0x539/0x13a0 [usbcore] [] ? sched_clock_local+0x15/0x80 [] ? sched_clock_cpu+0xb8/0xd0 [] ? bit_waitqueue+0xb0/0xb0 [] ? usb_port_resume+0x430/0x430 [usbcore] [] ? usb_port_resume+0x430/0x430 [usbcore] [] ? kthread+0xce/0xf0 [] ? kthread_create_on_node+0x1c0/0x1c0 [] ? ret_from_fork+0x7c/0xb0 [] ? kthread_create_on_node+0x1c0/0x1c0 ---[ end trace 40b1928d1136b91e ]--- This comes from the fact that usb-audio driver may receive the disconnect callback multiple times, per each usb interface. When a device has both audio and midi interfaces, it gets called twice, and currently the driver tries to release resources at the last call. At this point, the first parent interface has been already deleted, thus deleting a child of the first parent hits such a warning. For fixing this problem, we need to call snd_card_disconnect() and cancel pending operations at the very first disconnect while the release of the whole objects waits until the last disconnect call. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=80931 Reported-and-tested-by: Tomas Gayoso Reported-and-tested-by: Chris J Arges Signed-off-by: Takashi Iwai [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings

ASoC: fsi: remove unsupported PAUSE flag

2014-12-14T16:23:52Z

commit c1b9b9b1ad2df6144ca3fbe6989f7bd9ea5c5562 upstream. FSI doesn't support PAUSE. Remove SNDRV_PCM_INFO_PAUSE flags from snd_pcm_hardware info Signed-off-by: Kuninori Morimoto Signed-off-by: Mark Brown [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings

ALSA: pcm: Zero-clear reserved fields of PCM status ioctl in compat mode

2014-12-14T16:23:52Z

commit 317168d0c766defd14b3d0e9c2c4a9a258b803ee upstream. In compat mode, we copy each field of snd_pcm_status struct but don't touch the reserved fields, and this leaves uninitialized values there. Meanwhile the native ioctl does zero-clear the whole structure, so we should follow the same rule in compat mode, too. Reported-by: Pierre-Louis Bossart Signed-off-by: Takashi Iwai Signed-off-by: Ben Hutchings

ALSA: emu10k1: Fix deadlock in synth voice lookup

2014-12-14T16:23:48Z

commit 95926035b187cc9fee6fb61385b7da9c28123f74 upstream. The emu10k1 voice allocator takes voice_lock spinlock. When there is no empty stream available, it tries to release a voice used by synth, and calls get_synth_voice. The callback function, snd_emu10k1_synth_get_voice(), however, also takes the voice_lock, thus it deadlocks. The fix is simply removing the voice_lock holds in snd_emu10k1_synth_get_voice(), as this is always called in the spinlock context. Reported-and-tested-by: Arthur Marsh Signed-off-by: Takashi Iwai Signed-off-by: Ben Hutchings

ALSA: pcm: fix fifo_size frame calculation

2014-11-05T20:27:45Z

commit a9960e6a293e6fc3ed414643bb4e4106272e4d0a upstream. The calculated frame size was wrong because snd_pcm_format_physical_width() actually returns the number of bits, not bytes. Use snd_pcm_format_size() instead, which not only returns bytes, but also simplifies the calculation. Fixes: 8bea869c5e56 ("ALSA: PCM midlevel: improve fifo_size handling") Signed-off-by: Clemens Ladisch Signed-off-by: Takashi Iwai Signed-off-by: Ben Hutchings

ALSA: hda - Fix COEF setups for ALC1150 codec

2014-11-05T20:27:40Z

commit acf08081adb5e8fe0519eb97bb49797ef52614d6 upstream. ALC1150 codec seems to need the COEF- and PLL-setups just like its compatible ALC882 codec. Some machines (e.g. SunMicro X10SAT) show the problem like too low output volumes unless the COEF setup is applied. Reported-and-tested-by: Dana Goyette Signed-off-by: Takashi Iwai Signed-off-by: Ben Hutchings

ALSA: hda/realtek - Avoid setting wrong COEF on ALC269 & co

2014-09-13T22:41:44Z

commit f3ee07d8b6e061bf34a7167c3f564e8da4360a99 upstream. ALC269 & co have many vendor-specific setups with COEF verbs. However, some verbs seem specific to some codec versions and they result in the codec stalling. Typically, such a case can be avoided by checking the return value from reading a COEF. If the return value is -1, it implies that the COEF is invalid, thus it shouldn't be written. This patch adds the invalid COEF checks in appropriate places accessing ALC269 and its variants. The patch actually fixes the resume problem on Acer AO725 laptop. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=52181 Tested-by: Francesco Muzio Signed-off-by: Takashi Iwai [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings

ASoC: pxa-ssp: drop SNDRV_PCM_FMTBIT_S24_LE

2014-09-13T22:41:44Z

commit 9301503af016eb537ccce76adec0c1bb5c84871e upstream. This mode is unsupported, as the DMA controller can't do zero-padding of samples. Signed-off-by: Daniel Mack Reported-by: Johannes Stezenbach Signed-off-by: Mark Brown Signed-off-by: Ben Hutchings