1. 05 10月, 2019 1 次提交
    • C
      ALSA: hda: Flush interrupts on disabling · 3eec108a
      Chris Wilson 提交于
      [ Upstream commit caa8422d01e983782548648e125fd617cadcec3f ]
      
      I was looking at
      
      <4> [241.835158] general protection fault: 0000 [#1] PREEMPT SMP PTI
      <4> [241.835181] CPU: 1 PID: 214 Comm: kworker/1:3 Tainted: G     U            5.2.0-CI-CI_DRM_6509+ #1
      <4> [241.835199] Hardware name: Dell Inc.                 OptiPlex 745                 /0GW726, BIOS 2.3.1  05/21/2007
      <4> [241.835234] Workqueue: events snd_hdac_bus_process_unsol_events [snd_hda_core]
      <4> [241.835256] RIP: 0010:input_handle_event+0x16d/0x5e0
      <4> [241.835270] Code: 48 8b 93 58 01 00 00 8b 52 08 89 50 04 8b 83 f8 06 00 00 48 8b 93 00 07 00 00 8d 70 01 48 8d 04 c2 83 e1 08 89 b3 f8 06 00 00 <66> 89 28 66 44 89 60 02 44 89 68 04 8b 93 f8 06 00 00 0f 84 fd fe
      <4> [241.835304] RSP: 0018:ffffc9000019fda0 EFLAGS: 00010046
      <4> [241.835317] RAX: 6b6b6b6ec6c6c6c3 RBX: ffff8880290fefc8 RCX: 0000000000000000
      <4> [241.835332] RDX: 000000006b6b6b6b RSI: 000000006b6b6b6c RDI: 0000000000000046
      <4> [241.835347] RBP: 0000000000000005 R08: 0000000000000000 R09: 0000000000000001
      <4> [241.835362] R10: ffffc9000019faa0 R11: 0000000000000000 R12: 0000000000000004
      <4> [241.835377] R13: 0000000000000000 R14: ffff8880290ff1d0 R15: 0000000000000293
      <4> [241.835392] FS:  0000000000000000(0000) GS:ffff88803de80000(0000) knlGS:0000000000000000
      <4> [241.835409] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      <4> [241.835422] CR2: 00007ffe9a99e9b7 CR3: 000000002f588000 CR4: 00000000000006e0
      <4> [241.835436] Call Trace:
      <4> [241.835449]  input_event+0x45/0x70
      <4> [241.835464]  snd_jack_report+0xdc/0x100
      <4> [241.835490]  snd_hda_jack_report_sync+0x83/0xc0 [snd_hda_codec]
      <4> [241.835512]  snd_hdac_bus_process_unsol_events+0x5a/0x70 [snd_hda_core]
      <4> [241.835530]  process_one_work+0x245/0x610
      
      which has the hallmarks of a worker queued from interrupt after it was
      supposedly cancelled (note the POISON_FREE), and I could not see where
      the interrupt would be flushed on shutdown so added the likely suspects.
      
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111174Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      3eec108a
  2. 01 10月, 2019 2 次提交
  3. 16 9月, 2019 7 次提交
  4. 06 9月, 2019 1 次提交
  5. 25 8月, 2019 5 次提交
  6. 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
  7. 31 7月, 2019 1 次提交
  8. 26 7月, 2019 2 次提交
  9. 14 7月, 2019 1 次提交
  10. 10 7月, 2019 3 次提交
  11. 22 6月, 2019 1 次提交
  12. 19 6月, 2019 2 次提交
  13. 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
  14. 09 6月, 2019 2 次提交
  15. 22 5月, 2019 7 次提交
  16. 08 5月, 2019 2 次提交