Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 05 1月, 2020 1 次提交
  3. 03 1月, 2020 2 次提交
  5. 24 12月, 2019 1 次提交
    • T
      ALSA: hda - Apply sync-write workaround to old Intel platforms, too · c366b3db
      由 Takashi Iwai 提交于 
      Klaus Ethgen reported occasional high CPU usages in his system that
seem caused by HD-audio driver.  The perf output revealed that it's
in the unsolicited event handling in the workqueue, and the problem
seems triggered by some communication stall between the controller and
the codec at the runtime or system resume.

Actually a similar phenomenon was seen in the past for other Intel
platforms, and we already applied the workaround to enforce sync-write
for CORB/RIRB verbs for Skylake and newer chipsets (commit
2756d914 "ALSA: hda - Fix intermittent CORB/RIRB stall on Intel
chips").  Fortunately, the same workaround is applicable to the old
chipset, and the experiment showed the positive effect.

Based on the experiment result, this patch enables the sync-write
workaround for all Intel chipsets.  The only reason I hesitated to
apply this workaround was about the possibly slightly higher CPU usage.
But if the lack of sync causes a much severer problem even for quite
old chip, we should think this would be necessary for all Intel chips.
Reported-by: NKlaus Ethgen <Klaus@ethgen.ch>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20191223171833.GA17053@chua
Link: https://lore.kernel.org/r/20191223221816.32572-1-tiwai@suse.deSigned-off-by: NTakashi Iwai <tiwai@suse.de>
      c366b3db
  7. 21 12月, 2019 1 次提交
  9. 13 12月, 2019 1 次提交
  11. 11 12月, 2019 2 次提交
  13. 26 11月, 2019 3 次提交
  15. 15 11月, 2019 1 次提交
  17. 11 11月, 2019 1 次提交
  19. 28 10月, 2019 2 次提交
  21. 23 10月, 2019 2 次提交
  23. 21 10月, 2019 1 次提交
  25. 20 9月, 2019 1 次提交
  27. 27 8月, 2019 1 次提交
    • T
      ALSA: hda - Allow runtime PM for controller if component notifier is used · dd23e1d5
      由 Takashi Iwai 提交于 
      Currently we disallow the runtime PM of the HD-audio controller if
it's bound with HDMI/DP on Nvidia / AMD unless it's for dGPU.  This is
for keeping the link up to get the proper notification for ELD
hotplug.

As explained in the commit 37a3a98e ("ALSA: hda - Enable runtime
PM only for discrete GPU"), this keep-power-up behavior is rather a
stop-gap solution until the ELD notification via audio component.
And now we finally got the audio component for these graphics drivers
via commit ade49db3 ("ALSA: hda/hdmi - Allow audio component for
AMD/ATI and Nvidia HDMI"), so it's time to change.

This patch makes HD-audio controller again runtime-suspendable when
the device gets bound with audio component in HDMI codec driver.  For
making it easier to access from the codec driver, move the flag into
the common hda_bus object instead of hda_intel flag.  Also rename it
to keep_power, to indicate the actual meaning.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      dd23e1d5
  29. 13 8月, 2019 1 次提交
    • T
      ALSA: hda: Set fifo_size for both playback and capture streams · 7da20788
      由 Takashi Iwai 提交于 
      Currently we set hdac_stream.fifo_size field only for the playback
stream by some odd reason I forgot, while this field isn't referred in
any places.  Actually this fifo_size field would have been required in
the position report correction for VIA chipset, but due to the lack of
the fifo_size set for capture streams, snd-hda-intel driver fetches
the register by itself.

This patch straightens and simplifies the code by setting the
fifo_size field for both playback and capture streams, and use it in
the HD-audio controller driver.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      7da20788
  31. 09 8月, 2019 1 次提交
  33. 08 8月, 2019 2 次提交
    • T
      ALSA: hda: Direct MMIO accesses · 19abfefd
      由 Takashi Iwai 提交于 
      HD-audio drivers access to the mmio registers indirectly via the
corresponding bus->io_ops callbacks.  This is because some platform
(notably Tegra SoC) requires the word-aligned access.  But it's rather
a rare case, and other platforms suffer from the penalties by indirect
calls unnecessarily.

This patch is an attempt to optimize and cleanup for this situation.
Now the special aligned access is used only when a new kconfig
CONFIG_SND_HDA_ALIGNED_MMIO is set.  And the HD-audio core itself
provides the aligned MMIO access helpers instead of the driver side.
If Kconfig isn't set (as default), the standard helpers like readl()
or writel() are used directly.

A couple of places in ASoC Intel drivers have the access via io_ops
reg_writel(), and they are replaced with the direct writel() calls.

And now with this patch, the whole bus->io_ops becomes empty, so it's
dropped completely.  The bus initialization functions are changed
accordingly as well to drop the whole bus->io_ops.
Reviewed-by: NPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      19abfefd
    • T
      ALSA: hda: Remove page allocation redirection · 619a1f19
      由 Takashi Iwai 提交于 
      The HD-audio core allocates and releases pages via driver's specific
dma_alloc_pages and dma_free_pages ops defined in bus->io_ops.  This
was because some platforms require the uncached pages and the handling
of page flags had to be done locally in the driver code.

Since the recent change in ALSA core memory allocator, we can simply
pass SNDRV_DMA_TYPE_DEV_UC for the uncached pages, and the only
difference became about this type to be passed to the core allocator.
That is, it's good time for cleaning up the mess.

This patch changes the allocation code in HD-audio core to call the
core allocator directly so that we get rid of dma_alloc_pages and
dma_free_pages io_ops.  If a driver needs the uncached pages, it has
to set bus->dma_type right after the bus initialization.

This is merely a code refactoring and shouldn't bring any behavior
changes.
Reviewed-by: NPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      619a1f19
  35. 07 8月, 2019 1 次提交
    • T
      ALSA: hda - Workaround for crackled sound on AMD controller (1022:1457) · c02f77d3
      由 Takashi Iwai 提交于 
      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>
      c02f77d3
  37. 02 8月, 2019 1 次提交
  39. 31 7月, 2019 1 次提交
    • P
      ALSA: hda/intel: stop probe if DMICS are detected on Skylake+ platforms · 8c575883
      由 Pierre-Louis Bossart 提交于 
      The legacy HD-Audio driver cannot handle Skylake+ platforms with
digital microphones. For those platforms, the SOF or SST drivers need
to be used.

This patch provides an automatic way of detecting the presence of
DMICs using NHTL information reported by the BIOS. A kernel kconfig
option or a kernel module parameter provide an opt-in means of
stopping the probe. The kernel would then look for an alternate driver
registered for the same PCI ID to probe.

With this capability, distros no longer have to blacklist
snd-hda-intel, but still need to make sure the SOF/SST drivers are
functional by providing the relevant firmware and topology files in
/lib/firmware/intel

The coexistence between SOF and SST drivers and their dynamic
detection is not addressed by this patch, different mechanisms need to
be used, e.g. DMI-based quirks.
Signed-off-by: NPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      8c575883
  41. 25 7月, 2019 1 次提交
    • T
      ALSA: hda - Fix intermittent CORB/RIRB stall on Intel chips · 2756d914
      由 Takashi Iwai 提交于 
      It turned out that the recent Intel HD-audio controller chips show a
significant stall during the system PM resume intermittently.  It
doesn't happen so often and usually it may read back successfully
after one or more seconds, but in some rare worst cases the driver
went into fallback mode.

After trial-and-error, we found out that the communication stall seems
covered by issuing the sync after each verb write, as already done for
AMD and other chipsets.  So this patch enables the write-sync flag for
the recent Intel chips, Skylake and onward, as a workaround.

Also, since Broxton and co have the very same driver flags as Skylake,
refer to the Skylake driver flags instead of defining the same
contents again for simplification.

BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=201901Reported-and-tested-by: NTodd Brandt <todd.e.brandt@linux.intel.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      2756d914
  43. 22 7月, 2019 1 次提交
    • C
      ALSA: hda: Flush interrupts on disabling · caa8422d
      由 Chris Wilson 提交于 
      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>
      caa8422d
  45. 25 6月, 2019 1 次提交
  47. 13 6月, 2019 1 次提交
  49. 31 5月, 2019 1 次提交
  51. 28 5月, 2019 3 次提交
  53. 08 5月, 2019 1 次提交
  55. 30 4月, 2019 1 次提交
    • T
      ALSA: hda - Register irq handler after the chip initialization · f495222e
      由 Takashi Iwai 提交于 
      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>
      f495222e
  57. 08 4月, 2019 1 次提交
  59. 19 3月, 2019 1 次提交
    • H
      ALSA: hda - Don't trigger jackpoll_work in azx_resume · 744c67ff
      由 Hui Wang 提交于 
      The commit 3baffc4a (ALSA: hda/intel: Refactoring PM code) changed
the behaviour of azx_resume(), it triggers the jackpoll_work after
applying this commit.

This change introduced a new issue, all codecs are runtime active
after S3, and will not call runtime_suspend() automatically.

The root cause is the jackpoll_work calls snd_hda_power_up/down_pm,
and it calls up_pm before snd_hdac_enter_pm is called, while calls
the down_pm in the middle of enter_pm and leave_pm is called. This
makes the dev->power.usage_count unbalanced after S3.

To fix it, let azx_resume() don't trigger jackpoll_work as before
it did.

Fixes: 3baffc4a ("ALSA: hda/intel: Refactoring PM code")
Signed-off-by: NHui Wang <hui.wang@canonical.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      744c67ff
  61. 18 3月, 2019 1 次提交