1. 04 7月, 2012 1 次提交
    • T
      ALSA: hda - Remove beep_mode=2 · 0920c9b4
      Takashi Iwai 提交于
      The beep_mode=2 option was introduced to make the beep mixer
      controlling the beep input allocation/deallocation dynamically, so
      that a user can switch between HD-audio codec digital beep and the
      system beep only via mixer API.  This was necessary because the
      keyboard driver took only the first input beep instance at that time.
      
      However, the recent keyboard driver already processes the multiple
      input instances, thus there is no point to keep this mode.
      
      Let's remove it.
      Acked-by: NJaroslav Kysela <perex@perex.cz>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      0920c9b4
  2. 18 6月, 2012 1 次提交
    • D
      ALSA: hda - Handle open while transitioning to D3. · b4a91cf0
      Dylan Reid 提交于
      This addresses an issue encountered when a pcm is opened while
      transitioning to low power state (codec->power_on == 1 &&
      codec->power_transition == -1).  Add snd_pcm_power_up_d3wait to
      hda_codec.  This function is used to power up from azx_open as opposed
      to snd_hda_power_up used from codec_exec_verb. When powering up from
      azx_open, wait for pending power downs to complete, avoiding the power
      up continuing in parallel with the power down on the work queue.
      
      The specific issue seen was with the CS4210 codec, it powers off the ADC
      and DAC nid in its suspend handler.  If it is re-opened before the
      ~100ms power down process completes, the ADC and DAC nid are initialized
      while powered down and audio is lost until another suspend/resume cycle.
      Signed-off-by: NDylan Reid <dgreid@chromium.org>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      b4a91cf0
  3. 11 6月, 2012 1 次提交
  4. 08 6月, 2012 2 次提交
    • S
      ALSA: hda - HDMI Audio init all connectors when VGA-switcheroo is off · 8393ec4a
      Steven Newbury 提交于
      When VGA_SWITCHEROO support is enabled hda_intel initialises the HDMI
      audio device on the current VGA device.  When it's not enabled it only
      initialises the HDMI device on the default VGA adaptor, this means
      secondary cards get no audio support which is very unhelpful for
      multi-seat!
      
      With this patch, when SUPPORT_VGA_SWITCHEROO is disabled hda_intel
      initialises all HDMI audio devices, not just the default VGA.
      
      [minor optimizations by tiwai]
      Signed-off-by: NSteven Newbury <steve@snewbury.org.uk>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      8393ec4a
    • T
      ALSA: hda - Fix uninitialized HDMI controllers with VGA-switcheroo · 12b78a7f
      Takashi Iwai 提交于
      When VGA-switcheroo is built in but unused on systems with multiple
      graphics cards, the initializations of non-default graphics cards are
      skipped and never enabled (because the switcheroo is activated only
      when the controller supports).  The current behavior is for avoiding
      the system lockup by accessing the disabled GPU, but due to the recent
      change in VGA-switcheroo, it determines the state simply by checking
      with the default VGA device.  This is the culprit.
      
      Now with the new vga_switcheroo_get_client_state(), we can know the
      initial state of the bound GPU, thus can determine the initial audio
      client state more correctly.
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      12b78a7f
  5. 18 5月, 2012 1 次提交
  6. 15 5月, 2012 1 次提交
  7. 14 5月, 2012 2 次提交
  8. 10 5月, 2012 1 次提交
  9. 09 5月, 2012 2 次提交
    • D
      ALSA: HDA: Lessen CPU usage when waiting for chip to respond · 32cf4023
      David Henningsson 提交于
      When an IRQ for some reason gets lost, we wait up to a second using
      udelay, which is CPU intensive. This patch improves the situation by
      waiting about 30 ms in the CPU intensive mode, then stepping down to
      using msleep(2) instead. In essence, we trade some granularity in
      exchange for less CPU consumption when the waiting time is a bit longer.
      
      As a result, PulseAudio should no longer be killed by the kernel
      for taking up to much RT-prio CPU time. At least not for *this* reason.
      Signed-off-by: NDavid Henningsson <david.henningsson@canonical.com>
      Tested-by: NArun Raghavan <arun.raghavan@collabora.co.uk>
      Cc: <stable@kernel.org>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      32cf4023
    • T
      ALSA: hda - Always resume the codec immediately · 7f30830b
      Takashi Iwai 提交于
      This is a fix for the problem in commit 785f857d, the pop noise
      issue on some machines with ALC269.  The problem was the uninitialized
      state after the resume due to the delayed resume of the codec chips.
      In that commit, we tried to fix by forcibly putting the codec to D3 at
      suspend.  But, this still also leaves the uninitialized state after
      resume, and it _might_ be still problematic with some BIOS.  Since the
      commit turned out to regress another issues, we reverted it in the
      end.
      
      Now, in this fix, try to fix by turning on the codec immediately at
      the resume path.  We need to take care of the power-saving in this
      case.  When the device is woken up at the power-saved state, it should
      go power-saving again after the resume.
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      7f30830b
  10. 08 5月, 2012 1 次提交
    • T
      Revert "ALSA: hda - Set codec to D3 forcibly even if not used" · 619a341b
      Takashi Iwai 提交于
      This reverts commit 785f857d.
      
      The commit causes a problem with the wrong D3 state after suspend
      because the call of hda_set_power_state() involves with the power-up
      sequence, which changes the power_count, and this confuses the resume
      sequence that checks the power_count as well.
      
      Originally, this go-to-D3 sequence should be a simple task without the
      power-up sequence.  But, it'd need some proper sanity checks in the
      case of power-saved state, so it's not too easy to write now in the
      3.4-rc cycle.
      
      In short, the safest option now is to revert this affecting commit.
      
      Of course, we need to clean up and robustify the power-saving code
      better for 3.5 kernel.
      Reported-by: NKonstantin Khlebnikov <khlebnikov@openvz.org>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      619a341b
  11. 24 4月, 2012 1 次提交
  12. 07 3月, 2012 1 次提交
    • T
      ALSA: hda - Set codec to D3 forcibly even if not used · 785f857d
      Takashi Iwai 提交于
      We've seen a problem with a pop-noise at suspend/resume on a HP
      machine with ALC269, and it turned out to be an issue that the
      controller going to D3 while the codec is unused.
      
      When the device is once suspended and resumed and kept unused, the
      driver doesn't initialize the codecs.  Instead, the codec chips are
      set up dynamically at the first usage.  Now, suppose the device going
      to suspend again before the codec is set up.  The controller is turned
      off to D3 while the codec chips are untouched.  This caused a pop
      noise because the codec chip might have been turned on implicitly by
      the hardware.
      
      As a workaround, the codec chip needs to be set to D3 when going to
      suspend no matter whether it was used or not.  Also, for making it
      happening, the controller has to be always set up in the resume path.
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      785f857d
  13. 28 2月, 2012 1 次提交
  14. 08 2月, 2012 1 次提交
  15. 24 1月, 2012 2 次提交
  16. 20 1月, 2012 1 次提交
  17. 13 1月, 2012 1 次提交
  18. 08 1月, 2012 2 次提交
  19. 01 1月, 2012 1 次提交
  20. 19 12月, 2011 1 次提交
  21. 15 12月, 2011 1 次提交
  22. 14 12月, 2011 2 次提交
  23. 12 12月, 2011 1 次提交
  24. 29 11月, 2011 1 次提交
    • M
      ALSA: hda_intel - revert a quirk that affect VIA chipsets · 4f8b6c7d
      Marc Vertes 提交于
      This quirk sould be reverted. It has the following probems:
      
      1) The quirk was intended to "ASUS MV2-MX SE" motherboards only, but the
      ID used matches a much broader range, potentially all boards containing a
      VIA chipset model in the family of vendor VIA 0x1106 and audio device ID
      0x3288, which encompasses VIA-VT82xx, VIA-VT1xx and VIA-VT20xx chipsets.
      
      2) VIA chipsets rely on azx_via_get_position() to handle correctly dma
      transfers during capture. Using POS_FIX_LPIB instead of POS_FIX_VIACOMBO
      leads to partially corrupted input buffers during capture. The effects
      of this bug are not immediately visible, it took strong DSP expertise,
      some expensive signal generator and a spectrum analyzer to identify it
      and verify correct behaviour using original default.
      
      3) It's almost certain that the quirk did not fix the real problem,
      if there was one. Refer to original submission:
      http://mailman.alsa-project.org/pipermail/alsa-devel/2010-February/025109.htmlSigned-of-by: NMarc Vertes <mvertes@sigfox.com>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      4f8b6c7d
  25. 26 11月, 2011 1 次提交
    • T
      ALSA: hda - Supports more audio streams · 01b65bfb
      Takashi Iwai 提交于
      So far, the driver supports up to 10 streams.  This is a restriction in
      hda_intel.c and hda_codec.c: in the former, the fixed array size limits
      the amount, and in the latter, the fixed device-number assignment table
      (in get_empty_pcm_device()) limits the possibility.
      
      This patch reduces the restriction by
      - using linked list for managing PCM instances in hda_intel.c, and
      - assigning non-fixed device numbers for the extra devices
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      01b65bfb
  26. 06 11月, 2011 1 次提交
  27. 18 10月, 2011 1 次提交
  28. 06 10月, 2011 1 次提交
    • T
      ALSA: hda - Distinguish each substream for better sticky assignment · d5cf9911
      Takashi Iwai 提交于
      The commit ef18bede introduced a
      mechanism to assign the previously used slot for the next reopen of a
      PCM stream.  But the PCM device number isn't always unique (it may
      have multiple substreams), and also the code doesn't check the stream
      direction, thus both playback and capture streams share the same
      device number.
      
      For avoiding this conflict, make a unique key for each substream and
      store/check this value at reopening.
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      d5cf9911
  29. 30 9月, 2011 1 次提交
  30. 29 9月, 2011 1 次提交
    • T
      ALSA: hda - Add snoop option · 27fe48d9
      Takashi Iwai 提交于
      Added a new option "snoop" for the traffic control of the HD-audio
      controller chip.  When set to 0, the non-snooping mode is used with
      the traffic control bit is set in each stream control register.
      This may allow better operations in the low power mode, but the actual
      implementation is depending pretty much on the chipset.
      
      As already implemented, more or less each chipset has own snoop-control
      register bit.  Now this setup refers to the snoop option, too.
      
      Also, a new VIA chipset may require the non-snooping mode when set so
      in BIOS.  In such a case, the option value is overridden.
      
      As default, it's still set to snoop=1 for keeping the same behavior as
      before.  In near future, it'll be set to 0 as default after checking
      it works in every system well.
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      27fe48d9
  31. 04 8月, 2011 1 次提交
  32. 12 7月, 2011 1 次提交
  33. 18 6月, 2011 1 次提交
  34. 10 6月, 2011 1 次提交