Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
1 年多 前同步成功

通知 161
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 04 11月, 2014 3 次提交
    • T
      ALSA: pcm: Add xrun_injection proc entry · 2b30d411
      由 Takashi Iwai 提交于 
      This patch adds a new proc entry for PCM substreams to inject an
XRUN.  When a PCM substream is running and any value is written to its
xrun_injection proc file, the driver triggers XRUN.  This is a useful
feature for debugging XRUN and error handling code paths.

Note that this entry is enabled only when CONFIG_SND_PCM_XRUN_DEBUG is
set.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      2b30d411
    • T
      ALSA: pcm: Replace PCM hwptr tracking with tracepoints · f5914908
      由 Takashi Iwai 提交于 
      ALSA PCM core has a mechanism tracking the PCM hwptr updates for
analyzing XRUNs.  But its log is limited (up to 10) and its log output
is a kernel message, which is hard to handle.

In this patch, the hwptr logging is moved to the tracing
infrastructure instead of its own.  Not only the hwptr updates but
also XRUN and hwptr errors are recorded on the trace log, so that user
can see such events at the exact timing.

The new "snd_pcm" entry will appear in the tracing events:
  # ls -F /sys/kernel/debug/tracing/events/snd_pcm
  enable  filter  hw_ptr_error/  hwptr/  xrun/

The hwptr is for the regular hwptr update events.  An event trace
looks like:

  aplay-26187 [004] d..3  4012.834761: hwptr: pcmC0D0p/sub0: POS: pos=488, old=0, base=0, period=1024, buf=16384

"POS" shows the hwptr update by the explicit position update call and
"IRQ" means the hwptr update by the interrupt,
i.e. snd_pcm_period_elapsed() call.  The "pos" is the passed
ring-buffer offset by the caller, "old" is the previous hwptr, "base"
is the hwptr base position, "period" and "buf" are period- and
buffer-size of the target PCM substream.
(Note that the hwptr position displayed here isn't the ring-buffer
 offset.  It increments up to the PCM position boundary.)

The XRUN event appears similarly, but without "pos" field.
The hwptr error events appear with the PCM identifier and its reason
string, such as "Lost interrupt?".

The XRUN and hwptr error reports on kernel message are still left, can
be turned on/off via xrun_debug proc like before.  But the bit 3, 4, 5
and 6 bits of xrun_debug proc are dropped by this patch.  Also, along
with the change, the message strings have been reformatted to be a bit
more consistent.

Last but not least, the hwptr reporting is enabled only when
CONFIG_SND_PCM_XRUN_DEBUG is set.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      f5914908
    • T
      ALSA: pcm: Correct PCM BUG error message · d507941b
      由 Takashi Iwai 提交于 
      While converting to dev_*(), the message showing the invalid PCM
position was wrongly tagged as if an XRUN although it's actually a
BUG.  This patch corrects the message again.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      d507941b
  3. 31 10月, 2014 2 次提交
    • T
      ALSA: pcm: Refactoring snd_pcm_action() · aa8edd8c
      由 Takashi Iwai 提交于 
      Just a small code refactoring to reduce more lines.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      aa8edd8c
    • T
      ALSA: pcm: Simplify snd_pcm_action_lock_irq() · e3a4bd5e
      由 Takashi Iwai 提交于 
      The function snd_pcm_action_lock_irq() can be much simplified by
simply wrapping snd_pcm_action() with the stream lock.  This was
rather the original idea, but later it was open coded for
optimization.  However, looking at the optimization part closely, one
notices that the probability of the optimized path is quite low; in
normal situations, the linked stream action happens only for the
triggered substream, thus the operation becomes identical.  So the
code simplification has a clear win, especially because we have now
doubly codes for both atomic and non-atomic locks.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      e3a4bd5e
  5. 30 10月, 2014 3 次提交
  7. 24 10月, 2014 1 次提交
    • T
      ALSA: pcm: Avoid mmap warnings on x86 · 49d776ff
      由 Takashi Iwai 提交于 
      On x86, using dma_mmap_coherent() for the pages allocated via
dma_alloc_coherent() results in a warning like:
  aplay:32536 map pfn RAM range req uncached-minus for [mem 0x21d500000-0x21d51ffff], got write-back

Until the issue is addressed in the core side, take back to the old
good way in PCM code only for x86.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      49d776ff
  9. 22 10月, 2014 3 次提交
    • T
      ALSA: pcm: Disable mmap for known broken archs · 63825f3a
      由 Takashi Iwai 提交于 
      Some architectures like PARISC is known not to support mmap properly
with the DMA buffer, where dma_mmap_coherent() returns -EINVAL
unconditionally.  From the API POV, we should rather drop the mmap
support there and expose it before the user-space tries to call mmap.

The patch contains again ugly ifdef's, unfortunately, as there is no
global flag indicating this.  Once when such macro is defined, we can
get rid of this instead.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      63825f3a
    • T
      ALSA: pcm: Remove arch-dependent mmap kludges · c37de55e
      由 Takashi Iwai 提交于 
      Since we have consistently dma_mmap_coherent() for all architectures,
the current ifdef and arch-specific codes in pcm core can be cleaned
up gracefully.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      c37de55e
    • T
      ALSA: pcm: Fix false lockdep warnings · dde1c652
      由 Takashi Iwai 提交于 
      As PCM core handles the multiple linked streams in parallel, lockdep
gets confused (partly because of weak annotations) and spews the
false-positive warnings.  This hasn't been a problem for long time but
the latest PCM lock path update seems to have woken up a sleeping
dog.

Here is an attempt to paper over this issue: pass the lock subclass
just calculated from the depth in snd_pcm_action_group().  Also, a
(possibly) wrong lock subclass set in snd_pcm_action_lock_mutex() is
dropped, too.
Reported-and-tested-by: NArthur Marsh <arthur.marsh@internode.on.net>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      dde1c652
  11. 21 10月, 2014 2 次提交
  13. 19 10月, 2014 2 次提交
    • T
      Subject: ALSA: seq: Remove autoload locks in driver registration · d5129f33
      由 Takashi Iwai 提交于 
      Since we're calling request_module() asynchronously now, we can get
rid of the autoload lock in snd_seq_device_register_driver(), as well
as in the snd-seq driver registration itself.  This enables the
automatic loading of dependent sequencer modules, such as
snd-seq-virmidi from snd-emu10k1-synth.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      d5129f33
    • T
      ALSA: seq: bind seq driver automatically · 68ab6108
      由 Takashi Iwai 提交于 
      Currently the sequencer module binding is performed independently from
the card module itself.  The reason behind it is to keep the sequencer
stuff optional and allow the system running without it (e.g. for using
PCM or rawmidi only).  This works in most cases, but a remaining
problem is that the binding isn't done automatically when a new driver
module is probed.  Typically this becomes visible when a hotplug
driver like usb audio is used.

This patch tries to address this and other potential issues.  First,
the seq-binder (seq_device.c) tries to load a missing driver module at
creating a new device object.  This is done asynchronously in a workq
for avoiding the deadlock (modprobe call in module init path).

This action, however, should be enabled only when the sequencer stuff
was already initialized, i.e. snd-seq module was already loaded.  For
that, a new function, snd_seq_autoload_init() is introduced here; this
clears the blocking of autoloading, and also tries to load all pending
driver modules.
Reported-by: NAdam Goode <agoode@chromium.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      68ab6108
  15. 18 10月, 2014 1 次提交
  17. 15 10月, 2014 1 次提交
  19. 14 10月, 2014 1 次提交
  21. 08 10月, 2014 1 次提交
  23. 22 9月, 2014 1 次提交
  25. 08 9月, 2014 3 次提交
  27. 03 9月, 2014 2 次提交
    • T
      ALSA: pcm: Uninline snd_pcm_stream_lock() and _unlock() · 7af142f7
      由 Takashi Iwai 提交于 
      The previous commit for the non-atomic PCM ops added more codes to
snd_pcm_stream_lock() and its variants.  Since they are inlined
functions, it resulted in a significant code size bloat.  For reducing
the size bloat, this patch changes the inline functions to the normal
function calls.  The export of rwlock and rwsem are removed as well,
since they are referred only in pcm_native.c now.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      7af142f7
    • T
      ALSA: pcm: Allow nonatomic trigger operations · 257f8cce
      由 Takashi Iwai 提交于 
      Currently, many PCM operations are performed in a critical section
protected by spinlock, typically the trigger and pointer callbacks are
assumed to be atomic.  This is basically because some trigger action
(e.g. PCM stop after drain or xrun) is done in the interrupt handler.
If a driver runs in a threaded irq, however, this doesn't have to be
atomic.  And many devices want to handle trigger in a non-atomic
context due to lengthy communications.

This patch tries all PCM calls operational in non-atomic context.
What it does is very simple: replaces the substream spinlock with the
corresponding substream mutex when pcm->nonatomic flag is set.  The
driver that wants to use the non-atomic PCM ops just needs to set the
flag and keep the rest as is.  (Of course, it must not handle any PCM
ops in irq context.)

Note that the code doesn't check whether it's atomic-safe or not, but
trust in 100% that the driver sets pcm->nonatomic correctly.

One possible problem is the case where linked PCM substreams have
inconsistent nonatomic states.  For avoiding this, snd_pcm_link()
returns an error if one tries to link an inconsistent PCM substream.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      257f8cce
  29. 22 8月, 2014 2 次提交
  31. 21 7月, 2014 2 次提交
  33. 16 7月, 2014 1 次提交
  35. 15 7月, 2014 1 次提交
  37. 10 7月, 2014 2 次提交
  39. 05 7月, 2014 2 次提交
  41. 23 6月, 2014 1 次提交
  43. 18 6月, 2014 3 次提交