This project is mirrored from https://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-rt-devel.git. Pull mirroring updated .
  1. 17 Apr, 2018 1 commit
  2. 13 Mar, 2018 1 commit
  3. 10 Jan, 2018 1 commit
    • Takashi Iwai's avatar
      ALSA: pcm: Remove yet superfluous WARN_ON() · 23b19b7b
      Takashi Iwai authored
      
      
      muldiv32() contains a snd_BUG_ON() (which is morphed as WARN_ON() with
      debug option) for checking the case of 0 / 0.  This would be helpful
      if this happens only as a logical error; however, since the hw refine
      is performed with any data set provided by user, the inconsistent
      values that can trigger such a condition might be passed easily.
      Actually, syzbot caught this by passing some zero'ed old hw_params
      ioctl.
      
      So, having snd_BUG_ON() there is simply superfluous and rather
      harmful to give unnecessary confusions.  Let's get rid of it.
      
      Reported-by: default avatar <syzbot+7e6ee55011deeebce15d@syzkaller.appspotmail.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      23b19b7b
  4. 02 Jan, 2018 2 commits
    • Takashi Iwai's avatar
      ALSA: pcm: Set config update bits only when really changed · 7a0a8716
      Takashi Iwai authored
      
      
      The PCM config space refine codes touch the parameter rmask and cmask
      bits when the given config parameter is changed.  But in most places
      it checks only whether the changed value is non-zero or not, and they
      don't consider whether a negative error value is returned.  This will
      lead to the incorrect update bits set upon the error path.
      
      Fix the codes to check properly the return code whether it's really
      updated or an error.
      
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      7a0a8716
    • Takashi Iwai's avatar
      ALSA: pcm: Remove incorrect snd_BUG_ON() usages · fe08f34d
      Takashi Iwai authored
      
      
      syzkaller triggered kernel warnings through PCM OSS emulation at
      closing a stream:
        WARNING: CPU: 0 PID: 3502 at sound/core/pcm_lib.c:1635
        snd_pcm_hw_param_first+0x289/0x690 sound/core/pcm_lib.c:1635
        Call Trace:
        ....
         snd_pcm_hw_param_near.constprop.27+0x78d/0x9a0 sound/core/oss/pcm_oss.c:457
         snd_pcm_oss_change_params+0x17d3/0x3720 sound/core/oss/pcm_oss.c:969
         snd_pcm_oss_make_ready+0xaa/0x130 sound/core/oss/pcm_oss.c:1128
         snd_pcm_oss_sync+0x257/0x830 sound/core/oss/pcm_oss.c:1638
         snd_pcm_oss_release+0x20b/0x280 sound/core/oss/pcm_oss.c:2431
         __fput+0x327/0x7e0 fs/file_table.c:210
         ....
      
      This happens while it tries to open and set up the aloop device
      concurrently.  The warning above (invoked from snd_BUG_ON() macro) is
      to detect the unexpected logical error where snd_pcm_hw_refine() call
      shouldn't fail.  The theory is true for the case where the hw_params
      config rules are static.  But for an aloop device, the hw_params rule
      condition does vary dynamically depending on the connected target;
      when another device is opened and changes the parameters, the device
      connected in another side is also affected, and it caused the error
      from snd_pcm_hw_refine().
      
      That is, the simplest "solution" for this is to remove the incorrect
      assumption of static rules, and treat such an error as a normal error
      path.  As there are a couple of other places using snd_BUG_ON()
      incorrectly, this patch removes these spurious snd_BUG_ON() calls.
      
      Reported-by: default avatar <syzbot+6f11c7e2a1b91d466432@syzkaller.appspotmail.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      fe08f34d
  5. 21 Nov, 2017 1 commit
    • Henrik Eriksson's avatar
      ALSA: pcm: update tstamp only if audio_tstamp changed · 20e3f985
      Henrik Eriksson authored
      commit 3179f620 ("ALSA: core: add .get_time_info") had a side effect
      of changing the behaviour of the PCM runtime tstamp.  Prior to this
      change tstamp was not updated by snd_pcm_update_hw_ptr0() unless the
      hw_ptr had moved, after this change tstamp was always updated.
      
      For an application using alsa-lib, doing snd_pcm_readi() followed by
      snd_pcm_status() to estimate the age of the read samples by subtracting
      status->avail * [sample rate] from status->tstamp this change degraded
      the accuracy of the estimate on devices where the pcm hw does not
      provide a granular hw_ptr, e.g., devices using
      soc-generic-dmaengine-pcm.c and a dma-engine with residue_granularity
      DMA_RESIDUE_GRANULARITY_DESCRIPTOR.  The accuracy of the estimate
      depended on the latency between the PCM hw completing a period and the
      driver called snd_pcm_period_elapsed() to notify ALSA core, typically
      determined by interrupt handling latency.  After the change the accuracy
      of the estimate depended on the latency between the PCM hw completing a
      period and the application calling snd_pcm_status(), determined by the
      scheduling of the application process.  The maximum error of the
      estimate is one period length in both cases, but the error average and
      variance is smaller when it depends on interrupt latency.
      
      Instead of always updating tstamp, update it only if audio_tstamp
      changed.
      
      Fixes: 3179f620
      
       ("ALSA: core: add .get_time_info")
      Suggested-by: default avatarPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
      Signed-off-by: default avatarHenrik Eriksson <henrik.eriksson@axis.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      20e3f985
  6. 20 Jun, 2017 2 commits
    • 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: default avatarIngo Molnar <mingo@kernel.org>
      ac6424b9
    • Takashi Iwai's avatar
      ALSA: pcm: Fix possible inconsistent appl_ptr update via mmap · aa30db06
      Takashi Iwai authored
      
      
      The ALSA PCM core refers to the appl_ptr value stored on the mmapped
      page that is shared between kernel and user-space.  Although the
      reference is performed in the PCM stream lock, it doesn't guarantee
      the atomic access when the value gets updated concurrently from the
      user-space on another CPU.
      
      In most of codes, this is no big problem, but still there are a few
      places that may result in slight inconsistencies because they access
      runtime->control->appl_ptr multiple times; that is, the second read
      might be a different value from the first value.  It can be even
      backward or jumping, as we have no control for it.  Hence, the
      calculation may give an unexpected value.  Luckily, there is no
      security vulnerability by that, as far as I've checked.  But still we
      should address it.
      
      This patch tries to reduce such possible cases.  The fix is simple --
      we just read once, store it to a local variable and use it for the
      rest calculations.  The READ_ONCE() macro is used for it in order to
      avoid the ill-effect by possible compiler optimizations.
      
      Reviewed-by: default avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      aa30db06
  7. 16 Jun, 2017 1 commit
  8. 14 Jun, 2017 3 commits
    • Takashi Iwai's avatar
      ALSA: pcm: Don't treat NULL chmap as a fatal error · 2deaeaf1
      Takashi Iwai authored
      
      
      The standard PCM chmap helper callbacks treat the NULL info->chmap as
      a fatal error and spews the kernel warning with stack trace when
      CONFIG_SND_DEBUG is on.  This was OK, originally it was supposed to be
      always static and non-NULL.  But, as the recent addition of Intel LPE
      audio driver shows, the chmap content may vary dynamically, and it can
      be even NULL when disconnected.  The user still sees the kernel
      warning unnecessarily.
      
      For clearing such a confusion, this patch simply removes the
      snd_BUG_ON() in each place, just returns an error without warning.
      
      Cc: <stable@vger.kernel.org> # v4.11+
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      2deaeaf1
    • Takashi Sakamoto's avatar
      ALSA: pcm: remove SNDRV_PCM_IOCTL1_INFO internal command · e11f0f90
      Takashi Sakamoto authored
      
      
      Drivers can implement 'struct snd_pcm_ops.ioctl' to handle some requests
      from ALSA PCM core. These requests are internal purpose in kernel land.
      Usually common set of operations are used for it.
      
      SNDRV_PCM_IOCTL1_INFO is one of the requests. According to code comment,
      it has been obsoleted in the old days.
      
      We can see old releases in ftp.alsa-project.org. The command was firstly
      introduced in v0.5.0 release as SND_PCM_IOCTL1_INFO, to allow drivers to
      fill data of 'struct snd_pcm_channel_info' type. In v0.9.0 release,
      this was obsoleted by the other commands for ioctl(2) such as
      SNDRV_PCM_IOCTL_CHANNEL_INFO.
      
      This commit removes the long-abandoned command, bye.
      
      Signed-off-by: default avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      e11f0f90
    • Takashi Iwai's avatar
      ALSA: pcm: Skip ack callback without actual appl_ptr update · f8ff2f28
      Takashi Iwai authored
      
      
      We call ack callback whenever appl_ptr gets updated via
      pcm_lib_apply_appl_ptr().  There are various code paths to call this
      function.  A part of them are for read/write/forward/rewind, where the
      appl_ptr is always changed and thus the call of ack is mandatory.
      OTOH, another part of code paths are from the explicit user call,
      e.g. via SYNC_PTR ioctl.  There, we may receive the same appl_ptr
      value, and in such a case, calling ack is obviously superfluous.
      
      This patch adds the check of the given appl_ptr value, and returns
      immediately if it's no real update.
      
      Reviewed-by: default avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      f8ff2f28
  9. 12 Jun, 2017 2 commits
    • Takashi Sakamoto's avatar
      ALSA: pcm: add 'applptr' event of tracepoint · fccf5388
      Takashi Sakamoto authored
      
      
      In design of ALSA PCM core, status and control data for runtime of ALSA
      PCM substream are shared between kernel/user spaces by page frame
      mapping with read-only attribute. Both of hardware-side and
      application-side position on PCM buffer are maintained as a part of
      the status data. In a view of ALSA PCM application, these two positions
      can be updated by executing ioctl(2) with some commands.
      
      There's an event of tracepoint for hardware-side position; 'hwptr'.
      On the other hand, no events for application-side position. This commit
      adds a new event for this purpose; 'applptr'. When the application-side
      position is changed in kernel space, this event is probed with useful
      information for developers.
      
      I note that the event is not probed for all of ALSA PCM applications, When
      applications are written by read/write programming scenario, the event is
      surely probed. The applications execute ioctl(2) with
      SNDRV_PCM_IOCTL_[READ|WRITE][N/I]_FRAMES to read/write any PCM frame, then
      ALSA PCM core updates the application-side position in kernel land.
      However, when applications are written by mmap programming scenario, if
      maintaining the application side position in kernel space accurately,
      applications should voluntarily execute ioctl(2) with
      SNDRV_PCM_IOCTL_SYNC_PTR to commit the number of handled PCM frames. If
      not voluntarily, the application-side position is not changed, thus the
      added event is not probed.
      
      There's a loophole, using architectures to which ALSA PCM core judges
      non cache coherent. In this case, the status and control data is not mapped
      into processe's VMA for any applications. Userland library, alsa-lib, is
      programmed for this case. It executes ioctl(2) with
      SNDRV_PCM_IOCTL_SYNC_PTR command every time to requiring the status and
      control data.
      
      ARM is such an architecture. Below is an example with serial sound interface
      (ssi) on i.mx6 quad core SoC. I use v4.1 kernel released by fsl-community
      with patches from VIA Tech. Inc. for VAB820, and my backport patches for
      relevant features for this patchset. I use Ubuntu 17.04 from
      ports.ubuntu.com as user land for armhf architecture.
      
      $ aplay -v -M -D hw:imx6vab820sgtl5,0 /dev/urandom -f S16_LE -r 48000 --period-size=128 --buffer-size=256
      Playing raw data '/dev/urandom' : Signed 16 bit Little Endian, Rate 48000 Hz, Mono
      Hardware PCM card 0 'imx6-vab820-sgtl5000' device 0 subdevice 0
      Its setup is:
        stream       : PLAYBACK
        access       : MMAP_INTERLEAVED
        format       : S16_LE
        subformat    : STD
        channels     : 1
        rate         : 48000
        exact rate   : 48000 (48000/1)
        msbits       : 16
        buffer_size  : 256
        period_size  : 128
        period_time  : 2666
        tstamp_mode  : NONE
        tstamp_type  : MONOTONIC
        period_step  : 1
        avail_min    : 128
        period_event : 0
        start_threshold  : 256
        stop_threshold   : 256
        silence_threshold: 0
        silence_size : 0
        boundary     : 1073741824
        appl_ptr     : 0
        hw_ptr       : 0
      mmap_area[0] = 0x76f98000,0,16 (16)
      
      $ trace-cmd record -e snd_pcm:hwptr -e snd_pcm:applptr
      $ trace-cmd report
      ...
      60.208495: applptr: pcmC0D0p/sub0: prev=1792, curr=1792, avail=0, period=128, buf=256
      60.208633: applptr: pcmC0D0p/sub0: prev=1792, curr=1792, avail=0, period=128, buf=256
      60.210022: hwptr:   pcmC0D0p/sub0: IRQ: pos=128, old=1536, base=1536, period=128, buf=256
      60.210202: applptr: pcmC0D0p/sub0: prev=1792, curr=1792, avail=128, period=128, buf=256
      60.210344: hwptr:   pcmC0D0p/sub0: POS: pos=128, old=1664, base=1536, period=128, buf=256
      60.210348: applptr: pcmC0D0p/sub0: prev=1792, curr=1792, avail=128, period=128, buf=256
      60.210486: applptr: pcmC0D0p/sub0: prev=1792, curr=1792, avail=128, period=128, buf=256
      60.210626: applptr: pcmC0D0p/sub0: prev=1792, curr=1920, avail=0, period=128, buf=256
      60.211002: applptr: pcmC0D0p/sub0: prev=1920, curr=1920, avail=0, period=128, buf=256
      60.211142: hwptr:   pcmC0D0p/sub0: POS: pos=128, old=1664, base=1536, period=128, buf=256
      60.211146: applptr: pcmC0D0p/sub0: prev=1920, curr=1920, avail=0, period=128, buf=256
      60.211287: applptr: pcmC0D0p/sub0: prev=1920, curr=1920, avail=0, period=128, buf=256
      60.212690: hwptr:   pcmC0D0p/sub0: IRQ: pos=0, old=1664, base=1536, period=128, buf=256
      60.212866: applptr: pcmC0D0p/sub0: prev=1920, curr=1920, avail=128, period=128, buf=256
      60.212999: hwptr:   pcmC0D0p/sub0: POS: pos=0, old=1792, base=1792, period=128, buf=256
      60.213003: applptr: pcmC0D0p/sub0: prev=1920, curr=1920, avail=128, period=128, buf=256
      60.213135: applptr: pcmC0D0p/sub0: prev=1920, curr=1920, avail=128, period=128, buf=256
      60.213276: applptr: pcmC0D0p/sub0: prev=1920, curr=2048, avail=0, period=128, buf=256
      60.213654: applptr: pcmC0D0p/sub0: prev=2048, curr=2048, avail=0, period=128, buf=256
      60.213796: hwptr:   pcmC0D0p/sub0: POS: pos=0, old=1792, base=1792, period=128, buf=256
      60.213800: applptr: pcmC0D0p/sub0: prev=2048, curr=2048, avail=0, period=128, buf=256
      60.213937: applptr: pcmC0D0p/sub0: prev=2048, curr=2048, avail=0, period=128, buf=256
      60.215356: hwptr:   pcmC0D0p/sub0: IRQ: pos=128, old=1792, base=1792, period=128, buf=256
      60.215542: applptr: pcmC0D0p/sub0: prev=2048, curr=2048, avail=128, period=128, buf=256
      60.215679: hwptr:   pcmC0D0p/sub0: POS: pos=128, old=1920, base=1792, period=128, buf=256
      60.215683: applptr: pcmC0D0p/sub0: prev=2048, curr=2048, avail=128, period=128, buf=256
      60.215813: applptr: pcmC0D0p/sub0: prev=2048, curr=2048, avail=128, period=128, buf=256
      60.215947: applptr: pcmC0D0p/sub0: prev=2048, curr=2176, avail=0, period=128, buf=256
      ...
      
      We can surely see 'applptr' event is probed even if the application run
      for mmap programming scenario ('-M' option and 'hw' plugin). Below is a
      result of strace:
      
      02:44:15.886382 ioctl(4, SNDRV_PCM_IOCTL_SYNC_PTR, 0x56a32b30) = 0
      02:44:15.887203 poll([{fd=4, events=POLLOUT|POLLERR|POLLNVAL}], 1, -1) = 1 ([{fd=4, revents=POLLOUT}])
      02:44:15.887471 ioctl(4, SNDRV_PCM_IOCTL_SYNC_PTR, 0x56a32b30) = 0
      02:44:15.887637 ioctl(4, SNDRV_PCM_IOCTL_SYNC_PTR, 0x56a32b30) = 0
      02:44:15.887805 ioctl(4, SNDRV_PCM_IOCTL_SYNC_PTR, 0x56a32b30) = 0
      02:44:15.887969 ioctl(4, SNDRV_PCM_IOCTL_SYNC_PTR, 0x56a32b30) = 0
      02:44:15.888132 read(3, "..."..., 256) = 256
      02:44:15.889040 ioctl(4, SNDRV_PCM_IOCTL_SYNC_PTR, 0x56a32b30) = 0
      02:44:15.889221 ioctl(4, SNDRV_PCM_IOCTL_SYNC_PTR, 0x56a32b30) = 0
      02:44:15.889431 ioctl(4, SNDRV_PCM_IOCTL_SYNC_PTR, 0x56a32b30) = 0
      02:44:15.889606 poll([{fd=4, events=POLLOUT|POLLERR|POLLNVAL}], 1, -1) = 1 ([{fd=4, revents=POLLOUT}])
      02:44:15.889833 ioctl(4, SNDRV_PCM_IOCTL_SYNC_PTR, 0x56a32b30) = 0
      02:44:15.889998 ioctl(4, SNDRV_PCM_IOCTL_SYNC_PTR, 0x56a32b30) = 0
      02:44:15.890164 ioctl(4, SNDRV_PCM_IOCTL_SYNC_PTR, 0x56a32b30) = 0
      02:44:15.891048 ioctl(4, SNDRV_PCM_IOCTL_SYNC_PTR, 0x56a32b30) = 0
      02:44:15.891228 read(3, "..."..., 256) = 256
      02:44:15.891497 ioctl(4, SNDRV_PCM_IOCTL_SYNC_PTR, 0x56a32b30) = 0
      02:44:15.891661 ioctl(4, SNDRV_PCM_IOCTL_SYNC_PTR, 0x56a32b30) = 0
      02:44:15.891829 ioctl(4, SNDRV_PCM_IOCTL_SYNC_PTR, 0x56a32b30) = 0
      02:44:15.891991 poll([{fd=4, events=POLLOUT|POLLERR|POLLNVAL}], 1, -1) = 1 ([{fd=4, revents=POLLOUT}])
      02:44:15.893007 ioctl(4, SNDRV_PCM_IOCTL_SYNC_PTR, 0x56a32b30) = 0
      
      We can see 7 calls of ioctl(2) with SNDRV_PCM_IOCTL_SYNC_PTR per loop with
      call of poll(2). 128 PCM frames are transferred per loop of one poll(2),
      because the PCM substream is configured with S16_LE format and 1 channel
      (2 byte * 1 * 128 = 256 bytes). This equals to the size of period of PCM
      buffer. Comparing to the probed data, one of the 7 calls of ioctl(2) is
      actually used to commit the number of copied PCM frames to kernel space.
      The other calls are just used to check runtime status of PCM substream;
      e.g. XRUN.
      
      The tracepoint event is useful to investigate this case. I note that below
      modules are related to the above sample.
      
       * snd-soc-dummy.ko
       * snd-soc-imx-sgtl5000.ko
       * snd-soc-fsl-ssi.ko
       * snd-soc-imx-pcm-dma.ko
       * snd-soc-sgtl5000.ko
      
      My additional note is lock acquisition. The event is probed under acquiring
      PCM stream lock. This means that calculation in the event is free from
      any hardware events.
      
      Signed-off-by: default avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      fccf5388
    • Takashi Sakamoto's avatar
      ALSA: pcm: unify codes to operate application-side position on PCM buffer · 66e01a5c
      Takashi Sakamoto authored
      
      
      In a series of recent work, ALSA PCM core got some arrangements to handle
      application-side position on PCM buffer. However, relevant codes still
      disperse to two translation units
      
      This commit unifies these codes into a helper function.
      
      Signed-off-by: default avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      66e01a5c
  10. 09 Jun, 2017 1 commit
  11. 02 Jun, 2017 9 commits
  12. 26 May, 2017 1 commit
  13. 17 May, 2017 2 commits
  14. 02 Mar, 2017 1 commit
  15. 10 May, 2016 1 commit
    • Takashi Iwai's avatar
      ALSA: pcm: Bail out when chmap is already present · 8d879be8
      Takashi Iwai authored
      
      
      When snd_pcm_add_chmap_ctls() is called to the PCM stream to which a
      chmap has been already assigned, it returns as an error due to the
      conflicting snd_ctl_add() result.  However, this also clears the
      already assigned chmap_kctl field via pcm_chmap_ctl_private_free(),
      and becomes inconsistent in the later operation.
      
      This patch adds the check of the conflicting chmap kctl before
      actually trying to allocate / assign.  The check failure is treated as
      a kernel warning, as the double call of snd_pcm_add_chmap_ctls() is
      basically a driver bug and having the stack trace would help
      developers to figure out the bad code path.
      
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      8d879be8
  16. 14 Apr, 2016 1 commit
    • Takashi Iwai's avatar
      ALSA: pcm : Call kill_fasync() in stream lock · 3aa02cb6
      Takashi Iwai authored
      
      
      Currently kill_fasync() is called outside the stream lock in
      snd_pcm_period_elapsed().  This is potentially racy, since the stream
      may get released even during the irq handler is running.  Although
      snd_pcm_release_substream() calls snd_pcm_drop(), this doesn't
      guarantee that the irq handler finishes, thus the kill_fasync() call
      outside the stream spin lock may be invoked after the substream is
      detached, as recently reported by KASAN.
      
      As a quick workaround, move kill_fasync() call inside the stream
      lock.  The fasync is rarely used interface, so this shouldn't have a
      big impact from the performance POV.
      
      Ideally, we should implement some sync mechanism for the proper finish
      of stream and irq handler.  But this oneliner should suffice for most
      cases, so far.
      
      Reported-by: default avatarBaozeng Ding <sploving1@gmail.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      3aa02cb6
  17. 10 Mar, 2016 1 commit
    • Takashi Iwai's avatar
      ALSA: pcm: Avoid "BUG:" string for warnings again · 0ab1ace8
      Takashi Iwai authored
      The commit [d507941b
      
      : ALSA: pcm: Correct PCM BUG error message]
      made the warning prefix back to "BUG:" due to its previous wrong
      prefix.  But a kernel message containing "BUG:" seems taken as an Oops
      message wrongly by some brain-dead daemons, and it annoys users in the
      end.  Instead of teaching daemons, change the string again to a more
      reasonable one.
      
      Fixes: 507941beb1e ('ALSA: pcm: Correct PCM BUG error message')
      Cc: <stable@vger.kernel.org> # v3.19+
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      0ab1ace8
  18. 28 Oct, 2015 1 commit
  19. 22 Oct, 2015 1 commit
  20. 16 Oct, 2015 1 commit
  21. 19 May, 2015 1 commit
    • Koro Chen's avatar
      ALSA: pcm: Modify double acknowledged interrupts check condition · 13a98839
      Koro Chen authored
      
      
      Currently in snd_pcm_update_hw_ptr0 during interrupt,
      we consider there were double acknowledged interrupts when:
      1. HW reported pointer is smaller than expected, and
      2. Time from last update time (hdelta) is over half a buffer time.
      
      However, when HW reported pointer is only a few bytes smaller than
      expected, and when hdelta is just a little larger than half a buffer time
      (e.g. ping-pong buffer), it wrongly treats this IRQ as double acknowledged.
      
      The condition #2 uses jiffies, but jiffies is not high resolution
      since it is integer. We should consider jiffies inaccuracy.
      
      Signed-off-by: default avatarKoro Chen <koro.chen@mediatek.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      13a98839
  22. 20 Feb, 2015 1 commit
  23. 28 Jan, 2015 1 commit
  24. 30 Dec, 2014 2 commits
    • Lars-Peter Clausen's avatar
      ALSA: Add support for wildcard msbits constraints · 8ef9df55
      Lars-Peter Clausen authored
      
      
      Currently the msbits constraints requires to specify a specific sample
      format width for which the constraint should be applied. But often the
      number of most significant bits is not sample format specific, but rather a
      absolute limit. E.g. the PCM interface might accept 32-bit and 24-bit
      samples, but the DAC has a 16-bit resolution and throws away the LSBs. In
      this case for both 32-bit and 24-bit format msbits should be set to 16. This
      patch extends snd_pcm_hw_constraint_msbits() so that a wildcard constraint
      can be setup that is applied for all formats with a sample width larger than
      the specified msbits. Choosing the wildcard constraint is done by setting
      the sample width parameter of the function to 0.
      
      Signed-off-by: default avatarLars-Peter Clausen <lars@metafoo.de>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      8ef9df55
    • Lars-Peter Clausen's avatar
      ALSA: Fix handling of multiple msbits constraints on the same runtime · 19f52fae
      Lars-Peter Clausen authored
      
      
      If the sound card is made up of discrete components, each with their own
      driver (e.g. like in the ASoC case), we might end up with multiple msbits
      constraint rules installed. Currently this will result in msbits being set
      to whatever the last rule set it to.
      
      This patch updates the behavior of the rule to choose the minimum (other
      than zero) of all the installed rules.
      
      Signed-off-by: default avatarLars-Peter Clausen <lars@metafoo.de>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      19f52fae
  25. 04 Nov, 2014 1 commit
    • Takashi Iwai's avatar
      ALSA: pcm: Replace PCM hwptr tracking with tracepoints · f5914908
      Takashi Iwai authored
      
      
      ALSA PCM core has a mechanism tracking the PCM hwptr updates for
      analyzing XRUNs.  But its log is limited (up to 10) and its log output
      is a kernel message, which is hard to handle.
      
      In this patch, the hwptr logging is moved to the tracing
      infrastructure instead of its own.  Not only the hwptr updates but
      also XRUN and hwptr errors are recorded on the trace log, so that user
      can see such events at the exact timing.
      
      The new "snd_pcm" entry will appear in the tracing events:
        # ls -F /sys/kernel/debug/tracing/events/snd_pcm
        enable  filter  hw_ptr_error/  hwptr/  xrun/
      
      The hwptr is for the regular hwptr update events.  An event trace
      looks like:
      
        aplay-26187 [004] d..3  4012.834761: hwptr: pcmC0D0p/sub0: POS: pos=488, old=0, base=0, period=1024, buf=16384
      
      "POS" shows the hwptr update by the explicit position update call and
      "IRQ" means the hwptr update by the interrupt,
      i.e. snd_pcm_period_elapsed() call.  The "pos" is the passed
      ring-buffer offset by the caller, "old" is the previous hwptr, "base"
      is the hwptr base position, "period" and "buf" are period- and
      buffer-size of the target PCM substream.
      (Note that the hwptr position displayed here isn't the ring-buffer
       offset.  It increments up to the PCM position boundary.)
      
      The XRUN event appears similarly, but without "pos" field.
      The hwptr error events appear with the PCM identifier and its reason
      string, such as "Lost interrupt?".
      
      The XRUN and hwptr error reports on kernel message are still left, can
      be turned on/off via xrun_debug proc like before.  But the bit 3, 4, 5
      and 6 bits of xrun_debug proc are dropped by this patch.  Also, along
      with the change, the message strings have been reformatted to be a bit
      more consistent.
      
      Last but not least, the hwptr reporting is enabled only when
      CONFIG_SND_PCM_XRUN_DEBUG is set.
      
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      f5914908