1. 10 6月, 2021 2 次提交
  2. 23 1月, 2021 1 次提交
    • T
      ALSA: pcm: One more dependency for hw constraints · 23b53d44
      Takashi Iwai 提交于
      The fix for a long-standing USB-audio bug required one more dependency
      variable to be added to the hw constraints.  Unfortunately I didn't
      realize at debugging that the new addition may result in the overflow
      of the dependency array of each snd_pcm_hw_rule (up to three plus a
      sentinel), because USB-audio driver adds one more dependency only for
      a certain device and bus, hence it works as is for many devices.  But
      in a bad case, a simple open always results in -EINVAL (with kernel
      WARNING if CONFIG_SND_DEBUG is set) no matter what is passed.
      
      Since the dependencies are real and unavoidable (USB-audio restricts
      the hw_params per looping over the format/rate/channels combos), the
      only good solution seems to raise the bar for one more dependency for
      snd_pcm_hw_rule -- so does this patch: now the hw constraint
      dependencies can be up to four.
      
      Fixes: 506c203c ("ALSA: usb-audio: Fix hw constraints dependencies")
      Reported-by: NJamie Heilman <jamie@audible.transient.net>
      Link: https://lore.kernel.org/r/20210123155730.22576-1-tiwai@suse.deSigned-off-by: NTakashi Iwai <tiwai@suse.de>
      23b53d44
  3. 26 10月, 2020 1 次提交
  4. 06 3月, 2020 1 次提交
  5. 19 2月, 2020 1 次提交
  6. 10 2月, 2020 1 次提交
  7. 31 1月, 2020 1 次提交
    • T
      ALSA: pcm: Fix sparse warnings wrt snd_pcm_state_t · cb639a42
      Takashi Iwai 提交于
      Since we have a bitwise definition of snd_pcm_state_t and use it for
      certain struct fields, a few new (and years old) sparse warnings came
      up.  This patch is an attempt to cover them.
      
      - The state fields in snd_pcm_mmap_status* and co are all defined as
        snd_pcm_state_t type now
      
      - The PCM action callbacks take snd_pcm_state_t argument as well;
        some actions taking special values got the explicit cast and
        comments
      
      - For the PCM action that doesn't need an extra argument receives
        ACTION_ARG_IGNORE instead of ambiguous 0
      
      While we're at it, the boolean argument is also properly changed to
      bool and true/false, as well as a slight refactoring of PCM pause
      helper function to make easier to read.
      
      No functional changes, just shutting up chatty sparse.
      
      Fixes: 46b770f7 ("ALSA: uapi: Fix sparse warning")
      Reported-by: Nkbuild test robot <lkp@intel.com>
      Link: https://lore.kernel.org/r/20200131152214.11698-1-tiwai@suse.deSigned-off-by: NTakashi Iwai <tiwai@suse.de>
      cb639a42
  8. 12 12月, 2019 2 次提交
    • B
      ALSA: Avoid using timespec for struct snd_pcm_status · 3ddee7f8
      Baolin Wang 提交于
      The struct snd_pcm_status will use 'timespec' type variables to record
      timestamp, which is not year 2038 safe on 32bits system.
      
      Userspace will use SNDRV_PCM_IOCTL_STATUS and SNDRV_PCM_IOCTL_STATUS_EXT
      as commands to issue ioctl() to fill the 'snd_pcm_status' structure in
      userspace. The command number is always defined through _IOR/_IOW/IORW,
      so when userspace changes the definition of 'struct timespec' to use
      64-bit types, the command number also changes.
      
      Thus in the kernel, we now need to define two versions of each such ioctl
      and corresponding ioctl commands to handle 32bit time_t and 64bit time_t
      in native mode:
      struct snd_pcm_status32 {
      	......
      
      	s32 trigger_tstamp_sec;
      	s32 trigger_tstamp_nsec;
      
      	......
      
      	s32 audio_tstamp_sec;
      	s32 audio_tstamp_nsec;
      
      	......
      };
      
      struct snd_pcm_status64 {
      	......
      
      	s32 trigger_tstamp_sec;
      	s32 trigger_tstamp_nsec;
      
      	......
      
      	s32 audio_tstamp_sec;
      	s32 audio_tstamp_nsec;
      
      	......
      };
      
      Moreover in compat file, we renamed or introduced new structures to handle
      32bit/64bit time_t in compatible mode. The 'struct snd_pcm_status32' and
      snd_pcm_status_user32() are used to handle 32bit time_t in compat mode.
      'struct compat_snd_pcm_status64' and snd_pcm_status_user_compat64() are used
      to handle 64bit time_t.
      
      The implicit padding before timespec is made explicit to avoid incompatible
      structure layout between 32-bit and 64-bit x86 due to the different
      alignment requirements, and the snd_pcm_status structure is now hidden
      from the kernel to avoid relying on the timespec definitio definitionn
      
      Finally we can replace SNDRV_PCM_IOCTL_STATUS and SNDRV_PCM_IOCTL_STATUS_EXT
      with new commands and introduce new functions to fill new 'struct snd_pcm_status64'
      instead of using unsafe 'struct snd_pcm_status'. Then in future, the new
      commands can be matched when userspace changes 'timespec' to 64bit type
      to make a size change of 'struct snd_pcm_status'. When glibc changes time_t
      to 64-bit, any recompiled program will issue ioctl commands that the kernel
      does not understand without this patch.
      Signed-off-by: NBaolin Wang <baolin.wang@linaro.org>
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      3ddee7f8
    • B
      ALSA: Replace timespec with timespec64 · fcae40c9
      Baolin Wang 提交于
      Since timespec is not year 2038 safe on 32bit system, and we need to
      convert all timespec variables to timespec64 type for sound subsystem.
      
      This patch is used to do preparation for following patches, that will
      convert all structures defined in uapi/sound/asound.h to use 64-bit
      time_t.
      Signed-off-by: NBaolin Wang <baolin.wang@linaro.org>
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      fcae40c9
  9. 21 11月, 2019 3 次提交
    • T
      ALSA: pcm: Add the support for sync-stop operation · 1e850bee
      Takashi Iwai 提交于
      The standard programming model of a PCM sound driver is to process
      snd_pcm_period_elapsed() from an interrupt handler.  When a running
      stream is stopped, PCM core calls the trigger-STOP PCM ops, sets the
      stream state to SETUP, and moves on to the next step.  This is
      performed in an atomic manner -- this could be called from the interrupt
      context, after all.
      
      The problem is that, if the stream goes further and reaches to the
      CLOSE state immediately, the stream might be still being processed in
      snd_pcm_period_elapsed() in the interrupt context, and hits a NULL
      dereference.  Such a crash happens because of the atomic operation,
      and we can't wait until the stream-stop finishes.
      
      For addressing such a problem, this commit adds a new PCM ops,
      sync_stop.  This gets called at the appropriate places that need a
      sync with the stream-stop, i.e. at hw_params, prepare and hw_free.
      
      Some drivers already have a similar mechanism implemented locally, and
      we'll refactor the code later.
      
      Link: https://lore.kernel.org/r/20191117085308.23915-7-tiwai@suse.deSigned-off-by: NTakashi Iwai <tiwai@suse.de>
      1e850bee
    • T
      ALSA: pcm: Move PCM_RUNTIME_CHECK() macro into local header · 0821fd77
      Takashi Iwai 提交于
      It should be used only in the PCM core code locally.
      
      Link: https://lore.kernel.org/r/20191117085308.23915-6-tiwai@suse.deSigned-off-by: NTakashi Iwai <tiwai@suse.de>
      0821fd77
    • T
      ALSA: pcm: Introduce managed buffer allocation mode · 0dba808e
      Takashi Iwai 提交于
      This patch adds the support for the feature to automatically allocate
      and free PCM buffers, so called "managed buffer allocation" mode.
      It's set up via new PCM helpers, snd_pcm_set_managed_buffer() and
      snd_pcm_set_managed_buffer_all(), both of which correspond to the
      existing preallocator helpers, snd_pcm_lib_preallocate_pages() and
      snd_pcm_lib_preallocate_pages_for_all().  When the new helper is used,
      it not only performs the pre-allocation of buffers, but also it
      manages to call snd_pcm_lib_malloc_pages() before the PCM hw_params
      ops and snd_lib_pcm_free() after the PCM hw_free ops inside PCM core,
      respectively.  This allows drivers to drop the explicit calls of the
      memory allocation / release functions, and it will be a good amount of
      code reduction in the end of this patch series.
      
      When the PCM substream is set to the managed buffer allocation mode,
      the managed_buffer_alloc flag is set in the substream object.  Since
      some drivers want to know when a buffer is newly allocated or
      re-allocated at hw_params callback (e.g. want to set up the additional
      stuff for the given buffer only at allocation time), now PCM core
      turns on buffer_changed flag when the buffer has changed.
      
      The standard conversions to use the new API will be straightforward:
      - Replace snd_pcm_lib_preallocate*() calls with the corresponding
        snd_pcm_set_managed_buffer*(); the arguments should be unchanged
      - Drop superfluous snd_pcm_lib_malloc() and snd_pcm_lib_free() calls;
        the check of snd_pcm_lib_malloc() returns should be replaced with
        the check of runtime->buffer_changed flag.
      - If hw_params or hw_free becomes empty, drop them from PCM ops
      
      Link: https://lore.kernel.org/r/20191117085308.23915-2-tiwai@suse.deSigned-off-by: NTakashi Iwai <tiwai@suse.de>
      0dba808e
  10. 10 11月, 2019 1 次提交
  11. 28 8月, 2019 1 次提交
  12. 31 5月, 2019 1 次提交
  13. 14 3月, 2019 1 次提交
  14. 08 2月, 2019 1 次提交
  15. 24 1月, 2019 2 次提交
  16. 23 1月, 2019 1 次提交
    • T
      ALSA: pcm: More fine-grained PCM link locking · f57f3df0
      Takashi Iwai 提交于
      We have currently two global locks, a rwlock and a rwsem, that are
      used for managing linking the PCM streams.  Due to these global locks,
      once when a linked stream is used, the lock granularity suffers a
      lot.
      
      This patch attempts to eliminate the former global lock for atomic
      ops.  The latter rwsem needs remaining because of the loosy way of the
      loop calls in snd_pcm_action_nonatomic(), as well as for avoiding the
      deadlock at linking.  However, these are used far rarely, actually
      only by two actions (prepare and  reset), where both are no timing
      critical ones.  So this can be still seen as a good improvement.
      
      The basic strategy to eliminate the rwlock is to assure group->lock at
      adding or removing a stream to / from the group.  Since we already
      takes the group lock whenever taking the all substream locks under the
      group, this shouldn't be a big problem.  The reference to group
      pointer in snd_pcm_substream object is protected by the stream lock
      itself.
      
      However, there are still pitfalls: a race window at re-locking and the
      lifecycle of group object.  The former is a small race window for
      dereferencing the substream group object opened while snd_pcm_action()
      performs re-locking to avoid ABBA deadlocks.  This includes the unlink
      of group during that window, too.  And the latter is the kfree
      performed after all streams are removed from the group while it's
      still dereferenced.
      
      For addressing these corner cases, two new tricks are introduced:
      - After re-locking, the group assigned to the stream is checked again;
        if the group is changed, we retry the whole procedure.
      - Introduce a refcount to snd_pcm_group object, so that it's freed
        only when it's empty and really no one refers to it.
      
      (Some readers might wonder why not RCU for the latter.  RCU in this
      case would cost more than refcounting, unfortunately.  We take the
      group lock sooner or later, hence the performance improvement by RCU
      would be negligible.  Meanwhile, because we need to deal with
      schedulable context depending on the pcm->nonatomic flag, it'll become
      dynamic RCU/SRCU switch, and the grace period may become too long.)
      
      Along with these changes, there are a significant amount of code
      refactoring.  The complex group re-lock & ref code is factored out to
      snd_pcm_stream_group_ref() function, for example.
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      f57f3df0
  17. 21 1月, 2019 1 次提交
  18. 16 1月, 2019 2 次提交
    • T
      ALSA: pcm: Make snd_pcm_suspend() local static · ce7f93e2
      Takashi Iwai 提交于
      snd_pcm_suspend() is no longer called from outside, so let's make it
      local static.  Also drop a superfluous NULL check there.
      Reviewed-by: NJaroslav Kysela <perex@perex.cz>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      ce7f93e2
    • T
      ALSA: pcm: Suspend streams globally via device type PM ops · 3d21ef0b
      Takashi Iwai 提交于
      Until now we rely on each driver calling snd_pcm_suspend*() explicitly
      at its own PM handling.  However, this can be done far more easily by
      setting the PM ops to each actual snd_pcm device object.
      
      This patch adds the device_type object for PCM stream and assigns to
      each PCM stream object.  The type contains only the PM ops for system
      suspend; we don't need to deal with the resume in general.
      
      The suspend hook simply calls snd_pcm_suspend_all() for the given PCM
      streams.  This implies that the PM order is correctly put, i.e. PCM is
      suspended before the main (or codec) driver, which should be true in
      general.  If a special ordering is needed, you'd need to adjust the
      device PM order manually later.
      
      This patch introduces a new flag, snd_pcm.no_device_suspend, too.
      With this flag set, the PCM device object won't invoke
      snd_pcm_suspend_all() by itself.  This is needed for ASoC who wants to
      manage the PM call orders in its serialized way, and the flag is set
      in soc_new_pcm() as default.
      
      For the non-ASoC world, we can get rid of the manual snd_pcm_suspend
      calls.  This will be done in the later patches.
      Reviewed-by: NJaroslav Kysela <perex@perex.cz>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      3d21ef0b
  19. 26 7月, 2018 1 次提交
  20. 18 7月, 2018 1 次提交
  21. 06 7月, 2018 1 次提交
  22. 29 11月, 2017 1 次提交
  23. 27 6月, 2017 1 次提交
    • 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
  24. 14 6月, 2017 2 次提交
  25. 03 6月, 2017 5 次提交
    • T
      ALSA: pcm: Direct in-kernel read/write support · 68541213
      Takashi Iwai 提交于
      Now all materials are ready, let's allow the direct in-kernel
      read/write, i.e. a kernel-space buffer is passed for read or write,
      instead of the normal user-space buffer.  This feature is used by OSS
      layer and UAC1 driver, for example.
      
      The __snd_pcm_lib_xfer() takes in_kernel argument that indicates the
      in-kernel buffer copy.  When this flag is set, another transfer code
      is used.  It's either via copy_kernel PCM ops or the normal memcpy(),
      depending on the driver setup.
      
      As external API, snd_pcm_kernel_read(), *_write() and other variants
      are provided.
      
      That's all.  This support is really simple because of the code
      refactoring until now.
      Reviewed-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      68541213
    • T
      ALSA: pcm: Unify read/write loop · 5c7264cf
      Takashi Iwai 提交于
      Both __snd_pcm_lib_read() and __snd_pcm_write() functions have almost
      the same code to loop over samples.  For simplification, this patch
      unifies both as the single helper, __snd_pcm_lib_xfer().
      
      Other than that, there should be no functional change by this patch.
      Reviewed-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      5c7264cf
    • T
      ALSA: pcm: Call directly the common read/write helpers · c48f12ee
      Takashi Iwai 提交于
      Make snd_pcm_lib_read() and *_write() static inline functions that
      call the common helper functions directly.  This reduces a slight
      amount of codes, and at the same time, it's a preparation for the
      further cleanups / fixes.
      Reviewed-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      c48f12ee
    • T
      ALSA: pcm: Drop the old copy and silence ops · 2ae48354
      Takashi Iwai 提交于
      Now that all users of old copy and silence ops have been converted to
      the new PCM ops, the old stuff can be retired and go away.
      Reviewed-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      2ae48354
    • T
      ALSA: pcm: Introduce copy_user, copy_kernel and fill_silence ops · 29d1a873
      Takashi Iwai 提交于
      For supporting the explicit in-kernel copy of PCM buffer data, and
      also for further code refactoring, three new PCM ops, copy_user,
      copy_kernel and fill_silence, are introduced.  The old copy and
      silence ops will be deprecated and removed later once when all callers
      are converted.
      
      The copy_kernel ops is the new one, and it's supposed to transfer the
      PCM data from the given kernel buffer to the hardware ring-buffer (or
      vice-versa depending on the stream direction), while the copy_user ops
      is equivalent with the former copy ops, to transfer the data from the
      user-space buffer.
      
      The major difference of the new copy_* and fill_silence ops from the
      previous ops is that the new ops take bytes instead of frames for size
      and position arguments.  It has two merits: first, it allows the
      callback implementation often simpler (just call directly memcpy() &
      co), and second, it may unify the implementations of both interleaved
      and non-interleaved cases, as we'll see in the later patch.
      
      As of this stage, copy_kernel ops isn't referred yet, but only
      copy_user is used.
      Reviewed-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Acked-by: NMark Brown <broonie@kernel.org>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      29d1a873
  26. 26 5月, 2017 1 次提交
  27. 17 5月, 2017 3 次提交