Skip to content

K
kernel_linux

OpenHarmony / kernel_linux
上一次同步 4 年多

通知 15
Star 8
Fork 2
K
kernel_linux
切换分支/标签
  1. 12 2月, 2009 1 次提交
  3. 18 12月, 2008 1 次提交
  5. 28 11月, 2008 1 次提交
  7. 26 11月, 2008 1 次提交
    • T
      ALSA: pcsp - Fix starting the stream with HRTIMER_CB_IRQSAFE_UNLOCK · eea0579f
      由 Takashi Iwai 提交于 
      With the callback mode HRTIMER_CB_IRQSAFE_UNLOCK, the start of the
stream with zero delay doesn't work.  Since IRQSAFE mode is removed,
we have to change the pcsp start-up code.

This patch splits the callback function to two parts, the triggering
of the port and the calculation of the expire time, and the update of
the ALSA PCM core.  The first part is called both from the trigger-start
and the hrtimer callback while the latter is handled only in the
hrtimer callback.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      eea0579f
  9. 25 11月, 2008 1 次提交
    • P
      hrtimer: removing all ur callback modes · ca109491
      由 Peter Zijlstra 提交于 
      Impact: cleanup, move all hrtimer processing into hardirq context

This is an attempt at removing some of the hrtimer complexity by
reducing the number of callback modes to 1.

This means that all hrtimer callback functions will be ran from HARD-irq
context.

I went through all the 30 odd hrtimer callback functions in the kernel
and saw only one that I'm not quite sure of, which is the one in
net/can/bcm.c - hence I'm CC-ing the folks responsible for that code.

Furthermore, the hrtimer core now calls callbacks directly with IRQs
disabled in case you try to enqueue an expired timer. If this timer is a
periodic timer (which should use hrtimer_forward() to advance its time)
then it might be possible to end up in an inf. recursive loop due to the
fact that hrtimer_forward() doesn't round up to the next timer
granularity, and therefore keeps on calling the callback - obviously
this needs a fix.

Aside from that, this seems to compile and actually boot on my dual core
test box - although I'm sure there are some bugs in, me not hitting any
makes me certain :-)
Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: NIngo Molnar <mingo@elte.hu>
      ca109491
  11. 14 11月, 2008 1 次提交
  13. 03 11月, 2008 2 次提交
  15. 20 10月, 2008 1 次提交
    • T
      ALSA: pcsp - Fix locking messes in snd-pcsp · 96c7d478
      由 Takashi Iwai 提交于 
      snd-pcsp driver takes chip->substream_lock together with PCM substream
lock.  These are even mixed up with hrtimer's lock, resulting in messy
lock depencies.  Right now, snd-pcsp driver resolves the deadlock by
using HRTIMER_CB_SOFTIRQ.  However, this isn't nice for a really fast
path like bit-flipping.

This patch introduces a tasklet for PCM period handling so that the
hrtimer callback can be handled fast.  This also reduce the use of
chip->substream_lock to avoid deadlocks.  It's still used in pointer
callback, but even this could be removed with a proper barrier.

Another good solution is to introduce async trigger callback.  But,
this will involve with a major rewrite of the PCM core code, so I
take first this easy fix.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      96c7d478
  17. 19 10月, 2008 1 次提交
  19. 10 10月, 2008 1 次提交
  21. 06 9月, 2008 1 次提交
  23. 15 8月, 2008 2 次提交
  25. 13 8月, 2008 1 次提交
  27. 10 7月, 2008 3 次提交
  29. 27 5月, 2008 2 次提交
  31. 26 5月, 2008 1 次提交
  33. 20 5月, 2008 1 次提交
  35. 19 5月, 2008 5 次提交
  37. 07 5月, 2008 1 次提交
  39. 05 5月, 2008 1 次提交
  41. 30 4月, 2008 2 次提交
  43. 24 4月, 2008 9 次提交