1. 21 Apr, 2023 2 commits
  2. 19 Apr, 2023 2 commits
  3. 18 Apr, 2023 1 commit
  4. 11 Apr, 2023 1 commit
  5. 08 Apr, 2023 1 commit
    • Oswald Buddenhagen's avatar
      ALSA: pcm: fix wait_time calculations · 3ed2b549
      Oswald Buddenhagen authored
      ... in wait_for_avail() and snd_pcm_drain().
      
      t was calculated in seconds, so it would be pretty much always zero, to
      be subsequently de-facto ignored due to being max(t, 10)'d. And then it
      (i.e., 10) would be treated as secs, which doesn't seem right.
      
      However, fixing it to properly calculate msecs would potentially cause
      timeouts when using twice the period size for the default timeout (which
      seems reasonable to me), so instead use the buffer size plus 10 percent
      to be on the safe side ... but that still seems insufficient, presumably
      because the hardware typically needs a moment to fire up. To compensate
      for this, we up the minimal timeout to 100ms, which is still two orders
      of magnitude less than the bogus minimum.
      
      substream->wait_time was also misinterpreted as jiffies, despite being
      documented as being in msecs. Only the soc/sof driver sets it - to 500,
      which looks very much like msecs were intended.
      
      Speaking of which, shouldn't snd_pcm_drain() also use substream->
      wait_time?
      
      As a drive-by, make the debug messages on timeout less confusing.
      Signed-off-by: default avatarOswald Buddenhagen <oswald.buddenhagen@gmx.de>
      Link: https://lore.kernel.org/r/20230405201219.2197774-1-oswald.buddenhagen@gmx.deSigned-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      3ed2b549
  6. 06 Apr, 2023 3 commits
  7. 30 Mar, 2023 1 commit
  8. 29 Mar, 2023 8 commits
  9. 24 Mar, 2023 8 commits
  10. 22 Mar, 2023 1 commit
  11. 21 Mar, 2023 2 commits
    • Takashi Iwai's avatar
      ALSA: usb-audio: Fix recursive locking at XRUN during syncing · 8c721c53
      Takashi Iwai authored
      The recent support of low latency playback in USB-audio driver made
      the snd_usb_queue_pending_output_urbs() function to be called via PCM
      ack ops.  In the new code path, the function is performed already in
      the PCM stream lock.  The problem is that, when an XRUN is detected,
      the function calls snd_pcm_xrun() to notify, but snd_pcm_xrun() is
      supposed to be called only outside the stream lock.  As a result, it
      leads to a deadlock of PCM stream locking.
      
      For avoiding such a recursive locking, this patch adds an additional
      check to the code paths in PCM core that call the ack callback; now it
      checks the error code from the callback, and if it's -EPIPE, the XRUN
      is handled in the PCM core side gracefully.  Along with it, the
      USB-audio driver code is changed to follow that, i.e. -EPIPE is
      returned instead of the explicit snd_pcm_xrun() call when the function
      is performed already in the stream lock.
      
      Fixes: d5f871f8 ("ALSA: usb-audio: Improved lowlatency playback support")
      Reported-and-tested-by: default avatarJohn Keeping <john@metanate.com>
      Link: https://lore.kernel.org/r/20230317195128.3911155-1-john@metanate.comReviewed-by: default avatarJaroslav Kysela <perex@perex.cz>
      Reviewed-by; Takashi Sakamoto <o-takashi@sakamocchi.jp>
      Link: https://lore.kernel.org/r/20230320142838.494-1-tiwai@suse.deSigned-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      8c721c53
    • Takashi Iwai's avatar
      ALSA: hda/conexant: Partial revert of a quirk for Lenovo · b871cb97
      Takashi Iwai authored
      The recent commit f83bb259 ("ALSA: hda/conexant: Add quirk for
      LENOVO 20149 Notebook model") introduced a quirk for the device with
      17aa:3977, but this caused a regression on another model (Lenovo
      Ideadpad U31) with the very same PCI SSID.  And, through skimming over
      the net, it seems that this PCI SSID is used for multiple different
      models, so it's no good idea to apply the quirk with the SSID.
      
      Although we may take a different ID check (e.g. the codec SSID instead
      of the PCI SSID), unfortunately, the original patch author couldn't
      identify the hardware details any longer as the machine was returned,
      and we can't develop the further proper fix.
      
      In this patch, instead, we partially revert the change so that the
      quirk won't be applied as default for addressing the regression.
      Meanwhile, the quirk function itself is kept, and it's now made to be
      applicable via the explicit model=lenovo-20149 option.
      
      Fixes: f83bb259 ("ALSA: hda/conexant: Add quirk for LENOVO 20149 Notebook model")
      Reported-by: default avatarJetro Jormalainen <jje-lxkl@jetro.fi>
      Link: https://lore.kernel.org/r/20230308215009.4d3e58a6@mopti
      Cc: <stable@vger.kernel.org>
      Link: https://lore.kernel.org/r/20230320140954.31154-1-tiwai@suse.deSigned-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      b871cb97
  12. 20 Mar, 2023 1 commit
  13. 19 Mar, 2023 3 commits
  14. 14 Mar, 2023 3 commits
  15. 10 Mar, 2023 1 commit
  16. 09 Mar, 2023 1 commit
  17. 08 Mar, 2023 1 commit
    • Guenter Roeck's avatar
      ASoC: da7219: Initialize jack_det_mutex · af0f46e5
      Guenter Roeck authored
      The following traceback is reported if mutex debugging is enabled.
      
      DEBUG_LOCKS_WARN_ON(lock->magic != lock)
      WARNING: CPU: 0 PID: 17 at kernel/locking/mutex.c:950 __mutex_lock_common+0x31c/0x11d4
      Modules linked in:
      CPU: 0 PID: 17 Comm: kworker/0:1 Not tainted 5.10.172-lockdep-21846-g849884cfca5a #1 fd2de466502012eb58bc8beb467f07d0b925611f
      Hardware name: MediaTek kakadu rev0/rev1 board (DT)
      Workqueue: events da7219_aad_jack_det_work
      pstate: 60400005 (nZCv daif +PAN -UAO -TCO BTYPE=--)
      pc : __mutex_lock_common+0x31c/0x11d4
      lr : __mutex_lock_common+0x31c/0x11d4
      sp : ffffff80c0317ae0
      x29: ffffff80c0317b50 x28: ffffff80c0317b20
      x27: 0000000000000000 x26: 0000000000000000
      x25: 0000000000000000 x24: 0000000100000000
      x23: ffffffd0121d296c x22: dfffffd000000000
      x21: 0000000000000000 x20: 0000000000000000
      x19: ffffff80c73d7190 x18: 1ffffff018050f52
      x17: 0000000000000000 x16: 0000000000000000
      x15: 0000000000000000 x14: 0000000000000000
      x13: 0000000000000001 x12: 0000000000000001
      x11: 0000000000000000 x10: 0000000000000000
      x9 : 83f0d991da544b00 x8 : 83f0d991da544b00
      x7 : 0000000000000000 x6 : 0000000000000001
      x5 : ffffff80c03176a0 x4 : 0000000000000000
      x3 : ffffffd01067fd78 x2 : 0000000100000000
      x1 : ffffff80c030ba80 x0 : 0000000000000028
      Call trace:
      __mutex_lock_common+0x31c/0x11d4
      mutex_lock_nested+0x98/0xac
      da7219_aad_jack_det_work+0x54/0xf0
      process_one_work+0x6cc/0x19dc
      worker_thread+0x458/0xddc
      kthread+0x2fc/0x370
      ret_from_fork+0x10/0x30
      irq event stamp: 579
      hardirqs last enabled at (579): [<ffffffd012442b30>] exit_to_kernel_mode+0x108/0x138
      hardirqs last disabled at (577): [<ffffffd010001144>] __do_softirq+0x53c/0x125c
      softirqs last enabled at (578): [<ffffffd01009995c>] __irq_exit_rcu+0x264/0x4f4
      softirqs last disabled at (573): [<ffffffd01009995c>] __irq_exit_rcu+0x264/0x4f4
      ---[ end trace 26da674636181c40 ]---
      
      Initialize the mutex to fix the problem.
      
      Cc: David Rau <David.Rau.opensource@dm.renesas.com>
      Fixes: 7fde88ed ("ASoC: da7219: Improve the IRQ process to increase the stability")
      Signed-off-by: default avatarGuenter Roeck <linux@roeck-us.net>
      Link: https://lore.kernel.org/r/20230307155111.1985522-1-linux@roeck-us.netSigned-off-by: default avatarMark Brown <broonie@kernel.org>
      af0f46e5