Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 14 6月, 2017 1 次提交
  3. 12 6月, 2017 3 次提交
  5. 09 6月, 2017 13 次提交
  7. 07 6月, 2017 3 次提交
  9. 26 5月, 2017 2 次提交
    • T
      ALSA: pcm: add local header file for snd-pcm module · 2c4842d3
      由 Takashi Sakamoto 提交于 
      Several files are used to construct PCM core module, a.k.a snd-pcm.
Although available APIs are described in 'include/sound/pcm.h', some of
them are not exported as symbols in kernel space. Such APIs are just for
module local usage.

This commit adds module local header file and move some function prototypes
into it so that scopes of them are controlled properly and developers
get no confusion from unavailable symbols.
Signed-off-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      2c4842d3
    • T
      ALSA: pcm: Call ack() whenever appl_ptr is updated · 9027c463
      由 Takashi Iwai 提交于 
      Although the ack callback is supposed to be called at each appl_ptr or
hw_ptr update, we missed a few opportunities: namely, forward, rewind
and sync_ptr.

Formerly calling ack at rewind may have leaded to unexpected results
due to the forgotten negative appl_ptr update in indirect-PCM helper,
which is the major user of the PCM ack callback.  But now we fixed
this oversights, thus we can call ack callback safely even at rewind
callback -- of course with the proper handling of the error from the
callback.

This patch adds the calls of ack callback in the places mentioned in
the above.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      9027c463
  11. 23 5月, 2017 1 次提交
    • T
      ALSA: pcm: Remove set_fs() in PCM core code · c2c86a97
      由 Takashi Iwai 提交于 
      PCM core code has a few usages of set_fs(), mostly for two codepaths:
- The DELAY ioctl call from pcm_compat.c
- The ioctl wrapper in kernel context for PCM OSS and other

This patch removes the set_fs() usage in these places by a slight code
refactoring.  For the former point, snd_pcm_delay() is changed to
return the  value directly instead of putting the value to the given
address.  Each caller stores the result in an appropriate manner.

For fixing the latter, snd_pcm_lib_kernel_ioctl() is changed to call
the functions directly as well.  For achieving it, now the function
accepts only the limited set of ioctls that have been used, so far.
The primary user of this function is the PCM OSS layer, and the only
other user is USB UAC1 gadget driver.  Both drivers don't need the
full set of ioctls.
Reviewed-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      c2c86a97
  13. 21 5月, 2017 2 次提交
  15. 17 5月, 2017 2 次提交
  17. 02 3月, 2017 1 次提交
  19. 25 2月, 2017 1 次提交
  21. 06 9月, 2016 1 次提交
    • J
      ALSA: pcm: Fix avail to return error if stream is suspended · f3f6c614
      由 Jeeja KP 提交于 
      When the stream is in suspended state some applications wait
on "Stream Pipe Error" in response to snd_pcm_avail call to
resume the stream.

In the current implementation snd_pcm_avail() returns zero
when the stream is in suspended state. This causes application
to enter in infinite loop for frames to be available.

"Stream pipe Error" code is getting returned for read/write
call when the stream is in suspended state. Similarly update
snd_pcm_avail to return -ESTRPIPE.
Signed-off-by: NJeeja KP <jeeja.kp@intel.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      f3f6c614
  23. 09 5月, 2016 1 次提交
  25. 18 2月, 2016 1 次提交
    • T
      ALSA: pcm: Fix rwsem deadlock for non-atomic PCM stream · 67ec1072
      由 Takashi Iwai 提交于 
      A non-atomic PCM stream may take snd_pcm_link_rwsem rw semaphore twice
in the same code path, e.g. one in snd_pcm_action_nonatomic() and
another in snd_pcm_stream_lock().  Usually this is OK, but when a
write lock is issued between these two read locks, the problem
happens: the write lock is blocked due to the first reade lock, and
the second read lock is also blocked by the write lock.  This
eventually deadlocks.

The reason is the way rwsem manages waiters; it's queued like FIFO, so
even if the writer itself doesn't take the lock yet, it blocks all the
waiters (including reads) queued after it.

As a workaround, in this patch, we replace the standard down_write()
with an spinning loop.  This is far from optimal, but it's good
enough, as the spinning time is supposed to be relatively short for
normal PCM operations, and the code paths requiring the write lock
aren't called so often.
Reported-by: NVinod Koul <vinod.koul@intel.com>
Tested-by: NRamesh Babu <ramesh.babu@intel.com>
Cc: <stable@vger.kernel.org> # v3.18+
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      67ec1072
  27. 30 11月, 2015 1 次提交
  29. 16 10月, 2015 1 次提交
  31. 29 9月, 2015 1 次提交
  33. 24 9月, 2015 1 次提交
  35. 17 7月, 2015 1 次提交
    • T
      ALSA: pcm: Fix lockdep warning with nonatomic PCM ops · 67756e31
      由 Takashi Iwai 提交于 
      With the nonatomic PCM ops, the system may spew lockdep warnings like:

 =============================================
 [ INFO: possible recursive locking detected ]
 4.2.0-rc1-jeejaval3 #12 Not tainted
 ---------------------------------------------
 aplay/4029 is trying to acquire lock:
  (snd_pcm_link_rwsem){.+.+.+}, at: [<ffffffff816fd473>] snd_pcm_stream_lock+0x43/0x60

 but task is already holding lock:
  (snd_pcm_link_rwsem){.+.+.+}, at: [<ffffffff816fcf29>] snd_pcm_action_nonatomic+0x29/0x80

 other info that might help us debug this:
  Possible unsafe locking scenario:

        CPU0
        ----
   lock(snd_pcm_link_rwsem);
   lock(snd_pcm_link_rwsem);

Although this is false-positive as the rwsem is taken always as
read-only for these code paths, it's certainly annoying to see this at
any occasion.  A simple fix is to use down_read_nested() in
snd_pcm_stream_lock() that can be called inside another lock.
Reported-by: NVinod Koul <vinod.koul@intel.com>
Reported-by: NJeeja Kp <jeeja.kp@intel.com>
Tested-by: NJeeja Kp <jeeja.kp@intel.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      67756e31
  37. 12 4月, 2015 1 次提交
    • A
      pcm: another weird API abuse · 1c65d986
      由 Al Viro 提交于 
      readv() and writev() should _not_ ignore all but the first ->iov_len,
among other things.  Really weird abuse of those syscalls - it
expects a vector element per channel, with identical lengths (it
actually assumes them to be identical - no checking is done).
readv() and writev() are really bad match for that.  Unfortunately,
userland API is userland API and we can't do anything about them.

Converted to ->read_iter/->write_iter.  Please, _please_ don't do
anything of that kind when designing new interfaces.
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      1c65d986
  39. 26 3月, 2015 1 次提交
  41. 23 2月, 2015 1 次提交