- 11 Feb, 2016 1 commit
-
-
Daniele Ceraolo Spurio authored
While running some tests on the scheduler patches with rpm enabled I came across a corruption in the ringbuffer, which was root-caused to the GPU being suspended while commands were being emitted to the ringbuffer. The access to memory was failing because the GPU needs to be awake when accessing stolen memory (where my ringbuffer was located). Since we have this constraint it looks like a sensible idea to check that we hold a refcount when we access the rungbuffer. v2: move the check from ring_begin to ringbuffer iomap time (Chris) v3: update comment (Chris) Cc: John Harrison <John.C.Harrison@Intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1453909429-11024-1-git-send-email-daniele.ceraolospurio@intel.com
-
- 10 Feb, 2016 7 commits
-
-
Rasmus Villemoes authored
This fails to undo the setup for pin==0; moreover, something interesting happens if the setup failed already at pin==0. Signed-off-by:
Rasmus Villemoes <linux@rasmusvillemoes.dk> Fixes: f899fc64 ("drm/i915: use GMBUS to manage i2c links") Cc: stable@vger.kernel.org Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1455048677-19882-3-git-send-email-linux@rasmusvillemoes.dk
-
Daniel Vetter authored
The AGP_INTEL driver provides an interface for very old userspace to control the GART (though the GART itself was only ever emulated on Intel systems). The pci bridge discovery code is also used by the i915.ko driver to set up the GTT on old systems, but it does not require the old userspace interface. When i915.ko selects the old interface, it binds another user to the core GTT routines, and in particular creates a second reference to the scratch pages allocated. This hinders resource leak debugging for when we unload i915.ko as we want to assert that all DMA pages have been released, but we appear to leak because of the secondary interface which persists after i915.ko unloads. All i915.ko users do not require the old /dev/agpgart interface so stop selecting it and simplify our debugging by dropping the historical baggage. Note that by selecting AGP=n it was already possible to unselect AGP_INTEL. But since we've dropped support for any of the AGP stuff long ago there's really no point for this any more. Also note that we still need INTEL_GTT, which is the underlying, shared, driver for the graphics GART on gen1-5. v2: Entirely new commit message (Chris, Ville). Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Daniel Vetter <daniel.vetter@intel.com> Reviewed-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
Daniel Vetter authored
Recently discovered by enabling CONFIG_DMA_API_DEBUG in our CI. By the looks of it broken since forever. v2: Don't forget to set the scratch page back to wb (Chris). Reuse intel_gtt_teardown_scratch_page for that (and fix it up to treat needs_dmar y/n correctly). Cc: Chris Wilson <chris@chris-wilson.co.uk> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93793Signed-off-by:
-
Arun Siluvery authored
Revision id along with device id is useful in better identification of the HW and its limitations so include this detail in error state. v2: make it clear that it is PCI revision and We might as well dump PCI subsystem details while we update this (Ville, Chris). Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Arun Siluvery <arun.siluvery@linux.intel.com> Signed-off-by:
-
Nick Hoath authored
Swap the order of context & engine cleanup, so that contexts are cleaned up first, and *then* engines. This is a more sensible order anyway, but in particular has become necessary since the 'intel_ring_initialized() must be simple and inline' patch, which now uses ring->dev as an 'initialised' flag, so it can now be NULL after engine teardown. This in turn can cause a problem in the context code, which (used to) check the ring->dev->struct_mutex -- causing a fault if ring->dev was NULL. Also rename the cleanup function to reflect what it actually does (cleanup engines, not a ringbuffer), and fix an annoying whitespace issue. v2: Also make the fix in i915_load_modeset_init, not just in i915_driver_unload (Chris Wilson) v3: Had extra stuff in it. v4: Reverted extra stuff (so we're back to v2). Rebased and updated commentary above (Dave Gordon). Signed-off-by:Nick Hoath <nicholas.hoath@intel.com> Signed-off-by:
David Gordon <david.s.gordon@intel.com> Reviewed-by:
-
Gabriel Feceoru authored
Some Gen7/8 production parts may have the Display Pipe C fused off. In this case, the display hardware will prevent the enable bit in PIPE_CONF register (for Pipe C) from being set to 1. Fixed by adjusting pipe_count to reflect this. v2: Rename HSW_PIPE_C_DISABLE to IVB_PIPE_C_DISABLE as it already exists on ivybridge (Ville) v3: Remove unnecessary MMIO read, correct the description (Damien) v4: Be more specific in description (Patrick) Signed-off-by:Gabriel Feceoru <gabriel.feceoru@intel.com> Reviewed-by:
Patrik Jakobsson <patrik.jakobsson@linux.intel.com> Signed-off-by:
-
Lyude authored
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:
Lyude <cpaul@redhat.com> Cc: drm-intel-fixes@lists.freedesktop.org Reviewed-by:
-
- 09 Feb, 2016 3 commits
-
-
Mika Kahola authored
Skip DDI PLL selection if display type is DSI/MIPI. Signed-off-by:
Mika Kahola <mika.kahola@intel.com> Reviewed-by:
Sivakumar Thulasimani <sivakumar.thulasimani@intel.com> Signed-off-by:
-
Lyude authored
Assuming any connector that isn't DP, MST, or HDMI is eDP definitely seems likely to cover up other bugs in the future. Signed-off-by:
-
Lyude authored
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:
-
- 08 Feb, 2016 4 commits
-
-
Michał Winiarski authored
Used by production devices: Intel(R) Iris Graphics 540 (Skylake GT3e) Intel(R) Iris Graphics 550 (Skylake GT3e) v2: More ids v3: Less ids (GT1 got duplicated) Cc: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by:Michał Winiarski <michal.winiarski@intel.com> Reviewed-by:
Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by:
-
Maarten Lankhorst authored
It's safe to assume cxsr is already disabled when the crtc is off. This prevents an unclaimed register warning when the required power wells are not enabled. [ 262.864984] ------------[ cut here ]------------ [ 262.865025] WARNING: CPU: 1 PID: 6799 at drivers/gpu/drm/i915/intel_uncore.c:638 __unclaimed_reg_debug+0x68/0x80 [i915]() [ 262.865029] Unclaimed register detected before reading register 0x186500 [ 262.865032] Modules linked in: i915 intel_powerclamp [ 262.865057] CPU: 1 PID: 6799 Comm: kms_pipe_crc_ba Tainted: G U W 4.4.0-gfxbench+ #1 [ 262.865060] Hardware name: DN2820FYK, BIOS FYBYT10H.86A.0038.2014.0717.1455 07/17/2014 [ 262.865064] ffffffffa0338cf8 ffff88007448ba78 ffffffff813df90c ffff88007448bac0 [ 262.865071] ffff88007448bab0 ffffffff810746e1 0000000000186500 0000000000000001 [ 262.865077] 0000000000000001 ffff880074420000 0000000000000000 ffff88007448bb10 [ 262.865083] Call Trace: [ 262.865092] [<ffffffff813df90c>] dump_stack+0x4e/0x82 [ 262.865098] [<ffffffff810746e1>] warn_slowpath_common+0x81/0xc0 [ 262.865102] [<ffffffff81074767>] warn_slowpath_fmt+0x47/0x50 [ 262.865128] [<ffffffffa02a07e8>] __unclaimed_reg_debug+0x68/0x80 [i915] [ 262.865154] [<ffffffffa02a0e4e>] vlv_read32+0x2de/0x370 [i915] [ 262.865173] [<ffffffffa0256837>] intel_set_memory_cxsr+0x87/0x1a0 [i915] [ 262.865200] [<ffffffffa02c4cb3>] intel_pre_plane_update+0xb3/0xf0 [i915] [ 262.865228] [<ffffffffa02c54b5>] intel_atomic_commit+0x3b5/0x17c0 [i915] [ 262.865234] [<ffffffff8150dc45>] ? drm_atomic_check_only+0x145/0x660 [ 262.865239] [<ffffffff8150d75a>] ? drm_atomic_set_crtc_for_connector+0x6a/0xe0 [ 262.865243] [<ffffffff8150e192>] drm_atomic_commit+0x32/0x50 [ 262.865249] [<ffffffff814eb155>] drm_atomic_helper_set_config+0x75/0xb0 [ 262.865253] [<ffffffff814fd090>] drm_mode_set_config_internal+0x60/0x110 [ 262.865258] [<ffffffff81501e26>] drm_mode_setcrtc+0x186/0x4f0 [ 262.865263] [<ffffffff814f3eed>] drm_ioctl+0x13d/0x590 [ 262.865267] [<ffffffff81501ca0>] ? drm_mode_setplane+0x1b0/0x1b0 [ 262.865273] [<ffffffff811d4c4c>] do_vfs_ioctl+0x2fc/0x550 [ 262.865278] [<ffffffff8118d5ea>] ? vm_munmap+0x4a/0x60 [ 262.865283] [<ffffffff811e06ba>] ? __fget_light+0x6a/0x90 [ 262.865287] [<ffffffff811d4edc>] SyS_ioctl+0x3c/0x70 [ 262.865292] [<ffffffff8179a75b>] entry_SYSCALL_64_fastpath+0x16/0x73 [ 262.865296] ---[ end trace 6387a0ad001bb39f ]--- Testcase: kms_flip.basic-flip-vs-wf_vblank Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93698Signed-off-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1454514805-10595-4-git-send-email-maarten.lankhorst@linux.intel.comReviewed-by:
-
Maarten Lankhorst authored
This can be derived from the atomic state in pre_plane_update, which makes it more clear when it's supposed to be called. Reviewed-by:
Ander Conselvan de Oliveira <conselvan2@gmail.com> Signed-off-by:
-
Maarten Lankhorst authored
This is a revert of commit 066cf55b "drm/i915: Fix IPS related flicker". intel_pre_disable_primary already handles this, and now everything goes through the atomic path there's no need to try to disable ips twice. Signed-off-by:
-
- 05 Feb, 2016 3 commits
-
-
Sagar Arun Kamble authored
RC6 setup is shared between BIOS and Driver. BIOS sets up subset of RC6 setup registers. If those are not setup Driver should not enable RC6. For implementing this, driver can check RC_CTRL0 and RC_CTRL1 values to know if BIOS has enabled HW/SW RC6. This will also enable user to control RC6 using BIOS settings alone. RC6 related instability can be avoided by disabling via BIOS settings till driver fixes it. v2: Had placed logic in gen8 function by mistake. Fixed it. Ensuring RPM is not enabled in case BIOS disabled RC6. v3: Need to disable RPM if RC6 is disabled due to BIOS settings. (Daniel) Runtime PM enabling happens before gen9_enable_rc6. Moved the updation of enable_rc6 parameter in intel_uncore_sanitize. v4: Added elaborate check for BIOS RC6 setup. Prepared check_pctx for bxt. (Imre) v5: Caching reserved stolen base and size in the driver private data. Reorganized RC6 setup check. Moved from gen9_enable_rc6 to intel_uncore_sanitize. (Imre) v6: Rebasing on the patch submitted by Imre that moves gem_init_stolen earlier in the load. v7: Removed PWRCTX_MAXCNT_VCSUNIT1 check as it applies to SKL. (Imre) v8: Fixed formatting and checkpatch issues. Fixed functional issue where RC6 ctx size check was missing. (Imre) Cc: Imre Deak <imre.deak@intel.com> Signed-off-by:Sagar Arun Kamble <sagar.a.kamble@intel.com> Signed-off-by:
Imre Deak <imre.deak@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1454697809-22113-1-git-send-email-sagar.a.kamble@intel.com
-
Jani Nikula authored
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:
-
Jani Nikula authored
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:
-
- 04 Feb, 2016 11 commits
-
-
Jani Nikula authored
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:
-
Deepak M authored
Make the gpio read/write functions more generic iosf sideband read/write functions, taking the iosf port as argument. v2: rebase v3: rebase v4 by Jani: address Ville's review v5 by Jani: drop the PCI_DEVFN change (Ville) Signed-off-by:
Deepak M <m.deepak@intel.com> Reviewed-by:
-
Jani Nikula authored
Not needed. Signed-off-by:
-
Jani Nikula authored
Make it easier to spot duplicates. Signed-off-by:
-
Jani Nikula authored
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:
-
Jani Nikula authored
Do not blindly trust the VBT data used for indexing. Cc: stable@vger.kernel.org Reviewed-by:
-
Paulo Zanoni authored
Now that we have top-level gen-independent hw_activate and hw_deactivate functions, set fbc->active directly from them, removing the duplicated code. Reviewed-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1454101060-23198-3-git-send-email-paulo.r.zanoni@intel.com
-
Paulo Zanoni authored
The recent introduction of a new caller of dev_priv->fbc.deactivate() is a good example of why we need unexport those functions. Anything outside intel_fbc.c should only call the functions exported by intel_fbc.c, so in order to enforce that, kill the function pointers stored inside dev_priv->fbc and replace them with functions that can't be called from outside intel_fbc.c. This should make it much harder for new code to call these functions from outside intel_fbc.c. Reviewed-by:
-
Paulo Zanoni authored
FBC is already deactivated at this point. Besides, nothing should be calling these lower-level function pointers. A few months ago, the only caller of dev_priv->fbc.deactivate was intel_pipe_set_base_atomic(), which was the kgdboc function. But the following commit added it to the SKL function: commit a8d201af Author: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Date: Thu Jan 7 11:54:11 2016 +0100 drm/i915: Use plane state for primary plane updates. Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: -
Tim Gore authored
WaIncreaseDefaultTLBEntries increases the number of TLB entries available for GPGPU workloads and gives significant ( > 10% ) performance gain for some OCL benchmarks. Put this in a new function that can be a place for workarounds that are GT related but not required per ring. This function is called on driver load and also after a reset and on resume, so it is safe for workarounds that get clobbered in these situations. This function currently has just this one workaround. v2: This was originally split into 3 patches but following review feedback was squashed into 1. I have not incorporated some style comments from Chris Wilson as I felt that after defining and intialising a temporary variable and then adding an additional if block to only write the register if the temporary variable had been set, this didn't really give a net gain. v3: Resending in the hope that BAT will run v4: Change subject line to trigger BAT (please!) Signed-off-by:
Tim Gore <tim.gore@intel.com> Reviewed-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1454586574-2343-1-git-send-email-tim.gore@intel.com
-
Ramalingam C authored
We need to enable DSI PLL before configuring the DSI registers. This has worked before on BYT/CHV, but BXT is more fussy. Signed-off-by:
Ramalingam C <ramalingam.c@intel.com> Reviewed-by:
-
- 03 Feb, 2016 3 commits
-
-
Chris Wilson authored
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:
Kristian Høgsberg Kristensen <krh@bitplanet.net> Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1453487551-16799-1-git-send-email-chris@chris-wilson.co.uk
-
Matt Roper authored
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:Matt Roper <matthew.d.roper@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1454479611-6804-1-git-send-email-matthew.d.roper@intel.com
-
Matt Roper authored
In commit bfb9faab8 we added a workaround for some BXT BIOS that fail to properly initialize the DDI_A_4_LANES bit of the control register (4 lanes is the only valid configuration on BXT since there is no DDI E to share with). A recent patch added some additional checks on this register bit before the workaround gets applied; this breaks eDP on BXT in some settings. Some minor code shuffling is all we need to restore the workaround. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Fixes: 7cd87cb80 ("drm/i915: Check max number of lanes when registering DDI ports") Signed-off-by:
-
- 02 Feb, 2016 7 commits
-
-
Matt Roper authored
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: -
Imre Deak authored
Signed-off-by:
David Weinehall <david.weinehall@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1454071949-24677-4-git-send-email-imre.deak@intel.com
-
Imre Deak authored
While not being able to enable MSI interrupts may be a normal circumstance, for debugging it may still be a useful information, so emit an info about this. Signed-off-by:
-
Imre Deak authored
Atm we wouldn't catch these errors or on the error path we would end up with a division-by-zero, fix this up. Signed-off-by:
-
Imre Deak authored
While we are calling intel_dp_aux_transfer() with msg->size=0 whenever msg->buffer is NULL, passing NULL to memcpy() is undefined according to the ISO C standard. I haven't found any notes about this in the GNU C's or the kernel's documentation of the function and can't imagine what it would do with the NULL ptr. To better document this use of the parameters it still make sense to add an explicit check for this to the code. Signed-off-by:
-
Imre Deak authored
Add PCIIDs for new versions of the SOC, based on BSpec. Also add the name of the versions as code comment where this is available. The new versions don't have any changes visible to the kernel driver. Signed-off-by:
-
Patrik Jakobsson authored
On SKL and KBL we can have pipe A/B/C disabled by fuse settings. The pipes must be fused in descending order (e.g. C, B+C, A+B+C). We simply decrease info->num_pipes if we find a valid fused out config. v2: Don't store the pipe disabled mask in device info (Damien) v3: Don't check FUSE_STRAP register for pipe c disabled Cc: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by:
Damien Lespiau <damien.lespiau@intel.com> [Jani: fixed some checkpatch indentation complaints] Signed-off-by:
-
- 01 Feb, 2016 1 commit
-
-
Rodrigo Vivi authored
Unfortunately we don't know all panels and platforms out there and we found internal prototypes without VBT proper set but where only link in standby worked well. So, before enable PSR by default let's instrument the PSR parameter in a way that we can identify different panels out there that might require or work better with link standby mode. It is also useful to say that for backward compatibility I'm not changing the meaning of this flag. So "0" still means disabled and "1" means enabled with full support and maximum power savings. v2: Use positive value instead of negative for different operation mode as suggested by Daniel. v3: As Paulo suggested use 2 to force link standby and 3 to force link fully on. Also split the link_standby introduction in a separated patch. v4: Use DRM_ERROR for link off request on platforms that don't support and Remove the quirk promise. Cc: Jani Nikula <jani.nikula@intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
-
