1. 01 4月, 2016 3 次提交
    • T
      ALSA: timer: Use mod_timer() for rearming the system timer · 4a07083e
      Takashi Iwai 提交于
      ALSA system timer backend stops the timer via del_timer() without sync
      and leaves del_timer_sync() at the close instead.  This is because of
      the restriction by the design of ALSA timer: namely, the stop callback
      may be called from the timer handler, and calling the sync shall lead
      to a hangup.  However, this also triggers a kernel BUG() when the
      timer is rearmed immediately after stopping without sync:
       kernel BUG at kernel/time/timer.c:966!
       Call Trace:
        <IRQ>
        [<ffffffff8239c94e>] snd_timer_s_start+0x13e/0x1a0
        [<ffffffff8239e1f4>] snd_timer_interrupt+0x504/0xec0
        [<ffffffff8122fca0>] ? debug_check_no_locks_freed+0x290/0x290
        [<ffffffff8239ec64>] snd_timer_s_function+0xb4/0x120
        [<ffffffff81296b72>] call_timer_fn+0x162/0x520
        [<ffffffff81296add>] ? call_timer_fn+0xcd/0x520
        [<ffffffff8239ebb0>] ? snd_timer_interrupt+0xec0/0xec0
        ....
      
      It's the place where add_timer() checks the pending timer.  It's clear
      that this may happen after the immediate restart without sync in our
      cases.
      
      So, the workaround here is just to use mod_timer() instead of
      add_timer().  This looks like a band-aid fix, but it's a right move,
      as snd_timer_interrupt() takes care of the continuous rearm of timer.
      Reported-by: NJiri Slaby <jslaby@suse.cz>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      4a07083e
    • H
      ALSA: hda - fix front mic problem for a HP desktop · e549d190
      Hui Wang 提交于
      The front mic jack (pink color) can't detect any plug or unplug. After
      applying this fix, both detecting function and recording function
      work well.
      
      BugLink: https://bugs.launchpad.net/bugs/1564712
      Cc: stable@vger.kernel.org
      Signed-off-by: NHui Wang <hui.wang@canonical.com>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      e549d190
    • V
      ALSA: usb-audio: Fix double-free in error paths after snd_usb_add_audio_stream() call · 836b34a9
      Vladis Dronov 提交于
      create_fixed_stream_quirk(), snd_usb_parse_audio_interface() and
      create_uaxx_quirk() functions allocate the audioformat object by themselves
      and free it upon error before returning. However, once the object is linked
      to a stream, it's freed again in snd_usb_audio_pcm_free(), thus it'll be
      double-freed, eventually resulting in a memory corruption.
      
      This patch fixes these failures in the error paths by unlinking the audioformat
      object before freeing it.
      
      Based on a patch by Takashi Iwai <tiwai@suse.de>
      
      [Note for stable backports:
       this patch requires the commit 902eb7fd ('ALSA: usb-audio: Minor
       code cleanup in create_fixed_stream_quirk()')]
      
      Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1283358Reported-by: NRalf Spenneberg <ralf@spenneberg.net>
      Cc: <stable@vger.kernel.org> # see the note above
      Signed-off-by: NVladis Dronov <vdronov@redhat.com>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      836b34a9
  2. 31 3月, 2016 1 次提交
  3. 28 3月, 2016 1 次提交
  4. 23 3月, 2016 4 次提交
  5. 21 3月, 2016 1 次提交
  6. 20 3月, 2016 2 次提交
    • V
      ALSA: usb-audio: add Microsoft HD-5001 to quirks · 0ef21100
      Victor Clément 提交于
      The Microsoft HD-5001 webcam microphone does not support sample rate
      reading as the HD-5000 one.
      This results in dmesg errors and sound hanging with pulseaudio.
      Signed-off-by: NVictor Clément <victor.clement@openmailbox.org>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      0ef21100
    • T
      ALSA: hda - Workaround for unbalanced i915 power refcount by concurrent probe · 7169701a
      Takashi Iwai 提交于
      The recent addition of on-demand i915 audio component binding in the
      codec driver seems leading to the unbalanced i915 power refcount,
      according to Intel CI tests.  Typically, it gets a kernel WARNING
      like:
        WARNING: CPU: 3 PID: 173 at sound/hda/hdac_i915.c:91 snd_hdac_display_power+0xf1/0x110 [snd_hda_core]()
        Call Trace:
         [<ffffffff813fef15>] dump_stack+0x67/0x92
         [<ffffffff81078a21>] warn_slowpath_common+0x81/0xc0
         [<ffffffff81078b15>] warn_slowpath_null+0x15/0x20
         [<ffffffffa00f77e1>] snd_hdac_display_power+0xf1/0x110 [snd_hda_core]
         [<ffffffffa015039d>] azx_intel_link_power+0xd/0x10 [snd_hda_intel]
         [<ffffffffa011e32a>] azx_link_power+0x1a/0x30 [snd_hda_codec]
         [<ffffffffa00f21f9>] snd_hdac_link_power+0x29/0x40 [snd_hda_core]
         [<ffffffffa01192a6>] hda_codec_runtime_suspend+0x76/0xa0 [snd_hda_codec]
         .....
      
      The scenario is like below:
      - HD-audio driver and i915 driver are probed concurrently at the
        (almost) same time; HDA bus tries to bind with i915, but it fails
        because i915 initialization is still being processed.
      - Later on, HD-audio probes the HDMI codec, where it again tries to
        bind with i915.  At this time, it succeeds.
      - At finishing the probe of HDA, it decreases the refcount as if it
        were already bound at the bus probe, since the component is bound
        now.  This triggers a kernel WARNING due to the unbalance.
      
      As a workaround, in this patch, we just disable the on-demand i915
      component binding in the codec driver.  This essentially reverts back
      to the state of 4.4 kernel.
      
      We know that this is no real solution, but it's a minimalistic simple
      change that can be applied to 4.5.x kernel as stable.
      
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94566Reported-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Cc: <stable@vger.kernel.org> # v4.5
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      7169701a
  7. 19 3月, 2016 2 次提交
  8. 18 3月, 2016 2 次提交
  9. 17 3月, 2016 2 次提交
    • T
      ALSA: hda - Fix mutex deadlock at HDMI/DP hotplug · 222bde03
      Takashi Iwai 提交于
      The recent change in HD-audio HDMI/DP codec driver for allowing the
      dynamic PCM binding introduced a new spec->pcm_mutex.  One of the
      protected area by this mutex is hdmi_present_sense().  As reported by
      Intel CI tests, unfortunately, the new mutex causes a deadlock when
      the hotplug/unplug is triggered during the codec is in runtime
      suspend.  The buggy code path is like the following:
      
        hdmi_unsol_event() -> ...
          -> hdmi_present_sense()
      ==>     ** here taking pcm_mutex
            -> hdmi_present_sense_via_verbs()
              -> snd_hda_power_up_pm() -> ... (runtime resume calls)
                -> generic_hdmi_resume()
                  -> hdmi_present_sense()
      ==>           ** here taking pcm_mutex again!
      
      As we can see here, the problem is that the mutex is taken before
      snd_hda_power_up_pm() call that triggers the runtime resume.  That is,
      the obvious solution is to move the power up/down call outside the
      mutex; it is exactly what this patch provides.
      
      The patch also clarifies why this bug wasn't caught beforehand.  We
      used to have the i915 audio component for hotplug for all Intel chips,
      and in that code path, there is no power up required but the
      information is taken directly from the graphics side.  However, we
      recently switched back to the old method for some old Intel chips due
      to regressions, and now the deadlock issue is surfaced.
      
      Fixes: a76056f2 ('ALSA: hda - hdmi dynamically bind PCM to pin when monitor hotplug')
      Reported-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Tested-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      222bde03
    • T
      ALSA: ctl: change return value in compatibility layer so that it's the same... · 6f021744
      Takashi Sakamoto 提交于
      ALSA: ctl: change return value in compatibility layer so that it's the same value in core implementation
      
      In control compatibility layer, when no elements are found by
      ELEM_READ/ELEM_WRITE ioctl commands, ENXIO is returned. On the other hand,
      in core implementation, ENOENT is returned. This is not good for
      ALSA ctl applications.
      
      This commit changes the return value from the compatibility layer so
      that the same value is returned.
      Signed-off-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      6f021744
  10. 16 3月, 2016 5 次提交
  11. 15 3月, 2016 2 次提交
  12. 14 3月, 2016 3 次提交
  13. 12 3月, 2016 12 次提交