Skip to content

cloud-kernel
cloud-kernel

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

通知 161
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 30 5月, 2018 1 次提交
  3. 24 5月, 2018 1 次提交
  5. 17 5月, 2018 1 次提交
    • T
      ALSA: core: Assure control device to be registered at last · dc82e524
      由 Takashi Iwai 提交于 
      The commit 289ca025 ("ALSA: Use priority list for managing device
list") changed the way to register/disconnect/free devices via a
single priority list.  This helped to make behavior consistent, but it
also changed a slight behavior change: namely, the control device is
registered earlier than others, while it was supposed to be the very
last one.

I've put SNDRV_DEV_CONTROL in the current position as the release of
ctl elements often conflict with the private ctl elements some PCM or
other components may create, which often leads to a double-free.
But, the order of register and disconnect should be indeed fixed as
expected in the early days: the control device gets registered at
last, and disconnected at first.

This patch changes the priority list order to move SNDRV_DEV_CONTROL
as the last guy to assure the register / disconnect order.  Meanwhile,
for keeping the messy resource release order, manually treat the
control and lowlevel devices as last freed one.

Additional note:
The lowlevel device is the device where a card driver creates at
probe.  And, we still keep the release order control -> lowlevel, as
there might  be link from a control element back to a lowlevel object.

Fixes: 289ca025 ("ALSA: Use priority list for managing device list")
Reported-by: NTzung-Bi Shih <tzungbi@google.com>
Tested-by: NTzung-Bi Shih <tzungbi@google.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      dc82e524
  7. 11 5月, 2018 2 次提交
  9. 09 5月, 2018 6 次提交
  11. 02 5月, 2018 1 次提交
    • J
      ASoC: dai playback and capture active may be greater than 1 · 40c57963
      由 Jerome Brunet 提交于 
      At the moment playback_active and capture_active are using only 1 bit so
the maximum active count is 1.

However, snd_soc_runtime_activate() may be called several time on the
same dai. This happens when a dai is part of several dai_links. It is
often the case for "snd-soc-dummy-dai".

This is a problem if snd_soc_runtime_activate() is called an even number
of times on a dai. In this case the active count overflow back to 0. As
consequence, ASoC functions, such as soc_dpcm_runtime_update(), won't run
correctly.

Storing these usage counts on plain 'unsigned int' solves the problem.

Fixes: f0fba2ad ("ASoC: multi-component - ASoC Multi-Component Support")
Signed-off-by: NJerome Brunet <jbrunet@baylibre.com>
Signed-off-by: NMark Brown <broonie@kernel.org>
      40c57963
  13. 26 4月, 2018 1 次提交
  15. 25 4月, 2018 1 次提交
    • T
      ALSA: control: Hardening for potential Spectre v1 · 088e861e
      由 Takashi Iwai 提交于 
      As recently Smatch suggested, a few places in ALSA control core codes
may expand the array directly from the user-space value with
speculation:

  sound/core/control.c:1003 snd_ctl_elem_lock() warn: potential spectre issue 'kctl->vd'
  sound/core/control.c:1031 snd_ctl_elem_unlock() warn: potential spectre issue 'kctl->vd'
  sound/core/control.c:844 snd_ctl_elem_info() warn: potential spectre issue 'kctl->vd'
  sound/core/control.c:891 snd_ctl_elem_read() warn: potential spectre issue 'kctl->vd'
  sound/core/control.c:939 snd_ctl_elem_write() warn: potential spectre issue 'kctl->vd'

Although all these seem doing only the first load without further
reference, we may want to stay in a safer side, so hardening with
array_index_nospec() would still make sense.

In this patch, we put array_index_nospec() to the common
snd_ctl_get_ioff*() helpers instead of each caller.  These helpers are
also referred from some drivers, too, and basically all usages are to
calculate the array index from the user-space value, hence it's better
to cover there.

BugLink: https://marc.info/?l=linux-kernel&m=152411496503418&w=2Reported-by: NDan Carpenter <dan.carpenter@oracle.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      088e861e
  17. 24 4月, 2018 1 次提交
  19. 19 4月, 2018 1 次提交
  21. 18 4月, 2018 5 次提交
  23. 17 4月, 2018 1 次提交
  25. 16 4月, 2018 1 次提交
    • 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
  27. 24 3月, 2018 1 次提交
    • T
      ALSA: pcm: Return -EBUSY for OSS ioctls changing busy streams · 40cab6e8
      由 Takashi Iwai 提交于 
      OSS PCM stream management isn't modal but it allows ioctls issued at
any time for changing the parameters.  In the previous hardening
patch ("ALSA: pcm: Avoid potential races between OSS ioctls and
read/write"), we covered these races and prevent the corruption by
protecting the concurrent accesses via params_lock mutex.  However,
this means that some ioctls that try to change the stream parameter
(e.g. channels or format) would be blocked until the read/write
finishes, and it may take really long.

Basically changing the parameter while reading/writing is an invalid
operation, hence it's even more user-friendly from the API POV if it
returns -EBUSY in such a situation.

This patch adds such checks in the relevant ioctls with the addition
of read/write access refcount.

Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      40cab6e8
  29. 14 3月, 2018 3 次提交
    • 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
    • S
      ASoC: dapm: add support to pinctrl dapm · 5b2d15bb
      由 Srinivas Kandagatla 提交于 
      Purpose of having pinctrl dapm is to dynamically put the pins in
low power state when they are not actively used by the audio and
saving power.

Without this each driver has to set the pinctrl states, either
during probe or dynamically depending on the callbacks received
from ASoC core.
Signed-off-by: NSrinivas Kandagatla <srinivas.kandagatla@linaro.org>
Signed-off-by: NMark Brown <broonie@kernel.org>
      5b2d15bb
    • O
      ASoC: dmaengine_pcm: document process callback · 2e78a556
      由 Olivier Moysan 提交于 
      Add missing description of process callback.

Fixes: 78648092 ("ASoC: dmaengine_pcm: add processing support")
Signed-off-by: NOlivier Moysan <olivier.moysan@st.com>
Signed-off-by: NMark Brown <broonie@kernel.org>
      2e78a556
  31. 13 3月, 2018 2 次提交
  33. 10 3月, 2018 1 次提交
    • A
      ASoC: da7219: Add common clock usage for providing DAI clks · fc8f7ea2
      由 Adam Thomson 提交于 
      There is a need to use DA7219 as DAI clock master for other codecs
within a system, which means that the DAI clocks are required to
remain, regardless of whether the codec is actually running
playback/capture. To be able to expose control of the DAI clocking
the common clock framework has been employed.

The current implementation adds a simple clock gate for enabling
and disabling the DAI clocks, with no rate control supported
(this is still handled through standard hw_params() functions as
before). If DT is enabled then the clock is added to the OF
providers list, otherwise a clkdev lookup is used.
Signed-off-by: NAdam Thomson <Adam.Thomson.Opensource@diasemi.com>
Signed-off-by: NMark Brown <broonie@kernel.org>
      fc8f7ea2
  35. 07 3月, 2018 2 次提交
  37. 02 3月, 2018 1 次提交
  39. 26 2月, 2018 1 次提交
  41. 14 2月, 2018 2 次提交
    • M
      ALSA: emu10k1: add a IOMMU workaround · 04f8773a
      由 Maciej S. Szmigiero 提交于 
      The Audigy 2 CA0102 chip (but most likely others from the emu10k1 family,
too) has a problem that from time to time it likes to do few DMA reads a
bit beyond its normal allocation and gets very confused if these reads get
blocked by a IOMMU.

For the first (reserved) page this happens multiple times at every
playback, for various synth pages it happens randomly, rarely for PCM
playback buffers and the page table memory itself.
All these reads seem to follow a similar pattern, observed read offsets
beyond the allocation end were 0x00, 0x40, 0x80 and 0xc0 (PCI cache line
multiples), so it looks like the device tries to accesses up to 256 extra
bytes.

As a workaround let's widen these DMA allocations by an extra page if we
detect that the device is behind a non-passthrough IOMMU (the DMA memory
should be relatively plenty on IOMMU systems).
Signed-off-by: NMaciej S. Szmigiero <mail@maciej.szmigiero.name>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      04f8773a
    • M
      ALSA: emu10k1: remove reserved_page · a4463c92
      由 Maciej S. Szmigiero 提交于 
      The emu10k1-family chips need the first page (index 0) reserved in their
page tables for some reason (every emu10k1 driver I've checked does this
without much of an explanation).
Using the first page for normal samples results in a broken playback.

However, we already have a dummy page allocated - so called "silent page"
and, in fact, had always been setting it as the first page in the chip page
table because an initialization of every entry of the page table to point
to a silent page happens after and overwrites the reserved_page allocation.

So the only thing remaining to remove the reserved_page allocation is a
trivial change to the page allocation logic to ignore the first page entry
and start its allocations from the second entry (index 1).
Signed-off-by: NMaciej S. Szmigiero <mail@maciej.szmigiero.name>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      a4463c92
  43. 12 2月, 2018 4 次提交