- 21 Nov, 2014 1 commit
-
-
Kailang Yang authored
New HP machine supported output mute led and input mute led. ALC286: GPIO1 to control output mute led. GPIO5 to control input mute led. Signed-off-by:
Kailang Yang <kailang@realtek.com> Signed-off-by:
Takashi Iwai <tiwai@suse.de>
-
- 20 Nov, 2014 1 commit
-
-
Takashi Iwai authored
There are a few duplicated codes handling the mute and mic-mute LEDs via GPIO pins. Let's consolidate to single helpers. Here we introduced two new fields to alc_spec, gpio_mute_led_mask and gpio_mic_led_mask, to contain the bit mask to set/clear. Also, mute_led_polarity is evaluated as well. Signed-off-by:
-
- 18 Nov, 2014 1 commit
-
-
Takashi Sakamoto authored
Complete missing parameters, correct wrong reference, and add an explaination about the differences between the latest specification and our implementation. Signed-off-by:
Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by:
-
- 17 Nov, 2014 5 commits
-
-
Markus Elfring authored
The pci_dev_put() function tests whether its argument is NULL and then returns 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:
-
Markus Elfring authored
The release_firmware() function tests whether its 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 authored
The vfree() function performs also input parameter validation. Thus the test around the call is not needed. This issue was detected by using the Coccinelle software. Signed-off-by:
-
Markus Elfring authored
The snd_ac97_resume() function tests whether its argument is NULL and then returns immediately. Thus the test around the call is not needed. This issue was detected by using the Coccinelle software. Signed-off-by:
-
Markus Elfring authored
The functions kfree() and release_firmware() 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:
-
- 14 Nov, 2014 4 commits
-
-
Sudip Mukherjee authored
earlier we were ignoring the return value of snd_ak4114_create and always returning 0. now we are returning the actual status. revo_init is calling this function, and revo_init is checking the return value. Signed-off-by:
Sudip Mukherjee <sudip@vectorindia.org> Signed-off-by:
-
Sudip Mukherjee authored
buf_size was initialized with snd_pcm_lib_buffer_bytes, but never used. and so it is safe to be deleted. Signed-off-by:
-
Sudip Mukherjee authored
the functions: snd_ice1712_akm4xxx_build_controls snd_ice1712_build_pro_mixer snd_ctl_add snd_ak4114_build prodigy192_ak4114_init snd_ak4113_build are all returning either 0 or a negetive error value. so we can easily remove the check for a negative value and return the value instead. Signed-off-by: -
Joe Perches authored
Use the inline function instead of directly indexing the array. This allows some architectures with hardware instructions for bit reversals to eliminate the array. Signed-off-by:
Joe Perches <joe@perches.com> Signed-off-by:
-
- 13 Nov, 2014 4 commits
-
-
Chris J Arges authored
This code contains the Scarlett mixer interface code that was originally written by Tobias Hoffman and Robin Gareus. Because the device doesn't properly implement UAC2 this code adds a mixer quirk for the device. Changes from the original code include removing the metering code along with dead code and comments. Compiler warnings were fixed. The code to initialize the sampling rate was causing a crash this was fixed as discussed on the mailing list. Error, and info messages were convered to dev_err and dev_info interfaces. The custom scarlett_mixer_elem_info struct was replaced with the more generic usb_mixer_elem_info to be able to recycle more code from mixer.c. This patch also makes additional modifications based on upstream comments. Individual control creation functions are removed and a generic function is no used. Macros for function calls are removed to improve readability. Hardcoded control initialization is removed. Save to HW functionality has been removed. Strings for enums are created dynamically for the mixer. Strings used for controls are now SNDRV_CTL_ELEM_ID_NAME_MAXLEN length. Signed-off-by:
Chris J Arges <chris.j.arges@canonical.com> Signed-off-by:
-
Chris J Arges authored
Make the functions set_cur_mix_value and get_cur_mix_value accessible by files that include mixer.h. In addition make usb_mixer_elem_free accessible. This allows reuse of these functions by mixers that may require quirks. The following summarizes the renamed functions: - set_cur_mix_value -> snd_usb_set_cur_mix_value - get_cur_mix_value -> snd_usb_get_cur_mix_value - usb_mixer_elem_free -> snd_usb_mixer_elem_free Signed-off-by:
-
Chris J Arges authored
Add a private_data pointer to usb_mixer_elem_info to allow other mixer implementations to extend the structure as necessary. Signed-off-by:
-
Chris J Arges authored
This reverts commit 1762a59d. This quirk is not needed because support for the Scarlett mixers will be added. Signed-off-by:
-
- 11 Nov, 2014 6 commits
-
-
Damien Zammit authored
This patch provides duplex support for the Digidesign Mbox 1 sound card and has been a work in progress for about a year. Users have confirmed on my website that previous versions of this patch have worked on the hardware and I have been testing extensively. It also enables the mixer control for providing clock source selector based on the previous patch. The sample rate has been hardcoded to 48kHz because it works better with the S/PDIF sync mode when the sample rate is locked. This is the highest rate that the device supports and no loss of functionality is observed by restricting the sample rate apart from the inability to selec a lower rate. Signed-off-by:
Damien Zammit <damien@zamaudio.com> Signed-off-by:
-
Damien Zammit authored
This patch provides the infrastructure for the Digidesign Mbox 1 to have a mixer control for selecting the clock source. Valid options are Internal and S/PDIF external sync. A non-documented command is sent to the device to enable this feature found by reverse engineering and bus snooping. Signed-off-by:
-
Takashi Iwai authored
They are no real kerneldoc comments, so drop such markers. Signed-off-by: -
Takashi Iwai authored
Signed-off-by: -
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:
-
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:
-
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 6 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:
-
