kernel/git/stable/linux.git/include/sound/hdaudio.h, branch linux-5.7.y

ASoC: SOF: Intel: Account for compress streams when servicing IRQs

2020-02-18T21:52:06+00:00

Update stream irq handler definition to correctly set hdac_stream current position when servicing stream interrupts for compress streams. Signed-off-by: Cezary Rojewski Acked-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20200218143924.10565-4-cezary.rojewski@intel.com Signed-off-by: Mark Brown

Merge branch 'for-linus' into for-next

2020-01-20T10:44:51+00:00

Resolved the merge conflict in HD-audio Tegra driver. Signed-off-by: Takashi Iwai

ALSA: hda: Apply aligned MMIO access only conditionally

2020-01-20T10:42:15+00:00

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: 19abfefd4c76 ("ALSA: hda: Direct MMIO accesses") BugLink: https://bugzilla.opensuse.org/show_bug.cgi?id=1161152 Cc: Link: https://lore.kernel.org/r/20200120104127.28985-1-tiwai@suse.de Signed-off-by: Takashi Iwai

ALSA: hda: Manage concurrent reg access more properly

2020-01-13T12:40:41+00:00

In the commit 8e85def5723e ("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: Kai Vehmanen Link: https://lore.kernel.org/r/20200109090104.26073-1-tiwai@suse.de Signed-off-by: Takashi Iwai

ALSA: hda: Unify get_response handling

2019-12-13T13:36:52+00:00

Now most of the get_response handling became quite similar between HDA-core and legacy drivers, and the only differences are: - the handling of extra-long polling delay for some codecs - the debug message for the stalled communication and both are worth to share in the common code. This patch unifies the code into snd_hdac_bus_get_response(), and use this from the legacy get_response callback. It results in a good amount of code reduction in the end. Reviewed-by: Kai Vehmanen Link: https://lore.kernel.org/r/20191212191101.19517-3-tiwai@suse.de Signed-off-by: Takashi Iwai

ALSA: hda: Use standard waitqueue for RIRB wakeup

2019-12-10T17:22:46+00:00

The HD-audio CORB/RIRB communication was programmed in a way that was documented in the reference in decades ago, which is essentially a polling in the waiter side. It's working fine but costs CPU cycles on some platforms that support only slow communications. Also, for some platforms that had unreliable communications, we put longer wait time (2 ms), which accumulate quite long time if you execute many verbs in a shot (e.g. at the initialization or resume phase). This patch attempts to improve the situation by introducing the standard waitqueue in the RIRB waiter side instead of polling. The test results on my machine show significant improvements. The time spent for "cat /proc/asound/card*/codec#*" were changed like: * Intel SKL + Realtek codec before the patch: 0.00user 0.04system 0:00.10elapsed 40.0%CPU after the patch: 0.00user 0.01system 0:00.10elapsed 10.0%CPU * Nvidia GP107GL + Nvidia HDMI codec before the patch: 0.00user 0.00system 0:02.76elapsed 0.0%CPU after the patch: 0.00user 0.00system 0:00.01elapsed 17.0%CPU So, for Intel chips, the total time is same, while the total time is greatly reduced (from 2.76 to 0.01s) for Nvidia chips. The only negative data here is the increase of CPU time for Nvidia, but this is the unavoidable cost for faster wakeups, supposedly. Link: https://lore.kernel.org/r/20191210145727.22054-1-tiwai@suse.de Signed-off-by: Takashi Iwai

ALSA: hda: Modify stream stripe mask only when needed

2019-12-03T06:46:30+00:00

The recent commit in HD-audio stream management for changing the stripe control seems causing a regression on some platforms. The stripe control is currently used only by HDMI codec, and applying the stripe mask unconditionally may lead to scratchy and static noises as seen on some MacBooks. For addressing the regression, this patch changes the stream management code to apply the stripe mask conditionally only when the codec driver requested. Fixes: 9b6f7e7a296e ("ALSA: hda: program stripe bits for controller") BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=204477 Tested-by: Michael Pobega Cc: Link: https://lore.kernel.org/r/20191202074947.1617-1-tiwai@suse.de Signed-off-by: Takashi Iwai

ALSA: hda: Unexport a few more stuff

2019-08-14T18:00:56+00:00

Drop EXPORT_SYMBOL*() from a few more stuff in HD-audio core that aren't used outside. Particular the unsol event handler can be staticized now because the recent change removed all external callers. Signed-off-by: Takashi Iwai

ALSA: hda: Drop export of snd_hdac_bus_add/remove_device()

2019-08-14T17:51:24+00:00

snd_hdac_bus_add_device() and snd_hdac_remove_device() are called only internally in hda-core. Let's drop the exports of them and move the declarations into local.h. Signed-off-by: Takashi Iwai

ALSA: hda: Direct MMIO accesses

2019-08-08T14:36:18+00:00

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: Pierre-Louis Bossart Signed-off-by: Takashi Iwai