1. 14 Jun, 2017 6 commits
  2. 12 Jun, 2017 1 commit
  3. 11 Jun, 2017 2 commits
  4. 09 Jun, 2017 5 commits
  5. 08 Jun, 2017 8 commits
  6. 07 Jun, 2017 3 commits
  7. 26 May, 2017 1 commit
  8. 25 May, 2017 1 commit
    • Takashi Iwai's avatar
      ALSA: pcm: Call ack() whenever appl_ptr is updated · 9027c463
      Takashi Iwai authored
      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: default avatarTakashi Iwai <tiwai@suse.de>
      9027c463
  9. 23 May, 2017 1 commit
    • Takashi Iwai's avatar
      ALSA: pcm: Remove set_fs() in PCM core code · c2c86a97
      Takashi Iwai authored
      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: default avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      c2c86a97
  10. 21 May, 2017 2 commits
  11. 17 May, 2017 2 commits
  12. 02 Mar, 2017 1 commit
  13. 25 Feb, 2017 1 commit
  14. 06 Sep, 2016 1 commit
    • Jeeja KP's avatar
      ALSA: pcm: Fix avail to return error if stream is suspended · f3f6c614
      Jeeja KP authored
      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: default avatarJeeja KP <jeeja.kp@intel.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      f3f6c614
  15. 09 May, 2016 1 commit
  16. 18 Feb, 2016 1 commit
    • Takashi Iwai's avatar
      ALSA: pcm: Fix rwsem deadlock for non-atomic PCM stream · 67ec1072
      Takashi Iwai authored
      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: default avatarVinod Koul <vinod.koul@intel.com>
      Tested-by: default avatarRamesh Babu <ramesh.babu@intel.com>
      Cc: <stable@vger.kernel.org> # v3.18+
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      67ec1072
  17. 30 Nov, 2015 1 commit
  18. 16 Oct, 2015 1 commit
  19. 29 Sep, 2015 1 commit