Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 05 6月, 2019 1 次提交
  3. 04 2月, 2019 1 次提交
  5. 16 1月, 2019 1 次提交
  7. 03 11月, 2018 2 次提交
  9. 28 8月, 2018 1 次提交
  11. 07 8月, 2018 1 次提交
  13. 28 6月, 2018 1 次提交
  15. 28 2月, 2018 2 次提交
    • T
      ALSA: x86: Fix potential crash at error path · c77a6edb
      由 Takashi Iwai 提交于 
      When LPE audio driver gets some error at probing, it may lead to a
crash because of canceling the pending work in hdmi_lpe_audio_free(),
since some of ports might be still not initialized.

For assuring the proper free of each port, initialize all ports at the
beginning of the probe.

Fixes: b4eb0d52 ("ALSA: x86: Split snd_intelhad into card and PCM specific structures")
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      c77a6edb
    • T
      ALSA: x86: Fix missing spinlock and mutex initializations · 35014406
      由 Takashi Iwai 提交于 
      The commit change for supporting the multiple ports moved involved
some code shuffling, and there the initializations of spinlock and
mutex in snd_intelhad object were dropped mistakenly.

This patch adds the missing initializations again for each port.

Fixes: b4eb0d52 ("ALSA: x86: Split snd_intelhad into card and PCM specific structures")
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      35014406
  17. 22 2月, 2018 1 次提交
    • T
      ALSA: x86: hdmi: Add single_port option for compatible behavior · 7229b12f
      由 Takashi Iwai 提交于 
      The recent support for the multiple PCM devices allowed user to use
multiple HDMI/DP outputs, but at the same time, the PCM stream
assignment has been changed, too.  Due to that, the former PCM#0
(there was only one stream in the past) is likely assigned to a
different one (e.g. PCM#2), and it ends up with the regression when
user sticks with the fixed configuration using the device#0.

Although the multiple monitor support shouldn't matter when user
deploys the backend like PulseAudio that checks the jack detection
state, the behavior change isn't always acceptable for some users.

As a mitigation, this patch introduces an option to switch the
behavior back to the old-good-days: when the new option,
single_port=1, is passed, the driver creates only a single PCM device,
and it's assigned to the first connected one, like the earlier
versions did.  The option is turned off as default still to support
the multiple monitors.

Fixes: 8a2d6ae1 ("ALSA: x86: Register multiple PCM devices for the LPE audio card")
Reported-and-tested-by: NHubert Mantel <mantel@metadox.de>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      7229b12f
  19. 01 7月, 2017 1 次提交
  21. 15 5月, 2017 1 次提交
    • V
      drm/i915: Fix runtime PM for LPE audio · 668e3b01
      由 Ville Syrjälä 提交于 
      Not calling pm_runtime_enable() means that runtime PM can't be
enabled at all via sysfs. So we definitely need to call it
from somewhere.

Calling it from the driver seems like a bad idea because it
would have to be paired with a pm_runtime_disable() at driver
unload time, otherwise the core gets upset. Also if there's
no LPE audio driver loaded then we couldn't runtime suspend
i915 either.

So it looks like a better plan is to call it from i915 when
we register the platform device. That seems to match how
pci generally does things. I cargo culted the
pm_runtime_forbid() and pm_runtime_set_active() calls from
pci as well.

The exposed runtime PM API is massive an thorougly misleading, so
I don't actually know if this is how you're supposed to use the API
or not. But it seems to work. I can now runtime suspend i915 again
with or without the LPE audio driver loaded, and reloading the
LPE audio driver also seems to work.

Note that powertop won't auto-tune runtime PM for platform devices,
which is a little annoying. So I'm not sure that leaving runtime
PM in "on" mode by default is the best choice here. But I've left
it like that for now at least.

Also remove the comment about there not being much benefit from
LPE audio runtime PM. Not allowing runtime PM blocks i915 runtime
PM, which will also block s0ix, and that could have a measurable
impact on power consumption.

Cc: stable@vger.kernel.org
Cc: Takashi Iwai <tiwai@suse.de>
Cc: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Fixes: 0b6b524f ("ALSA: x86: Don't enable runtime PM as default")
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170427160231.13337-2-ville.syrjala@linux.intel.comReviewed-by: NTakashi Iwai <tiwai@suse.de>
(cherry picked from commit 183c0035)
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
      668e3b01
  23. 09 5月, 2017 1 次提交
  25. 03 5月, 2017 9 次提交
  27. 22 2月, 2017 2 次提交
    • T
      ALSA: x86: Don't enable runtime PM as default · 0b6b524f
      由 Takashi Iwai 提交于 
      Unlike HSW and newer, BYT/CHT devices have no fine control of audio
power domain in i915 side.  Since there is little gain by runtime PM
on BYT/CHT, so far, this commit removes the pm_runtime_enable() call
as default.

User who still wants the runtime PM may adjust the corresponding
sysfs files (power/control and power/autosuspend_delay_ms)
appropriately, of course.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      0b6b524f
    • T
      ALSA: x86: Use runtime PM autosuspend · 3002b9fb
      由 Takashi Iwai 提交于 
      This patch adds a few lines to the driver to use autosuspend for the
runtime PM.  It'll become useful with the combination of the keep-link
feature.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      3002b9fb
  29. 16 2月, 2017 8 次提交
  31. 13 2月, 2017 2 次提交
    • T
      ALSA: x86: Drop unused stream.running field · df42cb49
      由 Takashi Iwai 提交于 
      The pcm_stream_info.running field is only set in the PCM trigger
callback but never referred, thus it can be safely removed.

Also, properly cover the spinlock in both the trigger START and STOP
to protect had_enable_audio() calls.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      df42cb49
    • T
      ALSA: x86: Handle reset at prepare callback · e2acecf2
      由 Takashi Iwai 提交于 
      Currently the driver handles some reset procedure at the trigger STOP
and the underrun functions, where both are executed in the interrupt
context.  Especially the underrun function has a sync-loop to clear
the UNDERRUN status bit, and this is supposed to be one of plausible
causes of GPU hangup.

Since the job to be done in the interrupt handler should be minimum,
we move the reset function out of trigger and underrun, and push it
into the prepare (and hw_free) callbacks instead.  Here a new flag,
need_reset, is introduced to indicate the requirement of the reset
procedure.  This is for avoiding the multiple resets when PCM prepare
is called sequentially.

Also in the UNDERRUN bit-clear sync loop, take a longer pause to be in
the safer side.  Taking a longer delay is no longer a problem now
because we're running in the normal context.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      e2acecf2
  33. 10 2月, 2017 5 次提交