Skip to content

L
linux
Switch branch/tag
  1. 20 Mar, 2016 2 commits
    • Victor Clément's avatar
      ALSA: usb-audio: add Microsoft HD-5001 to quirks · 0ef21100
      Victor Clément authored 
      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: default avatarVictor Clément <victor.clement@openmailbox.org>
Cc: <stable@vger.kernel.org>
Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      0ef21100
    • Takashi Iwai's avatar
      ALSA: hda - Workaround for unbalanced i915 power refcount by concurrent probe · 7169701a
      Takashi Iwai authored 
      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: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
Cc: <stable@vger.kernel.org> # v4.5
Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      7169701a
  3. 18 Mar, 2016 3 commits
    • Takashi Iwai's avatar
      ALSA: hda - Fix spurious kernel WARNING on Baytrail HDMI · 93a9ff15
      Takashi Iwai authored 
      snd_hdac_sync_audio_rate() call is mandatory only for HSW and later
models, but we call the function unconditionally blindly assuming that
the function doesn't do anything harmful.  But since recently, the
function checks the validity of the passed pin NID, and eventually
spews the warning if an unexpected pin is passed.  This is seen on old
chips like Baytrail.

The fix is to limit the call of this function again only for the chips
with the proper binding.  This can be identified by the same flag as
the eld notifier.
Reported-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
Tested-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
Cc: <stable@vger.kernel.org> # v4.5
Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      93a9ff15
    • Takashi Iwai's avatar
      ALSA: hda - Fix forgotten HDMI monitor_present update · bd481285
      Takashi Iwai authored 
      We forgot to copy monitor_present value when updating the ELD
information.  This won't change the ELD retrieval and the jack
notification behavior, but appears only in the proc output.   In that
sense, it's no fatal error, but a bug is a bug is a bug.

Cc: <stable@vger.kernel.org>
Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      bd481285
    • Takashi Iwai's avatar
      ALSA: hda - Really restrict i915 notifier to HSW+ · 691be973
      Takashi Iwai authored 
      The commit [b62232d4: ALSA: hda - Limit i915 HDMI binding only for
HSW and later] tried to limit the usage of i915 audio notifier to the
recent Intel models and switch to the old method on pre-Haswell
models.  However, it assumed that the i915 component binding hasn't
been done on such models, and the assumption was wrong: namely,
Baytrail had already the i915 component binding due to powerwell
control.  Thus, the workaround wasn't applied to Baytrail.

For fixing this properly, this patch introduces a new flag indicating
the usage of audio notifier and codec_has_acomp() refers to this flag
instead of checking the existence of audio component.
Reported-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
Cc: <stable@vger.kernel.org> # v4.5
Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      691be973
  5. 17 Mar, 2016 2 commits
    • Takashi Iwai's avatar
      ALSA: hda - Fix mutex deadlock at HDMI/DP hotplug · 222bde03
      Takashi Iwai authored 
      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: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
Tested-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      222bde03
    • Takashi Sakamoto's avatar
      ALSA: ctl: change return value in compatibility layer so that it's the same... · 6f021744
      Takashi Sakamoto authored 
      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: default avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      6f021744
  7. 16 Mar, 2016 4 commits
  9. 15 Mar, 2016 3 commits
  11. 14 Mar, 2016 5 commits
  13. 13 Mar, 2016 18 commits
  15. 12 Mar, 2016 3 commits
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7