From: Greg Kroah-Hartman Date: Wed, 12 Apr 2017 13:00:59 +0000 (+0200) Subject: 4.10-stable patches X-Git-Tag: v4.10.11~22 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=db1f7b140fa15a430799818a3382e698774e498c;p=thirdparty%2Fkernel%2Fstable-queue.git 4.10-stable patches added patches: drm-i915-avoid-rcu_barrier-from-reclaim-paths-shrinker.patch drm-i915-do-.init_clock_gating-earlier-to-avoid-it-clobbering-watermarks.patch drm-i915-drop-support-for-i915_exec_constants_-execbuf-parameters.patch drm-i915-only-enable-hotplug-interrupts-if-the-display-interrupts-are-enabled.patch drm-i915-reject-hdmi-12bpc-if-the-sink-doesn-t-indicate-support.patch drm-i915-stop-using-rp_down_ei-on-baytrail.patch orangefs-dan-carpenter-influenced-cleanups.patch orangefs-fix-buffer-size-mis-match-between-kernel-space-and-user-space.patch --- diff --git a/queue-4.10/drm-i915-avoid-rcu_barrier-from-reclaim-paths-shrinker.patch b/queue-4.10/drm-i915-avoid-rcu_barrier-from-reclaim-paths-shrinker.patch new file mode 100644 index 00000000000..9b63d9a461c --- /dev/null +++ b/queue-4.10/drm-i915-avoid-rcu_barrier-from-reclaim-paths-shrinker.patch @@ -0,0 +1,274 @@ +From 3d3d18f086cdda72ee18a454db70ca72c6e3246c Mon Sep 17 00:00:00 2001 +From: Chris Wilson +Date: Tue, 21 Mar 2017 14:45:31 +0000 +Subject: drm/i915: Avoid rcu_barrier() from reclaim paths (shrinker) + +From: Chris Wilson + +commit 3d3d18f086cdda72ee18a454db70ca72c6e3246c upstream. + +The rcu_barrier() takes the cpu_hotplug mutex which itself is not +reclaim-safe, and so rcu_barrier() is illegal from inside the shrinker. + +[ 309.661373] ========================================================= +[ 309.661376] [ INFO: possible irq lock inversion dependency detected ] +[ 309.661380] 4.11.0-rc1-CI-CI_DRM_2333+ #1 Tainted: G W +[ 309.661383] --------------------------------------------------------- +[ 309.661386] gem_exec_gttfil/6435 just changed the state of lock: +[ 309.661389] (rcu_preempt_state.barrier_mutex){+.+.-.}, at: [] _rcu_barrier+0x31/0x160 +[ 309.661399] but this lock took another, RECLAIM_FS-unsafe lock in the past: +[ 309.661402] (cpu_hotplug.lock){+.+.+.} +[ 309.661404] + + and interrupts could create inverse lock ordering between them. + +[ 309.661410] + other info that might help us debug this: +[ 309.661414] Possible interrupt unsafe locking scenario: + +[ 309.661417] CPU0 CPU1 +[ 309.661419] ---- ---- +[ 309.661421] lock(cpu_hotplug.lock); +[ 309.661425] local_irq_disable(); +[ 309.661432] lock(rcu_preempt_state.barrier_mutex); +[ 309.661441] lock(cpu_hotplug.lock); +[ 309.661446] +[ 309.661448] lock(rcu_preempt_state.barrier_mutex); +[ 309.661453] + *** DEADLOCK *** + +[ 309.661460] 4 locks held by gem_exec_gttfil/6435: +[ 309.661464] #0: (sb_writers#10){.+.+.+}, at: [] vfs_write+0x17d/0x1f0 +[ 309.661475] #1: (debugfs_srcu){......}, at: [] debugfs_use_file_start+0x41/0xa0 +[ 309.661486] #2: (&attr->mutex){+.+.+.}, at: [] simple_attr_write+0x37/0xe0 +[ 309.661495] #3: (&dev->struct_mutex){+.+.+.}, at: [] i915_drop_caches_set+0x3a/0x150 [i915] +[ 309.661540] + the shortest dependencies between 2nd lock and 1st lock: +[ 309.661547] -> (cpu_hotplug.lock){+.+.+.} ops: 829 { +[ 309.661553] HARDIRQ-ON-W at: +[ 309.661560] __lock_acquire+0x5e5/0x1b50 +[ 309.661565] lock_acquire+0xc9/0x220 +[ 309.661572] __mutex_lock+0x6e/0x990 +[ 309.661576] mutex_lock_nested+0x16/0x20 +[ 309.661583] get_online_cpus+0x61/0x80 +[ 309.661590] kmem_cache_create+0x25/0x1d0 +[ 309.661596] debug_objects_mem_init+0x30/0x249 +[ 309.661602] start_kernel+0x341/0x3fe +[ 309.661607] x86_64_start_reservations+0x2a/0x2c +[ 309.661612] x86_64_start_kernel+0x173/0x186 +[ 309.661619] verify_cpu+0x0/0xfc +[ 309.661622] SOFTIRQ-ON-W at: +[ 309.661627] __lock_acquire+0x611/0x1b50 +[ 309.661632] lock_acquire+0xc9/0x220 +[ 309.661636] __mutex_lock+0x6e/0x990 +[ 309.661641] mutex_lock_nested+0x16/0x20 +[ 309.661646] get_online_cpus+0x61/0x80 +[ 309.661650] kmem_cache_create+0x25/0x1d0 +[ 309.661655] debug_objects_mem_init+0x30/0x249 +[ 309.661660] start_kernel+0x341/0x3fe +[ 309.661664] x86_64_start_reservations+0x2a/0x2c +[ 309.661669] x86_64_start_kernel+0x173/0x186 +[ 309.661674] verify_cpu+0x0/0xfc +[ 309.661677] RECLAIM_FS-ON-W at: +[ 309.661682] mark_held_locks+0x6f/0xa0 +[ 309.661687] lockdep_trace_alloc+0xb3/0x100 +[ 309.661693] kmem_cache_alloc_trace+0x31/0x2e0 +[ 309.661699] __smpboot_create_thread.part.1+0x27/0xe0 +[ 309.661704] smpboot_create_threads+0x61/0x90 +[ 309.661709] cpuhp_invoke_callback+0x9c/0x8a0 +[ 309.661713] cpuhp_up_callbacks+0x31/0xb0 +[ 309.661718] _cpu_up+0x7a/0xc0 +[ 309.661723] do_cpu_up+0x5f/0x80 +[ 309.661727] cpu_up+0xe/0x10 +[ 309.661734] smp_init+0x71/0xb3 +[ 309.661738] kernel_init_freeable+0x94/0x19e +[ 309.661743] kernel_init+0x9/0xf0 +[ 309.661748] ret_from_fork+0x2e/0x40 +[ 309.661752] INITIAL USE at: +[ 309.661757] __lock_acquire+0x234/0x1b50 +[ 309.661761] lock_acquire+0xc9/0x220 +[ 309.661766] __mutex_lock+0x6e/0x990 +[ 309.661771] mutex_lock_nested+0x16/0x20 +[ 309.661775] get_online_cpus+0x61/0x80 +[ 309.661780] __cpuhp_setup_state+0x44/0x170 +[ 309.661785] page_alloc_init+0x23/0x3a +[ 309.661790] start_kernel+0x124/0x3fe +[ 309.661794] x86_64_start_reservations+0x2a/0x2c +[ 309.661799] x86_64_start_kernel+0x173/0x186 +[ 309.661804] verify_cpu+0x0/0xfc +[ 309.661807] } +[ 309.661813] ... key at: [] cpu_hotplug+0xb0/0x100 +[ 309.661817] ... acquired at: +[ 309.661821] lock_acquire+0xc9/0x220 +[ 309.661825] __mutex_lock+0x6e/0x990 +[ 309.661829] mutex_lock_nested+0x16/0x20 +[ 309.661833] get_online_cpus+0x61/0x80 +[ 309.661837] _rcu_barrier+0x9f/0x160 +[ 309.661841] rcu_barrier+0x10/0x20 +[ 309.661847] netdev_run_todo+0x5f/0x310 +[ 309.661852] rtnl_unlock+0x9/0x10 +[ 309.661856] default_device_exit_batch+0x133/0x150 +[ 309.661862] ops_exit_list.isra.0+0x4d/0x60 +[ 309.661866] cleanup_net+0x1d8/0x2c0 +[ 309.661872] process_one_work+0x1f4/0x6d0 +[ 309.661876] worker_thread+0x49/0x4a0 +[ 309.661881] kthread+0x107/0x140 +[ 309.661884] ret_from_fork+0x2e/0x40 + +[ 309.661890] -> (rcu_preempt_state.barrier_mutex){+.+.-.} ops: 179 { +[ 309.661896] HARDIRQ-ON-W at: +[ 309.661901] __lock_acquire+0x5e5/0x1b50 +[ 309.661905] lock_acquire+0xc9/0x220 +[ 309.661910] __mutex_lock+0x6e/0x990 +[ 309.661914] mutex_lock_nested+0x16/0x20 +[ 309.661919] _rcu_barrier+0x31/0x160 +[ 309.661923] rcu_barrier+0x10/0x20 +[ 309.661928] netdev_run_todo+0x5f/0x310 +[ 309.661932] rtnl_unlock+0x9/0x10 +[ 309.661936] default_device_exit_batch+0x133/0x150 +[ 309.661941] ops_exit_list.isra.0+0x4d/0x60 +[ 309.661946] cleanup_net+0x1d8/0x2c0 +[ 309.661951] process_one_work+0x1f4/0x6d0 +[ 309.661955] worker_thread+0x49/0x4a0 +[ 309.661960] kthread+0x107/0x140 +[ 309.661964] ret_from_fork+0x2e/0x40 +[ 309.661968] SOFTIRQ-ON-W at: +[ 309.661972] __lock_acquire+0x611/0x1b50 +[ 309.661977] lock_acquire+0xc9/0x220 +[ 309.661981] __mutex_lock+0x6e/0x990 +[ 309.661986] mutex_lock_nested+0x16/0x20 +[ 309.661990] _rcu_barrier+0x31/0x160 +[ 309.661995] rcu_barrier+0x10/0x20 +[ 309.661999] netdev_run_todo+0x5f/0x310 +[ 309.662003] rtnl_unlock+0x9/0x10 +[ 309.662008] default_device_exit_batch+0x133/0x150 +[ 309.662013] ops_exit_list.isra.0+0x4d/0x60 +[ 309.662017] cleanup_net+0x1d8/0x2c0 +[ 309.662022] process_one_work+0x1f4/0x6d0 +[ 309.662027] worker_thread+0x49/0x4a0 +[ 309.662031] kthread+0x107/0x140 +[ 309.662035] ret_from_fork+0x2e/0x40 +[ 309.662039] IN-RECLAIM_FS-W at: +[ 309.662043] __lock_acquire+0x638/0x1b50 +[ 309.662048] lock_acquire+0xc9/0x220 +[ 309.662053] __mutex_lock+0x6e/0x990 +[ 309.662058] mutex_lock_nested+0x16/0x20 +[ 309.662062] _rcu_barrier+0x31/0x160 +[ 309.662067] rcu_barrier+0x10/0x20 +[ 309.662089] i915_gem_shrink_all+0x33/0x40 [i915] +[ 309.662109] i915_drop_caches_set+0x141/0x150 [i915] +[ 309.662114] simple_attr_write+0xc7/0xe0 +[ 309.662119] full_proxy_write+0x4f/0x70 +[ 309.662124] __vfs_write+0x23/0x120 +[ 309.662128] vfs_write+0xc6/0x1f0 +[ 309.662133] SyS_write+0x44/0xb0 +[ 309.662138] entry_SYSCALL_64_fastpath+0x1c/0xb1 +[ 309.662142] INITIAL USE at: +[ 309.662147] __lock_acquire+0x234/0x1b50 +[ 309.662151] lock_acquire+0xc9/0x220 +[ 309.662156] __mutex_lock+0x6e/0x990 +[ 309.662160] mutex_lock_nested+0x16/0x20 +[ 309.662165] _rcu_barrier+0x31/0x160 +[ 309.662169] rcu_barrier+0x10/0x20 +[ 309.662174] netdev_run_todo+0x5f/0x310 +[ 309.662178] rtnl_unlock+0x9/0x10 +[ 309.662183] default_device_exit_batch+0x133/0x150 +[ 309.662188] ops_exit_list.isra.0+0x4d/0x60 +[ 309.662192] cleanup_net+0x1d8/0x2c0 +[ 309.662197] process_one_work+0x1f4/0x6d0 +[ 309.662202] worker_thread+0x49/0x4a0 +[ 309.662206] kthread+0x107/0x140 +[ 309.662210] ret_from_fork+0x2e/0x40 +[ 309.662214] } +[ 309.662220] ... key at: [] rcu_preempt_state+0x508/0x780 +[ 309.662225] ... acquired at: +[ 309.662229] check_usage_forwards+0x12b/0x130 +[ 309.662233] mark_lock+0x360/0x6f0 +[ 309.662237] __lock_acquire+0x638/0x1b50 +[ 309.662241] lock_acquire+0xc9/0x220 +[ 309.662245] __mutex_lock+0x6e/0x990 +[ 309.662249] mutex_lock_nested+0x16/0x20 +[ 309.662253] _rcu_barrier+0x31/0x160 +[ 309.662257] rcu_barrier+0x10/0x20 +[ 309.662279] i915_gem_shrink_all+0x33/0x40 [i915] +[ 309.662298] i915_drop_caches_set+0x141/0x150 [i915] +[ 309.662303] simple_attr_write+0xc7/0xe0 +[ 309.662307] full_proxy_write+0x4f/0x70 +[ 309.662311] __vfs_write+0x23/0x120 +[ 309.662315] vfs_write+0xc6/0x1f0 +[ 309.662319] SyS_write+0x44/0xb0 +[ 309.662323] entry_SYSCALL_64_fastpath+0x1c/0xb1 + +[ 309.662329] + stack backtrace: +[ 309.662335] CPU: 1 PID: 6435 Comm: gem_exec_gttfil Tainted: G W 4.11.0-rc1-CI-CI_DRM_2333+ #1 +[ 309.662342] Hardware name: Hewlett-Packard HP Compaq 8100 Elite SFF PC/304Ah, BIOS 786H1 v01.13 07/14/2011 +[ 309.662348] Call Trace: +[ 309.662354] dump_stack+0x67/0x92 +[ 309.662359] print_irq_inversion_bug.part.19+0x1a4/0x1b0 +[ 309.662365] check_usage_forwards+0x12b/0x130 +[ 309.662369] mark_lock+0x360/0x6f0 +[ 309.662374] ? print_shortest_lock_dependencies+0x1a0/0x1a0 +[ 309.662379] __lock_acquire+0x638/0x1b50 +[ 309.662383] ? __mutex_unlock_slowpath+0x3e/0x2e0 +[ 309.662388] ? trace_hardirqs_on+0xd/0x10 +[ 309.662392] ? _rcu_barrier+0x31/0x160 +[ 309.662396] lock_acquire+0xc9/0x220 +[ 309.662400] ? _rcu_barrier+0x31/0x160 +[ 309.662404] ? _rcu_barrier+0x31/0x160 +[ 309.662409] __mutex_lock+0x6e/0x990 +[ 309.662412] ? _rcu_barrier+0x31/0x160 +[ 309.662416] ? _rcu_barrier+0x31/0x160 +[ 309.662421] ? synchronize_rcu_expedited+0x35/0xb0 +[ 309.662426] ? _raw_spin_unlock_irqrestore+0x52/0x60 +[ 309.662434] mutex_lock_nested+0x16/0x20 +[ 309.662438] _rcu_barrier+0x31/0x160 +[ 309.662442] rcu_barrier+0x10/0x20 +[ 309.662464] i915_gem_shrink_all+0x33/0x40 [i915] +[ 309.662484] i915_drop_caches_set+0x141/0x150 [i915] +[ 309.662489] simple_attr_write+0xc7/0xe0 +[ 309.662494] full_proxy_write+0x4f/0x70 +[ 309.662498] __vfs_write+0x23/0x120 +[ 309.662503] ? rcu_read_lock_sched_held+0x75/0x80 +[ 309.662507] ? rcu_sync_lockdep_assert+0x2a/0x50 +[ 309.662512] ? __sb_start_write+0x102/0x210 +[ 309.662516] ? vfs_write+0x17d/0x1f0 +[ 309.662520] vfs_write+0xc6/0x1f0 +[ 309.662524] ? trace_hardirqs_on_caller+0xe7/0x200 +[ 309.662529] SyS_write+0x44/0xb0 +[ 309.662533] entry_SYSCALL_64_fastpath+0x1c/0xb1 +[ 309.662537] RIP: 0033:0x7f507eac24a0 +[ 309.662541] RSP: 002b:00007fffda8720e8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 +[ 309.662548] RAX: ffffffffffffffda RBX: ffffffff81482bd3 RCX: 00007f507eac24a0 +[ 309.662552] RDX: 0000000000000005 RSI: 00007fffda8720f0 RDI: 0000000000000005 +[ 309.662557] RBP: ffffc9000048bf88 R08: 0000000000000000 R09: 000000000000002c +[ 309.662561] R10: 0000000000000014 R11: 0000000000000246 R12: 00007fffda872230 +[ 309.662566] R13: 00007fffda872228 R14: 0000000000000201 R15: 00007fffda8720f0 +[ 309.662572] ? __this_cpu_preempt_check+0x13/0x20 + +Fixes: 0eafec6d3244 ("drm/i915: Enable lockless lookup of request tracking via RCU") +Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100192 +Signed-off-by: Chris Wilson +Cc: Daniel Vetter +Link: http://patchwork.freedesktop.org/patch/msgid/20170314115019.18127-1-chris@chris-wilson.co.uk +Reviewed-by: Daniel Vetter +(cherry picked from commit bd784b7cc41af7a19cfb705fa6d800e511c4ab02) +Signed-off-by: Jani Nikula +Link: http://patchwork.freedesktop.org/patch/msgid/20170321144531.12344-1-chris@chris-wilson.co.uk +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpu/drm/i915/i915_gem_shrinker.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/gpu/drm/i915/i915_gem_shrinker.c ++++ b/drivers/gpu/drm/i915/i915_gem_shrinker.c +@@ -263,7 +263,7 @@ unsigned long i915_gem_shrink_all(struct + I915_SHRINK_BOUND | + I915_SHRINK_UNBOUND | + I915_SHRINK_ACTIVE); +- rcu_barrier(); /* wait until our RCU delayed slab frees are completed */ ++ synchronize_rcu(); /* wait for our earlier RCU delayed slab frees */ + + return freed; + } diff --git a/queue-4.10/drm-i915-do-.init_clock_gating-earlier-to-avoid-it-clobbering-watermarks.patch b/queue-4.10/drm-i915-do-.init_clock_gating-earlier-to-avoid-it-clobbering-watermarks.patch new file mode 100644 index 00000000000..664f444c621 --- /dev/null +++ b/queue-4.10/drm-i915-do-.init_clock_gating-earlier-to-avoid-it-clobbering-watermarks.patch @@ -0,0 +1,92 @@ +From b7048ea12fbb2724ee0cd30752d4fac43cab0651 Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?Ville=20Syrj=C3=A4l=C3=A4?= +Date: Wed, 15 Mar 2017 16:31:58 +0200 +Subject: drm/i915: Do .init_clock_gating() earlier to avoid it clobbering watermarks +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Ville Syrjälä + +commit b7048ea12fbb2724ee0cd30752d4fac43cab0651 upstream. + +Currently ILK-BDW explicitly disable LP1+ watermarks from their +.init_clock_gating() hooks. Unfortunately that hook gets called way too +late since by that time we've already initialized all the watermark +state tracking which then gets out of sync with the hardware state. + +We may eventually want to consider killing off the explicit LP1+ +disable from .init_clock_gating(). In the meantime however, we can +avoid the problem by reordering the init sequence such that +intel_modeset_init_hw()->intel_init_clock_gating() gets called +prior to the hardware state takeover. + +I suppose prior to the two stage watermark programming we were +magically saved by something that forced the watermarks to be +reprogrammed fully after .init_clock_gating() got called. But +now that no longer happens. + +Note that the diff might look a bit odd as it kills off one +call of intel_update_cdclk(), but that's fine because +intel_modeset_init_hw() does the exact same thing. Previously +we just did it twice. + +Actually even this new init sequence is pretty bogus as +.init_clock_gating() really should be called before any gem +hardware init since it can configure various clock gating +workarounds and whatnot that affect the GT side as well. Also +intel_modeset_init() really should get split up into better +defined init stages. Another "fun" detail is that +intel_modeset_gem_init() is where RPS/RC6 gets configured. +Why that is done from the display code is beyond me. I've +decided to leave all this be for now, and just try to fix +the init sequence enough for watermarks to work. + +Cc: Gabriele Mazzotta +Cc: David Purton +Cc: Matt Roper +Cc: Maarten Lankhorst +Reported-by: Gabriele Mazzotta +Reported-by: David Purton +Tested-by: Gabriele Mazzotta +Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96645 +Fixes: ed4a6a7ca853 ("drm/i915: Add two-stage ILK-style watermark programming (v11)") +Signed-off-by: Ville Syrjälä +Link: http://patchwork.freedesktop.org/patch/msgid/20170220140443.30891-1-ville.syrjala@linux.intel.com +Reviewed-by: Daniel Vetter +Link: http://patchwork.freedesktop.org/patch/msgid/20170315143158.31780-1-ville.syrjala@linux.intel.com +(cherry picked from commit 5be6e33400992d3450e1c8234a5af353e1560580) +Signed-off-by: Jani Nikula +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpu/drm/i915/intel_display.c | 9 +++------ + 1 file changed, 3 insertions(+), 6 deletions(-) + +--- a/drivers/gpu/drm/i915/intel_display.c ++++ b/drivers/gpu/drm/i915/intel_display.c +@@ -16489,12 +16489,11 @@ int intel_modeset_init(struct drm_device + } + } + +- intel_update_czclk(dev_priv); +- intel_update_cdclk(dev_priv); +- dev_priv->atomic_cdclk_freq = dev_priv->cdclk_freq; +- + intel_shared_dpll_init(dev); + ++ intel_update_czclk(dev_priv); ++ intel_modeset_init_hw(dev); ++ + if (dev_priv->max_cdclk_freq == 0) + intel_update_max_cdclk(dev_priv); + +@@ -17049,8 +17048,6 @@ void intel_modeset_gem_init(struct drm_d + + intel_init_gt_powersave(dev_priv); + +- intel_modeset_init_hw(dev); +- + intel_setup_overlay(dev_priv); + } + diff --git a/queue-4.10/drm-i915-drop-support-for-i915_exec_constants_-execbuf-parameters.patch b/queue-4.10/drm-i915-drop-support-for-i915_exec_constants_-execbuf-parameters.patch new file mode 100644 index 00000000000..dec8b3507bc --- /dev/null +++ b/queue-4.10/drm-i915-drop-support-for-i915_exec_constants_-execbuf-parameters.patch @@ -0,0 +1,174 @@ +From 0f5418e564ac6452b9086295646e602a9addc4bf Mon Sep 17 00:00:00 2001 +From: Kenneth Graunke +Date: Mon, 13 Mar 2017 17:04:33 +0000 +Subject: drm/i915: Drop support for I915_EXEC_CONSTANTS_* execbuf parameters. + +From: Kenneth Graunke + +commit 0f5418e564ac6452b9086295646e602a9addc4bf upstream. + +This patch makes the I915_PARAM_HAS_EXEC_CONSTANTS getparam return 0 +(indicating the optional feature is not supported), and makes execbuf +always return -EINVAL if the flags are used. + +Apparently, no userspace ever shipped which used this optional feature: +I checked the git history of Mesa, xf86-video-intel, libva, and Beignet, +and there were zero commits showing a use of these flags. Kernel commit +72bfa19c8deb4 apparently introduced the feature prematurely. According +to Chris, the intention was to use this in cairo-drm, but "the use was +broken for gen6", so I don't think it ever happened. + +'relative_constants_mode' has always been tracked per-device, but this +has actually been wrong ever since hardware contexts were introduced, as +the INSTPM register is saved (and automatically restored) as part of the +render ring context. The software per-device value could therefore get +out of sync with the hardware per-context value. This meant that using +them is actually unsafe: a client which tried to use them could damage +the state of other clients, causing the GPU to interpret their BO +offsets as absolute pointers, leading to bogus memory reads. + +These flags were also never ported to execlist mode, making them no-ops +on Gen9+ (which requires execlists), and Gen8 in the default mode. + +On Gen8+, userspace can write these registers directly, achieving the +same effect. On Gen6-7.5, it likely makes sense to extend the command +parser to support them. I don't think anyone wants this on Gen4-5. + +Based on a patch by Dave Gordon. + +v3: Return -ENODEV for the getparam, as this is what we do for other + obsolete features. Suggested by Chris Wilson. + +Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92448 +Signed-off-by: Kenneth Graunke +Reviewed-by: Joonas Lahtinen +Reviewed-by: Chris Wilson +Link: http://patchwork.freedesktop.org/patch/msgid/20170215093446.21291-1-kenneth@whitecape.org +Acked-by: Daniel Vetter +Signed-off-by: Chris Wilson +Link: http://patchwork.freedesktop.org/patch/msgid/20170313170433.26843-1-chris@chris-wilson.co.uk +(cherry picked from commit ef0f411f51475f4eebf9fc1b19a85be698af19ff) +Signed-off-by: Jani Nikula +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpu/drm/i915/i915_drv.c | 4 -- + drivers/gpu/drm/i915/i915_drv.h | 2 - + drivers/gpu/drm/i915/i915_gem.c | 2 - + drivers/gpu/drm/i915/i915_gem_execbuffer.c | 52 +---------------------------- + 4 files changed, 3 insertions(+), 57 deletions(-) + +--- a/drivers/gpu/drm/i915/i915_drv.c ++++ b/drivers/gpu/drm/i915/i915_drv.c +@@ -248,6 +248,7 @@ static int i915_getparam(struct drm_devi + case I915_PARAM_IRQ_ACTIVE: + case I915_PARAM_ALLOW_BATCHBUFFER: + case I915_PARAM_LAST_DISPATCH: ++ case I915_PARAM_HAS_EXEC_CONSTANTS: + /* Reject all old ums/dri params. */ + return -ENODEV; + case I915_PARAM_CHIPSET_ID: +@@ -274,9 +275,6 @@ static int i915_getparam(struct drm_devi + case I915_PARAM_HAS_BSD2: + value = !!dev_priv->engine[VCS2]; + break; +- case I915_PARAM_HAS_EXEC_CONSTANTS: +- value = INTEL_GEN(dev_priv) >= 4; +- break; + case I915_PARAM_HAS_LLC: + value = HAS_LLC(dev_priv); + break; +--- a/drivers/gpu/drm/i915/i915_drv.h ++++ b/drivers/gpu/drm/i915/i915_drv.h +@@ -1805,8 +1805,6 @@ struct drm_i915_private { + + const struct intel_device_info info; + +- int relative_constants_mode; +- + void __iomem *regs; + + struct intel_uncore uncore; +--- a/drivers/gpu/drm/i915/i915_gem.c ++++ b/drivers/gpu/drm/i915/i915_gem.c +@@ -4567,8 +4567,6 @@ i915_gem_load_init(struct drm_device *de + init_waitqueue_head(&dev_priv->gpu_error.wait_queue); + init_waitqueue_head(&dev_priv->gpu_error.reset_queue); + +- dev_priv->relative_constants_mode = I915_EXEC_CONSTANTS_REL_GENERAL; +- + init_waitqueue_head(&dev_priv->pending_flip_queue); + + dev_priv->mm.interruptible = true; +--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c ++++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c +@@ -1410,10 +1410,7 @@ execbuf_submit(struct i915_execbuffer_pa + struct drm_i915_gem_execbuffer2 *args, + struct list_head *vmas) + { +- struct drm_i915_private *dev_priv = params->request->i915; + u64 exec_start, exec_len; +- int instp_mode; +- u32 instp_mask; + int ret; + + ret = i915_gem_execbuffer_move_to_gpu(params->request, vmas); +@@ -1424,56 +1421,11 @@ execbuf_submit(struct i915_execbuffer_pa + if (ret) + return ret; + +- instp_mode = args->flags & I915_EXEC_CONSTANTS_MASK; +- instp_mask = I915_EXEC_CONSTANTS_MASK; +- switch (instp_mode) { +- case I915_EXEC_CONSTANTS_REL_GENERAL: +- case I915_EXEC_CONSTANTS_ABSOLUTE: +- case I915_EXEC_CONSTANTS_REL_SURFACE: +- if (instp_mode != 0 && params->engine->id != RCS) { +- DRM_DEBUG("non-0 rel constants mode on non-RCS\n"); +- return -EINVAL; +- } +- +- if (instp_mode != dev_priv->relative_constants_mode) { +- if (INTEL_INFO(dev_priv)->gen < 4) { +- DRM_DEBUG("no rel constants on pre-gen4\n"); +- return -EINVAL; +- } +- +- if (INTEL_INFO(dev_priv)->gen > 5 && +- instp_mode == I915_EXEC_CONSTANTS_REL_SURFACE) { +- DRM_DEBUG("rel surface constants mode invalid on gen5+\n"); +- return -EINVAL; +- } +- +- /* The HW changed the meaning on this bit on gen6 */ +- if (INTEL_INFO(dev_priv)->gen >= 6) +- instp_mask &= ~I915_EXEC_CONSTANTS_REL_SURFACE; +- } +- break; +- default: +- DRM_DEBUG("execbuf with unknown constants: %d\n", instp_mode); ++ if (args->flags & I915_EXEC_CONSTANTS_MASK) { ++ DRM_DEBUG("I915_EXEC_CONSTANTS_* unsupported\n"); + return -EINVAL; + } + +- if (params->engine->id == RCS && +- instp_mode != dev_priv->relative_constants_mode) { +- struct intel_ring *ring = params->request->ring; +- +- ret = intel_ring_begin(params->request, 4); +- if (ret) +- return ret; +- +- intel_ring_emit(ring, MI_NOOP); +- intel_ring_emit(ring, MI_LOAD_REGISTER_IMM(1)); +- intel_ring_emit_reg(ring, INSTPM); +- intel_ring_emit(ring, instp_mask << 16 | instp_mode); +- intel_ring_advance(ring); +- +- dev_priv->relative_constants_mode = instp_mode; +- } +- + if (args->flags & I915_EXEC_GEN7_SOL_RESET) { + ret = i915_reset_gen7_sol_offsets(params->request); + if (ret) diff --git a/queue-4.10/drm-i915-only-enable-hotplug-interrupts-if-the-display-interrupts-are-enabled.patch b/queue-4.10/drm-i915-only-enable-hotplug-interrupts-if-the-display-interrupts-are-enabled.patch new file mode 100644 index 00000000000..da996184260 --- /dev/null +++ b/queue-4.10/drm-i915-only-enable-hotplug-interrupts-if-the-display-interrupts-are-enabled.patch @@ -0,0 +1,141 @@ +From 35a3abfd198e6c69a6644784bb09a2d951fc6b21 Mon Sep 17 00:00:00 2001 +From: Chris Wilson +Date: Mon, 13 Mar 2017 17:02:31 +0000 +Subject: drm/i915: Only enable hotplug interrupts if the display interrupts are enabled +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Chris Wilson + +commit 35a3abfd198e6c69a6644784bb09a2d951fc6b21 upstream. + +In order to prevent accessing the hpd registers outside of the display +power wells, we should refrain from writing to the registers before the +display interrupts are enabled. + +[ 4.740136] WARNING: CPU: 1 PID: 221 at drivers/gpu/drm/i915/intel_uncore.c:795 __unclaimed_reg_debug+0x44/0x50 [i915] +[ 4.740155] Unclaimed read from register 0x1e1110 +[ 4.740168] Modules linked in: i915(+) intel_gtt drm_kms_helper prime_numbers +[ 4.740190] CPU: 1 PID: 221 Comm: systemd-udevd Not tainted 4.10.0-rc6+ #384 +[ 4.740203] Hardware name: / , BIOS PYBSWCEL.86A.0027.2015.0507.1758 05/07/2015 +[ 4.740220] Call Trace: +[ 4.740236] dump_stack+0x4d/0x6f +[ 4.740251] __warn+0xc1/0xe0 +[ 4.740265] warn_slowpath_fmt+0x4a/0x50 +[ 4.740281] ? insert_work+0x77/0xc0 +[ 4.740355] ? fwtable_write32+0x90/0x130 [i915] +[ 4.740431] __unclaimed_reg_debug+0x44/0x50 [i915] +[ 4.740507] fwtable_read32+0xd8/0x130 [i915] +[ 4.740575] i915_hpd_irq_setup+0xa5/0x100 [i915] +[ 4.740649] intel_hpd_init+0x68/0x80 [i915] +[ 4.740716] i915_driver_load+0xe19/0x1380 [i915] +[ 4.740784] i915_pci_probe+0x32/0x90 [i915] +[ 4.740799] pci_device_probe+0x8b/0xf0 +[ 4.740815] driver_probe_device+0x2b6/0x450 +[ 4.740828] __driver_attach+0xda/0xe0 +[ 4.740841] ? driver_probe_device+0x450/0x450 +[ 4.740853] bus_for_each_dev+0x5b/0x90 +[ 4.740865] driver_attach+0x19/0x20 +[ 4.740878] bus_add_driver+0x166/0x260 +[ 4.740892] driver_register+0x5b/0xd0 +[ 4.740906] ? 0xffffffffa0166000 +[ 4.740920] __pci_register_driver+0x47/0x50 +[ 4.740985] i915_init+0x5c/0x5e [i915] +[ 4.740999] do_one_initcall+0x3e/0x160 +[ 4.741015] ? __vunmap+0x7c/0xc0 +[ 4.741029] ? kmem_cache_alloc+0xcf/0x120 +[ 4.741045] do_init_module+0x55/0x1c4 +[ 4.741060] load_module+0x1f3f/0x25b0 +[ 4.741073] ? __symbol_put+0x40/0x40 +[ 4.741086] ? kernel_read_file+0x100/0x190 +[ 4.741100] SYSC_finit_module+0xbc/0xf0 +[ 4.741112] SyS_finit_module+0x9/0x10 +[ 4.741125] entry_SYSCALL_64_fastpath+0x17/0x98 +[ 4.741135] RIP: 0033:0x7f8559a140f9 +[ 4.741145] RSP: 002b:00007fff7509a3e8 EFLAGS: 00000246 ORIG_RAX: 0000000000000139 +[ 4.741161] RAX: ffffffffffffffda RBX: 00007f855aba02d1 RCX: 00007f8559a140f9 +[ 4.741172] RDX: 0000000000000000 RSI: 000055b6db0914f0 RDI: 0000000000000011 +[ 4.741183] RBP: 0000000000020000 R08: 0000000000000000 R09: 000000000000000e +[ 4.741193] R10: 0000000000000011 R11: 0000000000000246 R12: 000055b6db0854d0 +[ 4.741204] R13: 000055b6db091150 R14: 0000000000000000 R15: 000055b6db035924 + +v2: Set dev_priv->display_irqs_enabled to true for all platforms other +than vlv/chv that manually control the display power domain. + +Fixes: 19625e85c6ec ("drm/i915: Enable polling when we don't have hpd") +Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97798 +Suggested-by: Ville Syrjälä +Signed-off-by: Chris Wilson +Cc: Lyude +Cc: Daniel Vetter +Cc: Ville Syrjälä +Cc: Hans de Goede +Reviewed-by: Ville Syrjälä +Link: http://patchwork.freedesktop.org/patch/msgid/20170215131547.5064-1-chris@chris-wilson.co.uk +Link: http://patchwork.freedesktop.org/patch/msgid/20170313170231.18633-1-chris@chris-wilson.co.uk +(cherry picked from commit 262fd485ac6b476479f41f00bb104f6a1766ae66) +Signed-off-by: Jani Nikula +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpu/drm/i915/i915_irq.c | 10 ++++++++++ + drivers/gpu/drm/i915/intel_hotplug.c | 14 ++++++++------ + 2 files changed, 18 insertions(+), 6 deletions(-) + +--- a/drivers/gpu/drm/i915/i915_irq.c ++++ b/drivers/gpu/drm/i915/i915_irq.c +@@ -4216,6 +4216,16 @@ void intel_irq_init(struct drm_i915_priv + if (!IS_GEN2(dev_priv)) + dev->vblank_disable_immediate = true; + ++ /* Most platforms treat the display irq block as an always-on ++ * power domain. vlv/chv can disable it at runtime and need ++ * special care to avoid writing any of the display block registers ++ * outside of the power domain. We defer setting up the display irqs ++ * in this case to the runtime pm. ++ */ ++ dev_priv->display_irqs_enabled = true; ++ if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) ++ dev_priv->display_irqs_enabled = false; ++ + dev->driver->get_vblank_timestamp = i915_get_vblank_timestamp; + dev->driver->get_scanout_position = i915_get_crtc_scanoutpos; + +--- a/drivers/gpu/drm/i915/intel_hotplug.c ++++ b/drivers/gpu/drm/i915/intel_hotplug.c +@@ -219,7 +219,7 @@ static void intel_hpd_irq_storm_reenable + } + } + } +- if (dev_priv->display.hpd_irq_setup) ++ if (dev_priv->display_irqs_enabled && dev_priv->display.hpd_irq_setup) + dev_priv->display.hpd_irq_setup(dev_priv); + spin_unlock_irq(&dev_priv->irq_lock); + +@@ -425,7 +425,7 @@ void intel_hpd_irq_handler(struct drm_i9 + } + } + +- if (storm_detected) ++ if (storm_detected && dev_priv->display_irqs_enabled) + dev_priv->display.hpd_irq_setup(dev_priv); + spin_unlock(&dev_priv->irq_lock); + +@@ -471,10 +471,12 @@ void intel_hpd_init(struct drm_i915_priv + * Interrupt setup is already guaranteed to be single-threaded, this is + * just to make the assert_spin_locked checks happy. + */ +- spin_lock_irq(&dev_priv->irq_lock); +- if (dev_priv->display.hpd_irq_setup) +- dev_priv->display.hpd_irq_setup(dev_priv); +- spin_unlock_irq(&dev_priv->irq_lock); ++ if (dev_priv->display_irqs_enabled && dev_priv->display.hpd_irq_setup) { ++ spin_lock_irq(&dev_priv->irq_lock); ++ if (dev_priv->display_irqs_enabled) ++ dev_priv->display.hpd_irq_setup(dev_priv); ++ spin_unlock_irq(&dev_priv->irq_lock); ++ } + } + + static void i915_hpd_poll_init_work(struct work_struct *work) diff --git a/queue-4.10/drm-i915-reject-hdmi-12bpc-if-the-sink-doesn-t-indicate-support.patch b/queue-4.10/drm-i915-reject-hdmi-12bpc-if-the-sink-doesn-t-indicate-support.patch new file mode 100644 index 00000000000..1c40e8015bd --- /dev/null +++ b/queue-4.10/drm-i915-reject-hdmi-12bpc-if-the-sink-doesn-t-indicate-support.patch @@ -0,0 +1,74 @@ +From 9c31b087348cb2b5e668261f2eee2f224b3780b5 Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?Ville=20Syrj=C3=A4l=C3=A4?= +Date: Mon, 13 Feb 2017 19:58:18 +0200 +Subject: drm/i915: Reject HDMI 12bpc if the sink doesn't indicate support +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Ville Syrjälä + +commit 9c31b087348cb2b5e668261f2eee2f224b3780b5 upstream. + +Check that the sink really declared 12bpc support before we enable it. +This should not actually never happen since it's mandatory for HDMI +sinks to support 12bpc if they support any deep color modes. But +reality disagrees with the theory and there are actually sinks in +the wild that violate the spec. + +v2: Fix the output_types check + Update commit message to state that these things are in fact real + +Cc: Nicholas Sielicki +Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99250 +Signed-off-by: Ville Syrjälä +Link: http://patchwork.freedesktop.org/patch/msgid/20170213175818.24958-1-ville.syrjala@linux.intel.com +Reviewed-by: Shashank Sharma +(cherry picked from commit c750bdd3e7e204cc88b32806c3864487a03cd84b) +Signed-off-by: Jani Nikula +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpu/drm/i915/intel_hdmi.c | 24 +++++++++++++++++++++--- + 1 file changed, 21 insertions(+), 3 deletions(-) + +--- a/drivers/gpu/drm/i915/intel_hdmi.c ++++ b/drivers/gpu/drm/i915/intel_hdmi.c +@@ -1293,16 +1293,34 @@ intel_hdmi_mode_valid(struct drm_connect + + static bool hdmi_12bpc_possible(struct intel_crtc_state *crtc_state) + { +- struct drm_device *dev = crtc_state->base.crtc->dev; ++ struct drm_i915_private *dev_priv = ++ to_i915(crtc_state->base.crtc->dev); ++ struct drm_atomic_state *state = crtc_state->base.state; ++ struct drm_connector_state *connector_state; ++ struct drm_connector *connector; ++ int i; + +- if (HAS_GMCH_DISPLAY(to_i915(dev))) ++ if (HAS_GMCH_DISPLAY(dev_priv)) + return false; + + /* + * HDMI 12bpc affects the clocks, so it's only possible + * when not cloning with other encoder types. + */ +- return crtc_state->output_types == 1 << INTEL_OUTPUT_HDMI; ++ if (crtc_state->output_types != 1 << INTEL_OUTPUT_HDMI) ++ return false; ++ ++ for_each_connector_in_state(state, connector, connector_state, i) { ++ const struct drm_display_info *info = &connector->display_info; ++ ++ if (connector_state->crtc != crtc_state->base.crtc) ++ continue; ++ ++ if ((info->edid_hdmi_dc_modes & DRM_EDID_HDMI_DC_36) == 0) ++ return false; ++ } ++ ++ return true; + } + + bool intel_hdmi_compute_config(struct intel_encoder *encoder, diff --git a/queue-4.10/drm-i915-stop-using-rp_down_ei-on-baytrail.patch b/queue-4.10/drm-i915-stop-using-rp_down_ei-on-baytrail.patch new file mode 100644 index 00000000000..c7239c10d71 --- /dev/null +++ b/queue-4.10/drm-i915-stop-using-rp_down_ei-on-baytrail.patch @@ -0,0 +1,177 @@ +From 8f68d591d4765b2e1ce9d916ac7bc5583285c4ad Mon Sep 17 00:00:00 2001 +From: Chris Wilson +Date: Mon, 13 Mar 2017 17:06:17 +0000 +Subject: drm/i915: Stop using RP_DOWN_EI on Baytrail + +From: Chris Wilson + +commit 8f68d591d4765b2e1ce9d916ac7bc5583285c4ad upstream. + +On Baytrail, we manually calculate busyness over the evaluation interval +to avoid issues with miscaluations with RC6 enabled. However, it turns +out that the DOWN_EI interrupt generator is completely bust - it +operates in two modes, continuous or never. Neither of which are +conducive to good behaviour. Stop unmask the DOWN_EI interrupt and just +compute everything from the UP_EI which does seem to correspond to the +desired interval. + +v2: Fixup gen6_rps_pm_mask() as well +v3: Inline vlv_c0_above() to combine the now identical elapsed +calculation for up/down and simplify the threshold testing + +Fixes: 43cf3bf084ba ("drm/i915: Improved w/a for rps on Baytrail") +Signed-off-by: Chris Wilson +Cc: Mika Kuoppala +Link: http://patchwork.freedesktop.org/patch/msgid/20170309211232.28878-1-chris@chris-wilson.co.uk +Reviewed-by: Mika Kuoppala +Link: http://patchwork.freedesktop.org/patch/msgid/20170313170617.31564-1-chris@chris-wilson.co.uk +(cherry picked from commit e0e8c7cb6eb68e9256de2d8cbeb481d3701c05ac) +Signed-off-by: Jani Nikula +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpu/drm/i915/i915_drv.h | 2 - + drivers/gpu/drm/i915/i915_irq.c | 73 +++++++++++++++------------------------- + drivers/gpu/drm/i915/intel_pm.c | 5 +- + 3 files changed, 32 insertions(+), 48 deletions(-) + +--- a/drivers/gpu/drm/i915/i915_drv.h ++++ b/drivers/gpu/drm/i915/i915_drv.h +@@ -1263,7 +1263,7 @@ struct intel_gen6_power_mgmt { + unsigned boosts; + + /* manual wa residency calculations */ +- struct intel_rps_ei up_ei, down_ei; ++ struct intel_rps_ei ei; + + /* + * Protects RPS/RC6 register access and PCU communication. +--- a/drivers/gpu/drm/i915/i915_irq.c ++++ b/drivers/gpu/drm/i915/i915_irq.c +@@ -1046,68 +1046,51 @@ static void vlv_c0_read(struct drm_i915_ + ei->media_c0 = I915_READ(VLV_MEDIA_C0_COUNT); + } + +-static bool vlv_c0_above(struct drm_i915_private *dev_priv, +- const struct intel_rps_ei *old, +- const struct intel_rps_ei *now, +- int threshold) +-{ +- u64 time, c0; +- unsigned int mul = 100; +- +- if (old->cz_clock == 0) +- return false; +- +- if (I915_READ(VLV_COUNTER_CONTROL) & VLV_COUNT_RANGE_HIGH) +- mul <<= 8; +- +- time = now->cz_clock - old->cz_clock; +- time *= threshold * dev_priv->czclk_freq; +- +- /* Workload can be split between render + media, e.g. SwapBuffers +- * being blitted in X after being rendered in mesa. To account for +- * this we need to combine both engines into our activity counter. +- */ +- c0 = now->render_c0 - old->render_c0; +- c0 += now->media_c0 - old->media_c0; +- c0 *= mul * VLV_CZ_CLOCK_TO_MILLI_SEC; +- +- return c0 >= time; +-} +- + void gen6_rps_reset_ei(struct drm_i915_private *dev_priv) + { +- vlv_c0_read(dev_priv, &dev_priv->rps.down_ei); +- dev_priv->rps.up_ei = dev_priv->rps.down_ei; ++ memset(&dev_priv->rps.ei, 0, sizeof(dev_priv->rps.ei)); + } + + static u32 vlv_wa_c0_ei(struct drm_i915_private *dev_priv, u32 pm_iir) + { ++ const struct intel_rps_ei *prev = &dev_priv->rps.ei; + struct intel_rps_ei now; + u32 events = 0; + +- if ((pm_iir & (GEN6_PM_RP_DOWN_EI_EXPIRED | GEN6_PM_RP_UP_EI_EXPIRED)) == 0) ++ if ((pm_iir & GEN6_PM_RP_UP_EI_EXPIRED) == 0) + return 0; + + vlv_c0_read(dev_priv, &now); + if (now.cz_clock == 0) + return 0; + +- if (pm_iir & GEN6_PM_RP_DOWN_EI_EXPIRED) { +- if (!vlv_c0_above(dev_priv, +- &dev_priv->rps.down_ei, &now, +- dev_priv->rps.down_threshold)) +- events |= GEN6_PM_RP_DOWN_THRESHOLD; +- dev_priv->rps.down_ei = now; +- } ++ if (prev->cz_clock) { ++ u64 time, c0; ++ unsigned int mul; ++ ++ mul = VLV_CZ_CLOCK_TO_MILLI_SEC * 100; /* scale to threshold% */ ++ if (I915_READ(VLV_COUNTER_CONTROL) & VLV_COUNT_RANGE_HIGH) ++ mul <<= 8; ++ ++ time = now.cz_clock - prev->cz_clock; ++ time *= dev_priv->czclk_freq; ++ ++ /* Workload can be split between render + media, ++ * e.g. SwapBuffers being blitted in X after being rendered in ++ * mesa. To account for this we need to combine both engines ++ * into our activity counter. ++ */ ++ c0 = now.render_c0 - prev->render_c0; ++ c0 += now.media_c0 - prev->media_c0; ++ c0 *= mul; + +- if (pm_iir & GEN6_PM_RP_UP_EI_EXPIRED) { +- if (vlv_c0_above(dev_priv, +- &dev_priv->rps.up_ei, &now, +- dev_priv->rps.up_threshold)) +- events |= GEN6_PM_RP_UP_THRESHOLD; +- dev_priv->rps.up_ei = now; ++ if (c0 > time * dev_priv->rps.up_threshold) ++ events = GEN6_PM_RP_UP_THRESHOLD; ++ else if (c0 < time * dev_priv->rps.down_threshold) ++ events = GEN6_PM_RP_DOWN_THRESHOLD; + } + ++ dev_priv->rps.ei = now; + return events; + } + +@@ -4178,7 +4161,7 @@ void intel_irq_init(struct drm_i915_priv + /* Let's track the enabled rps events */ + if (IS_VALLEYVIEW(dev_priv)) + /* WaGsvRC0ResidencyMethod:vlv */ +- dev_priv->pm_rps_events = GEN6_PM_RP_DOWN_EI_EXPIRED | GEN6_PM_RP_UP_EI_EXPIRED; ++ dev_priv->pm_rps_events = GEN6_PM_RP_UP_EI_EXPIRED; + else + dev_priv->pm_rps_events = GEN6_PM_RPS_EVENTS; + +--- a/drivers/gpu/drm/i915/intel_pm.c ++++ b/drivers/gpu/drm/i915/intel_pm.c +@@ -4913,8 +4913,9 @@ static u32 gen6_rps_pm_mask(struct drm_i + { + u32 mask = 0; + ++ /* We use UP_EI_EXPIRED interupts for both up/down in manual mode */ + if (val > dev_priv->rps.min_freq_softlimit) +- mask |= GEN6_PM_RP_DOWN_EI_EXPIRED | GEN6_PM_RP_DOWN_THRESHOLD | GEN6_PM_RP_DOWN_TIMEOUT; ++ mask |= GEN6_PM_RP_UP_EI_EXPIRED | GEN6_PM_RP_DOWN_THRESHOLD | GEN6_PM_RP_DOWN_TIMEOUT; + if (val < dev_priv->rps.max_freq_softlimit) + mask |= GEN6_PM_RP_UP_EI_EXPIRED | GEN6_PM_RP_UP_THRESHOLD; + +@@ -5014,7 +5015,7 @@ void gen6_rps_busy(struct drm_i915_priva + { + mutex_lock(&dev_priv->rps.hw_lock); + if (dev_priv->rps.enabled) { +- if (dev_priv->pm_rps_events & (GEN6_PM_RP_DOWN_EI_EXPIRED | GEN6_PM_RP_UP_EI_EXPIRED)) ++ if (dev_priv->pm_rps_events & GEN6_PM_RP_UP_EI_EXPIRED) + gen6_rps_reset_ei(dev_priv); + I915_WRITE(GEN6_PMINTRMSK, + gen6_rps_pm_mask(dev_priv, dev_priv->rps.cur_freq)); diff --git a/queue-4.10/orangefs-dan-carpenter-influenced-cleanups.patch b/queue-4.10/orangefs-dan-carpenter-influenced-cleanups.patch new file mode 100644 index 00000000000..d049fedaf1b --- /dev/null +++ b/queue-4.10/orangefs-dan-carpenter-influenced-cleanups.patch @@ -0,0 +1,89 @@ +From 05973c2efb40122f2a9ecde2d065f7ea5068d024 Mon Sep 17 00:00:00 2001 +From: Mike Marshall +Date: Thu, 9 Feb 2017 14:38:50 -0500 +Subject: orangefs: Dan Carpenter influenced cleanups... + +From: Mike Marshall + +commit 05973c2efb40122f2a9ecde2d065f7ea5068d024 upstream. + +This patch is simlar to one Dan Carpenter sent me, cleans +up some return codes and whitespace errors. There was one +place where he thought inserting an error message into +the ring buffer might be too chatty, I hope I convinced him +othewise. As a consolation I changed a truly chatty +error message in another location into a debug message, +system-admins had already yelled at me about that one... + +Signed-off-by: Mike Marshall +Signed-off-by: Greg Kroah-Hartman + +--- + fs/orangefs/devorangefs-req.c | 5 +++-- + fs/orangefs/orangefs-debugfs.c | 15 ++++++++------- + 2 files changed, 11 insertions(+), 9 deletions(-) + +--- a/fs/orangefs/devorangefs-req.c ++++ b/fs/orangefs/devorangefs-req.c +@@ -400,8 +400,9 @@ static ssize_t orangefs_devreq_write_ite + /* remove the op from the in progress hash table */ + op = orangefs_devreq_remove_op(head.tag); + if (!op) { +- gossip_err("WARNING: No one's waiting for tag %llu\n", +- llu(head.tag)); ++ gossip_debug(GOSSIP_DEV_DEBUG, ++ "%s: No one's waiting for tag %llu\n", ++ __func__, llu(head.tag)); + return ret; + } + +--- a/fs/orangefs/orangefs-debugfs.c ++++ b/fs/orangefs/orangefs-debugfs.c +@@ -967,13 +967,13 @@ int orangefs_debugfs_new_client_string(v + int ret; + + ret = copy_from_user(&client_debug_array_string, +- (void __user *)arg, +- ORANGEFS_MAX_DEBUG_STRING_LEN); ++ (void __user *)arg, ++ ORANGEFS_MAX_DEBUG_STRING_LEN); + + if (ret != 0) { + pr_info("%s: CLIENT_STRING: copy_from_user failed\n", + __func__); +- return -EIO; ++ return -EFAULT; + } + + /* +@@ -988,17 +988,18 @@ int orangefs_debugfs_new_client_string(v + */ + client_debug_array_string[ORANGEFS_MAX_DEBUG_STRING_LEN - 1] = + '\0'; +- ++ + pr_info("%s: client debug array string has been received.\n", + __func__); + + if (!help_string_initialized) { + + /* Build a proper debug help string. */ +- if (orangefs_prepare_debugfs_help_string(0)) { ++ ret = orangefs_prepare_debugfs_help_string(0); ++ if (ret) { + gossip_err("%s: no debug help string \n", + __func__); +- return -EIO; ++ return ret; + } + + } +@@ -1011,7 +1012,7 @@ int orangefs_debugfs_new_client_string(v + + help_string_initialized++; + +- return ret; ++ return 0; + } + + int orangefs_debugfs_new_debug(void __user *arg) diff --git a/queue-4.10/orangefs-fix-buffer-size-mis-match-between-kernel-space-and-user-space.patch b/queue-4.10/orangefs-fix-buffer-size-mis-match-between-kernel-space-and-user-space.patch new file mode 100644 index 00000000000..a6248c2fe4b --- /dev/null +++ b/queue-4.10/orangefs-fix-buffer-size-mis-match-between-kernel-space-and-user-space.patch @@ -0,0 +1,38 @@ +From eb68d0324dc4d88ab0d6159bdcd98c247a3a8954 Mon Sep 17 00:00:00 2001 +From: Mike Marshall +Date: Tue, 7 Feb 2017 12:41:02 -0500 +Subject: orangefs: fix buffer size mis-match between kernel space and user space. + +From: Mike Marshall + +commit eb68d0324dc4d88ab0d6159bdcd98c247a3a8954 upstream. + +The deamon through which the kernel module communicates with the userspace +part of Orangefs, the "client-core", sends initialization data to the +kernel module with ioctl. The initialization data was built by the +client-core in a 2k buffer and copy_from_user'd into a 1k buffer +in the kernel module. When more than 1k of initialization data needed +to be sent, some was lost, reducing the usability of the control by which +debug levels are set. This patch sets the kernel side buffer to 2K to +match the userspace side... + +Signed-off-by: Mike Marshall +Signed-off-by: Martin Brandenburg +Signed-off-by: Greg Kroah-Hartman + +--- + fs/orangefs/orangefs-dev-proto.h | 3 +-- + 1 file changed, 1 insertion(+), 2 deletions(-) + +--- a/fs/orangefs/orangefs-dev-proto.h ++++ b/fs/orangefs/orangefs-dev-proto.h +@@ -50,8 +50,7 @@ + * Misc constants. Please retain them as multiples of 8! + * Otherwise 32-64 bit interactions will be messed up :) + */ +-#define ORANGEFS_MAX_DEBUG_STRING_LEN 0x00000400 +-#define ORANGEFS_MAX_DEBUG_ARRAY_LEN 0x00000800 ++#define ORANGEFS_MAX_DEBUG_STRING_LEN 0x00000800 + + /* + * The maximum number of directory entries in a single request is 96. diff --git a/queue-4.10/series b/queue-4.10/series index 865f79ed2c2..57ffbfd231d 100644 --- a/queue-4.10/series +++ b/queue-4.10/series @@ -6,3 +6,11 @@ drm-i915-gen9-increase-pcode-request-timeout-to-50ms.patch drm-i915-store-a-permanent-error-in-obj-mm.pages.patch drm-i915-nuke-debug-messages-from-the-pipe-update-critical-section.patch drm-i915-avoid-tweaking-evaluation-thresholds-on-baytrail-v3.patch +drm-i915-reject-hdmi-12bpc-if-the-sink-doesn-t-indicate-support.patch +drm-i915-only-enable-hotplug-interrupts-if-the-display-interrupts-are-enabled.patch +drm-i915-drop-support-for-i915_exec_constants_-execbuf-parameters.patch +drm-i915-stop-using-rp_down_ei-on-baytrail.patch +drm-i915-avoid-rcu_barrier-from-reclaim-paths-shrinker.patch +drm-i915-do-.init_clock_gating-earlier-to-avoid-it-clobbering-watermarks.patch +orangefs-dan-carpenter-influenced-cleanups.patch +orangefs-fix-buffer-size-mis-match-between-kernel-space-and-user-space.patch