1. 30 Jun, 2017 1 commit
    • Takashi Iwai's avatar
      ALSA: hda - Fix doubly initialization of i915 component · dba9b7b6
      Takashi Iwai authored
      In the commit fcc88d91 ("ALSA: hda - Bind with i915 component
      before codec binding"), the binding with i915 audio component is moved
      to be performed always at probing the controller.  This fixed the
      potential problems on IVB, but now it brought another issue on HSW and
      BDW.  These two platforms give two individual HD-audio controllers,
      one for the analog codec on PCH and another for HDMI over gfx.  Since
      I decided to take a lazy path to check only AZX_DRIVER_PCH type in the
      commit above, now both controllers try to bind with i915, and you see
      a kernel WARNING.
      
      This patch tries to address it again properly.  Now a new DCAPS bit,
      AZX_DCAPS_I915_COMPONENT, is introduced for indicating the binding
      with i915 component in addition to the existing I915_POWERWELL bit
      flag.  Each PCI entry has to give this new flag if it requires the
      binding with i915 component.  For HSW/BDW PCH (i.e. the ones defined
      by AZX_DCAPS_INTEL_PCH) doesn't contain AZX_DCAPS_I915_COMPONENT bit
      while others have it.
      
      While we're at it, add parentheses around the bit flag check for
      avoiding possible compiler warnings, too.
      
      The bug was spotted by Intel CI tests.
      
      Fixes: fcc88d91 ("ALSA: hda - Bind with i915 component before codec binding")
      Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=196219Reported-by: default avatarMartin Peres <martin.peres@free.fr>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      dba9b7b6
  2. 29 Jun, 2017 3 commits
  3. 28 Jun, 2017 7 commits
    • Takashi Iwai's avatar
      Merge branch 'topic/hda-fix' into for-next · 4032da5f
      Takashi Iwai authored
      4032da5f
    • Takashi Iwai's avatar
      ALSA: hda - Minor code refactoring for Intel HDMI codec parsers · 43f6c8d9
      Takashi Iwai authored
      No functional change, just a slight reduction of lines.
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      43f6c8d9
    • Takashi Iwai's avatar
      ALSA: hda - Bind with i915 component before codec binding · fcc88d91
      Takashi Iwai authored
      We used a on-demand i915 component binding for IvyBridge and
      SandyBridge HDMI codecs, but it has a potential problem of the nested
      module loading.  For avoiding that situation, assure the i915 binding
      happening at the controller driver level for PCH controller devices,
      where the initialization is performed in a detached work, instead of
      calling from the codec driver probe.
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      fcc88d91
    • Takashi Iwai's avatar
      ALSA: hda - Skip card registration when no codec is found · 17890880
      Takashi Iwai authored
      It's nonsense to register a card object when no codec is bound on it,
      as we don't support the deferred codec binding.  Instead of
      registering an empty card object, just skip the registration by
      returning an error from azx_codec_configure().
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      17890880
    • Takashi Iwai's avatar
      ALSA: hda - Fix endless loop of codec configure · d94815f9
      Takashi Iwai authored
      azx_codec_configure() loops over the codecs found on the given
      controller via a linked list.  The code used to work in the past, but
      in the current version, this may lead to an endless loop when a codec
      binding returns an error.
      
      The culprit is that the snd_hda_codec_configure() unregisters the
      device upon error, and this eventually deletes the given codec object
      from the bus.  Since the list is initialized via list_del_init(), the
      next object points to the same device itself.  This behavior change
      was introduced at splitting the HD-audio code code, and forgotten to
      adapt it here.
      
      For fixing this bug, just use a *_safe() version of list iteration.
      
      Fixes: d068ebc2 ("ALSA: hda - Move some codes up to hdac_bus struct")
      Reported-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      d94815f9
    • Takashi Iwai's avatar
      ALSA: Fix forgotten dependency fix for tristate OSS sequencer kconfig · f03293d8
      Takashi Iwai authored
      In the commit 3d774d5e ("ALSA: seq: Allow the tristate build of
      OSS emulation") we changed CONFIG_SND_SEQUENCER_OSS to tristate, but a
      couple of places were forgotten, namely, opl3 and emux Makefile.
      These contain the line like
        snd-opl3-synth-$(CONFIG_SND_SEQUENCER_OSS) += opl3_oss.o
      and this doesn't work any longer as expected because snd-opl3-synth
      can be built-in while CONFIG_SND_SEQUENCER_OSS=m.
      
      This patch fixes these places to build properly for the new kconfig
      dependency.  In the end, we had to use ifneq() to satisfy the
      requirement.  It's a bit ugly, but lesser evil.
      
      Fixes: 3d774d5e ("ALSA: seq: Allow the tristate build of OSS emulation")
      Reported-by: default avatarkbuild test robot <fengguang.wu@intel.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      f03293d8
    • Hui Wang's avatar
      ALSA: hda - set input_path bitmap to zero after moving it to new place · a8f20fd2
      Hui Wang authored
      Recently we met a problem, the codec has valid adcs and input pins,
      and they can form valid input paths, but the driver does not build
      valid controls for them like "Mic boost", "Capture Volume" and
      "Capture Switch".
      
      Through debugging, I found the driver needs to shrink the invalid
      adcs and input paths for this machine, so it will move the whole
      column bitmap value to the previous column, after moving it, the
      driver forgets to set the original column bitmap value to zero, as a
      result, the driver will invalidate the path whose index value is the
      original colume bitmap value. After executing this function, all
      valid input paths are invalidated by a mistake, there are no any
      valid input paths, so the driver won't build controls for them.
      
      Fixes: 3a65bcdc ("ALSA: hda - Fix inconsistent input_paths after ADC reduction")
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarHui Wang <hui.wang@canonical.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      a8f20fd2
  4. 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: default avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Signed-off-by: default 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: default avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      4b671f57
  5. 26 Jun, 2017 1 commit
    • Hui Wang's avatar
      ALSA: hda/realtek - There is no loopback mixer in the ALC234/274/294 · 532a7784
      Hui Wang authored
      We have a Lenovo machine with the codec ALC294 on it, without the
      patch, the Node 0x0b is regarded as the loopback mixer, but the Node
      0x0b in this codec is "Vendor Defined Widget" instead of the audio
      mixer, please see the log below:
      
      Node 0x0b [Vendor Defined Widget] wcaps 0xf00000: Mono
        Control: name="Beep Playback Volume", index=0, device=0
          ControlAmp: chs=3, dir=In, idx=4, ofs=0
        Control: name="Beep Playback Switch", index=0, device=0
          ControlAmp: chs=3, dir=In, idx=4, ofs=0
      
      And I have consulted with Realtek, so far the ALC234/274/294 all don't
      have loopback mixer.
      
      Cc: Kailang Yang <kailang@realtek.com>
      Signed-off-by: default avatarHui Wang <hui.wang@canonical.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      532a7784
  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: default avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      42f94597
  7. 21 Jun, 2017 1 commit
  8. 20 Jun, 2017 8 commits
  9. 19 Jun, 2017 1 commit
    • Takashi Sakamoto's avatar
      ALSA: firewire-lib: Fix stall of process context at packet error · 4a9bfafc
      Takashi Sakamoto authored
      At Linux v3.5, packet processing can be done in process context of ALSA
      PCM application as well as software IRQ context for OHCI 1394. Below is
      an example of the callgraph (some calls are omitted).
      
      ioctl(2) with e.g. HWSYNC
      (sound/core/pcm_native.c)
      ->snd_pcm_common_ioctl1()
        ->snd_pcm_hwsync()
          ->snd_pcm_stream_lock_irq
          (sound/core/pcm_lib.c)
          ->snd_pcm_update_hw_ptr()
            ->snd_pcm_udpate_hw_ptr0()
              ->struct snd_pcm_ops.pointer()
              (sound/firewire/*)
              = Each handler on drivers in ALSA firewire stack
                (sound/firewire/amdtp-stream.c)
                ->amdtp_stream_pcm_pointer()
                  (drivers/firewire/core-iso.c)
                  ->fw_iso_context_flush_completions()
                    ->struct fw_card_driver.flush_iso_completion()
                    (drivers/firewire/ohci.c)
                    = flush_iso_completions()
                      ->struct fw_iso_context.callback.sc
                      (sound/firewire/amdtp-stream.c)
                      = in_stream_callback() or out_stream_callback()
                        ->...
          ->snd_pcm_stream_unlock_irq
      
      When packet queueing error occurs or detecting invalid packets in
      'in_stream_callback()' or 'out_stream_callback()', 'snd_pcm_stop_xrun()'
      is called on local CPU with disabled IRQ.
      
      (sound/firewire/amdtp-stream.c)
      in_stream_callback() or out_stream_callback()
      ->amdtp_stream_pcm_abort()
        ->snd_pcm_stop_xrun()
          ->snd_pcm_stream_lock_irqsave()
          ->snd_pcm_stop()
          ->snd_pcm_stream_unlock_irqrestore()
      
      The process is stalled on the CPU due to attempt to acquire recursive lock.
      
      [  562.630853] INFO: rcu_sched detected stalls on CPUs/tasks:
      [  562.630861]      2-...: (1 GPs behind) idle=37d/140000000000000/0 softirq=38323/38323 fqs=7140
      [  562.630862]      (detected by 3, t=15002 jiffies, g=21036, c=21035, q=5933)
      [  562.630866] Task dump for CPU 2:
      [  562.630867] alsa-source-OXF R  running task        0  6619      1 0x00000008
      [  562.630870] Call Trace:
      [  562.630876]  ? vt_console_print+0x79/0x3e0
      [  562.630880]  ? msg_print_text+0x9d/0x100
      [  562.630883]  ? up+0x32/0x50
      [  562.630885]  ? irq_work_queue+0x8d/0xa0
      [  562.630886]  ? console_unlock+0x2b6/0x4b0
      [  562.630888]  ? vprintk_emit+0x312/0x4a0
      [  562.630892]  ? dev_vprintk_emit+0xbf/0x230
      [  562.630895]  ? do_sys_poll+0x37a/0x550
      [  562.630897]  ? dev_printk_emit+0x4e/0x70
      [  562.630900]  ? __dev_printk+0x3c/0x80
      [  562.630903]  ? _raw_spin_lock+0x20/0x30
      [  562.630909]  ? snd_pcm_stream_lock+0x31/0x50 [snd_pcm]
      [  562.630914]  ? _snd_pcm_stream_lock_irqsave+0x2e/0x40 [snd_pcm]
      [  562.630918]  ? snd_pcm_stop_xrun+0x16/0x70 [snd_pcm]
      [  562.630922]  ? in_stream_callback+0x3e6/0x450 [snd_firewire_lib]
      [  562.630925]  ? handle_ir_packet_per_buffer+0x8e/0x1a0 [firewire_ohci]
      [  562.630928]  ? ohci_flush_iso_completions+0xa3/0x130 [firewire_ohci]
      [  562.630932]  ? fw_iso_context_flush_completions+0x15/0x20 [firewire_core]
      [  562.630935]  ? amdtp_stream_pcm_pointer+0x2d/0x40 [snd_firewire_lib]
      [  562.630938]  ? pcm_capture_pointer+0x19/0x20 [snd_oxfw]
      [  562.630943]  ? snd_pcm_update_hw_ptr0+0x47/0x3d0 [snd_pcm]
      [  562.630945]  ? poll_select_copy_remaining+0x150/0x150
      [  562.630947]  ? poll_select_copy_remaining+0x150/0x150
      [  562.630952]  ? snd_pcm_update_hw_ptr+0x10/0x20 [snd_pcm]
      [  562.630956]  ? snd_pcm_hwsync+0x45/0xb0 [snd_pcm]
      [  562.630960]  ? snd_pcm_common_ioctl1+0x1ff/0xc90 [snd_pcm]
      [  562.630962]  ? futex_wake+0x90/0x170
      [  562.630966]  ? snd_pcm_capture_ioctl1+0x136/0x260 [snd_pcm]
      [  562.630970]  ? snd_pcm_capture_ioctl+0x27/0x40 [snd_pcm]
      [  562.630972]  ? do_vfs_ioctl+0xa3/0x610
      [  562.630974]  ? vfs_read+0x11b/0x130
      [  562.630976]  ? SyS_ioctl+0x79/0x90
      [  562.630978]  ? entry_SYSCALL_64_fastpath+0x1e/0xad
      
      This commit fixes the above bug. This assumes two cases:
      1. Any error is detected in software IRQ context of OHCI 1394 context.
      In this case, PCM substream should be aborted in packet handler. On the
      other hand, it should not be done in any process context. TO distinguish
      these two context, use 'in_interrupt()' macro.
      2. Any error is detect in process context of ALSA PCM application.
      In this case, PCM substream should not be aborted in packet handler
      because PCM substream lock is acquired. The task to abort PCM substream
      should be done in ALSA PCM core. For this purpose, SNDRV_PCM_POS_XRUN is
      returned at 'struct snd_pcm_ops.pointer()'.
      Suggested-by: default avatarClemens Ladisch <clemens@ladisch.de>
      Fixes: e9148ddd("ALSA: firewire-lib: flush completed packets when reading PCM position")
      Cc: <stable@vger.kernel.org> # 4.9+
      Signed-off-by: default avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      4a9bfafc
  10. 16 Jun, 2017 6 commits
  11. 14 Jun, 2017 9 commits