Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
1 年多 前同步成功

通知 160
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 16 7月, 2018 1 次提交
  3. 28 6月, 2018 1 次提交
  5. 29 5月, 2018 1 次提交
  7. 23 5月, 2018 4 次提交
  9. 13 5月, 2018 1 次提交
  11. 16 4月, 2018 1 次提交
  13. 30 3月, 2018 1 次提交
  15. 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
  17. 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
  19. 13 3月, 2018 1 次提交
  21. 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
  23. 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
  25. 23 11月, 2017 1 次提交
  27. 07 8月, 2017 1 次提交
  29. 04 7月, 2017 1 次提交
  31. 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
  33. 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
  35. 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
  37. 14 6月, 2017 1 次提交
  39. 09 5月, 2017 1 次提交
  41. 12 4月, 2017 1 次提交
  43. 07 4月, 2017 1 次提交
  45. 03 4月, 2017 2 次提交
  47. 25 2月, 2017 1 次提交
  49. 16 2月, 2017 2 次提交
  51. 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
  53. 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
  55. 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
  57. 10 8月, 2016 1 次提交
    • T
      ALSA: hda - Manage power well properly for resume · a52ff34e
      由 Takashi Iwai 提交于 
      For SKL and later Intel chips, we control the power well per codec
basis via link_power callback since the commit [03b135ce: ALSA:
hda - remove dependency on i915 power well for SKL].
However, there are a few exceptional cases where the gfx registers are
accessed from the audio driver: namely the wakeup override bit
toggling at (both system and runtime) resume.  This seems causing a
kernel warning when accessed during the power well down (and likely
resulting in the bogus register accesses).

This patch puts the proper power up / down sequence around the resume
code so that the wakeup bit is fiddled properly while the power is
up.  (The other callback, sync_audio_rate, is used only in the PCM
callback, so it's guaranteed in the power-on.)

Also, by this proper power up/down, the instantaneous flip of wakeup
bit in the resume callback that was introduced by the commit
[033ea349: ALSA: hda - Fix Skylake codec timeout] becomes
superfluous, as snd_hdac_display_power() already does it.  So we can
clean it up together.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96214
Fixes: 03b135ce ('ALSA: hda - remove dependency on i915 power well for SKL')
Cc: <stable@vger.kernel.org> # v4.2+
Tested-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      a52ff34e
  59. 09 8月, 2016 1 次提交
  61. 03 8月, 2016 1 次提交
  63. 12 7月, 2016 2 次提交
  65. 29 6月, 2016 1 次提交