Skip to content
  1. Jul 28, 2020
    • Takashi Iwai's avatar
      ALSA: hda/hdmi: Fix keep_power assignment for non-component devices · c2c3657f
      Takashi Iwai authored
      It's been reported that, when neither nouveau nor Nvidia graphics
      driver is used, the screen starts flickering.  And, after comparing
      between the working case (stable 4.4.x) and the broken case, it turned
      out that the problem comes from the audio component binding.  The
      Nvidia and AMD audio binding code clears the bus->keep_power flag
      whenever snd_hdac_acomp_init() succeeds.  But this doesn't mean that
      the component is actually bound, but it merely indicates that it's
      ready for binding.  So, when both nouveau and Nvidia are blacklisted
      or not ready, the driver keeps running without the audio component but
      also with bus->keep_power = false.  This made the driver runtime PM
      kicked in and powering down when unused, which results in flickering
      in the graphics side, as it seems.
      
      For fixing the bug, this patch moves the bus->keep_power flag change
      into generic_acomp_notifier_set() that is the function called from the
      master_bind callback of component ops; i.e. it's guaranteed that the
      binding succeeded.
      
      BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=208609
      Fixes: 5a858e79 ("ALSA: hda - Disable audio component for legacy Nvidia HDMI codecs")
      Cc: <stable@vger.kernel.org>
      Link: https://lore.kernel.org/r/20200728082033.23933-1-tiwai@suse.de
      
      
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      c2c3657f
    • Takashi Iwai's avatar
      ALSA: hda: Workaround for spurious wakeups on some Intel platforms · a6630529
      Takashi Iwai authored
      We've received a regression report on Intel HD-audio controller that
      wakes up immediately after S3 suspend.  The bisection leads to the
      commit c4c8dd6e ("ALSA: hda: Skip controller resume if not
      needed").  This commit replaces the system-suspend to use
      pm_runtime_force_suspend() instead of the direct call of
      __azx_runtime_suspend().  However, by some really mysterious reason,
      pm_runtime_force_suspend() causes a spurious wakeup (although it calls
      the same __azx_runtime_suspend() internally).
      
      As an ugly workaround for now, revert the behavior to call
      __azx_runtime_suspend() and __azx_runtime_resume() for those old Intel
      platforms that may exhibit such a problem, while keeping the new
      standard pm_runtime_force_suspend() and pm_runtime_force_resume()
      pair for the remaining chips.
      
      Fixes: c4c8dd6e ("ALSA: hda: Skip controller resume if not needed")
      BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=208649
      Cc: <stable@vger.kernel.org>
      Link: https://lore.kernel.org/r/20200727164443.4233-1-tiwai@suse.de
      
      
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      a6630529
  2. Jul 27, 2020
  3. Jul 25, 2020
  4. Jul 22, 2020
  5. Jul 18, 2020
  6. Jul 17, 2020
  7. Jul 16, 2020
  8. Jul 14, 2020
  9. Jul 13, 2020
  10. Jul 11, 2020
  11. Jul 10, 2020
  12. Jul 08, 2020
  13. Jul 07, 2020