1. 27 Nov, 2017 1 commit
  2. 16 Oct, 2017 1 commit
  3. 30 Aug, 2017 3 commits
    • Takashi Iwai's avatar
      ALSA: pcm: Unify ioctl functions for playback and capture streams · 67616fed
      Takashi Iwai authored
      Some ioctl functions are implemented individually for both playback
      and capture streams although most of the codes are identical with just
      a few different stream-specific function calls.  This patch unifies
      these places, removes the superfluous trivial check and flattens the
      call paths as a cleanup.  Meanwhile, for better readability, some
      codes (e.g. xfer ioctls or forward/rewind ioctls) are factored out as
      functions.
      Signed-off-by: 's avatarTakashi Iwai <tiwai@suse.de>
      67616fed
    • Takashi Iwai's avatar
      ALSA: Get rid of card power_lock · 7d8e8292
      Takashi Iwai authored
      Currently we're taking power_lock at each card component for assuring
      the power-up sequence, but it doesn't help anything in the
      implementation at the moment: it just serializes unnecessarily the
      callers, but it doesn't protect about the power state change itself.
      It used to have some usefulness in the early days where we managed the
      PM manually.  But now the suspend/resume core procedure is beyond our
      hands, and power_lock lost its meaning.
      
      This patch drops the power_lock from allover the places.
      There shouldn't be any issues by this change, as it's no helper
      regarding the power state change.  Rather we'll get better performance
      by removing the serialization; which is the only slight concern of any
      behavior change, but it can't be a showstopper, after all.
      Signed-off-by: 's avatarTakashi Iwai <tiwai@suse.de>
      7d8e8292
    • Takashi Iwai's avatar
      ALSA: pcm: Fix power lock unbalance via OSS emulation · bcab3a6e
      Takashi Iwai authored
      PCM OSS emulation issues the drain ioctl without power lock.  It used
      to work in the earlier kernels as the power lock was taken inside
      snd_pcm_drain() itself.  But since 68b4acd3 ("ALSA: pcm: Apply
      power lock globally to common ioctls"), the power lock is taken
      outside the function.  Due to that change, the call via OSS emulation
      leads to the unbalanced power lock, thus it deadlocks.
      
      As a quick fix, just take the power lock before snd_pcm_drain() call
      for OSS emulation path.  A better cleanup will follow later.
      
      Fixes: 68b4acd3 ("ALSA: pcm: Apply power lock globally to common ioctls")
      Reported-and-tested-by: 's avatarMarkus Trippelsdorf <markus@trippelsdorf.de>
      Signed-off-by: 's avatarTakashi Iwai <tiwai@suse.de>
      bcab3a6e
  4. 10 Jul, 2017 2 commits
  5. 27 Jun, 2017 2 commits
    • Takashi Iwai's avatar
      ALSA: pcm: Disable only control mmap for explicit appl_ptr sync · b602aa8e
      Takashi Iwai authored
      Now that user-space (typically alsa-lib) can specify which protocol
      version it supports, we can optimize the kernel code depending on the
      reported protocol version.
      
      In this patch, we change the previous hack for enforcing the appl_ptr
      sync by disabling status/control mmap.  Instead of forcibly disabling
      both mmaps, we disable only the control mmap when user-space declares
      the supported protocol version new enough.  For older user-space,
      still both PCM status and control mmaps are disabled when requested by
      the driver due to the compatibility reason.
      Reviewed-by: 's avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Signed-off-by: 's avatarTakashi Iwai <tiwai@suse.de>
      b602aa8e
    • Takashi Iwai's avatar
      ALSA: pcm: Add an ioctl to specify the supported protocol version · 4b671f57
      Takashi Iwai authored
      We have an ioctl to inform the PCM protocol version the running kernel
      supports, but there is no way to know which protocol version the
      user-space can understand.  This lack of information caused headaches
      in the past when we tried to extend the ABI.  For example, because we
      couldn't guarantee the validity of the reserved bytes, we had to
      introduce a new ioctl SNDRV_PCM_IOCTL_STATUS_EXT for assigning a few
      new fields in the formerly reserved bits.  If we could know that it's
      a new alsa-lib, we could assume the availability of the new fields,
      thus we could have reused the existing SNDRV_PCM_IOCTL_STATUS.
      
      In order to improve the ABI extensibility, this patch adds a new ioctl
      for user-space to inform its supporting protocol version to the
      kernel.  By reporting the supported protocol from user-space, the
      kernel can judge which feature should be provided and which not.
      
      With the addition of the new ioctl, the PCM protocol version is bumped
      to 2.0.14, too.  User-space checks the kernel protocol version via
      SNDRV_PCM_INFO_PVERSION, then it sets the supported version back via
      SNDRV_PCM_INFO_USER_PVERSION.
      Reviewed-by: 's avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Signed-off-by: 's avatarTakashi Iwai <tiwai@suse.de>
      4b671f57
  6. 23 Jun, 2017 1 commit
    • Takashi Iwai's avatar
      ALSA: pcm: Add the explicit appl_ptr sync support · 42f94597
      Takashi Iwai authored
      Currently x86 platforms use the PCM status/control mmaps for
      transferring the PCM status and appl_ptr between kernel and
      user-spaces.  The mmap is a most efficient way of communication, but
      it has a drawback per its nature, namely, it can't notify the change
      explicitly to kernel.
      
      The lack of appl_ptr update notification is a problem on a few
      existing drivers, but it's mostly a small issue and negligible.
      However, a new type of driver that uses DSP for a deep buffer
      management requires the exact position of appl_ptr for calculating the
      buffer prefetch size, and the asynchronous appl_ptr update between
      kernel and user-spaces becomes a significant problem for it.
      
      How can we enforce user-space to report the appl_ptr update?  The way
      is relatively simple.  Just by disabling the PCM control mmap, the
      user-space is supposed to fall back to the mode using SYNC_PTR ioctl,
      and the kernel gets control over that.  This fallback mode is used in
      all non-x86 platforms as default, and also in the 32bit compatible
      model on all platforms including x86.  It's been implemented already
      over a decade, so we can say it's fairly safe and stably working.
      
      With the help of the knowledge above, this patch introduces a new PCM
      info flag SNDRV_PCM_INFO_SYNC_APPLPTR for achieving the appl_ptr sync
      from user-space.  When a driver sets this flag at open, the PCM status
      / control mmap is disabled, which effectively switches to SYNC_PTR
      mode in user-space side.
      
      In this version, both PCM status and control mmaps are disabled
      although only the latter, control mmap, is the target.  It's because
      the current alsa-lib implementation supposes that both status and
      control mmaps are always coupled, thus it handles a fatal error when
      only one of them fails.
      
      Of course, the disablement of the status/control mmaps may bring a
      slight performance overhead.  Thus, as of now, this should be used
      only for the dedicated devices that deserves.
      
      Note that the disablement of mmap is a sort of workaround.  In the
      later patch, we'll introduce the way to identify the protocol version
      alsa-lib supports, and keep mmap working while the sync_ptr is
      performed together.
      Reviewed-by: 's avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Signed-off-by: 's avatarTakashi Iwai <tiwai@suse.de>
      42f94597
  7. 20 Jun, 2017 1 commit
    • Ingo Molnar's avatar
      sched/wait: Rename wait_queue_t => wait_queue_entry_t · ac6424b9
      Ingo Molnar authored
      Rename:
      
      	wait_queue_t		=>	wait_queue_entry_t
      
      'wait_queue_t' was always a slight misnomer: its name implies that it's a "queue",
      but in reality it's a queue *entry*. The 'real' queue is the wait queue head,
      which had to carry the name.
      
      Start sorting this out by renaming it to 'wait_queue_entry_t'.
      
      This also allows the real structure name 'struct __wait_queue' to
      lose its double underscore and become 'struct wait_queue_entry',
      which is the more canonical nomenclature for such data types.
      
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: 's avatarIngo Molnar <mingo@kernel.org>
      ac6424b9
  8. 16 Jun, 2017 1 commit
  9. 14 Jun, 2017 6 commits
  10. 12 Jun, 2017 1 commit
  11. 11 Jun, 2017 2 commits
  12. 09 Jun, 2017 5 commits
  13. 08 Jun, 2017 8 commits
  14. 07 Jun, 2017 3 commits
  15. 26 May, 2017 1 commit
  16. 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: 's avatarTakashi Iwai <tiwai@suse.de>
      9027c463
  17. 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: 's avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Signed-off-by: 's avatarTakashi Iwai <tiwai@suse.de>
      c2c86a97