1. 23 11月, 2014 4 次提交
  2. 22 11月, 2014 3 次提交
  3. 21 11月, 2014 1 次提交
  4. 20 11月, 2014 1 次提交
  5. 19 11月, 2014 1 次提交
  6. 17 11月, 2014 5 次提交
  7. 14 11月, 2014 4 次提交
  8. 13 11月, 2014 4 次提交
  9. 11 11月, 2014 6 次提交
  10. 10 11月, 2014 4 次提交
  11. 07 11月, 2014 1 次提交
  12. 06 11月, 2014 2 次提交
    • T
      ALSA: usb-audio: Trigger PCM XRUN at XRUN · 67e22500
      Takashi Iwai 提交于
      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: NTakashi Iwai <tiwai@suse.de>
      67e22500
    • T
      ALSA: pcm: Update the state properly before notification · 9bc889b4
      Takashi Iwai 提交于
      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: NTakashi Iwai <tiwai@suse.de>
      9bc889b4
  13. 05 11月, 2014 3 次提交
    • T
      ALSA: usb-audio: Fix device_del() sysfs warnings at disconnect · 0725dda2
      Takashi Iwai 提交于
      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: NTomas Gayoso <tgayoso@gmail.com>
      Reported-and-tested-by: NChris J Arges <chris.j.arges@canonical.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      0725dda2
    • S
      ALSA: echoaudio: cleanup of unnecessary messages · 9161bd0d
      Sudip Mukherjee 提交于
      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: NDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: NSudip Mukherjee <sudip@vectorindia.org>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      9161bd0d
    • H
      ALSA: hda - fix mute led problem for three HP laptops · c922c4e8
      Hui Wang 提交于
      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: NTieFu Chen <tienfu.chen@canonical.com>
      Cc: Kailang Yang <kailang@realtek.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: NHui Wang <hui.wang@canonical.com>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      c922c4e8
  14. 04 11月, 2014 1 次提交