1. 18 Mar, 2016 1 commit
    • 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
  2. 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
  3. 16 Mar, 2016 4 commits
  4. 15 Mar, 2016 3 commits
  5. 14 Mar, 2016 5 commits
  6. 13 Mar, 2016 18 commits
  7. 12 Mar, 2016 7 commits