1. 03 5月, 2013 1 次提交
  2. 16 4月, 2013 1 次提交
  3. 09 4月, 2013 1 次提交
  4. 05 4月, 2013 1 次提交
  5. 04 4月, 2013 1 次提交
    • T
      Revert "ALSA: hda - Allow power_save_controller option override DCAPS" · 8fc24426
      Takashi Iwai 提交于
      This reverts commit 6ab31741.
      
      The commit [6ab31741: ALSA: hda - Allow power_save_controller option
      override DCAPS] changed the behavior of power_save_controller so that
      it can override the driver capability.  This assumed that this option
      is rarely changed dynamically unlike power_save option.  Too naive.
      
      It turned out that the user-space power-management tool tries to set
      power_save_controller option to 1 together with power_save option
      without knowing what's actually doing.  This enabled forcibly the
      runtime PM of the controller,  which is known to be broken om many
      chips thus disabled as default.
      
      So, the only sane fix is to revert this commit again.  It was intended
      to ease debugging/testing for runtime PM enablement, but obviously we
      need another way for it.
      
      Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=56171Reported-and-tested-by: NNikita Tsukanov <keks9n@gmail.com>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      8fc24426
  6. 21 3月, 2013 1 次提交
    • T
      ALSA: hda - Fix abuse of snd_hda_lock_devices() for DSP loader · eb49faa6
      Takashi Iwai 提交于
      The current DSP loader code abuses snd_hda_lock_devices() for ensuring
      the DSP loader not conflicting with the other normal operations.  But
      this trick obviously doesn't work for the PM resume since the streams
      are kept opened there where snd_hda_lock_devices() returns -EBUSY.
      That means we need another lock mechanism instead of abuse.
      
      This patch provides the new lock state to azx_dev.  Theoretically it's
      possible that the DSP loader conflicts with the stream that has been
      already assigned for another PCM.  If it's running, the DSP loader
      should simply fail.  If not -- it's the case for PM resume --, we
      should assign this stream temporarily to the DSP loader, and take it
      back to the PCM after finishing DSP loading.  If the PCM is operated
      during the DSP loading, it should get an error, too.
      Reported-and-tested-by: NDylan Reid <dgreid@chromium.org>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      eb49faa6
  7. 14 2月, 2013 1 次提交
  8. 10 2月, 2013 2 次提交
  9. 08 2月, 2013 1 次提交
  10. 01 2月, 2013 1 次提交
  11. 30 1月, 2013 1 次提交
  12. 29 1月, 2013 1 次提交
  13. 12 1月, 2013 1 次提交
    • T
      ALSA: hda - Check CORB overflow · 3bcce5c0
      Takashi Iwai 提交于
      Add an overflow check of CORB in HD-audio controller and codec drivers
      so that flood of sequential writes would work properly.
      In the controller side, add a check of CORB read-pointer to make
      returning -EAGAIN when it's full.  Meanwhile in the codec side, when
      -EAGAIN error is received, it retries the write after flushing the
      pending verbs (calling get_response() essentially does it).
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      3bcce5c0
  14. 09 1月, 2013 2 次提交
  15. 19 12月, 2012 1 次提交
  16. 12 12月, 2012 4 次提交
  17. 07 12月, 2012 2 次提交
  18. 05 12月, 2012 1 次提交
  19. 04 12月, 2012 1 次提交
    • T
      ALSA: hda - Fix yet another race of vga_switcheroo registration · f4c482a4
      Takashi Iwai 提交于
      The recent fix for vga switcheroo race in commit 128960a9 opened yet
      another race.  At the time the audio driver starts probing, user may
      turn off D-GPU off.  But at this moment, the audio driver still
      doesn't register the vga switcheroo client, thus the switching isn't
      notified.  Then the hardware gets off out of sudden, resulting in
      invalid reads and lots of "spurious response" error messages.
      
      For solving this situation, the following changes have been done in
      this patch:
      - Move again vga switcheroo registration to the very early stage of
        the probing; this also requires to set pci drvdata properly before
        registration
      - Introduce the completion to synchronize the driver probe at vga
        switcheroo callbacks; this assures that the whole probing finished
        before executing the callbacks
      Reported-by: NDaniel J Blueman <daniel@quora.org>
      Tested-by: NDaniel J Blueman <daniel@quora.org>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      f4c482a4
  20. 28 11月, 2012 1 次提交
  21. 23 11月, 2012 1 次提交
    • T
      ALSA: hda - Don't release firmware when CONFIG_PM is set · e39ae856
      Takashi Iwai 提交于
      The new firmware code tries to re-read the formerly read firmware
      files before suspend.  Thus it's wiser to keep the "patch" firmware in
      the driver for avoiding this unnecessary re-reading.
      
      Of course, this will consume a bit of memory for unused stuff, but
      the patch fw is supposed to be fairly small, so it's more benefit in
      the end.
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      e39ae856
  22. 20 11月, 2012 1 次提交
  23. 04 11月, 2012 1 次提交
  24. 30 10月, 2012 1 次提交
  25. 23 10月, 2012 1 次提交
  26. 22 10月, 2012 1 次提交
  27. 17 10月, 2012 2 次提交
  28. 15 10月, 2012 3 次提交
  29. 10 10月, 2012 1 次提交
    • T
      ALSA: hda - Remove AZX_DCAPS_POSFIX_COMBO · 7fd5b1eb
      Takashi Iwai 提交于
      It turned out that the COMBO position fix mode is rather more harmful,
      and it got reverted (with the replacement of runtime->delay
      calculation) recently.  Hence we can get rid of AZX_DCAPS_POSFIX_COMBO
      as well.
      
      It's still possible to pass this mode via position_fix module option,
      in case where this really helps on weird machines (who knows).
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      7fd5b1eb
  30. 22 9月, 2012 2 次提交