Skip to content

L
linux
Switch branch/tag
  1. 23 Dec, 2019 1 commit
    • Takashi Iwai's avatar
      ALSA: hda - Apply sync-write workaround to old Intel platforms, too · c366b3db
      Takashi Iwai authored 
      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: default avatarKlaus 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: default avatarTakashi Iwai <tiwai@suse.de>
      c366b3db
  3. 21 Dec, 2019 1 commit
  5. 20 Dec, 2019 1 commit
  7. 19 Dec, 2019 1 commit
  9. 18 Dec, 2019 1 commit
    • Hui Wang's avatar
      ALSA: usb-audio: set the interface format after resume on Dell WD19 · 92adc96f
      Hui Wang authored 
      Recently we found the headset-mic on the Dell Dock WD19 doesn't work
anymore after s3 (s2i or deep), this problem could be workarounded by
closing (pcm_close) the app and then reopening (pcm_open) the app, so
this bug is not easy to be detected by users.

When problem happens, retire_capture_urb() could still be called
periodically, but the size of captured data is always 0, it could be
a firmware bug on the dock. Anyway I found after resuming, the
snd_usb_pcm_prepare() will be called, and if we forcibly run
set_format() to set the interface and its endpoint, the capture
size will be normal again. This problem and workaound also apply to
playback.

To fix it in the kernel, add a quirk to let set_format() run
forcibly once after resume.
Signed-off-by: default avatarHui Wang <hui.wang@canonical.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20191218132650.6303-1-hui.wang@canonical.comSigned-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      92adc96f
  11. 17 Dec, 2019 1 commit
  13. 16 Dec, 2019 2 commits
  15. 14 Dec, 2019 5 commits
  17. 11 Dec, 2019 1 commit
  19. 10 Dec, 2019 8 commits
  21. 09 Dec, 2019 4 commits
  23. 08 Dec, 2019 1 commit
    • Olof Johansson's avatar
      ALSA: echoaudio: simplify get_audio_levels · c08f0a92
      Olof Johansson authored 
      The loop optimizer seems to go astray here, and produces some warnings
that don't seem valid.

Still, the code can be simplified -- just clear the whole array at the
beginning, and fill in whatever values are valid on the platform.

Warnings before this change (GCC 8.2.0 ARM allmodconfig):

In file included from ../sound/pci/echoaudio/gina24.c:115:
../sound/pci/echoaudio/echoaudio.c: In function 'snd_echo_vumeters_get':
../sound/pci/echoaudio/echoaudio_dsp.c:647:9: warning: iteration 1073741824 invokes undefined behavior [-Waggressive-loop-optimizations]
In file included from ../sound/pci/echoaudio/layla24.c:112:
../sound/pci/echoaudio/echoaudio.c: In function 'snd_echo_vumeters_get':
../sound/pci/echoaudio/echoaudio_dsp.c:658:9: warning: iteration 1073741824 invokes undefined behavior [-Waggressive-loop-optimizations]
../sound/pci/echoaudio/echoaudio_dsp.c:647:9: warning: iteration 1073741824 invokes undefined behavior [-Waggressive-loop-optimizations]
Signed-off-by: default avatarOlof Johansson <olof@lixom.net>
Link: https://lore.kernel.org/r/20191207224953.25944-1-olof@lixom.netSigned-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      c08f0a92
  25. 04 Dec, 2019 3 commits
  27. 03 Dec, 2019 3 commits
  29. 29 Nov, 2019 3 commits
  31. 28 Nov, 2019 2 commits
  33. 27 Nov, 2019 2 commits
    • Kai Vehmanen's avatar
      ALSA: hda: hdmi - fix regression in connect list handling · ae254888
      Kai Vehmanen authored 
      Fix regression in how intel_haswell_fixup_connect_list()
results are used in hda_read_pin_conn(). Use of
snd_hda_get_raw_connections() in hda_read_pin_conn() bypasses
the cache and thus also bypasses the overridden pin connection
list. On platforms that require the connection list fixup,
mux list will be empty and HDMI playback will fail to -EBUSY
at open.

Fix the regression in hda_read_pinn_conn(). Simplify code
as suggested by Takashi Iwai to remove old
intel_haswell_fixup_connect_list() and copy the cvt_nid list
directly and not use snd_hda_override_conn_list() at all.

Fixes: 9c32fea8 ("ALSA: hda - Add DP-MST support for non-acomp codecs")
BugLink: https://github.com/thesofproject/linux/issues/1537
Cc: Nikhil Mahale <nmahale@nvidia.com>
Signed-off-by: default avatarKai Vehmanen <kai.vehmanen@linux.intel.com>
Link: https://lore.kernel.org/r/20191127161240.17026-1-kai.vehmanen@linux.intel.comSigned-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      ae254888
    • Tzung-Bi Shih's avatar
      ASoC: max98090: fix possible race conditions · 45dfbf56
      Tzung-Bi Shih authored 
      max98090_interrupt() and max98090_pll_work() run in 2 different threads.
There are 2 possible races:

Note: M98090_REG_DEVICE_STATUS = 0x01.
Note: ULK == 0, PLL is locked; ULK == 1, PLL is unlocked.

max98090_interrupt      max98090_pll_work
----------------------------------------------
schedule max98090_pll_work
                        restart max98090 codec
receive ULK INT
                        assert ULK == 0
schedule max98090_pll_work (1).

In the case (1), the PLL is locked but max98090_interrupt unnecessarily
schedules another max98090_pll_work.

max98090_interrupt      max98090_pll_work      max98090 codec
----------------------------------------------------------------------
                                               ULK = 1
receive ULK INT
read 0x01
                                               ULK = 0 (clear on read)
schedule max98090_pll_work
                        restart max98090 codec
                                               ULK = 1
receive ULK INT
read 0x01
                                               ULK = 0 (clear on read)
                        read 0x01
                        assert ULK == 0 (2).

In the case (2), both max98090_interrupt and max98090_pll_work read
the same clear-on-read register.  max98090_pll_work would falsely
thought PLL is locked.
Note: the case (2) race is introduced by the previous commit ("ASoC:
max98090: exit workaround earlier if PLL is locked") to check the status
and exit the loop earlier in max98090_pll_work.

There are 2 possible solution options:
A. turn off ULK interrupt before scheduling max98090_pll_work; and turn
on again before exiting max98090_pll_work.
B. remove the second thread of execution.

Option A cannot fix the case (2) race because it still has 2 threads
access the same clear-on-read register simultaneously.  Although we
could suppose the register is volatile and read the status via I2C could
be much slower than the hardware raises the bits.

Option B introduces a maximum 10~12 msec penalty delay in the interrupt
handler.  However, it could only punish the jack detection by extra
10~12 msec.

Adopts option B which is the better solution overall.
Signed-off-by: default avatarTzung-Bi Shih <tzungbi@google.com>
Link: https://lore.kernel.org/r/20191122073114.219945-4-tzungbi@google.comReviewed-by: default avatarPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      45dfbf56
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7