- 11 Nov, 2014 3 commits
-
-
Takashi Iwai authored
Signed-off-by:Takashi Iwai <tiwai@suse.de>
-
Takashi Iwai authored
Signed-off-by: -
Takashi Iwai authored
The file isn't processed, but it's not bad to fix beforehand. Signed-off-by:
-
- 10 Nov, 2014 2 commits
-
-
Takashi Iwai authored
The quirk argument itself was used as iterator, so it cannot be taken back to the original value, obviously. Fixes: d4b8fc66 ('ALSA: usb-audio: Allow multiple entries for the same iface in composite quirk') Signed-off-by:
-
Takashi Iwai authored
Fix a copy & paste error: Warning(sound/core/pcm_native.c:1112): Excess function parameter 'state' description in 'snd_pcm_stop_xrun' The state argument was dropped from snd_pcm_stop_xrun(). Reported-by:
kbuild test robot <fengguang.wu@intel.com> Signed-off-by:
-
- 09 Nov, 2014 2 commits
-
-
Takashi Iwai authored
Currently the composite quirk doesn't work when multiple entries are assigned to the same interface because it marks the interface as claimed then checks whether the interface has been already claimed for the secondary entry. But, if you look at the code, you'll notice that multiple entries are allowed if the entry is the current interface; i.e. the current behavior is anyway inconsistent, and this is an unintended shortcoming. This patch fixes the problem by marking the relevant interfaces as claimed after applying the all composite entries. This fix will be needed for the upcoming enhancements for Digidesign Mbox 1 quirks. Reviewed-by:
Clemens Ladisch <clemens@ladisch.de> Signed-off-by:
-
Takashi Iwai authored
Add a new helper function snd_pcm_stop_xrun() to the standard sequnce lock/snd_pcm_stop(XRUN)/unlock by a single call, and replace the existing open codes with this helper. The function checks the PCM running state to prevent setting the wrong state, too, for more safety. Signed-off-by:
-
- 07 Nov, 2014 1 commit
-
-
Lars-Peter Clausen authored
We want to know the offset for the id that was passed to the function, not the offset of the first id of the control (which is always 0). Signed-off-by:
Lars-Peter Clausen <lars@metafoo.de> Signed-off-by:
-
- 06 Nov, 2014 2 commits
-
-
Takashi Iwai authored
The usb-audio driver detects XRUN at its complete callback, but the actual code to trigger PCM XRUN is commented out because it caused deadlock in the past. This patch revives the PCM trigger properly. It resulted in more than just enabling snd_pcm_stop(), but it had to deduce the PCM substream with proper NULL checks and holds the stream lock around the call. Signed-off-by: -
Takashi Iwai authored
Some state changes (e.g. snd_pcm_stop()) sets the runtime state after calling snd_timer_notify(). This is basically racy, since the notification may wakes up the user even before the state change. Although the possibility is low, we should set the state before the notifications. Signed-off-by:
-
- 05 Nov, 2014 5 commits
-
-
Takashi Iwai authored
This merges the USB-audio disconnect fix and resolves the conflicts so that we can continue working on development of usb-audio stuff. Conflicts: sound/usb/card.c
-
Takashi Iwai authored
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: [<ffffffff814a3e38>] ? dump_stack+0x49/0x71 [<ffffffff8103cb72>] ? warn_slowpath_common+0x82/0xb0 [<ffffffff8103cc55>] ? warn_slowpath_fmt+0x45/0x50 [<ffffffff813521e9>] ? device_del+0x39/0x180 [<ffffffff81352339>] ? device_unregister+0x9/0x20 [<ffffffff81352384>] ? device_destroy+0x34/0x40 [<ffffffffa00ba29f>] ? snd_unregister_device+0x7f/0xd0 [snd] [<ffffffffa025124e>] ? snd_rawmidi_dev_disconnect+0xce/0x100 [snd_rawmidi] [<ffffffffa00c0192>] ? snd_device_disconnect+0x62/0x90 [snd] [<ffffffffa00c025c>] ? snd_device_disconnect_all+0x3c/0x60 [snd] [<ffffffffa00bb574>] ? snd_card_disconnect+0x124/0x1a0 [snd] [<ffffffffa02e54e8>] ? usb_audio_disconnect+0x88/0x1c0 [snd_usb_audio] [<ffffffffa015260e>] ? usb_unbind_interface+0x5e/0x1b0 [usbcore] [<ffffffff813553e9>] ? __device_release_driver+0x79/0xf0 [<ffffffff81355485>] ? device_release_driver+0x25/0x40 [<ffffffff81354e11>] ? bus_remove_device+0xf1/0x130 [<ffffffff813522b9>] ? device_del+0x109/0x180 [<ffffffffa01501d5>] ? usb_disable_device+0x95/0x1f0 [usbcore] [<ffffffffa014634f>] ? usb_disconnect+0x8f/0x190 [usbcore] [<ffffffffa0149179>] ? hub_thread+0x539/0x13a0 [usbcore] [<ffffffff810669f5>] ? sched_clock_local+0x15/0x80 [<ffffffff81066c98>] ? sched_clock_cpu+0xb8/0xd0 [<ffffffff81070730>] ? bit_waitqueue+0xb0/0xb0 [<ffffffffa0148c40>] ? usb_port_resume+0x430/0x430 [usbcore] [<ffffffffa0148c40>] ? usb_port_resume+0x430/0x430 [usbcore] [<ffffffff8105973e>] ? kthread+0xce/0xf0 [<ffffffff81059670>] ? kthread_create_on_node+0x1c0/0x1c0 [<ffffffff814a8b7c>] ? ret_from_fork+0x7c/0xb0 [<ffffffff81059670>] ? 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=80931Reported-and-tested-by:
Tomas Gayoso <tgayoso@gmail.com> Reported-and-tested-by:
Chris J Arges <chris.j.arges@canonical.com> Cc: <stable@vger.kernel.org> Signed-off-by:
-
Sudip Mukherjee authored
commit "b5b4a41b" was dereferencing chip after it has been freed. This patch fixes that and at the same time removes some debugging messages, which are unnecessary, as they are just printing information about entry and exit from a function, and which switch-case it is executing. we can easily get from ftrace the information about the entry and exit from a function. Reported-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
Sudip Mukherjee <sudip@vectorindia.org> Signed-off-by:
-
Takashi Iwai authored
here is a small series of patches for cleaning up / enhancing the PCM core stuff.
-
Hui Wang authored
Without the fix, the mute led can't work on these three machines. After apply this fix, these three machines will fall back on the led control quirk as below, and through testing, the mute led works very well. PIN_QUIRK(0x10ec0282, 0x103c, "HP", ALC269_FIXUP_HP_LINE1_MIC1_LED, ALC282_STANDARD_PINS, {0x12, 0x90a60140}, ... BugLink: https://bugs.launchpad.net/bugs/1389497Tested-by:TieFu Chen <tienfu.chen@canonical.com> Cc: Kailang Yang <kailang@realtek.com> Cc: stable@vger.kernel.org Signed-off-by:
Hui Wang <hui.wang@canonical.com> Signed-off-by:
-
- 04 Nov, 2014 7 commits
-
-
Takashi Iwai authored
Signed-off-by: -
Takashi Iwai authored
Some functions in mixer.c and endpoint.c receive list_head instead of the object itself. This is not obvious and rather error-prone. Let's pass the proper object directly instead. The functions in midi.c still receive list_head and this can't be changed since the object definition isn't exposed to the outside of midi.c, so left as is. Signed-off-by: -
Takashi Iwai authored
The usb-audio probe and disconnect functions have been split just for adapting the (new!) API at 2.5 kernel time. We left them until now, partly because we wanted to build with the pretty old kernels in the external alsa-driver tree. But the support of such old kernels has been longly stopped, so it's good time to clean up this mess. One good point by this cleanup is that now the probe function returns a proper error code instead of only -EIO. Signed-off-by: -
Takashi Iwai authored
This patch adds a new proc entry for PCM substreams to inject an XRUN. When a PCM substream is running and any value is written to its xrun_injection proc file, the driver triggers XRUN. This is a useful feature for debugging XRUN and error handling code paths. Note that this entry is enabled only when CONFIG_SND_PCM_XRUN_DEBUG is set. Signed-off-by: -
Takashi Iwai authored
ALSA PCM core has a mechanism tracking the PCM hwptr updates for analyzing XRUNs. But its log is limited (up to 10) and its log output is a kernel message, which is hard to handle. In this patch, the hwptr logging is moved to the tracing infrastructure instead of its own. Not only the hwptr updates but also XRUN and hwptr errors are recorded on the trace log, so that user can see such events at the exact timing. The new "snd_pcm" entry will appear in the tracing events: # ls -F /sys/kernel/debug/tracing/events/snd_pcm enable filter hw_ptr_error/ hwptr/ xrun/ The hwptr is for the regular hwptr update events. An event trace looks like: aplay-26187 [004] d..3 4012.834761: hwptr: pcmC0D0p/sub0: POS: pos=488, old=0, base=0, period=1024, buf=16384 "POS" shows the hwptr update by the explicit position update call and "IRQ" means the hwptr update by the interrupt, i.e. snd_pcm_period_elapsed() call. The "pos" is the passed ring-buffer offset by the caller, "old" is the previous hwptr, "base" is the hwptr base position, "period" and "buf" are period- and buffer-size of the target PCM substream. (Note that the hwptr position displayed here isn't the ring-buffer offset. It increments up to the PCM position boundary.) The XRUN event appears similarly, but without "pos" field. The hwptr error events appear with the PCM identifier and its reason string, such as "Lost interrupt?". The XRUN and hwptr error reports on kernel message are still left, can be turned on/off via xrun_debug proc like before. But the bit 3, 4, 5 and 6 bits of xrun_debug proc are dropped by this patch. Also, along with the change, the message strings have been reformatted to be a bit more consistent. Last but not least, the hwptr reporting is enabled only when CONFIG_SND_PCM_XRUN_DEBUG is set. Signed-off-by: -
Takashi Iwai authored
While converting to dev_*(), the message showing the invalid PCM position was wrongly tagged as if an XRUN although it's actually a BUG. This patch corrects the message again. Signed-off-by: -
Ondrej Zary authored
Add GPO0 and GPO1 (General Purpose Outputs) controls to mixer. These can be used on some cards to control amplifier mute (seen in ES1868 datasheet) or additional onboard chips such as QX2130 QXpander processor. These GPOs are present on ES1868, ES1869, ES1887 and ES1888 chips. Tested on ES1868 with QX2130. Signed-off-by:
Ondrej Zary <linux@rainbow-software.org> Signed-off-by:
-
- 03 Nov, 2014 3 commits
-
-
Markus Elfring authored
The functions kfree(), release_firmware() and snd_util_memhdr_free() test whether their argument is NULL and then return immediately. Thus the test around the call is not needed. This issue was detected by using the Coccinelle software. Signed-off-by:
Markus Elfring <elfring@users.sourceforge.net> Signed-off-by:
-
Sudip Mukherjee authored
removed all references of snd_printk with the standard dev_* macro. [a few places degraded to dev_dbg(), too -- tiwai] Signed-off-by:
-
Sudip Mukherjee authored
added reference of struct echoaudio to free_firmware function. this structure will be later used to get a reference of the card when converting snd_printk to dev_* in the next patch of the series. Signed-off-by:
-
- 31 Oct, 2014 3 commits
-
-
Takashi Iwai authored
Just a small code refactoring to reduce more lines. Signed-off-by: -
Takashi Iwai authored
The function snd_pcm_action_lock_irq() can be much simplified by simply wrapping snd_pcm_action() with the stream lock. This was rather the original idea, but later it was open coded for optimization. However, looking at the optimization part closely, one notices that the probability of the optimized path is quite low; in normal situations, the linked stream action happens only for the triggered substream, thus the operation becomes identical. So the code simplification has a clear win, especially because we have now doubly codes for both atomic and non-atomic locks. Signed-off-by: -
Takashi Iwai authored
-
- 30 Oct, 2014 12 commits
-
-
Takashi Iwai authored
Fixes: 90446d07 ('ALSA: doc: Add missing headers and compress stuff to alsa-driver-api.tmpl') Signed-off-by:
-
Takashi Iwai authored
Some functions missed the proper kerneldoc comments. Signed-off-by: -
Takashi Iwai authored
... and add proper kerneldoc comments. There is no big reason to keep them as macros. Static inline functions are safer in general, and suitable for kerneldoc, too. Signed-off-by: -
Takashi Iwai authored
Add proper kerneldoc comments to the exported functions. Signed-off-by: -
Takashi Iwai authored
... instead of #if 0 hack. It's more straightforward and obvious. Signed-off-by: -
Takashi Iwai authored
A few functions have no proper documentation yet, so let's add them. Along with it, remove superfluous blank line between the closing brace and EXPORT_SYMBOL() line. Signed-off-by: -
Takashi Iwai authored
Signed-off-by: -
Takashi Iwai authored
Signed-off-by: -
Kailang Yang authored
The default EAPD control uses verb command to control EAPD. Some codec does not have verb command for EAPD. It needs to control by hidden register. This update will avoid wrong behavior for some codec. This patch will fix double setup for EAPD. It just needs to turn on by one site for verb command or hidden register controlled. Detailed changes: - alc889_coef_init() is replaced with alc_update_coef_idx() with a correct COEF value. - for ALC262, ALC887 and ALC900, the EAPD setup via the hidden register is removed because this rather conflicts with the EAPD verb setup. - For ALC888-VC, also the hidden register access is removed in alc888_coef_init(). - Remove the dead #if 0 code for ALC267/ALC268. Signed-off-by:
Kailang Yang <kailang@realtek.com> Cc: <stable@vger.kernel.org> Signed-off-by:
-
David Henningsson authored
These three HP machines all have the same pin config, so we can change it to a pin quirk. Signed-off-by:
David Henningsson <david.henningsson@canonical.com> Signed-off-by:
-
David Henningsson authored
These HP machines needs GPIO 4 low to enable the headphone amplifier. In addition, we still need to control LEDs via vref and GPIO. Cc: stable@vger.kernel.org BugLink: https://bugs.launchpad.net/bugs/1387128Tested-by:
-
Takashi Iwai authored
-
