forked from luck/tmp_suning_uos_patched
88452da92b
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 <tiwai@suse.de> |
||
|---|---|---|
| .. | ||
| ext | ||
| array.c | ||
| hda_bus_type.c | ||
| hdac_bus.c | ||
| hdac_component.c | ||
| hdac_controller.c | ||
| hdac_device.c | ||
| hdac_i915.c | ||
| hdac_regmap.c | ||
| hdac_stream.c | ||
| hdac_sysfs.c | ||
| hdmi_chmap.c | ||
| intel-dsp-config.c | ||
| intel-nhlt.c | ||
| Kconfig | ||
| local.h | ||
| Makefile | ||
| trace.c | ||
| trace.h | ||