Skip to content

cloud-kernel
cloud-kernel

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

通知 160
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 08 5月, 2016 11 次提交
  3. 29 4月, 2016 1 次提交
    • T
      ALSA: usb-audio: Limit retrying sample rate reads · 57dd5414
      由 Takashi Iwai 提交于 
      There are many USB audio devices with buggy firmware that don't react
with the sample rate reading properly.  This often results in the
flood of error messages and slowing down the operation.

The sample rate read back is basically only for confirming the sample
rate setup, and it's not critically important.  As a compromise, in
this patch, we stop the sample rate read back once when the device
gives errors more than tolerance (twice, as of now).  This should
improve most of error cases while we still can catch the firmware
bugginess.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      57dd5414
  5. 26 4月, 2016 5 次提交
    • T
      Merge branch 'for-linus' into for-next · a33d5959
      由 Takashi Iwai 提交于 
      For taking back the recent change of HDA HDMI fixes for i915 HSW/BDW.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      a33d5959
    • T
      ALSA: hda - Update BCLK also at hotplug for i915 HSW/BDW · bb03ed21
      由 Takashi Iwai 提交于 
      The recent bug report suggests that BCLK setup for i915 HSW/BDW needs
to be updated at each HDMI hotplug, not only at initialization and
resume.  That is, we need to update HSW_EM4 and HSW_EM5 registers at
ELD notification, too.  Otherwise the HDMI audio may be out of sync
and played in a wrong pitch.

However, the HDA codec driver has no access to the controller
registers, and currently the code managing these registers is in
hda_intel.c, i.e. local to the controller driver.  For allowing the
explicit BCLK update from the codec driver, as in this patch, the
former haswell_set_bclk() in hda_intel.c is moved to hdac_i915.c and
exposed as snd_hdac_i915_set_bclk().  This is called from both the HDA
controller driver and intel_pin_eld_notify() in HDMI codec driver.

Along with this change, snd_hdac_get_display_clk() gets dropped as
it's no longer used.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91410
Cc: <stable@vger.kernel.org> # v4.5+
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      bb03ed21
    • C
      ALSA: hda - Add dock support for ThinkPad X260 · 037e1197
      由 Conrad Kostecki 提交于 
      Fixes audio output on a ThinkPad X260, when using Lenovo CES 2013
docking station series (basic, pro, ultra).
Signed-off-by: NConrad Kostecki <ck+linuxkernel@bl4ckb0x.de>
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      037e1197
    • T
      ALSA: au88x0: Fix overlapped PCM pointer · 58a8738c
      由 Takashi Iwai 提交于 
      au88x0 hardware seems returning the current pointer at the buffer
boundary instead of going back to zero.  This results in spewing
warnings from PCM core.

This patch corrects the return value from the pointer callback within
the proper value range, just returning zero if the position is equal
or above the buffer size.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      58a8738c
    • T
      ALSA: hrtimer: Handle start/stop more properly · d2c5cf88
      由 Takashi Iwai 提交于 
      This patch tries to address the still remaining issues in ALSA hrtimer
driver:
- Spurious use-after-free was detected in hrtimer callback
- Incorrect rescheduling due to delayed start
- WARN_ON() is triggered in hrtimer_forward() invoked in hrtimer
  callback

The first issue happens only when the new timer is scheduled even
while hrtimer is being closed.  It's related with the second and third
items; since ALSA timer core invokes hw.start callback during hrtimer
interrupt, this may result in the explicit call of hrtimer_start().

Also, the similar problem is seen for the stop; ALSA timer core
invokes hw.stop callback even in the hrtimer handler, too.  Since we
must not call the synced hrtimer_cancel() in such a context, it's just
a hrtimer_try_to_cancel() call that doesn't properly work.

Another culprit of the second and third items is the call of
hrtimer_forward_now() before snd_timer_interrupt().  The timer->stick
value may change during snd_timer_interrupt() call, but this
possibility is ignored completely.

For covering these subtle and messy issues, the following changes have
been done in this patch:
- A new flag, in_callback, is introduced in the private data to
  indicate that the hrtimer handler is being processed.
- Both start and stop callbacks skip when called from (during)
  in_callback flag.
- The hrtimer handler returns properly HRTIMER_RESTART and NORESTART
  depending on the running state now.
- The hrtimer handler reprograms the expiry properly after
  snd_timer_interrupt() call, instead of before.
- The close callback clears running flag and sets in_callback flag
  to block any further start/stop calls.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      d2c5cf88
  7. 25 4月, 2016 3 次提交
  9. 21 4月, 2016 2 次提交
    • T
      ALSA: hda - Fix possible race on regmap bypass flip · 3194ed49
      由 Takashi Iwai 提交于 
      HD-audio driver uses regmap cache bypass feature for reading a raw
value without the cache.  But this is racy since both the cached and
the uncached reads may occur concurrently.  The former is done via the
normal control API access while the latter comes from the proc file
read.

Even though the regmap itself has the protection against the
concurrent accesses, the flag set/reset is done without the
protection, so it may lead to inconsistent state of bypass flag that
doesn't match with the current read and occasionally result in a
kernel WARNING like:
  WARNING: CPU: 3 PID: 2731 at drivers/base/regmap/regcache.c:499 regcache_cache_only+0x78/0x93

One way to work around such a problem is to wrap with a mutex.  But in
this case, the solution is simpler: for the uncached read, we just
skip the regmap and directly calls its accessor.  The verb execution
there is protected by itself, so basically it's safe to call
individually.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=116171Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      3194ed49
    • T
      ALSA: pcxhr: Fix missing mutex unlock · 67f3754b
      由 Takashi Iwai 提交于 
      The commit [9bef72bd: ALSA: pcxhr: Use nonatomic PCM ops]
converted to non-atomic PCM ops, but shamelessly with an unbalanced
mutex locking, which leads to the hangup easily.  Fix it.

Fixes: 9bef72bd ('ALSA: pcxhr: Use nonatomic PCM ops')
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=116441
Cc: <stable@vger.kernel.org> # 3.18+
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      67f3754b
  11. 20 4月, 2016 2 次提交
    • L
      ALSA: hda - add PCI ID for Intel Broxton-T · 9859a971
      由 Lu, Han 提交于 
      Add HD Audio Device PCI ID for the Intel Broxton-T platform.
It is an HDA Intel PCH controller.
Signed-off-by: NLu, Han <han.lu@intel.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      9859a971
    • T
      ALSA: hda - Keep powering up ADCs on Cirrus codecs · de3df8a9
      由 Takashi Iwai 提交于 
      Although one weird behavior about the input path (inconsistent D0/D3
switch) on Cirrus CS420x codecs was fixed in the previous commit,
there is still an issue on some Mac machines: the capture stream
stalls when switching the ADCs on the fly.  More badly, this keeps
stuck until the next reboot.

The dynamic ADC switching is already a bit fragile and assuming
optimistically that the chip accepts the frequent power changes.  On
Cirrus codecs, this doesn't seem applicable.

As a quick workaround, we pin down the ADCs to keep up in D0 when
spec->dyn_adc_switch is set.  In this way, the ADCs are kept up only
for the system that were confirmed to be broken.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=116171
Cc: <stable@vger.kernel.org> # v4.4+
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      de3df8a9
  13. 19 4月, 2016 1 次提交
  15. 18 4月, 2016 2 次提交
  17. 17 4月, 2016 1 次提交
    • T
      ALSA: hda - Don't trust the reported actual power state · 50fd4987
      由 Takashi Iwai 提交于 
      We've got a regression report that the recording on Mac with a cirrus
codec doesn't work any longer.  This turned out to be the missing
power up to D0 by power_save_node enablement.

After analyzing the traces, we found out that the culprit is that the
codec advertises the "actual" power state of a few nodes to be D0
while the "target" power state is D3.  This inconsistency is usually
OK, as it implies the power transition.  But in the case of cirrus
codec, this seems to be stuck to D3 while it's not actually D0.

This patch addresses the issue by checking the power state difference
more strictly.  It sends the power-state change verb unless both the
target and the actual power states show the given value.

We may introduce yet another flag indicating the possible broken
hardware power state, but it's anyway safer to set the proper power
state even in a transition (at least it's harmless as long as the
target state is same).  So this simpler change was applied now.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=116171
Cc: <stable@vger.kernel.org> # v4.4+
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      50fd4987
  19. 15 4月, 2016 2 次提交
    • T
      ALSA: lx646es: Fix possible uninitialized variable reference · a19c921f
      由 Takashi Iwai 提交于 
      lx_pipe_state() checks the return value from lx_message_send_atomic()
and breaks the loop only when it's a negative value.  However,
lx_message_send_atomic() may return a positive error code (as the
return code from the hardware), and then lx_pipe_state() tries to
compare the uninitialized current_state variable.

Fix this behavior by checking the positive non-zero error code as
well.
Reported-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      a19c921f
    • T
      ALSA: pcm : Call kill_fasync() in stream lock · 3aa02cb6
      由 Takashi Iwai 提交于 
      Currently kill_fasync() is called outside the stream lock in
snd_pcm_period_elapsed().  This is potentially racy, since the stream
may get released even during the irq handler is running.  Although
snd_pcm_release_substream() calls snd_pcm_drop(), this doesn't
guarantee that the irq handler finishes, thus the kill_fasync() call
outside the stream spin lock may be invoked after the substream is
detached, as recently reported by KASAN.

As a quick workaround, move kill_fasync() call inside the stream
lock.  The fasync is rarely used interface, so this shouldn't have a
big impact from the performance POV.

Ideally, we should implement some sync mechanism for the proper finish
of stream and irq handler.  But this oneliner should suffice for most
cases, so far.
Reported-by: NBaozeng Ding <sploving1@gmail.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      3aa02cb6
  21. 13 4月, 2016 2 次提交
    • T
      ALSA: hda - Fix inconsistent monitor_present state until repoll · c44da62b
      由 Takashi Iwai 提交于 
      While the previous commit fixed the missing monitor_present flag
update, it may be still in an inconsistent state while the driver
repolls: the flag itself is updated, but the eld_valid flag and the
contents don't follow until the repoll finishes (and may be repeated
for a few times).

The basic problem is that pin_eld->monitor_present is updated in the
caller side.  This should have been updated only in update_eld().  So,
the proper fix is to avoid accessing pin_eld but only spec->temp_eld.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      c44da62b
    • H
      ALSA: hda - Fix regression of monitor_present flag in eld proc file · 023d8218
      由 Hyungwon Hwang 提交于 
      The commit [bd481285: ALSA: hda - Fix forgotten HDMI
monitor_present update] covered the missing update of monitor_present
flag, but this caused a regression for devices without the i915 eld
notifier.  Since the old code supposed that pin_eld->monitor_present
was updated by the caller side, the hdmi_present_sense_via_verbs()
doesn't update the temporary eld->monitor_present but only
pin_eld->monitor_present, which is now overridden in update_eld().

The fix is to update pin_eld->monitor_present as well before calling
update_eld().

Note that this may still leave monitor_present flag in an inconsistent
state when the driver repolls, but this is at least the old behavior.
More proper fix will follow in the later patch.

Fixes: bd481285 ('ALSA: hda - Fix forgotten HDMI monitor_present update')
Signed-off-by: NHyungwon Hwang <hyungwon.hwang7@gmail.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      023d8218
  23. 12 4月, 2016 3 次提交
  25. 11 4月, 2016 2 次提交
  27. 09 4月, 2016 3 次提交