--- /dev/null
+From 9ad54547cf6f4410eba83bb95dfd2a0966718d6d Mon Sep 17 00:00:00 2001
+From: Kailang Yang <kailang@realtek.com>
+Date: Tue, 26 Nov 2013 15:41:40 +0800
+Subject: ALSA: hda/realtek - Set pcbeep amp for ALC668
+
+From: Kailang Yang <kailang@realtek.com>
+
+commit 9ad54547cf6f4410eba83bb95dfd2a0966718d6d upstream.
+
+Set the missing pcbeep default amp for ALC668.
+
+Signed-off-by: Kailang Yang <kailang@realtek.com>
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ sound/pci/hda/patch_realtek.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/sound/pci/hda/patch_realtek.c
++++ b/sound/pci/hda/patch_realtek.c
+@@ -6969,6 +6969,7 @@ static int patch_alc662(struct hda_codec
+ case 0x10ec0272:
+ case 0x10ec0663:
+ case 0x10ec0665:
++ case 0x10ec0668:
+ set_beep_amp(spec, 0x0b, 0x04, HDA_INPUT);
+ break;
+ case 0x10ec0273:
--- /dev/null
+From 0fc0287c9ed1ffd3706f8b4d9b314aa102ef1245 Mon Sep 17 00:00:00 2001
+From: Peter Zijlstra <peterz@infradead.org>
+Date: Tue, 26 Nov 2013 15:03:41 +0100
+Subject: cpuset: Fix memory allocator deadlock
+
+From: Peter Zijlstra <peterz@infradead.org>
+
+commit 0fc0287c9ed1ffd3706f8b4d9b314aa102ef1245 upstream.
+
+Juri hit the below lockdep report:
+
+[ 4.303391] ======================================================
+[ 4.303392] [ INFO: SOFTIRQ-safe -> SOFTIRQ-unsafe lock order detected ]
+[ 4.303394] 3.12.0-dl-peterz+ #144 Not tainted
+[ 4.303395] ------------------------------------------------------
+[ 4.303397] kworker/u4:3/689 [HC0[0]:SC0[0]:HE0:SE1] is trying to acquire:
+[ 4.303399] (&p->mems_allowed_seq){+.+...}, at: [<ffffffff8114e63c>] new_slab+0x6c/0x290
+[ 4.303417]
+[ 4.303417] and this task is already holding:
+[ 4.303418] (&(&q->__queue_lock)->rlock){..-...}, at: [<ffffffff812d2dfb>] blk_execute_rq_nowait+0x5b/0x100
+[ 4.303431] which would create a new lock dependency:
+[ 4.303432] (&(&q->__queue_lock)->rlock){..-...} -> (&p->mems_allowed_seq){+.+...}
+[ 4.303436]
+
+[ 4.303898] the dependencies between the lock to be acquired and SOFTIRQ-irq-unsafe lock:
+[ 4.303918] -> (&p->mems_allowed_seq){+.+...} ops: 2762 {
+[ 4.303922] HARDIRQ-ON-W at:
+[ 4.303923] [<ffffffff8108ab9a>] __lock_acquire+0x65a/0x1ff0
+[ 4.303926] [<ffffffff8108cbe3>] lock_acquire+0x93/0x140
+[ 4.303929] [<ffffffff81063dd6>] kthreadd+0x86/0x180
+[ 4.303931] [<ffffffff816ded6c>] ret_from_fork+0x7c/0xb0
+[ 4.303933] SOFTIRQ-ON-W at:
+[ 4.303933] [<ffffffff8108abcc>] __lock_acquire+0x68c/0x1ff0
+[ 4.303935] [<ffffffff8108cbe3>] lock_acquire+0x93/0x140
+[ 4.303940] [<ffffffff81063dd6>] kthreadd+0x86/0x180
+[ 4.303955] [<ffffffff816ded6c>] ret_from_fork+0x7c/0xb0
+[ 4.303959] INITIAL USE at:
+[ 4.303960] [<ffffffff8108a884>] __lock_acquire+0x344/0x1ff0
+[ 4.303963] [<ffffffff8108cbe3>] lock_acquire+0x93/0x140
+[ 4.303966] [<ffffffff81063dd6>] kthreadd+0x86/0x180
+[ 4.303969] [<ffffffff816ded6c>] ret_from_fork+0x7c/0xb0
+[ 4.303972] }
+
+Which reports that we take mems_allowed_seq with interrupts enabled. A
+little digging found that this can only be from
+cpuset_change_task_nodemask().
+
+This is an actual deadlock because an interrupt doing an allocation will
+hit get_mems_allowed()->...->__read_seqcount_begin(), which will spin
+forever waiting for the write side to complete.
+
+Cc: John Stultz <john.stultz@linaro.org>
+Cc: Mel Gorman <mgorman@suse.de>
+Reported-by: Juri Lelli <juri.lelli@gmail.com>
+Signed-off-by: Peter Zijlstra <peterz@infradead.org>
+Tested-by: Juri Lelli <juri.lelli@gmail.com>
+Acked-by: Li Zefan <lizefan@huawei.com>
+Acked-by: Mel Gorman <mgorman@suse.de>
+Signed-off-by: Tejun Heo <tj@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ kernel/cpuset.c | 8 ++++++--
+ 1 file changed, 6 insertions(+), 2 deletions(-)
+
+--- a/kernel/cpuset.c
++++ b/kernel/cpuset.c
+@@ -983,8 +983,10 @@ static void cpuset_change_task_nodemask(
+ need_loop = task_has_mempolicy(tsk) ||
+ !nodes_intersects(*newmems, tsk->mems_allowed);
+
+- if (need_loop)
++ if (need_loop) {
++ local_irq_disable();
+ write_seqcount_begin(&tsk->mems_allowed_seq);
++ }
+
+ nodes_or(tsk->mems_allowed, tsk->mems_allowed, *newmems);
+ mpol_rebind_task(tsk, newmems, MPOL_REBIND_STEP1);
+@@ -992,8 +994,10 @@ static void cpuset_change_task_nodemask(
+ mpol_rebind_task(tsk, newmems, MPOL_REBIND_STEP2);
+ tsk->mems_allowed = *newmems;
+
+- if (need_loop)
++ if (need_loop) {
+ write_seqcount_end(&tsk->mems_allowed_seq);
++ local_irq_enable();
++ }
+
+ task_unlock(tsk);
+ }
--- /dev/null
+From 02e5f5c0a0f726e66e3d8506ea1691e344277969 Mon Sep 17 00:00:00 2001
+From: NeilBrown <neilb@suse.de>
+Date: Thu, 14 Nov 2013 15:16:15 +1100
+Subject: md: fix calculation of stacking limits on level change.
+
+From: NeilBrown <neilb@suse.de>
+
+commit 02e5f5c0a0f726e66e3d8506ea1691e344277969 upstream.
+
+The various ->run routines of md personalities assume that the 'queue'
+has been initialised by the blk_set_stacking_limits() call in
+md_alloc().
+
+However when the level is changed (by level_store()) the ->run routine
+for the new level is called for an array which has already had the
+stacking limits modified. This can result in incorrect final
+settings.
+
+So call blk_set_stacking_limits() before ->run in level_store().
+
+A specific consequence of this bug is that it causes
+discard_granularity to be set incorrectly when reshaping a RAID4 to a
+RAID0.
+
+This is suitable for any -stable kernel since 3.3 in which
+blk_set_stacking_limits() was introduced.
+
+Reported-and-tested-by: "Baldysiak, Pawel" <pawel.baldysiak@intel.com>
+Signed-off-by: NeilBrown <neilb@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/md/md.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/md/md.c
++++ b/drivers/md/md.c
+@@ -3507,6 +3507,7 @@ level_store(struct mddev *mddev, const c
+ mddev->in_sync = 1;
+ del_timer_sync(&mddev->safemode_timer);
+ }
++ blk_set_stacking_limits(&mddev->queue->limits);
+ pers->run(mddev);
+ mddev_resume(mddev);
+ set_bit(MD_CHANGE_DEVS, &mddev->flags);
--- /dev/null
+From ec67ad82814bee92251fd963bf01c7a173856555 Mon Sep 17 00:00:00 2001
+From: Michael Neuling <mikey@neuling.org>
+Date: Mon, 25 Nov 2013 11:12:20 +1100
+Subject: powerpc/signals: Improved mark VSX not saved with small contexts fix
+
+From: Michael Neuling <mikey@neuling.org>
+
+commit ec67ad82814bee92251fd963bf01c7a173856555 upstream.
+
+In a recent patch:
+ commit c13f20ac48328b05cd3b8c19e31ed6c132b44b42
+ Author: Michael Neuling <mikey@neuling.org>
+ powerpc/signals: Mark VSX not saved with small contexts
+
+We fixed an issue but an improved solution was later discussed after the patch
+was merged.
+
+Firstly, this patch doesn't handle the 64bit signals case, which could also hit
+this issue (but has never been reported).
+
+Secondly, the original patch isn't clear what MSR VSX should be set to. The
+new approach below always clears the MSR VSX bit (to indicate no VSX is in the
+context) and sets it only in the specific case where VSX is available (ie. when
+VSX has been used and the signal context passed has space to provide the
+state).
+
+This reverts the original patch and replaces it with the improved solution. It
+also adds a 64 bit version.
+
+Signed-off-by: Michael Neuling <mikey@neuling.org>
+Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/powerpc/kernel/signal_32.c | 16 +++++++---------
+ arch/powerpc/kernel/signal_64.c | 6 ++++++
+ 2 files changed, 13 insertions(+), 9 deletions(-)
+
+--- a/arch/powerpc/kernel/signal_32.c
++++ b/arch/powerpc/kernel/signal_32.c
+@@ -447,6 +447,12 @@ static int save_user_regs(struct pt_regs
+ #endif /* CONFIG_ALTIVEC */
+ if (copy_fpr_to_user(&frame->mc_fregs, current))
+ return 1;
++
++ /*
++ * Clear the MSR VSX bit to indicate there is no valid state attached
++ * to this context, except in the specific case below where we set it.
++ */
++ msr &= ~MSR_VSX;
+ #ifdef CONFIG_VSX
+ /*
+ * Copy VSR 0-31 upper half from thread_struct to local
+@@ -459,15 +465,7 @@ static int save_user_regs(struct pt_regs
+ if (copy_vsx_to_user(&frame->mc_vsregs, current))
+ return 1;
+ msr |= MSR_VSX;
+- } else if (!ctx_has_vsx_region)
+- /*
+- * With a small context structure we can't hold the VSX
+- * registers, hence clear the MSR value to indicate the state
+- * was not saved.
+- */
+- msr &= ~MSR_VSX;
+-
+-
++ }
+ #endif /* CONFIG_VSX */
+ #ifdef CONFIG_SPE
+ /* save spe registers */
+--- a/arch/powerpc/kernel/signal_64.c
++++ b/arch/powerpc/kernel/signal_64.c
+@@ -117,6 +117,12 @@ static long setup_sigcontext(struct sigc
+ flush_fp_to_thread(current);
+ /* copy fpr regs and fpscr */
+ err |= copy_fpr_to_user(&sc->fp_regs, current);
++
++ /*
++ * Clear the MSR VSX bit to indicate there is no valid state attached
++ * to this context, except in the specific case below where we set it.
++ */
++ msr &= ~MSR_VSX;
+ #ifdef CONFIG_VSX
+ /*
+ * Copy VSX low doubleword to local buffer for formatting,
--- /dev/null
+From 97b6ff6be9da7675aab339334fda996d6c5077d9 Mon Sep 17 00:00:00 2001
+From: Jerome Glisse <jglisse@redhat.com>
+Date: Tue, 12 Nov 2013 10:51:16 -0500
+Subject: radeon: workaround pinning failure on low ram gpu
+
+From: Jerome Glisse <jglisse@redhat.com>
+
+commit 97b6ff6be9da7675aab339334fda996d6c5077d9 upstream.
+
+GPU with low amount of ram can fails at pinning new framebuffer before
+unpinning old one. On such failure, retry with unpinning old one before
+pinning new one allowing to work around the issue. This is somewhat
+ugly but only affect those old GPU we care about.
+
+Signed-off-by: Jerome Glisse <jglisse@redhat.com>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/radeon/radeon_legacy_crtc.c | 28 ++++++++++++++++++++++++++++
+ 1 file changed, 28 insertions(+)
+
+--- a/drivers/gpu/drm/radeon/radeon_legacy_crtc.c
++++ b/drivers/gpu/drm/radeon/radeon_legacy_crtc.c
+@@ -416,6 +416,7 @@ int radeon_crtc_do_set_base(struct drm_c
+ /* Pin framebuffer & get tilling informations */
+ obj = radeon_fb->obj;
+ rbo = gem_to_radeon_bo(obj);
++retry:
+ r = radeon_bo_reserve(rbo, false);
+ if (unlikely(r != 0))
+ return r;
+@@ -424,6 +425,33 @@ int radeon_crtc_do_set_base(struct drm_c
+ &base);
+ if (unlikely(r != 0)) {
+ radeon_bo_unreserve(rbo);
++
++ /* On old GPU like RN50 with little vram pining can fails because
++ * current fb is taking all space needed. So instead of unpining
++ * the old buffer after pining the new one, first unpin old one
++ * and then retry pining new one.
++ *
++ * As only master can set mode only master can pin and it is
++ * unlikely the master client will race with itself especialy
++ * on those old gpu with single crtc.
++ *
++ * We don't shutdown the display controller because new buffer
++ * will end up in same spot.
++ */
++ if (!atomic && fb && fb != crtc->fb) {
++ struct radeon_bo *old_rbo;
++ unsigned long nsize, osize;
++
++ old_rbo = gem_to_radeon_bo(to_radeon_framebuffer(fb)->obj);
++ osize = radeon_bo_size(old_rbo);
++ nsize = radeon_bo_size(rbo);
++ if (nsize <= osize && !radeon_bo_reserve(old_rbo, false)) {
++ radeon_bo_unpin(old_rbo);
++ radeon_bo_unreserve(old_rbo);
++ fb = NULL;
++ goto retry;
++ }
++ }
+ return -EINVAL;
+ }
+ radeon_bo_get_tiling_flags(rbo, &tiling_flags, NULL);
drm-i915-flush-cursors-harder.patch
drm-nouveau-when-bailing-out-of-a-pushbuf-ioctl-do-not-remove-previous-fence.patch
drm-radeon-si-fix-define-for-mc_seq_train_wakeup_cntl.patch
+radeon-workaround-pinning-failure-on-low-ram-gpu.patch
+md-fix-calculation-of-stacking-limits-on-level-change.patch
+powerpc-signals-improved-mark-vsx-not-saved-with-small-contexts-fix.patch
+cpuset-fix-memory-allocator-deadlock.patch
+alsa-hda-realtek-set-pcbeep-amp-for-alc668.patch
projects / thirdparty / kernel / stable-queue.git / commitdiff
