Skip to content

K
Kernel

openeuler / Kernel
接近 2 年 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 13 5月, 2018 5 次提交
  3. 02 5月, 2018 2 次提交
  5. 28 4月, 2018 1 次提交
  7. 25 4月, 2018 8 次提交
  9. 24 4月, 2018 2 次提交
  11. 19 4月, 2018 2 次提交
  13. 16 4月, 2018 5 次提交
    • T
      ALSA: emu10k1: Reduce GFP_ATOMIC allocation · 057666b6
      由 Takashi Iwai 提交于 
      The emu10k1 fx8010 code allocates each irq resource dynamically and
links to the list at PCM trigger callback.  Due to the nature of
trigger callback, the allocation is done with GFP_ATOMIC, hence it
may fail more often.  Moreover, the irq resource isn't big at all, and
using the kmalloc for this won't save many bytes, either.

This patch removes the dynamic allocation and embeds the irq resource
into struct snd_emu10k1_fx8010_pcm.irq field instead of keeping a
pointer.  As a result, it simplifies the code and removes the
unnecessary GFP_ATOMIC usage.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      057666b6
    • T
      ALSA: cmipci: Allocate with GFP_KERNEL instead of GFP_ATOMIC · 0be51680
      由 Takashi Iwai 提交于 
      save_mixer_state() is called in a sleepable context, so it's safe to
allocate with GFP_KERNEL instead of the current GFP_ATOMIC.  The
GFP_ATOMIC usage must have been based on an incorrect assumption in
the very old code base.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      0be51680
    • D
      ALSA: hda - New VIA controller suppor no-snoop path · af52f998
      由 David Wang 提交于 
      This patch is used to tell kernel that new VIA HDAC controller also
support no-snoop path.

[ minor coding style fix by tiwai ]
Signed-off-by: NDavid Wang <davidwang@zhaoxin.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      af52f998
    • J
      ALSA: ad1889: Replace mdelay with usleep_range in snd_ad1889_ac97_ready · 1fa350b6
      由 Jia-Ju Bai 提交于 
      snd_ad1889_ac97_ready() is never called in atomic context.

The call chain ending up at snd_ad1889_ac97_ready() is:
[1] snd_ad1889_ac97_ready() <- snd_ad1889_ac97_xinit() <-
	snd_ad1889_ac97_init() <- snd_ad1889_probe()

snd_ad1889_probe() is only set as ".probe" in struct pci_driver.
This function is not called in atomic context.

Despite never getting called from atomic context, snd_ad1889_ac97_ready()
calls mdelay for busy wait.
This is not necessary and can be replaced with usleep_range to
avoid busy waiting.

This is found by a static analysis tool named DCNS written by myself.
Signed-off-by: NJia-Ju Bai <baijiaju1990@gmail.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      1fa350b6
    • J
      ALSA: ad1889: Replace mdelay with usleep_range in snd_ad1889_init · 621fdf60
      由 Jia-Ju Bai 提交于 
      snd_ad1889_init() is never called in atomic context.

The call chain ending up at snd_ad1889_init() is:
[1] snd_ad1889_init() <- snd_ad1889_create() <- snd_ad1889_probe()

snd_ad1889_probe() is only set as ".probe" in struct pci_driver.
This function is not called in atomic context.

Despite never getting called from atomic context, snd_ad1889_init()
calls mdelay for busy wait.
This is not necessary and can be replaced with usleep_range to
avoid busy waiting.

This is found by a static analysis tool named DCNS written by myself.
Signed-off-by: NJia-Ju Bai <baijiaju1990@gmail.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      621fdf60
  15. 30 3月, 2018 1 次提交
  17. 22 3月, 2018 2 次提交
  19. 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
  21. 18 3月, 2018 1 次提交
    • T
      ALSA: hda/realtek - Always immediately update mute LED with pin VREF · e40bdb03
      由 Takashi Iwai 提交于 
      Some HP laptops have a mute mute LED controlled by a pin VREF.  The
Realtek codec driver updates the VREF via vmaster hook by calling
snd_hda_set_pin_ctl_cache().

This works fine as long as the driver is running in a normal mode.
However, when the VREF change happens during the codec being in
runtime PM suspend, the regmap access will skip and postpone the
actual register change.  This ends up with the unchanged LED status
until the next runtime PM resume even if you change the Master mute
switch.  (Interestingly, the machine keeps the LED status even after
the codec goes into D3 -- but it's another story.)

For improving this usability, let the driver temporarily powering up /
down only during the pin VREF change.  This can be achieved easily by
wrapping the call with snd_hda_power_up_pm() / *_down_pm().

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=199073
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      e40bdb03
  23. 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
  25. 13 3月, 2018 1 次提交
  27. 12 3月, 2018 2 次提交
    • C
      ALSA: echoaudio: remove redundant initialization of pointer 'pipe' · 0bc66fd3
      由 Colin Ian King 提交于 
      The pointer 'pipe' is being initialized with a value that is never
read and it is re-assigned later, hence the initialization is redundant
and can be removed. Also remove pointer 'runtime' as it is no longer
required.

Cleans up clang warning:
sound/pci/echoaudio/echoaudio.c:740:20: warning: Value stored to 'pipe'
during its initialization is never read
Signed-off-by: NColin Ian King <colin.king@canonical.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      0bc66fd3
    • 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
  29. 09 3月, 2018 2 次提交
  31. 08 3月, 2018 1 次提交
  33. 06 3月, 2018 3 次提交