1. 18 4月, 2018 1 次提交
    • L
      ASoC: core: Allow topology to override machine driver FE DAI link config. · 45f8cb57
      Liam Girdwood 提交于
      Machine drivers statically define a number of DAI links that currently
      cannot be changed or removed by topology. This means PCMs and platform
      components cannot be changed by topology at runtime AND machine drivers
      are tightly coupled to topology.
      
      This patch allows topology to override the machine driver DAI link config
      in order to reuse machine drivers with different topologies and platform
      components. The patch supports :-
      
      1) create new FE PCMs with a topology defined PCM ID.
      2) destroy existing static FE PCMs
      3) change the platform component driver.
      4) assign any new HW params fixups.
      
      The patch requires no changes to the machine drivers, but does add some
      platform component flags that the platform component driver can assign
      before loading topologies.
      Signed-off-by: NLiam Girdwood <liam.r.girdwood@linux.intel.com>
      Signed-off-by: NMark Brown <broonie@kernel.org>
      45f8cb57
  2. 17 4月, 2018 1 次提交
  3. 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
  4. 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
  5. 13 3月, 2018 2 次提交
  6. 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
  7. 07 3月, 2018 2 次提交
  8. 02 3月, 2018 1 次提交
  9. 26 2月, 2018 1 次提交
  10. 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
  11. 12 2月, 2018 5 次提交
  12. 25 1月, 2018 1 次提交
  13. 16 1月, 2018 1 次提交
  14. 13 1月, 2018 2 次提交
  15. 08 1月, 2018 2 次提交
  16. 22 12月, 2017 1 次提交
  17. 20 12月, 2017 2 次提交
  18. 12 12月, 2017 1 次提交
  19. 01 12月, 2017 1 次提交
  20. 29 11月, 2017 1 次提交
  21. 28 11月, 2017 2 次提交
  22. 22 11月, 2017 1 次提交
    • T
      ALSA: hda - Fix yet remaining issue with vmaster 0dB initialization · d6c0615f
      Takashi Iwai 提交于
      The previous fix for addressing the breakage in vmaster slave
      initialization, commit a91d6612 ("ALSA: hda - Fix incorrect TLV
      callback check introduced during set_fs() removal"), introduced a new
      helper to process over each slave kctl.  However, this helper passes
      only the original kctl, not the virtual slave kctl.  As a result,
      HD-audio driver (which is the only user so far) couldn't initialize
      the slave correctly because it's trying to update the value directly
      with the original kctl, not with the mapped kctl.
      
      This patch fixes the situation again by passing both the mapped slaved
      and original slave kctls to the function.  Luckily there is a single
      caller as of now, so changing the call signature is no big matter.
      
      Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=197959
      Fixes: a91d6612 ("ALSA: hda - Fix incorrect TLV callback check introduced during set_fs() removal")
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      d6c0615f
  23. 09 11月, 2017 4 次提交
  24. 07 11月, 2017 1 次提交