Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 11 12月, 2018 3 次提交
    • T
      ALSA: hda/intel: Properly free the display power at error path · 457f3c86
      由 Takashi Iwai 提交于 
      When an error occurs in azx_probe_continue(), we should release the
display power.  However, the current code ignores it and releases the
display power only for HSW/BDW cases.  Fix it.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      457f3c86
    • T
      ALSA: hda/intel: Drop superfluous AZX_DCAPS_I915_POWERWELL checks · e454ff8e
      由 Takashi Iwai 提交于 
      snd_hdac_display_power() can be called even for a HDA controller
without DRM binding.  The same is true for other helpers,
snd_hdac_i915_set_bclk() and snd_hdac_set_codec_wakeup().
So all superfluous AZX_DCAPS_I915_POWERWELL  checks in hda_intel.c can
be dropped, and the definition of AZX_DCAPS_I915_POWERWELL itself can
be removed as well.  This simplifies the code a lot.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      e454ff8e
    • T
      ALSA: hda: Refactor display power management · 029d92c2
      由 Takashi Iwai 提交于 
      The current HD-audio code manages the DRM audio power via too complex
redirections, and this seems even still unbalanced in a corner case as
Intel DRM CI has been intermittently reporting.  This patch is a big
surgery for addressing the complexity and the possible unbalance.

Basically the patch changes the display PM in the following ways:

- Both HD-audio controller and codec drivers call a single helper,
  snd_hdac_display_power().  (Formerly, the display power control from
  a codec was done indirectly via link_power bus ops.)

- snd_hdac_display_power() receives the codec address index.  For
  turning on/off from the controller, pass HDA_CODEC_IDX_CONTROLLER.

- snd_hdac_display_power() doesn't manage refcounts any longer, but
  keeps the power status in bitmap.  If any of controller or codecs is
  turned on, the function updates the DRM power state via get_power()
  or put_power().

Also this refactor allows us more cleanup:

- The link_power bus ops is dropped, so there is no longer indirect
  management, as mentioned in the above.

- hdac_device link_power_control flag is moved to hda_codec
  display_power_control flag, as it's only for HDA legacy.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106525Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      029d92c2
  3. 09 12月, 2018 1 次提交
    • T
      ALSA: hda/intel: Refactoring PM code · 3baffc4a
      由 Takashi Iwai 提交于 
      Make unified suspend / resume helpers and call them from both the
runtime- and the system-PM callbacks for simplifying code.

There are slight changes of call orders, but there shouldn't be any
functional difference after refactoring.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      3baffc4a
  5. 29 11月, 2018 1 次提交
  7. 24 11月, 2018 1 次提交
  9. 16 10月, 2018 1 次提交
  11. 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
  13. 30 8月, 2018 2 次提交
  15. 29 8月, 2018 1 次提交
  17. 28 8月, 2018 3 次提交
    • T
      ALSA: hda: Remove substream allocation/free ops · 193c7e14
      由 Takashi Iwai 提交于 
      Since we dropped the memory page fiddling in the own allocators in
hda_intel.c, the substream allocation and free ops in both hda_intel.c
and hda_tegra.c became nothing but the simple calls of the standard
snd_pcm_lib helpers.  As both are identical, there is no longer need
for indirect calls via ops; it's a good opportunity for removing ops
and simplifying the codes.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      193c7e14
    • T
      ALSA: hda: Use new non-cached allocation for non-snoop mode · fc478143
      由 Takashi Iwai 提交于 
      Now the ALSA memory allocator helper supports the new non-cached
pages, let's use the new type, SNDRV_DMA_TYPE_DEV_UC_SG, for HD-audio
driver.  This allows us to reduce lots of codes.

As another positive side-effect by this patch, the long-standing issue
with non-snoop mode playing in the non-mmap mode is fixed.  The core
memalloc helper does the proper pgprot setup for non-cached pages for
vmap(), which was missing in the past.
Reported-and-tested-by: NHans Hu <HansHu@zhaoxin.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      fc478143
    • T
      ALSA: hda: Check the non-cached stream buffers more explicitly · 78c9be61
      由 Takashi Iwai 提交于 
      Introduce a new flag, uc_buffer, to indicate that the controller
requires the non-cached pages for stream buffers, either as a
chip-specific requirement or specified via snoop=0 option.
This improves the code-readability.

Also, this patch fixes the incorrect behavior for C-Media chip where
the stream buffers were never handled as non-cached due to the check
of driver_type even if you pass snoop=0 option.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      78c9be61
  19. 02 8月, 2018 1 次提交
  21. 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
  23. 16 7月, 2018 1 次提交
  25. 28 6月, 2018 1 次提交
  27. 29 5月, 2018 1 次提交
  29. 23 5月, 2018 4 次提交
  31. 13 5月, 2018 1 次提交
  33. 16 4月, 2018 1 次提交
  35. 30 3月, 2018 1 次提交
  37. 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
  39. 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
  41. 13 3月, 2018 1 次提交
  43. 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
  45. 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
  47. 23 11月, 2017 1 次提交
  49. 07 8月, 2017 1 次提交
  51. 04 7月, 2017 1 次提交
  53. 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
  55. 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
  57. 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
  59. 14 6月, 2017 1 次提交
  61. 09 5月, 2017 1 次提交