1. 16 9月, 2019 7 次提交
  2. 06 9月, 2019 1 次提交
  3. 25 8月, 2019 5 次提交
  4. 16 8月, 2019 2 次提交
    • T
      ALSA: hda - Workaround for crackled sound on AMD controller (1022:1457) · af9d64f8
      Takashi Iwai 提交于
      commit c02f77d32d2c45cfb1b2bb99eabd8a78f5ecc7db upstream.
      
      A long-time problem on the recent AMD chip (X370, X470, B450, etc with
      PCI ID 1022:1457) with Realtek codecs is the crackled or distorted
      sound for capture streams, as well as occasional playback hiccups.
      After lengthy debugging sessions, the workarounds we've found are like
      the following:
      
      - Set up the proper driver caps for this controller, similar as the
        other AMD controller.
      
      - Correct the DMA position reporting with the fixed FIFO size, which
        is similar like as workaround used for VIA chip set.
      
      - Even after the position correction, PulseAudio still shows
        mysterious stalls of playback streams when a capture is triggered in
        timer-scheduled mode.  Since we have no clear way to eliminate the
        stall, pass the BATCH PCM flag for PA to suppress the tsched mode as
        a temporary workaround.
      
      This patch implements the workarounds.  For the driver caps, it
      defines a new preset, AXZ_DCAPS_PRESET_AMD_SB.  It enables the FIFO-
      corrected position reporting (corresponding to the new position_fix=6)
      and enforces the SNDRV_PCM_INFO_BATCH flag.
      
      Note that the current implementation is merely a workaround.
      Hopefully we'll find a better alternative in future, especially about
      removing the BATCH flag hack again.
      
      BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=195303
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      af9d64f8
    • T
      ALSA: hda - Don't override global PCM hw info flag · 06f0bcac
      Takashi Iwai 提交于
      commit c1c6c877b0c79fd7e05c931435aa42211eaeebaf upstream.
      
      The commit bfcba288 ("ALSA - hda: Add support for link audio time
      reporting") introduced the conditional PCM hw info setup, but it
      overwrites the global azx_pcm_hw object.  This will cause a problem if
      any other HD-audio controller, as it'll inherit the same bit flag
      although another controller doesn't support that feature.
      
      Fix the bug by setting the PCM hw info flag locally.
      
      Fixes: bfcba288 ("ALSA - hda: Add support for link audio time reporting")
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      06f0bcac
  5. 31 7月, 2019 1 次提交
  6. 26 7月, 2019 2 次提交
  7. 14 7月, 2019 1 次提交
  8. 10 7月, 2019 3 次提交
  9. 22 6月, 2019 1 次提交
  10. 19 6月, 2019 2 次提交
  11. 15 6月, 2019 1 次提交
    • T
      ALSA: hda - Register irq handler after the chip initialization · 962ce402
      Takashi Iwai 提交于
      [ Upstream commit f495222e28275222ab6fd93813bd3d462e16d340 ]
      
      Currently the IRQ handler in HD-audio controller driver is registered
      before the chip initialization.  That is, we have some window opened
      between the azx_acquire_irq() call and the CORB/RIRB setup.  If an
      interrupt is triggered in this small window, the IRQ handler may
      access to the uninitialized RIRB buffer, which leads to a NULL
      dereference Oops.
      
      This is usually no big problem since most of Intel chips do register
      the IRQ via MSI, and we've already fixed the order of the IRQ
      enablement and the CORB/RIRB setup in the former commit b61749a8
      ("sound: enable interrupt after dma buffer initialization"), hence the
      IRQ won't be triggered in that room.  However, some platforms use a
      shared IRQ, and this may allow the IRQ trigger by another source.
      
      Another possibility is the kdump environment: a stale interrupt might
      be present in there, the IRQ handler can be falsely triggered as well.
      
      For covering this small race, let's move the azx_acquire_irq() call
      after hda_intel_init_chip() call.  Although this is a bit radical
      change, it can cover more widely than checking the CORB/RIRB setup
      locally in the callee side.
      Reported-by: NLiwei Song <liwei.song@windriver.com>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      962ce402
  12. 09 6月, 2019 2 次提交
  13. 22 5月, 2019 7 次提交
  14. 08 5月, 2019 3 次提交
  15. 02 5月, 2019 1 次提交
  16. 27 4月, 2019 1 次提交