1. 06 12月, 2018 1 次提交
  2. 14 11月, 2018 2 次提交
  3. 13 9月, 2018 1 次提交
    • T
      ALSA: hda - Enable runtime PM only for discrete GPU · 37a3a98e
      Takashi Iwai 提交于
      The recent change of vga_switcheroo allowed the runtime PM for
      HD-audio on AMD GPUs, but this also resulted in a regression.  When
      the HD-audio controller driver gets runtime-suspended, HD-audio link
      is turned off, and the hotplug notification is ignored.  This leads to
      the inconsistent audio state (the connection isn't notified and ELD is
      ignored).
      
      The best fix would be to implement the proper ELD notification via the
      audio component, but it's still not ready.  As a quick workaround,
      this patch adds the check of runtime_idle and allows the runtime
      suspend only when the vga_switcheroo is bound with discrete GPU.
      That is, a system with a single GPU and APU would be again without
      runtime PM to keep the HD-audio link for the hotplug notification and
      ELD read out.
      
      Also, the codec->auto_runtime_pm flag is set only for the discrete GPU
      at the time GPU gets bound via vga_switcheroo (i.e. only dGPU is
      forcibly runtime-PM enabled), so that APU can still get the ELD
      notification.
      
      For identifying which GPU is bound, a new vga_switcheroo client
      callback, gpu_bound, is implemented.  The vga_switcheroo simply calls
      this when GPU is bound, and tells whether it's dGPU or APU.
      
      Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=200945
      Fixes: 07f4f97d ("vga_switcheroo: Use device link for HDA controller")
      Reported-by: NJian-Hong Pan <jian-hong@endlessm.com>
      Tested-by: NJian-Hong Pan <jian-hong@endlessm.com>
      Acked-by: NLukas Wunner <lukas@wunner.de>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      37a3a98e
  4. 02 8月, 2018 1 次提交
  5. 17 7月, 2018 1 次提交
    • J
      vga_switcheroo: set audio client id according to bound GPU id · 4aaf448f
      Jim Qu 提交于
      On modern laptop, there are more and more platforms
      have two GPUs, and each of them maybe have audio codec
      for HDMP/DP output. For some dGPU which is no output,
      audio codec usually is disabled.
      
      In currect HDA audio driver, it will set all codec as
      VGA_SWITCHEROO_DIS, the audio which is binded to UMA
      will be suspended if user use debugfs to contorl power
      
      In HDA driver side, it is difficult to know which GPU
      the audio has binded to. So set the bound gpu pci dev
      to vga_switcheroo.
      
      if the audio client is not the third registration, audio
      id will set in vga_switcheroo enable function. if the
      audio client is the last registration when vga_switcheroo
      _ready() get true, we should get audio client id from bound
      GPU directly.
      Signed-off-by: NJim Qu <Jim.Qu@amd.com>
      Reviewed-by: NLukas Wunner <lukas@wunner.de>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      4aaf448f
  6. 16 7月, 2018 1 次提交
  7. 28 6月, 2018 1 次提交
  8. 29 5月, 2018 1 次提交
  9. 23 5月, 2018 4 次提交
  10. 13 5月, 2018 1 次提交
  11. 16 4月, 2018 1 次提交
  12. 30 3月, 2018 1 次提交
  13. 21 3月, 2018 1 次提交
    • T
      ALSA: hda - Force polling mode on CFL for fixing codec communication · a8d7bde2
      Takashi Iwai 提交于
      We've observed too long probe time with Coffee Lake (CFL) machines,
      and the likely cause is some communication problem between the
      HD-audio controller and the codec chips.  While the controller expects
      an IRQ wakeup for each codec response, it seems sometimes missing, and
      it takes one second for the controller driver to time out and read the
      response in the polling mode.
      
      Although we aren't sure about the real culprit yet, in this patch, we
      put a workaround by forcing the polling mode as default for CFL
      machines; the polling mode itself isn't too heavy, and much better
      than other workarounds initially suggested (e.g. disabling
      power-save), at least.
      
      Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=199007
      Fixes: e79b0006 ("ALSA: hda - Add Coffelake PCI ID")
      Reported-and-tested-by: NHui Wang <hui.wang@canonical.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      a8d7bde2
  14. 14 3月, 2018 1 次提交
    • L
      vga_switcheroo: Use device link for HDA controller · 07f4f97d
      Lukas Wunner 提交于
      Back in 2013, runtime PM for GPUs with integrated HDA controller was
      introduced with commits 0d69704a ("gpu/vga_switcheroo: add driver
      control power feature. (v3)") and 246efa4a ("snd/hda: add runtime
      suspend/resume on optimus support (v4)").
      
      Briefly, the idea was that the HDA controller is forced on and off in
      unison with the GPU.
      
      The original code is mostly still in place even though it was never a
      100% perfect solution:  E.g. on access to the HDA controller, the GPU
      is powered up via vga_switcheroo_runtime_resume_hdmi_audio() but there
      are no provisions to keep it resumed until access to the HDA controller
      has ceased:  The GPU autosuspends after 5 seconds, rendering the HDA
      controller inaccessible.
      
      Additionally, a kludge is required when hda_intel.c probes:  It has to
      check whether the GPU is powered down (check_hdmi_disabled()) and defer
      probing if so.
      
      However in the meantime (in v4.10) the driver core has gained a feature
      called device links which promises to solve such issues in a clean way:
      It allows us to declare a dependency from the HDA controller (consumer)
      to the GPU (supplier).  The PM core then automagically ensures that the
      GPU is runtime resumed as long as the HDA controller's ->probe hook is
      executed and whenever the HDA controller is accessed.
      
      By default, the HDA controller has a dependency on its parent, a PCIe
      Root Port.  Adding a device link creates another dependency on its
      sibling:
      
                                  PCIe Root Port
                                   ^          ^
                                   |          |
                                   |          |
                                  HDA  ===>  GPU
      
      The device link is not only used for runtime PM, it also guarantees that
      on system sleep, the HDA controller suspends before the GPU and resumes
      after the GPU, and on system shutdown the HDA controller's ->shutdown
      hook is executed before the one of the GPU.  It is a complete solution.
      
      Using this functionality is as simple as calling device_link_add(),
      which results in a dmesg entry like this:
      
              pci 0000:01:00.1: Linked as a consumer to 0000:01:00.0
      
      The code for the GPU-governed audio power management can thus be removed
      (except where it's still needed for legacy manual power control).
      
      The device link is added in a PCI quirk rather than in hda_intel.c.
      It is therefore legal for the GPU to runtime suspend to D3cold even if
      the HDA controller is not bound to a driver or if CONFIG_SND_HDA_INTEL
      is not enabled, for accesses to the HDA controller will cause the GPU to
      wake up regardless if they're occurring outside of hda_intel.c (think
      config space readout via sysfs).
      
      Contrary to the previous implementation, the HDA controller's power
      state is now self-governed, rather than GPU-governed, whereas the GPU's
      power state is no longer fully self-governed.  (The HDA controller needs
      to runtime suspend before the GPU can.)
      
      It is thus crucial that runtime PM is always activated on the HDA
      controller even if CONFIG_SND_HDA_POWER_SAVE_DEFAULT is set to 0 (which
      is the default), lest the GPU stays awake.  This is achieved by setting
      the auto_runtime_pm flag on every codec and the AZX_DCAPS_PM_RUNTIME
      flag on the HDA controller.
      
      A side effect is that power consumption might be reduced if the GPU is
      in use but the HDA controller is not, because the HDA controller is now
      allowed to go to D3hot.  Before, it was forced to stay in D0 as long as
      the GPU was in use.  (There is no reduction in power consumption on my
      Nvidia GK107, but there might be on other chips.)
      
      The code paths for legacy manual power control are adjusted such that
      runtime PM is disabled during power off, thereby preventing the PM core
      from resuming the HDA controller.
      
      Note that the device link is not only added on vga_switcheroo capable
      systems, but for *any* GPU with integrated HDA controller.  The idea is
      that the HDA controller streams audio via connectors located on the GPU,
      so the GPU needs to be on for the HDA controller to do anything useful.
      
      This commit implicitly fixes an unbalanced runtime PM ref upon unbind of
      hda_intel.c:  On ->probe, a runtime PM ref was previously released under
      the condition "azx_has_pm_runtime(chip) || hda->use_vga_switcheroo", but
      on ->remove a runtime PM ref was only acquired under the first of those
      conditions.  Thus, binding and unbinding the driver twice on a
      vga_switcheroo capable system caused the runtime PM refcount to drop
      below zero.  The issue is resolved because the AZX_DCAPS_PM_RUNTIME flag
      is now always set if use_vga_switcheroo is true.
      
      For more information on device links please refer to:
      https://www.kernel.org/doc/html/latest/driver-api/device_link.html
      Documentation/driver-api/device_link.rst
      
      Cc: Dave Airlie <airlied@redhat.com>
      Cc: Ben Skeggs <bskeggs@redhat.com>
      Cc: Alex Deucher <alexander.deucher@amd.com>
      Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: NBjorn Helgaas <bhelgaas@google.com>
      Reviewed-by: NTakashi Iwai <tiwai@suse.de>
      Reviewed-by: NPeter Wu <peter@lekensteyn.nl>
      Tested-by: Kai Heng Feng <kai.heng.feng@canonical.com> # AMD PowerXpress
      Tested-by: Mike Lothian <mike@fireburn.co.uk>          # AMD PowerXpress
      Tested-by: Denis Lisov <dennis.lissov@gmail.com>       # Nvidia Optimus
      Tested-by: Peter Wu <peter@lekensteyn.nl>              # Nvidia Optimus
      Tested-by: Lukas Wunner <lukas@wunner.de>              # MacBook Pro
      Signed-off-by: NLukas Wunner <lukas@wunner.de>
      Link: https://patchwork.freedesktop.org/patch/msgid/51bd38360ff502a8c42b1ebf4405ee1d3f27118d.1520068884.git.lukas@wunner.de
      07f4f97d
  15. 13 3月, 2018 1 次提交
  16. 12 3月, 2018 1 次提交
    • T
      ALSA: hda - Revert power_save option default value · 40088dc4
      Takashi Iwai 提交于
      With the commit 1ba8f9d3 ("ALSA: hda: Add a power_save
      blacklist"), we changed the default value of power_save option to -1
      for processing the power-save blacklist.
      Unfortunately, this seems breaking user-space applications that
      actually read the power_save parameter value via sysfs and judge /
      adjust the power-saving status.  They see the value -1 as if the
      power-save is turned off, although the actual value is taken from
      CONFIG_SND_HDA_POWER_SAVE_DEFAULT and it can be a positive.
      
      So, overall, passing -1 there was no good idea.  Let's partially
      revert it -- at least for power_save option default value is restored
      again to CONFIG_SND_HDA_POWER_SAVE_DEFAULT.  Meanwhile, in this patch,
      we keep the blacklist behavior and make is adjustable via the new
      option, pm_blacklist.
      
      Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=199073
      Fixes: 1ba8f9d3 ("ALSA: hda: Add a power_save blacklist")
      Acked-by: NHans de Goede <hdegoede@redhat.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      40088dc4
  17. 24 2月, 2018 1 次提交
    • H
      ALSA: hda: Add a power_save blacklist · 1ba8f9d3
      Hans de Goede 提交于
      On some boards setting power_save to a non 0 value leads to clicking /
      popping sounds when ever we enter/leave powersaving mode. Ideally we would
      figure out how to avoid these sounds, but that is not always feasible.
      
      This commit adds a blacklist for devices where powersaving is known to
      cause problems and disables it on these devices.
      
      Note I tried to put this blacklist in userspace first:
      https://github.com/systemd/systemd/pull/8128
      
      But the systemd maintainers rightfully pointed out that it would be
      impossible to then later remove entries once we actually find a way to
      make power-saving work on listed boards without issues. Having this list
      in the kernel will allow removal of the blacklist entry in the same commit
      which fixes the clicks / plops.
      
      The blacklist only applies to the default power_save module-option value,
      if a user explicitly sets the module-option then the blacklist is not
      used.
      
      [ added an ifdef CONFIG_PM for the build error -- tiwai]
      
      BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1525104
      BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=198611
      Cc: stable@vger.kernel.org
      Signed-off-by: NHans de Goede <hdegoede@redhat.com>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      1ba8f9d3
  18. 23 11月, 2017 1 次提交
  19. 07 8月, 2017 1 次提交
  20. 04 7月, 2017 1 次提交
  21. 30 6月, 2017 1 次提交
    • T
      ALSA: hda - Fix doubly initialization of i915 component · dba9b7b6
      Takashi Iwai 提交于
      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: NMartin Peres <martin.peres@free.fr>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      dba9b7b6
  22. 28 6月, 2017 1 次提交
    • T
      ALSA: hda - Bind with i915 component before codec binding · fcc88d91
      Takashi Iwai 提交于
      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: NTakashi Iwai <tiwai@suse.de>
      fcc88d91
  23. 20 6月, 2017 2 次提交
    • T
      ALSA: hda - Add AZX_DRIVER_SKL for simplification · a4b4793f
      Takashi Iwai 提交于
      We checked the quirks specific to the recent Intel chips by checking
      the PCI IDs manually, but it's becoming messy with lots of IS_SKL()
      and other macros, as the amount accumulated.
      
      For simplification, here the new AZX_DRIVER_SKL type is introduced,
      and check chip->driver_type instead of the manual PCI ID.  The short
      name for this is still "HDA Intel PCH", so that it doesn't break the
      existing user-space unnecessarily.
      Suggested-by: NVinod Koul <vinod.koul@intel.com>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      a4b4793f
    • T
      ALSA: hda - Apply quirks to Broxton-T, too · c7ecb906
      Takashi Iwai 提交于
      Broxton-T was a forgotten child and we didn't apply the quirks for
      Skylake+ properly.  Meanwhile, a quirk for reducing the DMA latency
      seems specific to the early Broxton model, so we leave as is.
      
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      c7ecb906
  24. 14 6月, 2017 1 次提交
  25. 09 5月, 2017 1 次提交
  26. 12 4月, 2017 1 次提交
  27. 07 4月, 2017 1 次提交
  28. 03 4月, 2017 2 次提交
  29. 25 2月, 2017 1 次提交
  30. 16 2月, 2017 2 次提交
  31. 15 1月, 2017 1 次提交
    • T
      ALSA: hda - Make single_cmd option to stop the fallback mechanism · 41438f13
      Takashi Iwai 提交于
      HD-audio driver has a mechanism to fall back to the single cmd mode as
      a last resort if the CORB/RIRB communication goes wrong even after
      switching to the polling mode.  The switching has worked in the past
      well, but Enrico Mioso reported that his system crashes when this
      happens.
      
      Although the actual cause of the crash isn't still fully analyzed yet,
      it'd be in anyway good to provide an option to turn off the fallback
      mode.  Now this patch extends the behavior of the existing single_cmd
      option for that.  Namely,
      
      - The option is changed from bool to bint.
      - As default, it is the mode allowing the fallback to single cmd.
      - Once when either true/false value is given to the option, the driver
        explicitly turns on/off the single cmd mode, but without the
        fallback.
      
      That is, if you want to disable the fallback, just pass single_cmd=0
      option.  Passing single_cmd=1 will keep working like before.
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      41438f13
  32. 04 1月, 2017 1 次提交
    • T
      ALSA: hda - Fix deadlock of controller device lock at unbinding · ab949d51
      Takashi Iwai 提交于
      Imre Deak reported a deadlock of HD-audio driver at unbinding while
      it's still in probing.  Since we probe the codecs asynchronously in a
      work, the codec driver probe may still be kicked off while the
      controller itself is being unbound.  And, azx_remove() tries to
      process all pending tasks via cancel_work_sync() for fixing the other
      races (see commit [0b8c8219: ALSA: hda - Cancel probe work instead
      of flush at remove]), now we may meet a bizarre deadlock:
      
      Unbind snd_hda_intel via sysfs:
        device_release_driver() ->
          device_lock(snd_hda_intel) ->
            azx_remove() ->
              cancel_work_sync(azx_probe_work)
      
      azx_probe_work():
        codec driver probe() ->
           __driver_attach() ->
             device_lock(snd_hda_intel)
      
      This deadlock is caused by the fact that both device_release_driver()
      and driver_probe_device() take both the device and its parent locks at
      the same time.  The codec device sets the controller device as its
      parent, and this lock is taken before the probe() callback is called,
      while the controller remove() callback gets called also with the same
      lock.
      
      In this patch, as an ugly workaround, we unlock the controller device
      temporarily during cancel_work_sync() call.  The race against another
      bind call should be still suppressed by the parent's device lock.
      Reported-by: NImre Deak <imre.deak@intel.com>
      Fixes: 0b8c8219 ("ALSA: hda - Cancel probe work instead of flush at remove")
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      ab949d51
  33. 18 10月, 2016 1 次提交
    • A
      ALSA: hda - allow 40 bit DMA mask for NVidia devices · 3ab7511e
      Ard Biesheuvel 提交于
      Commit 49d9e77e ("ALSA: hda - Fix system panic when DMA > 40 bits
      for Nvidia audio controllers") simply disabled any DMA exceeding 32
      bits for NVidia devices, even though they are capable of performing
      DMA up to 40 bits. On some architectures (such as arm64), system memory
      is not guaranteed to be 32-bit addressable by PCI devices, and so this
      change prevents NVidia devices from working on platforms such as AMD
      Seattle.
      
      Since the original commit already mentioned that up to 40 bits of DMA
      is supported, and given that the code has been updated in the meantime
      to support a 40 bit DMA mask on other devices, revert commit 49d9e77e
      and explicitly set the DMA mask to 40 bits for NVidia devices.
      
      Fixes: 49d9e77e ('ALSA: hda - Fix system panic when DMA > 40 bits...')
      Signed-off-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      3ab7511e