Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 05 3月, 2020 3 次提交
  3. 19 2月, 2020 1 次提交
  5. 18 2月, 2020 2 次提交
  7. 17 2月, 2020 1 次提交
  9. 12 2月, 2020 2 次提交
  11. 06 2月, 2020 2 次提交
  13. 05 2月, 2020 1 次提交
  15. 02 2月, 2020 2 次提交
  17. 01 2月, 2020 1 次提交
  19. 26 1月, 2020 1 次提交
  21. 23 1月, 2020 2 次提交
  23. 21 1月, 2020 1 次提交
  25. 20 1月, 2020 1 次提交
    • T
      ALSA: hda: Apply aligned MMIO access only conditionally · 4d024fe8
      由 Takashi Iwai 提交于 
      It turned out that the recent simplification of HD-audio bus access
helpers caused a regression on the virtual HD-audio device on QEMU
with ARM platforms.  The driver got a CORB/RIRB timeout and couldn't
probe any codecs.

The essential difference that caused a problem was the enforced
aligned MMIO accesses by simplification.  Since snd-hda-tegra driver
is enabled on ARM, it enables CONFIG_SND_HDA_ALIGNED_MMIO, which makes
the all HD-audio drivers using the aligned MMIO accesses.  While this
is mandatory for snd-hda-tegra, it seems that snd-hda-intel on ARM
gets broken by this access pattern.

For addressing the regression, this patch introduces a new flag,
aligned_mmio, to hdac_bus object, and applies the aligned MMIO only
when this flag is set.  This change affects only platforms with
CONFIG_SND_HDA_ALIGNED_MMIO set, i.e. mostly only for ARM platforms.

Unfortunately the patch became a big bigger than it should be, just
because the former calls didn't take hdac_bus object in the argument,
hence we had to extend the call patterns.

Fixes: 19abfefd ("ALSA: hda: Direct MMIO accesses")
BugLink: https://bugzilla.opensuse.org/show_bug.cgi?id=1161152
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20200120104127.28985-1-tiwai@suse.deSigned-off-by: NTakashi Iwai <tiwai@suse.de>
      4d024fe8
  27. 17 1月, 2020 2 次提交
  29. 14 1月, 2020 2 次提交
  31. 13 1月, 2020 1 次提交
    • T
      ALSA: hda: Manage concurrent reg access more properly · 1a462be5
      由 Takashi Iwai 提交于 
      In the commit 8e85def5 ("ALSA: hda: enable regmap internal
locking"), we re-enabled the regmap lock due to the reported
regression that showed the possible concurrent accesses.  It was a
temporary workaround, and there are still a few opened races even
after the revert.  In this patch, we cover those still opened windows
with a proper mutex lock and disable the regmap internal lock again.

First off, the patch introduces a new snd_hdac_device.regmap_lock
mutex that is applied for each snd_hdac_regmap_*() call, including
read, write and update helpers.  The mutex is applied carefully so
that it won't block the self-power-up procedure in the helper
function.  Also, this assures the protection for the accesses without
regmap, too.

The snd_hdac_regmap_update_raw() is refactored to use the standard
regmap_update_bits_check() function instead of the open-code.  The
non-regmap case is still open-coded but it's an easy part.  The all
read and write operations are in the single mutex protection, so it's
now race-free.

In addition, a couple of new helper functions are added:
snd_hdac_regmap_update_raw_once() and snd_hdac_regmap_sync().  Both
are called from HD-audio legacy driver.  The former is to initialize
the given verb bits but only once when it's not initialized yet.  Due
to this condition, the function invokes regcache_cache_only(), and
it's now performed inside the regmap_lock (formerly it was racy) too.
The latter function is for simply invoking regcache_sync() inside the
regmap_lock, which is called from the codec resume call path.
Along with that, the HD-audio codec driver code is slightly modified /
simplified to adapt those new functions.

And finally, snd_hdac_regmap_read_raw(), *_write_raw(), etc are
rewritten with the helper macro.  It's just for simplification because
the code logic is identical among all those functions.
Tested-by: NKai Vehmanen <kai.vehmanen@linux.intel.com>
Link: https://lore.kernel.org/r/20200109090104.26073-1-tiwai@suse.deSigned-off-by: NTakashi Iwai <tiwai@suse.de>
      1a462be5
  33. 12 1月, 2020 1 次提交
  35. 11 1月, 2020 1 次提交
    • T
      ALSA: hda: Rename back to dmic_detect option · 7fba6aea
      由 Takashi Iwai 提交于 
      We've got quite a few bug reports showing the SOF driver being loaded
unintentionally recently, and the reason seems to be that users didn't
know the module option change: with the recent kernel, a new option
dsp_driver=1 has to be passed to a new module snd-intel-dspcfg
instead of snd_hda_intel.dmic_detect=0 option.

That is, actually there are two tricky things here:
- We changed the whole detection in another module and another
  option semantics.
- The existing option for skipping the DSP probe was also renamed.

For avoiding the confusion and giving user more hint, this patch
reverts the renamed option dsp_driver back to dmic_detect for
snd-hda-intel module, and show the warning about the module option
change when the non-default value is passed.

Fixes: 82d9d54a ("ALSA: hda: add Intel DSP configuration / probe code")
Link: https://lore.kernel.org/r/20200109082000.26729-1-tiwai@suse.deSigned-off-by: NTakashi Iwai <tiwai@suse.de>
      7fba6aea
  37. 08 1月, 2020 3 次提交
  39. 06 1月, 2020 1 次提交
  41. 05 1月, 2020 9 次提交