- 17 2月, 2016 1 次提交
-
-
由 Ville Syrjälä 提交于
Looks like g4x hpd live status bits actually agree with the spec. At least they do on the machine I have, and apparently on Nick Bowler's g4x as well. So gm45 may be the only platform where they don't agree. At least that seems to be the case based on the (somewhat incomplete) logs/dumps in [1], and Daniel has also tested this on his gm45 sometime in the past. So let's change the bits to match the spec on g4x. That actually makes the g4x bits identical to vlv/chv so we can just share the code between those platforms, leaving gm45 as the special case. [1] https://bugzilla.kernel.org/show_bug.cgi?id=52361 Cc: Shashank Sharma <shashank.sharma@intel.com> Cc: Sonika Jindal <sonika.jindal@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Nick Bowler <nbowler@draconx.ca> References: https://lists.freedesktop.org/archives/dri-devel/2016-February/100382.htmlReported-by: NNick Bowler <nbowler@draconx.ca> Cc: stable@vger.kernel.org Fixes: 237ed86c ("drm/i915: Check live status before reading edid") Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1455127145-20087-1-git-send-email-ville.syrjala@linux.intel.comReviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch> (cherry picked from commit 0780cd36) Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
- 11 2月, 2016 3 次提交
-
-
由 Rasmus Villemoes 提交于
This fails to undo the setup for pin==0; moreover, something interesting happens if the setup failed already at pin==0. Signed-off-by: NRasmus Villemoes <linux@rasmusvillemoes.dk> Fixes: f899fc64 ("drm/i915: use GMBUS to manage i2c links") Cc: stable@vger.kernel.org Signed-off-by: NJani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1455048677-19882-3-git-send-email-linux@rasmusvillemoes.dk (cherry picked from commit 2417c8c0) Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 Lyude 提交于
We accidentally point both cfgcr registers for the second shared DPLL to the same location in i915_reg.h. This results in a lot of hw pipe state mismatches whenever we try to do a modeset that requires allocating the DPLL to a CRTC: [drm:intel_pipe_config_compare [i915]] *ERROR* mismatch in dpll_hw_state.cfgcr1 (expected 0x80000168, found 0x000004a5) [drm:intel_pipe_config_compare [i915]] *ERROR* mismatch in base.adjusted_mode.crtc_clock (expected 108000, found 49500) [drm:intel_pipe_config_compare [i915]] *ERROR* mismatch in port_clock (expected 108000, found 49500) This usually ends up causing blank monitors, since the DPLL never can get set to the right clock. Fixes: 086f8e84 ("drm/i915: Prefix raw register defines with underscore") Signed-off-by: NLyude <cpaul@redhat.com> Cc: drm-intel-fixes@lists.freedesktop.org Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1454600601-21900-1-git-send-email-cpaul@redhat.com (cherry picked from commit da3b891b) Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 Lyude 提交于
We don't actually check for INTEL_OUTPUT_DP_MST at all in here, as a result we skip assigning a DPLL to any DP MST ports, which makes link training fail: [ 1442.933896] [drm:intel_power_well_enable] enabling DDI D power well [ 1442.933905] [drm:skl_set_power_well] Enabling DDI D power well [ 1442.933957] [drm:intel_mst_pre_enable_dp] 0 [ 1442.935474] [drm:intel_dp_set_signal_levels] Using signal levels 00000000 [ 1442.935477] [drm:intel_dp_set_signal_levels] Using vswing level 0 [ 1442.935480] [drm:intel_dp_set_signal_levels] Using pre-emphasis level 0 [ 1442.936190] [drm:intel_dp_set_signal_levels] Using signal levels 05000000 [ 1442.936193] [drm:intel_dp_set_signal_levels] Using vswing level 1 [ 1442.936195] [drm:intel_dp_set_signal_levels] Using pre-emphasis level 1 [ 1442.936858] [drm:intel_dp_set_signal_levels] Using signal levels 08000000 [ 1442.936862] [drm:intel_dp_set_signal_levels] Using vswing level 2 … [ 1442.998253] [drm:intel_dp_link_training_clock_recovery [i915]] *ERROR* too many full retries, give up [ 1442.998512] [drm:intel_dp_start_link_train [i915]] *ERROR* failed to train DP, aborting After which the pipe state goes completely out of sync: [ 70.075596] [drm:check_crtc_state] [CRTC:25] [ 70.075696] [drm:intel_pipe_config_compare [i915]] *ERROR* mismatch in ddi_pll_sel (expected 0x00000000, found 0x00000001) [ 70.075747] [drm:intel_pipe_config_compare [i915]] *ERROR* mismatch in shared_dpll (expected -1, found 0) [ 70.075798] [drm:intel_pipe_config_compare [i915]] *ERROR* mismatch in dpll_hw_state.ctrl1 (expected 0x00000000, found 0x00000021) [ 70.075840] [drm:intel_pipe_config_compare [i915]] *ERROR* mismatch in dpll_hw_state.cfgcr1 (expected 0x00000000, found 0x80400173) [ 70.075884] [drm:intel_pipe_config_compare [i915]] *ERROR* mismatch in dpll_hw_state.cfgcr2 (expected 0x00000000, found 0x000003a5) [ 70.075954] [drm:intel_pipe_config_compare [i915]] *ERROR* mismatch in base.adjusted_mode.crtc_clock (expected 262750, found 72256) [ 70.075999] [drm:intel_pipe_config_compare [i915]] *ERROR* mismatch in port_clock (expected 540000, found 148500) And if you're especially lucky, it keeps going downhill: [ 83.309256] Kernel panic - not syncing: Timeout: Not all CPUs entered broadcast exception handler [ 83.309265] [ 83.309265] ================================= [ 83.309266] [ INFO: inconsistent lock state ] [ 83.309267] 4.5.0-rc1Lyude-Test #265 Not tainted [ 83.309267] --------------------------------- [ 83.309268] inconsistent {IN-HARDIRQ-W} -> {HARDIRQ-ON-W} usage. [ 83.309270] Xorg/1194 [HC0[1]:SC0[0]:HE1:SE1] takes: [ 83.309293] (&(&dev_priv->uncore.lock)->rlock){?.-...}, at: [<ffffffffa02a6073>] gen9_write32+0x63/0x400 [i915] [ 83.309293] {IN-HARDIRQ-W} state was registered at: [ 83.309297] [<ffffffff810e84f4>] __lock_acquire+0x9c4/0x1d00 [ 83.309299] [<ffffffff810ea1be>] lock_acquire+0xce/0x1c0 [ 83.309302] [<ffffffff8177d936>] _raw_spin_lock_irqsave+0x56/0x90 [ 83.309321] [<ffffffffa02a5492>] gen9_read32+0x52/0x3d0 [i915] [ 83.309332] [<ffffffffa024beea>] gen8_irq_handler+0x27a/0x6a0 [i915] [ 83.309337] [<ffffffff810fdbc1>] handle_irq_event_percpu+0x41/0x300 [ 83.309339] [<ffffffff810fdeb9>] handle_irq_event+0x39/0x60 [ 83.309341] [<ffffffff811010b4>] handle_edge_irq+0x74/0x130 [ 83.309344] [<ffffffff81009073>] handle_irq+0x73/0x120 [ 83.309346] [<ffffffff817805f1>] do_IRQ+0x61/0x120 [ 83.309348] [<ffffffff8177e6d6>] ret_from_intr+0x0/0x20 [ 83.309351] [<ffffffff815f5105>] cpuidle_enter_state+0x105/0x330 [ 83.309353] [<ffffffff815f5367>] cpuidle_enter+0x17/0x20 [ 83.309356] [<ffffffff810dbe1a>] call_cpuidle+0x2a/0x50 [ 83.309358] [<ffffffff810dc1dd>] cpu_startup_entry+0x26d/0x3a0 [ 83.309360] [<ffffffff817701da>] rest_init+0x13a/0x140 [ 83.309363] [<ffffffff81f2af8e>] start_kernel+0x475/0x482 [ 83.309365] [<ffffffff81f2a315>] x86_64_start_reservations+0x2a/0x2c [ 83.309367] [<ffffffff81f2a452>] x86_64_start_kernel+0x13b/0x14a Fixes: 82d35437 ("drm/i915/skl: Implementation of SKL DPLL programming") Signed-off-by: NLyude <cpaul@redhat.com> Cc: stable@vger.kernel.org Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1454428183-994-1-git-send-email-cpaul@redhat.com (cherry picked from commit 78385cb3) Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
- 09 2月, 2016 1 次提交
-
-
由 Matt Roper 提交于
Due to our lack of two-step watermark programming, our driver has historically pretended that the cursor plane is always on for the purpose of watermark calculations; this helps avoid serious flickering when the cursor turns off/on (e.g., when the user moves the mouse pointer to a different screen). That workaround was accidentally dropped as we started working toward atomic watermark updates. Since we still aren't quite there yet with two-stage updates, we need to resurrect the workaround and treat the cursor as always active. v2: Tweak cursor width calculations slightly to more closely match the logic we used before the atomic overhaul began. (Ville) Cc: simdev11@outlook.com Cc: manfred.kitzbichler@gmail.com Cc: drm-intel-fixes@lists.freedesktop.org Reported-by: simdev11@outlook.com Reported-by: manfred.kitzbichler@gmail.com Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93892 Fixes: 43d59eda ("drm/i915: Eliminate usage of plane_wm_parameters from ILK-style WM code (v2)") Signed-off-by: NMatt Roper <matthew.d.roper@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1454479611-6804-1-git-send-email-matthew.d.roper@intel.com (cherry picked from commit b2435692) Signed-off-by: NJani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1454958328-30129-1-git-send-email-matthew.d.roper@intel.com
-
- 08 2月, 2016 7 次提交
-
-
由 Jani Nikula 提交于
Per spec, TPS3 support is mandatory for downstream devices that support HBR2. We've therefore logged errors on HBR2 without TPS3 since commit 1da7d713 Author: Jani Nikula <jani.nikula@intel.com> Date: Thu Sep 3 11:16:08 2015 +0300 drm/i915: ignore link rate in TPS3 selection However, it seems there are real world devices out there that just aren't spec compliant, and still work at HBR2 using TPS2. So reduce the error message to debug logging. Cc: Ander Conselvan de Oliveira <conselvan2@gmail.com> Cc: Sivakumar Thulasimani <sivakumar.thulasimani@intel.com> Reviewed-by: NSivakumar Thulasimani <sivakumar.thulasimani@intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92932 Fixes: 1da7d713 ("drm/i915: ignore link rate in TPS3 selection") Cc: drm-intel-fixes@lists.freedesktop.org Signed-off-by: NJani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1454667370-8001-2-git-send-email-jani.nikula@intel.com (cherry picked from commit bfcef5d2) Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 Jani Nikula 提交于
Make it cleaner to add more checks in the function. No functional changes. Cc: Ander Conselvan de Oliveira <conselvan2@gmail.com> Cc: Sivakumar Thulasimani <sivakumar.thulasimani@intel.com> Reviewed-by: NSivakumar Thulasimani <sivakumar.thulasimani@intel.com> Cc: drm-intel-fixes@lists.freedesktop.org # dependency on the next patch Signed-off-by: NJani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1454667370-8001-1-git-send-email-jani.nikula@intel.com (cherry picked from commit 23a5110d) Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 Jani Nikula 提交于
Skip v3 gpio element because the support is not there, and skip gpio element on non-vlv because the sideband code is vlv specific. v2: the gpio stuff is currently only supported on vlv (Ville) Cc: drm-intel-fixes@lists.freedesktop.org Fixes: 2a33d934 ("drm/i915/bios: add support for MIPI sequence block v3") Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NJani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1454604767-2440-1-git-send-email-jani.nikula@intel.com (cherry picked from commit 96afef1d) Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 Jani Nikula 提交于
Since sequence block v2 the second byte contains flags other than just pull up/down. Don't pass arbitrary data to the sideband interface. The rest may or may not work for sequence block v2, but there should be no harm done. Cc: stable@vger.kernel.org Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NJani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/ebe3c2eee623afc4b3a134533b01f8d591d13f32.1454582914.git.jani.nikula@intel.com (cherry picked from commit 4e1c63e3) Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 Jani Nikula 提交于
Do not blindly trust the VBT data used for indexing. Cc: stable@vger.kernel.org Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NJani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/cc32d40c2b47f2d2151811855ac2c3dabab1d57d.1454582914.git.jani.nikula@intel.com (cherry picked from commit 5d2d0a12) Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 Matt Roper 提交于
Our attempts save/restore panel power state in i915_suspend.c are causing unclaimed register warnings on BXT since the registers for this platform differ from older platforms. The big hammer suspend/resume shouldn't be necessary for PP since the connector/encoder hooks should already handle this. In theory we could remove this for all platforms, but in practice it's likely that would cause some regressions since older platforms with LVDS may have incomplete PP handling. For now we'll leave the PCH save/restore alone and change the non-PCH branch to only operate on gen <= 4 so that BXT and future platforms aren't included. v2: Typo fix: s/||/&&/ v3: Change non-PCH condition to a gen <= 4 test rather than listing VLV/CHV/BXT as specific platforms to exclude; should be more future-proof as we add new platforms. (Daniel) Cc: Vandana Kannan <vandana.kannan@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: drm-intel-fixes@lists.freedesktop.org Signed-off-by: NMatt Roper <matthew.d.roper@intel.com> Reviewed-by: NJani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1452102821-17190-1-git-send-email-matthew.d.roper@intel.com (cherry picked from commit e1ea0754) Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 Chris Wilson 提交于
commit 033908ae Author: Dave Gordon <david.s.gordon@intel.com> Date: Thu Dec 10 18:51:23 2015 +0000 drm/i915: mark GEM object pages dirty when mapped & written by the CPU introduced a check into i915_gem_object_get_dirty_pages() that returned a NULL pointer when called with a bad object, one that was not backed by shmemfs. This WARN was too strict as we can work on all struct page backed objects, and resulted in a WARN + GPF for existing userspace. In order to differentiate the various types of objects, add a new flags field to the i915_gem_object_ops struct to describe their capabilities, with the first flag being whether the object has struct pages. v2: Drop silly const before an integer in the structure declaration. Testcase: igt/gem_userptr_blits/relocations Reported-and-tested-by: NKristian Høgsberg Kristensen <krh@bitplanet.net> Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: Dave Gordon <david.s.gordon@intel.com> Cc: Kristian Høgsberg Kristensen <krh@bitplanet.net> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: NDave Gordon <david.s.gordon@intel.com> Reviewed-by: NKristian Høgsberg Kristensen <krh@bitplanet.net> Tested-by: NMichal Winiarski <michal.winiarski@intel.com> Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com> Fixes: 033908ae ("drm/i915: mark GEM object pages dirty when mapped & written by the CPU") Link: http://patchwork.freedesktop.org/patch/msgid/1453487551-16799-1-git-send-email-chris@chris-wilson.co.uk (cherry picked from commit de472664) Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
- 29 1月, 2016 6 次提交
-
-
由 Gerd Hoffmann 提交于
The test for the qemu q35 south bridge added by commit "39bfcd52 drm/i915: more virtual south bridge detection" also matches on real hardware. Having the check for virtual systems last in the list is not enough to avoid that ... Refine the check by additionally verifying the pci subsystem id to see whenever it *really* is qemu. [ v2: fix subvendor tyops ] Reported-and-tested-by: NBjørn Mork <bjorn@mork.no> Signed-off-by: NGerd Hoffmann <kraxel@redhat.com> Tested-by: NBruno Wolff III <bruno@wolff.to> Cc: drm-intel-fixes@lists.freedesktop.org Signed-off-by: NJani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1453719748-10944-1-git-send-email-kraxel@redhat.com (cherry picked from commit 1e859111)
-
由 Andreas Ziegler 提交于
Commit 5bab6f60 ("drm/i915: Serialise updates to GGTT with access through GGTT on Braswell") depended upon a working stop_machine() and so forced the selection of STOP_MACHINE. However, commit 86fffe4a ("kernel: remove stop_machine() Kconfig dependency") removed the option STOP_MACHINE from init/Kconfig and ensured that stop_machine() universally works. Due to the order in which the patches were applied, removing the select from DRM_I915 got lost during merging. Remove the now obsolete select statement. Signed-off-by: NAndreas Ziegler <andreas.ziegler@fau.de> Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/1453722079-2604-1-git-send-email-andreas.ziegler@fau.de Cc: drm-intel-fixes@lists.freedesktop.org Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch> (cherry picked from commit 21fabbeb) Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 Ville Syrjälä 提交于
In this atomic age, we can't trust the plane->fb pointer anymore. It might get update too late. Instead we are supposed to use the plane_state->fb pointer instead. Let's do that in intel_plane_obj_offset() and avoid problems from dereferencing the potentially stale plane->fb pointer. Paulo found this with 'kms_frontbuffer_tracking --show-hidden --run-subtest nop-1p-rte' but it can be reproduced with just plain old kms_setplane. I was too lazy to bisect this, so not sure exactly when it broke. The most obvious candidate commit ce7f1728 ("drm/i915: Fix i915_ggtt_view_equal to handle rotation correctly") was actually still fine, so it must have broken some time after that. Here's the resulting fireworks: BUG: unable to handle kernel NULL pointer dereference at (null) IP: [<ffffffffa02d2d9a>] intel_fill_fb_ggtt_view+0x1b/0x15a [i915] PGD 8a5f6067 PUD 8a5f5067 PMD 0 Oops: 0000 [#1] PREEMPT SMP Modules linked in: i915 i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops drm intel_gtt agpgart netconsole mousedev hid_generic psmouse usbhid atkbd libps2 coretemp hwmon efi_pstore intel_rapl iosf_mbi x86_pkg_temp_thermal efivars pcspkr e1000e sdhci_pci ptp pps_core sdhci i2c_i801 mmc_core i2c_hid hid i8042 serio evdev sch_fq_codel ip_tables x_tables ipv6 autofs4 CPU: 1 PID: 260 Comm: kms_plane Not tainted 4.4.0-skl+ #171 Hardware name: Intel Corporation Skylake Client platform/Skylake Y LPDDR3 RVP3, BIOS SKLSE2R1.R00.B104.B00.1511030553 11/03/2015 task: ffff88008bde2d80 ti: ffff88008a6ec000 task.ti: ffff88008a6ec000 RIP: 0010:[<ffffffffa02d2d9a>] [<ffffffffa02d2d9a>] intel_fill_fb_ggtt_view+0x1b/0x15a [i915] RSP: 0018:ffff88008a6efa10 EFLAGS: 00010086 RAX: 0000000000000001 RBX: ffff8801674f4240 RCX: 0000000000000014 RDX: ffff88008a7440c0 RSI: 0000000000000000 RDI: ffff88008a6efa40 RBP: ffff88008a6efa30 R08: ffff88008bde3598 R09: 0000000000000001 R10: ffff88008b782000 R11: 0000000000000000 R12: 0000000000000000 R13: ffff88008a7440c0 R14: 0000000000000000 R15: ffff88008a7449c0 FS: 00007fa0c07a28c0(0000) GS:ffff88016ec40000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000008a6ff000 CR4: 00000000003406e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Stack: ffff8801674f4240 0000000000000000 ffff88008a7440c0 0000000000000000 ffff88008a6efaa0 ffffffffa02daf25 ffffffff814ec80e 0000000000070298 ffff8800850d0000 ffff88008a6efaa0 ffffffffa02c49c2 0000000000000002 Call Trace: [<ffffffffa02daf25>] intel_plane_obj_offset+0x2d/0xa9 [i915] [<ffffffff814ec80e>] ? _raw_spin_unlock_irqrestore+0x4b/0x60 [<ffffffffa02c49c2>] ? gen9_write32+0x2e8/0x3b8 [i915] [<ffffffffa02eecfc>] skl_update_plane+0x203/0x4c5 [i915] [<ffffffffa02ca1ab>] intel_plane_atomic_update+0x53/0x6a [i915] [<ffffffffa02494a4>] drm_atomic_helper_commit_planes_on_crtc+0x142/0x1d5 [drm_kms_helper] [<ffffffffa02de44b>] intel_atomic_commit+0x1262/0x1350 [i915] [<ffffffffa024a0ee>] ? __drm_atomic_helper_crtc_duplicate_state+0x2f/0x41 [drm_kms_helper] [<ffffffffa01ef089>] ? drm_atomic_check_only+0x3e3/0x552 [drm] [<ffffffffa01ef245>] drm_atomic_commit+0x4d/0x52 [drm] [<ffffffffa024996b>] drm_atomic_helper_update_plane+0xcb/0x118 [drm_kms_helper] [<ffffffffa01e42e8>] __setplane_internal+0x1c8/0x224 [drm] [<ffffffffa01e477f>] drm_mode_setplane+0x14e/0x172 [drm] [<ffffffffa01d8117>] drm_ioctl+0x265/0x3ad [drm] [<ffffffffa01e4631>] ? drm_mode_cursor_common+0x158/0x158 [drm] [<ffffffff810d00ab>] ? current_kernel_time64+0x5e/0x98 [<ffffffff810a76ea>] ? trace_hardirqs_on_caller+0x17a/0x196 [<ffffffff8119880f>] do_vfs_ioctl+0x42b/0x4ea [<ffffffff811a2b72>] ? __fget_light+0x4d/0x71 [<ffffffff81198911>] SyS_ioctl+0x43/0x61 [<ffffffff814ed057>] entry_SYSCALL_64_fastpath+0x12/0x6f Cc: drm-intel-fixes@lists.freedesktop.org Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Testcase: igt/kms_plane Reported-by: NPaulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1453220597-28973-1-git-send-email-ville.syrjala@linux.intel.comReviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch> (cherry picked from commit e7941294) Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 Ville Syrjälä 提交于
On SKL+ plane scaling is mutually exclusive with color keying. The code check for this, but during some refactoring the code got changed to also reject primary plane windowing when color keying is used. There is no such restriction in the hardware, so restore the original logic. Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Fixes: 061e4b8d ("drm/i915: clean up atomic plane check functions, v2.") Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1452883613-28549-1-git-send-email-ville.syrjala@linux.intel.com Cc: stable@vger.kernel.org Reviewed-by: NMatt Roper <matthew.d.roper@intel.com> Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com> (cherry picked from commit 693bdc28) Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 Jani Nikula 提交于
Per DP spec, the source device should fall back to 18 bpp, VESA range RGB when the sink capability is unknown. Fix the color depth clamping. 18 bpp color depth should ensure full color range in automatic mode. The clamping has been HDMI specific since its introduction in commit 996a2239 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Fri Apr 19 11:24:34 2013 +0200 drm/i915: Disable high-bpc on pre-1.4 EDID screens Cc: stable@vger.kernel.org Reported-and-tested-by: NDihan Wickremasuriya <nayomal@gmail.com> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=105331Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NJani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1452695720-7076-1-git-send-email-jani.nikula@intel.com (cherry picked from commit 013dd9e0)
-
由 Francisco Jerez 提交于
We need to set the DC FLUSH PIPE_CONTROL bit on Gen7+ to guarantee that writes performed via the HDC are visible in memory. Fixes an intermittent failure in a Piglit test that writes to a BO from a shader using GL atomic counters (implemented as HDC untyped atomics) and then expects the memory to read back the same value after mapping it on the CPU. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91298Tested-by: NMark Janes <mark.a.janes@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: stable@vger.kernel.org Signed-off-by: NFrancisco Jerez <currojerez@riseup.net> Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1452740379-3194-1-git-send-email-currojerez@riseup.net (cherry picked from commit 965fd602) Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
- 13 1月, 2016 8 次提交
-
-
由 Daniel Vetter 提交于
Since commit ac9b8236 Author: Ville Syrjälä <ville.syrjala@linux.intel.com> Date: Fri Nov 27 18:55:26 2015 +0200 drm/i915: Introduce a gmbus power domain gmbus also needs the power domain infrastructure right from the start, since as soon as we register the i2c controllers someone can use them. v2: Adjust cleanup paths too (Chris). v3: Rebase onto -nightly (totally bogus tree I had lying around) and also move dpio init head (Ville). v4: Ville instead suggested to move gmbus setup later in the sequence, since it's only needed by the modeset code. v5: Move even close to the actual user, right next to the comment that states where we really need gmbus (and interrupts!). Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Patrik Jakobsson <patrik.jakobsson@linux.intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Meelis Roos <mroos@linux.ee> Cc: Chris Wilson <chris@chris-wilson.co.uk> Fixes: ac9b8236 ("drm/i915: Introduce a gmbus power domain") Cc: stable@vger.kernel.org References: http://www.spinics.net/lists/intel-gfx/msg83075.htmlSigned-off-by: NDaniel Vetter <daniel.vetter@intel.com> Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1452682528-19437-1-git-send-email-daniel.vetter@ffwll.chSigned-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Michel Thierry 提交于
Kernel and userspace are able to handle 4GB (1<<32) address space range, but "A32 Stateless Model" is not. According to documentation, A32 accesses are based on General State Base Address and bound checking is in place. Because size field (instruction State Base Address) limitation, it is not possible to address full 4GB memory region. A32 Stateless Model is used by some libraries and without this patch, the last page of 4GB address space is not accessible in 32bit processes. Reported-by: NArtur Harasimiuk <artur.harasimiuk@intel.com> Signed-off-by: NMichel Thierry <michel.thierry@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1452512367-23614-1-git-send-email-michel.thierry@intel.com Cc: drm-intel-fixes@lists.freedesktop.org Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch> (cherry picked from commit 1892faa9) Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 Maarten Lankhorst 提交于
This fixes a spurious warning from an integer overflow on 64-bits systems. The function may return MAX_SCHEDULE_TIMEOUT which gets truncated to -1. Explicitly handling this by casting to lret fixes it. Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com> Reported-and-tested-by: NJoseph Yasi <joe.yasi@gmail.com> Tested-by: NAndreas Reis <andreas.reis@gmail.com> Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Cc: drm-intel-fixes@lists.freedesktop.org Fixes: 3c28ff22 ("i915: wait for fence in prepare_plane_fb") Link: http://patchwork.freedesktop.org/patch/msgid/5666EEC8.2000403@linux.intel.com (cherry picked from commit bcf8be27) Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 Lyude 提交于
This fixes reprobing of display connectors on resume. After some talking with danvet on IRC, I learned that calling drm_helper_hpd_irq_event() does actually trigger a full reprobe of each connector's status. It turns out this is the actual reason reprobing on resume hasn't been working (this was observed on a T440s): - We call hpd_init() - We check each connector for a couple of things before marking connector->polled with DRM_CONNECTOR_POLL_HPD, one of which is an active encoder. Of course, a disconnected port won't have an active encoder, so we don't add the flag to any of the connectors. - We call drm_helper_hpd_irq_event() - drm_helper_irq_event() checks each connector for the DRM_CONNECTOR_POLL_HPD flag. The only one that has it is eDP-1, so we skip reprobing each connector except that one. In addition, we also now avoid setting connector->polled to DRM_CONNECTOR_POLL_HPD for MST connectors, since their reprobing is handled by the mst helpers. This is probably what was originally intended to happen here. Changes since V1: * Use the explanation of the issue as the commit message instead * Change the title of the commit, since this does more then just stop a check for an encoder now * Add "Fixes" line for the patch that introduced this regression * Don't enable DRM_CONNECTOR_POLL_HPD for mst connectors Changes since V2: * Put patch changelog above Signed-off-by * Follow Daniel Vetter's suggestion for making the code here a bit more legible Fixes: 0e32b39c ("drm/i915: add DP 1.2 MST support (v0.7)") Cc: stable@vger.kernel.org Signed-off-by: NLyude <cpaul@redhat.com> Link: http://patchwork.freedesktop.org/patch/msgid/1452181408-14777-1-git-send-email-cpaul@redhat.comSigned-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch> (cherry picked from commit 07c51913) Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 Jani Nikula 提交于
We still keep getting [ 4.249930] [drm:gen8_irq_handler [i915]] *ERROR* The master control interrupt lied (SDE)! This reverts commit 820da7ae Author: Jani Nikula <jani.nikula@intel.com> Date: Wed Nov 25 16:47:23 2015 +0200 Revert "drm/i915: shut up gen8+ SDE irq dmesg noise" which in itself is a revert, so this is just doing commit 97e5ed11 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Fri Oct 23 10:56:12 2015 +0200 drm/i915: shut up gen8+ SDE irq dmesg noise all over again. I'll stop pretending I understand what's going on like I did when I thought I'd fixed this for good in commit 6a39d7c9 Author: Jani Nikula <jani.nikula@intel.com> Date: Wed Nov 25 16:47:22 2015 +0200 drm/i915: fix the SDE irq dmesg warnings properly Reported-by: NChris Wilson <chris@chris-wilson.co.uk> Reference: http://mid.gmane.org/20151213124945.GA5715@nuc-i3427.alporthouse.com Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92084 Cc: drm-intel-fixes@lists.freedesktop.org Fixes: 820da7ae ("Revert "drm/i915: shut up gen8+ SDE irq dmesg noise"") Acked-by: NChris Wilson <chris@chris-wilson.co.uk> Acked-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: NJani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1452155350-14658-1-git-send-email-jani.nikula@intel.com (cherry picked from commit 2dfb0b81) Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 Chris Wilson 提交于
Following a GPU reset, we may leave the context in a poorly defined state, and reloading from that context will leave the GPU flummoxed. For secondary contexts, this will lead to that context being banned - but currently it is also causing the default context to become banned, leading to turmoil in the shared state. This is a regression from commit 6702cf16 [v4.1] Author: Ben Widawsky <benjamin.widawsky@intel.com> Date: Mon Mar 16 16:00:58 2015 +0000 drm/i915: Initialize all contexts which quietly introduced the removal of the MI_RESTORE_INHIBIT on the default context. v2: Mark the global default context as uninitialized on GPU reset so that the context-local workarounds are reloaded upon re-enabling. Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: Michel Thierry <michel.thierry@intel.com> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1448630935-27377-1-git-send-email-chris@chris-wilson.co.ukReviewed-by: NMika Kuoppala <mika.kuoppala@intel.com> Cc: stable@vger.kernel.org [danvet: This seems to fix a gpu hand on after the first resume, resulting in any future suspend operation failing with -EIO because the gpu seems to be in a funky state. Somehow this patch fixes that.] Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch> (cherry picked from commit 42f1cae8) Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 Daniel Vetter 提交于
They're causing massive amounts of dmesg noise and hence CI noise all over the place. Enabling them for a bit was good enough to refresh our task list of what's still needed to enable rpm by default. To make sure we're not forgetting to make this noisy again add a FIXME comment. Fixes: da5827c3 ("drm/i915: add assert_rpm_wakelock_held helper") Cc: Imre Deak <imre.deak@intel.com> Cc: drm-intel-fixes@lists.freedesktop.org Cc: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: NChris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/1452012847-4737-1-git-send-email-daniel.vetter@ffwll.chSigned-off-by: NDaniel Vetter <daniel.vetter@intel.com> (cherry picked from commit becd9ca2) Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 Michał Winiarski 提交于
According to PRM, some parts of HW require the addresses to be in a canonical form, where bits [63:48] == [47]. Let's convert addresses to canonical form prior to relocating and return converted offsets to userspace. We also need to make sure that userspace is using addresses in canonical form in case of softpin. v2: Whitespace fixup, gen8_canonical_addr description (Chris, Ville) v3: Rebase on top of softpin, fix a hole in relocate_entry, s/expect/require (Chris) v4: Handle softpin in validate_exec_list (Chris) v5: Convert back to canonical form at copy_to_user time (Chris) v6: Don't use struct exec_object2 in place of exec_object v7: Use sign_extend64 for converting to canonical form (Joonas), reject non-canonical and non-page-aligned offset for softpin (Chris) v8: Convert back to non-canonical form in a function, split the test for EXEC_OBJECT_PINNED (Chris) v9: s/canonial/canonical, drop accidental double newline (Chris) Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Michel Thierry <michel.thierry@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NMichał Winiarski <michal.winiarski@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1451409892-13708-1-git-send-email-michal.winiarski@intel.com Testcase: igt/gem_bad_reloc/negative-reloc-blt Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92699 Cc: drm-intel-fixes@lists.freedesktop.org Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch> (cherry picked from commit 934acce3) Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
- 06 1月, 2016 1 次提交
-
-
由 Maarten Lankhorst 提交于
drm/i915: Update connector_mask during readout, v2. The connector_mask may be used any time during the non-atomic .crtc_disable which is called before the full atomic state is set up and needs to be accurate for that reason. Changes since v1: - Update connector_mask in readout_hw_state and add a comment. Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/568D1C55.8010001@linux.intel.comSigned-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 05 1月, 2016 1 次提交
-
-
由 Maarten Lankhorst 提交于
The atomic helper sets connector_state->connector, which the i915 code didn't. This will become a problem when we start using it. Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com> Acked-by: NThierry Reding <treding@nvidia.com> Link: http://patchwork.freedesktop.org/patch/msgid/1451908400-25147-1-git-send-email-maarten.lankhorst@linux.intel.comSigned-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 04 1月, 2016 1 次提交
-
-
由 Julia Lawall 提交于
The drm_dp_mst_topology_cbs structures are never modified, so declare them as const. Done with the help of Coccinelle. Signed-off-by: NJulia Lawall <Julia.Lawall@lip6.fr> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 30 12月, 2015 1 次提交
-
-
由 Gary Wang 提交于
The total delay of HDMI hotplug detecting with 30ms is sometimes not enoughtfor HDMI live status up with specific HDMI monitors in BSW platform. After doing experiments for following monitors, it needs 80ms at least for those worst cases. Lenovo L246 1xwA (4 failed, necessary hot-plug delay: 58/40/60/40ms) Philips HH2AP (9 failed, necessary hot-plug delay: 80/50/50/60/46/40/58/58/39ms) BENQ ET-0035-N (6 failed, necessary hot-plug delay: 60/50/50/80/80/40ms) DELL U2713HM (2 failed, necessary hot-plug delay: 58/59ms) HP HP-LP2475w (5 failed, necessary hot-plug delay: 70/50/40/60/40ms) It looks like 70-80 ms is BSW platform needs in some bad cases of the monitors at this end (8 times delay at most). Keep less than 100ms for HDCP pulse HPD low (with at least 100ms) to respond a plug out. Reviewed-by: NCooper Chiou <cooper.chiou@intel.com> Tested-by: NGary Wang <gary.c.wang@intel.com> Cc: Gavin Hindman <gavin.hindman@intel.com> Cc: Sonika Jindal <sonika.jindal@intel.com> Cc: Shashank Sharma <shashank.sharma@intel.com> Cc: Shobhit Kumar <shobhit.kumar@intel.com> Signed-off-by: NGary Wang <gary.c.wang@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1450858295-12804-1-git-send-email-gary.c.wang@intel.comTested-by: NShobhit Kumar <shobhit.kumar@intel.com> Cc: drm-intel-fixes@lists.freedesktop.org Fixes: 237ed86c ("drm/i915: Check live status before reading edid") Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch> (cherry picked from commit f8d03ea0) [Jani: undo the file mode change of the original commit] Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
- 23 12月, 2015 1 次提交
-
-
由 Ville Syrjälä 提交于
Atomic changes broke check_digital_port_conflicts(). It needs to look at the global situation instead of just trying to find a conflict within the current atomic state. This bug made my HSW explode spectacularly after I had split the DDI encoders into separate DP and HDMI encoders. With the fix, things seem much more solid. I hope holding the connection_mutex is enough protection that we can actually walk the connectors even if they're not part of the current atomic state... v2: Regenerate the patch so that it actually applies (Jani) Cc: stable@vger.kernel.org Cc: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Fixes: 5448a00d ("drm/i915: Don't use staged config in check_digital_port_conflicts()") Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1449764551-12466-1-git-send-email-ville.syrjala@linux.intel.com (cherry picked from commit 0bff4858) Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
- 22 12月, 2015 9 次提交
-
-
由 Chris Wilson 提交于
There was a silent conflict between commit 0a878716 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Thu Oct 15 14:23:01 2015 +0200 drm/i915: restore ggtt double-bind avoidance and commit 5bab6f60 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Fri Oct 23 18:43:32 2015 +0100 drm/i915: Serialise updates to GGTT with access through GGTT on Braswell thankfully caught by the extra WARN safegaurd in 0a878716. Since we now override the GGTT insert_pages callback when installing the aliasing ppgtt, we assert that the callback is the original ggtt routine. However, on Braswell we now use a different insertion routine to serialise access through the GGTT with updating the PTE and hence the conflict. To avoid the conflict, move the custom insertion routine for Braswell down a level. Reported-by: Ville Syrjälä <ville.syrjala@linux.intel.com Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Michel Thierry <michel.thierry@intel.com> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1447859979-20107-1-git-send-email-chris@chris-wilson.co.ukReviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Tested-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Cc: drm-intel-fixes@lists.freedesktop.org Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch> (cherry picked from commit c140330b) Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 Gary Wang 提交于
The total delay of HDMI hotplug detecting with 30ms have already been split into a resolution of 3 retries of 10ms each, for the worst cases. But it still suffered from only waiting 10ms at most in intel_hdmi_detect(). This patch corrects it by reading hotplug status with 4 times at most for 30ms delay. v2: - straight up to loop execution for more clear in code readability - mdelay will replace with msleep by Daniel's new patch drm/i915: mdelay(10) considered harmful - suggest to re-evaluate try times for being compatible to old HDMI monitor Reviewed-by: NCooper Chiou <cooper.chiou@intel.com> Tested-by: NGary Wang <gary.c.wang@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Gavin Hindman <gavin.hindman@intel.com> Cc: Sonika Jindal <sonika.jindal@intel.com> Cc: Shashank Sharma <shashank.sharma@intel.com> Signed-off-by: NGary Wang <gary.c.wang@intel.com> [danvet: fixup conflict with s/mdelay/msleep/ patch.] Cc: drm-intel-fixes@lists.freedesktop.org Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch> (cherry picked from commit 61fb3980) Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 Daniel Vetter 提交于
I missed this myself when reviewing commit 237ed86c Author: Sonika Jindal <sonika.jindal@intel.com> Date: Tue Sep 15 09:44:20 2015 +0530 drm/i915: Check live status before reading edid Long sleeps like this really shouldn't waste cpu cycles spinning. Cc: Sonika Jindal <sonika.jindal@intel.com> Cc: "Wang, Gary C" <gary.c.wang@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1449859455-32609-1-git-send-email-daniel.vetter@ffwll.chReviewed-by: NSonika Jindal <sonika.jindal@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch> (cherry picked from commit 71a199ba) Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 Ville Syrjälä 提交于
The vma may have been rebound between the last time the cursor was enabled and now, so skipping the cursor gtt offset deduction is not safe unless we would also reset cursor_bo to NULL when disabling the cursor. Just thow cursor_bo to the bin instead since it's lost all other uses thanks to universal plane support. Chris pointed out that cursor updates are currently too slow via universal planes that micro optimizations like these wouldn't even help. v2: Add a note about futility of micro optimizations (Chris) Cc: drm-intel-fixes@lists.freedesktop.org References: http://lists.freedesktop.org/archives/intel-gfx/2015-December/082976.html Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Takashi Iwai <tiwai@suse.de> Cc: Jani Nikula <jani.nikula@linux.intel.com> Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1450107302-17171-1-git-send-email-ville.syrjala@linux.intel.comReviewed-by: NChris Wilson <chris@chris-wilson.co.uk> (cherry picked from commit 1264859d) Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 Ville Syrjälä 提交于
Turns out CHV pipe C was glued on somewhat poorly, and there's something wrong with the cursor. If the cursor straddles the left screen edge, and is then moved away from the edge or disabled, the pipe will often underrun. If enough underruns are triggered quickly enough the pipe will fall over and die (it just scans out a solid color and reports a constant underrun). We need to turn the disp2d power well off and on again to recover the pipe. None of that is very nice for the user, so let's just refuse to place the cursor in the compromised position. The ddx appears to fall back to swcursor when the ioctl returns an error, so theoretically there's no loss of functionality for the user (discounting swcursor bugs). I suppose most cursors images actually have the hotspot not exactly at 0,0 so under typical conditions the fallback will in fact kick in as soon as the cursor touches the left edge of the screen. Any atomic compositor should anyway be prepared to fall back to GPU composition when things don't work out, so there should be no problem with those. Other things that I tried to solve this include flipping all display related clock gating knobs I could find, increasing the minimum gtt alignment all the way up to 512k. I also tried to see if there are more specific screen coordinates that hit the bug, but the findings were somewhat inconclusive. Sometimes the failures happen almost across the whole left edge, sometimes more at the very top and around the bottom half. I wasn't able to find any real pattern to these variations, so it seems our only choice is to just refuse to straddle the left screen edge at all. Cc: stable@vger.kernel.org Cc: Jason Plum <max@warheads.net> Testcase: igt/kms_chv_cursor_fail Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92826Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1450459479-16286-1-git-send-email-ville.syrjala@linux.intel.comSigned-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch> (cherry picked from commit b29ec92c) Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 Chris Wilson 提交于
Limit busywaiting only to the request currently being processed by the GPU. If the request is not currently being processed by the GPU, there is a very low likelihood of it being completed within the 2 microsecond spin timeout and so we will just be wasting CPU cycles. v2: Check for logical inversion when rebasing - we were incorrectly checking for this request being active, and instead busywaiting for when the GPU was not yet processing the request of interest. v3: Try another colour for the seqno names. v4: Another colour for the function names. v5: Remove the forced coherency when checking for the active request. On reflection and plenty of recent experimentation, the issue is not a cache coherency problem - but an irq/seqno ordering problem (timing issue). Here, we do not need the w/a to force ordering of the read with an interrupt. Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Cc: "Rogozhkin, Dmitry V" <dmitry.v.rogozhkin@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Cc: Eero Tamminen <eero.t.tamminen@intel.com> Cc: "Rantala, Valtteri" <valtteri.rantala@intel.com> Cc: stable@vger.kernel.org Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1449833608-22125-4-git-send-email-chris@chris-wilson.co.uk (cherry picked from commit 821485dc) Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 Chris Wilson 提交于
When waiting for high frequency requests, the finite amount of time required to set up the irq and wait upon it limits the response rate. By busywaiting on the request completion for a short while we can service the high frequency waits as quick as possible. However, if it is a slow request, we want to sleep as quickly as possible. The tradeoff between waiting and sleeping is roughly the time it takes to sleep on a request, on the order of a microsecond. Based on measurements of synchronous workloads from across big core and little atom, I have set the limit for busywaiting as 10 microseconds. In most of the synchronous cases, we can reduce the limit down to as little as 2 miscroseconds, but that leaves quite a few test cases regressing by factors of 3 and more. The code currently uses the jiffie clock, but that is far too coarse (on the order of 10 milliseconds) and results in poor interactivity as the CPU ends up being hogged by slow requests. To get microsecond resolution we need to use a high resolution timer. The cheapest of which is polling local_clock(), but that is only valid on the same CPU. If we switch CPUs because the task was preempted, we can also use that as an indicator that the system is too busy to waste cycles on spinning and we should sleep instead. __i915_spin_request was introduced in commit 2def4ad9 [v4.2] Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Tue Apr 7 16:20:41 2015 +0100 drm/i915: Optimistically spin for the request completion v2: Drop full u64 for unsigned long - the timer is 32bit wraparound safe, so we can use native register sizes on smaller architectures. Mention the approximate microseconds units for elapsed time and add some extra comments describing the reason for busywaiting. v3: Raise the limit to 10us v4: Now 5us. Reported-by: NJens Axboe <axboe@kernel.dk> Link: https://lkml.org/lkml/2015/11/12/621Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Cc: "Rogozhkin, Dmitry V" <dmitry.v.rogozhkin@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Cc: Eero Tamminen <eero.t.tamminen@intel.com> Cc: "Rantala, Valtteri" <valtteri.rantala@intel.com> Cc: stable@vger.kernel.org Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1449833608-22125-3-git-send-email-chris@chris-wilson.co.uk (cherry picked from commit ca5b721e) Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 Chris Wilson 提交于
The busywait in __i915_spin_request() does not respect pending signals and so may consume the entire timeslice for the task instead of returning to userspace to handle the signal. In the worst case this could cause a delay in signal processing of 20ms, which would be a noticeable jitter in cursor tracking. If a higher resolution signal was being used, for example to provide fairness of a server timeslices between clients, we could expect to detect some unfairness between clients (i.e. some windows not updating as fast as others). This issue was noticed when inspecting a report of poor interactivity resulting from excessively high __i915_spin_request usage. Fixes regression from commit 2def4ad9 [v4.2] Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Tue Apr 7 16:20:41 2015 +0100 drm/i915: Optimistically spin for the request completion v2: Try to assess the impact of the bug Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Cc: Jens Axboe <axboe@kernel.dk> Cc; "Rogozhkin, Dmitry V" <dmitry.v.rogozhkin@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Cc: Eero Tamminen <eero.t.tamminen@intel.com> Cc: "Rantala, Valtteri" <valtteri.rantala@intel.com> Cc: stable@vger.kernel.org Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1449833608-22125-2-git-send-email-chris@chris-wilson.co.uk (cherry picked from commit 91b0c352) Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 Matt Roper 提交于
If we fail to reconstruct the BIOS fb (e.g., because the FB is too large), we'll be left with plane state that indicates the primary plane is visible yet has a NULL fb. This mismatch causes problems later on (e.g., for the watermark code). Since we've failed to reconstruct the BIOS FB, the best solution is to just disable the primary plane and pretend the BIOS never had it enabled. v2: Add intel_pre_disable_primary() call (Maarten) Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Ville Syrjälä <ville.syrjala@intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: drm-intel-fixes@lists.freedesktop.org Signed-off-by: NMatt Roper <matthew.d.roper@intel.com> Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1449171462-30763-2-git-send-email-matthew.d.roper@intel.com (cherry picked from commit 200757f5) Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-