1. 16 1月, 2018 1 次提交
  2. 05 1月, 2018 1 次提交
    • T
      ALSA: pcm: Workaround for weird PulseAudio behavior on rewind error · fb51f1cd
      Takashi Iwai 提交于
      The commit 9027c463 ("ALSA: pcm: Call ack() whenever appl_ptr is
      updated") introduced the possible error code returned from the PCM
      rewind ioctl.  Basically the change was for handling the indirect PCM
      more correctly, but ironically, it caused rather a side-effect:
      PulseAudio gets pissed off when receiving an error from rewind, throws
      everything away and stops processing further, resulting in the
      silence.
      
      It's clearly a failure in the application side, so the best would be
      to fix that bug in PA.  OTOH, PA is mostly the only user of the rewind
      feature, so it's not good to slap the sole customer.
      
      This patch tries to mitigate the situation: instead of returning an
      error, now the rewind ioctl returns zero when the driver can't rewind.
      It indicates that no rewind was performed, so the behavior is
      consistent, at least.
      
      Fixes: 9027c463 ("ALSA: pcm: Call ack() whenever appl_ptr is updated")
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      fb51f1cd
  3. 16 10月, 2017 1 次提交
  4. 31 8月, 2017 2 次提交
    • T
      ALSA: pcm: Unify ioctl functions for playback and capture streams · 67616fed
      Takashi Iwai 提交于
      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: NTakashi Iwai <tiwai@suse.de>
      67616fed
    • T
      ALSA: Get rid of card power_lock · 7d8e8292
      Takashi Iwai 提交于
      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: NTakashi Iwai <tiwai@suse.de>
      7d8e8292
  5. 30 8月, 2017 1 次提交
    • T
      ALSA: pcm: Fix power lock unbalance via OSS emulation · bcab3a6e
      Takashi Iwai 提交于
      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: NMarkus Trippelsdorf <markus@trippelsdorf.de>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      bcab3a6e
  6. 10 7月, 2017 2 次提交
  7. 27 6月, 2017 2 次提交
    • T
      ALSA: pcm: Disable only control mmap for explicit appl_ptr sync · b602aa8e
      Takashi Iwai 提交于
      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: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      b602aa8e
    • T
      ALSA: pcm: Add an ioctl to specify the supported protocol version · 4b671f57
      Takashi Iwai 提交于
      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: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      4b671f57
  8. 23 6月, 2017 1 次提交
    • T
      ALSA: pcm: Add the explicit appl_ptr sync support · 42f94597
      Takashi Iwai 提交于
      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: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      42f94597
  9. 20 6月, 2017 1 次提交
    • I
      sched/wait: Rename wait_queue_t => wait_queue_entry_t · ac6424b9
      Ingo Molnar 提交于
      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: NIngo Molnar <mingo@kernel.org>
      ac6424b9
  10. 16 6月, 2017 1 次提交
  11. 14 6月, 2017 6 次提交
  12. 12 6月, 2017 3 次提交
  13. 09 6月, 2017 13 次提交
  14. 07 6月, 2017 3 次提交
  15. 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