- 13 10月, 2016 3 次提交
-
-
由 Tvrtko Ursulin 提交于
unsigned long is too wide - use smaller types in struct cxsr_latency to save 800-something bytes of .rodata. v2: All data even fits in u16 for even more saving. (Ville Syrjala) v3: Move bitfields to the end of the struct. (Joonas Lahtinen) Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
-
由 Imre Deak 提交于
Currently resuming on HSW from S3 pm_test/devices state leads to an unrecoverable GPU hang. Resetting the GPU during suspend fixes this. For a full S3 cycle this change only means the reset happens earlier (before reaching S3). For S4 the reset will happen now both during the freeze and quiesce phases, which is a benefit since it will guarantee that the GPU is idle before creating and loading the hibernation image. Cc: Mika Kuoppala <mika.kuoppala@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Suggested-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NImre Deak <imre.deak@intel.com> Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/1476283597-580-1-git-send-email-imre.deak@intel.com
-
由 Chris Wilson 提交于
Treat a framebuffer reference with the same priority as an active reference whilst shrinking. Framebuffers are likely to be reused and typically cost more to migrate to and from GPU memory (on LLC architectures we need to clflush), so defer the temptation to purge them during a kswapd run until we have run out of cheap buffers. Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Reviewed-by: NJohn Harrison <john.c.harrison@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20161012124824.23521-1-chris@chris-wilson.co.uk
-
- 12 10月, 2016 10 次提交
-
-
由 Chris Wilson 提交于
The current meaning of whether an object has a GGTT vma is very ill-defined (and note we don't check for any partials either), it just means that at some point it was in the GGTT but it may not be now. The information we really care about here is whether it is taking up precious mappable aperture space. This is the obj->fault_mappable flag. We have a redundant long form reprinting of this information, so remove that in favour of the compact flag. Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20161012114827.17031-2-chris@chris-wilson.co.uk
-
由 Chris Wilson 提交于
During rpm resume we restore the fences, but we do not have the protection of struct_mutex. This rules out updating the activity tracking on the fences, and requires us to rely on the rpm as the serialisation barrier instead. [ 350.298052] [drm:intel_runtime_resume [i915]] Resuming device [ 350.308606] [ 350.310520] =============================== [ 350.315560] [ INFO: suspicious RCU usage. ] [ 350.320554] 4.8.0-rc8-bsw-rapl+ #3133 Tainted: G U W [ 350.327208] ------------------------------- [ 350.331977] ../drivers/gpu/drm/i915/i915_gem_request.h:371 suspicious rcu_dereference_protected() usage! [ 350.342619] [ 350.342619] other info that might help us debug this: [ 350.342619] [ 350.351593] [ 350.351593] rcu_scheduler_active = 1, debug_locks = 0 [ 350.358952] 3 locks held by Xorg/320: [ 350.363077] #0: (&dev->mode_config.mutex){+.+.+.}, at: [<ffffffffa030589c>] drm_modeset_lock_all+0x3c/0xd0 [drm] [ 350.375162] #1: (crtc_ww_class_acquire){+.+.+.}, at: [<ffffffffa03058a6>] drm_modeset_lock_all+0x46/0xd0 [drm] [ 350.387022] #2: (crtc_ww_class_mutex){+.+.+.}, at: [<ffffffffa0305056>] drm_modeset_lock+0x36/0x110 [drm] [ 350.398236] [ 350.398236] stack backtrace: [ 350.403196] CPU: 1 PID: 320 Comm: Xorg Tainted: G U W 4.8.0-rc8-bsw-rapl+ #3133 [ 350.412457] Hardware name: Intel Corporation CHERRYVIEW C0 PLATFORM/Braswell CRB, BIOS BRAS.X64.X088.R00.1510270350 10/27/2015 [ 350.425212] 0000000000000000 ffff8801680a78c8 ffffffff81332187 ffff88016c5c5000 [ 350.433611] 0000000000000001 ffff8801680a78f8 ffffffff810ca6da ffff88016cc8b0f0 [ 350.442012] ffff88016cc80000 ffff88016cc80000 ffff880177ad0000 ffff8801680a7948 [ 350.450409] Call Trace: [ 350.453165] [<ffffffff81332187>] dump_stack+0x67/0x90 [ 350.458931] [<ffffffff810ca6da>] lockdep_rcu_suspicious+0xea/0x120 [ 350.466002] [<ffffffffa039e8dd>] fence_update+0xbd/0x670 [i915] [ 350.472766] [<ffffffffa039efe2>] i915_gem_restore_fences+0x52/0x70 [i915] [ 350.480496] [<ffffffffa0368f42>] vlv_resume_prepare+0x72/0x570 [i915] [ 350.487839] [<ffffffffa0369802>] intel_runtime_resume+0x102/0x210 [i915] [ 350.495442] [<ffffffff8137f26f>] pci_pm_runtime_resume+0x7f/0xb0 [ 350.502274] [<ffffffff8137f1f0>] ? pci_restore_standard_config+0x40/0x40 [ 350.509883] [<ffffffff814401c5>] __rpm_callback+0x35/0x70 [ 350.516037] [<ffffffff8137f1f0>] ? pci_restore_standard_config+0x40/0x40 [ 350.523646] [<ffffffff81440224>] rpm_callback+0x24/0x80 [ 350.529604] [<ffffffff8137f1f0>] ? pci_restore_standard_config+0x40/0x40 [ 350.537212] [<ffffffff814417bd>] rpm_resume+0x4ad/0x740 [ 350.543161] [<ffffffff81441aa1>] __pm_runtime_resume+0x51/0x80 [ 350.549824] [<ffffffffa03889c8>] intel_runtime_pm_get+0x28/0x90 [i915] [ 350.557265] [<ffffffffa0388a53>] intel_display_power_get+0x23/0x50 [i915] [ 350.565001] [<ffffffffa03ef23d>] intel_atomic_commit_tail+0xdfd/0x10b0 [i915] [ 350.573106] [<ffffffffa034b2e9>] ? drm_atomic_helper_swap_state+0x159/0x300 [drm_kms_helper] [ 350.582659] [<ffffffff81615091>] ? _raw_spin_unlock+0x31/0x50 [ 350.589205] [<ffffffffa034b2e9>] ? drm_atomic_helper_swap_state+0x159/0x300 [drm_kms_helper] [ 350.598787] [<ffffffffa03ef8a5>] intel_atomic_commit+0x3b5/0x500 [i915] [ 350.606319] [<ffffffffa03061dc>] ? drm_atomic_set_crtc_for_connector+0xcc/0x100 [drm] [ 350.615209] [<ffffffffa0306b49>] drm_atomic_commit+0x49/0x50 [drm] [ 350.622242] [<ffffffffa034dee8>] drm_atomic_helper_set_config+0x88/0xc0 [drm_kms_helper] [ 350.631419] [<ffffffffa02f94ac>] drm_mode_set_config_internal+0x6c/0x120 [drm] [ 350.639623] [<ffffffffa02fa94c>] drm_mode_setcrtc+0x22c/0x4d0 [drm] [ 350.646760] [<ffffffffa02f0f19>] drm_ioctl+0x209/0x460 [drm] [ 350.653217] [<ffffffffa02fa720>] ? drm_mode_getcrtc+0x150/0x150 [drm] [ 350.660536] [<ffffffff810c984a>] ? __lock_is_held+0x4a/0x70 [ 350.666885] [<ffffffff81202303>] do_vfs_ioctl+0x93/0x6b0 [ 350.672939] [<ffffffff8120f843>] ? __fget+0x113/0x200 [ 350.678797] [<ffffffff8120f735>] ? __fget+0x5/0x200 [ 350.684361] [<ffffffff81202964>] SyS_ioctl+0x44/0x80 [ 350.690030] [<ffffffff81001deb>] do_syscall_64+0x5b/0x120 [ 350.696184] [<ffffffff81615ada>] entry_SYSCALL64_slow_path+0x25/0x25 Note we also have to remember the lesson from commit 4fc788f5 ("drm/i915: Flush delayed fence releases after reset") where we have to flush any changes to the fence on restore. v2: Replace call to release user mmaps with an assertion that they have already been zapped. Fixes: 49ef5294 ("drm/i915: Move fence tracking from object to vma") Reported-by: NVille 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: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20161012114827.17031-1-chris@chris-wilson.co.uk
-
由 Chris Wilson 提交于
Our error states are quickly growing, pinning kernel memory with them. The majority of the space is taken up by the error objects. These compress well using zlib and without decode are mostly meaningless, so encoding them does not hinder quickly parsing the error state for familiarity. v2: Make the zlib dependency optional Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20161012090522.367-6-chris@chris-wilson.co.uk
-
由 Chris Wilson 提交于
Leave all the pretty printing to userspace and simplify the error capture to only have a single common object printer. It makes the kernel code more compact, and the refactoring allows us to apply more complex transformations like compressing the output. Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20161012090522.367-5-chris@chris-wilson.co.uk
-
由 Chris Wilson 提交于
Since the GTT provides universal access to any GPU page, we can use it to reduce our plethora of read methods to just one. It also has the important characteristic of being exactly what the GPU sees - if there are incoherency problems, seeing the batch as executed (rather than as trapped inside the cpu cache) is important. Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20161012090522.367-4-chris@chris-wilson.co.uk
-
由 Chris Wilson 提交于
The error state is purposefully racy as we expect it to be called at any time and so have avoided any locking whilst capturing the crash dump. However, with multi-engine GPUs and multiple CPUs, those races can manifest into OOPSes as we attempt to chase dangling pointers freed on other CPUs. Under discussion are lots of ways to slow down normal operation in order to protect the post-mortem error capture, but what it we take the opposite approach and freeze the machine whilst the error capture runs (note the GPU may still running, but as long as we don't process any of the results the driver's bookkeeping will be static). Note that by of itself, this is not a complete fix. It also depends on the compiler barriers in list_add/list_del to prevent traversing the lists into the void. We also depend that we only require state from carefully controlled sources - i.e. all the state we require for post-mortem debugging should be reachable from the request itself so that we only have to worry about retrieving the request carefully. Once we have the request, we know that all pointers from it are intact. v2: Avoid drm_clflush_pages() inside stop_machine() as it may use stop_machine() itself for its wbinvd fallback. Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Acked-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20161012090522.367-3-chris@chris-wilson.co.uk
-
由 Chris Wilson 提交于
We currently capture the GPU state after we detect a hang. This is vital for us to both triage and debug hangs in the wild (post-mortem debugging). However, it comes at the cost of running some potentially dangerous code (since it has to make very few assumption about the state of the driver) that is quite resource intensive. This patch introduces both a method to disable error capture at runtime (for users who hit bugs at runtime and need a workaround) and to disable error capture at compiletime (for realtime users who want to minimise any possible latency, and never require error capture, saving ~30k of code). The cost is that we now have to be wary of (and test!) a kconfig flag and a module parameter. The effect of the module parameter is easy to verify through code inspection and runtime testing, but a kconfig flag needs regular compile checking. Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com> Acked-by: NJani Nikula <jani.nikula@linux.intel.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch Link: http://patchwork.freedesktop.org/patch/msgid/20161012090522.367-2-chris@chris-wilson.co.uk
-
由 Chris Wilson 提交于
In the next patch, I want to conditionally compile i915_gpu_error.c and that requires moving the functions used by debug out of i915_gpu_error.c! Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20161012090522.367-1-chris@chris-wilson.co.uk
-
由 Joonas Lahtinen 提交于
Remove never used BSM{,_MASK}. BSM_MASK #define also causes a warning. include/drm/i915_drm.h:96:34: warning: result of ‘65535 << 20’ requires 37 bits to represent, but ‘int’ only has 32 bits [-Wshiftoverflow=] #define INTEL_BSM_MASK (0xFFFF << 20) Reported-by: NLinus Torvalds <torvalds@linux-foundation.org> Signed-off-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/1476256734-6457-1-git-send-email-joonas.lahtinen@linux.intel.com
-
由 Paulo Zanoni 提交于
With the previous code we were only recomputing the DDB partitioning for the CRTCs included in the atomic commit, so any other active CRTCs would end up having their DDB registers zeroed. In this patch we make sure that the computed state starts as a copy of the current partitioning, and then we only zero the DDBs that we're actually going to recompute. How to reproduce the bug: 1 - Enable the primary plane on pipe A 2 - Enable the primary plane on pipe B 3 - Enable the cursor or sprite plane on pipe A Step 3 will zero the DDB partitioning for pipe B since it's not included in the commit that enabled the cursor or sprite for pipe A. I expect this to fix many FIFO underrun problems on gen9+. v2: - Mention the cursor on the steps to reproduce the problem (Paulo). - Add Testcase tag provided by Maarten (Maarten). Testcase: kms_cursor_legacy.cursorA-vs-flipB-atomic-transitions Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96226 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96828 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97450 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97596 Bugzilla: https://www.phoronix.com/scan.php?page=news_item&px=Intel-Skylake-Multi-Screen-Woes Cc: stable@vger.kernel.org Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: NLyude <cpaul@redhat.com> Link: http://patchwork.freedesktop.org/patch/msgid/1475602652-17326-1-git-send-email-paulo.r.zanoni@intel.com
-
- 11 10月, 2016 11 次提交
-
-
由 Jani Nikula 提交于
We'll be getting a function and a table for dp parameters soon enough, so rename the function and table for hdmi. No functional changes. Cc: Libin Yang <libin.yang@linux.intel.com> Reviewed-by: NLibin Yang <libin.yang@intel.com> Signed-off-by: NJani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/3d1c61cab70b6a2966db9b6115b76edbd747a835.1476111629.git.jani.nikula@intel.com
-
由 Jani Nikula 提交于
Have generic macros in line with the rest of the register bit definition macros instead of a dedicated function in intel_audio.c, and use them. No functional changes. Cc: Libin Yang <libin.yang@linux.intel.com> Reviewed-by: NLibin Yang <libin.yang@intel.com> Signed-off-by: NJani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/c8709b065ba5cb91b85c54f4e099219e4e68b192.1476111629.git.jani.nikula@intel.com
-
由 Libin Yang 提交于
HDMI audio should use crtc_clock to get the TMDS clock. This patch renames mode to adjusted_mode to unify the name. Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NLibin Yang <libin.yang@linux.intel.com> Signed-off-by: NJani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/8945ac6bdae9c63a563bdd60b44dd316254e4752.1476111629.git.jani.nikula@intel.com
-
由 Libin Yang 提交于
This patch applies setting proper N/M, N/CTS on more platforms. Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NLibin Yang <libin.yang@linux.intel.com> Signed-off-by: NJani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/073f8aaf302df1b638dd33b0ddf46930bcdfea99.1476111629.git.jani.nikula@intel.com
-
由 Jani Nikula 提交于
The code for dp and hdmi are already different, and they're about to diverge even more. Split them for clarity in future work. No functional changes. Cc: Libin Yang <libin.yang@linux.intel.com> Reviewed-by: NLibin Yang <libin.yang@intel.com> Signed-off-by: NJani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/41b8e24fed92effafaef69675ddabfa2008b4d31.1476111629.git.jani.nikula@intel.com
-
由 Jani Nikula 提交于
It gets fragile to duplicate the code for updating HSW_AUD_CFG. The only change should be that the hdmi pixel clock is also updated in i915_audio_component_sync_audio_rate(), but it should not be any different. Cc: Libin Yang <libin.yang@linux.intel.com> Reviewed-by: NLibin Yang <libin.yang@intel.com> Signed-off-by: NJani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/e0e88ec00c0ed1734083153b55283efd3116be5c.1476111629.git.jani.nikula@intel.com
-
由 Jani Nikula 提交于
If it was wrong, we'd be screwed already. Cc: Libin Yang <libin.yang@linux.intel.com> Reviewed-by: NLibin Yang <libin.yang@intel.com> Signed-off-by: NJani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/8cf454ccefc05b234aa81c45a4ce9018e7c9324f.1476111629.git.jani.nikula@intel.com
-
由 Jani Nikula 提交于
Prepare for using the same code for updating HSW_AUD_CFG register. No functional changes. Cc: Libin Yang <libin.yang@linux.intel.com> Reviewed-by: NLibin Yang <libin.yang@intel.com> Signed-off-by: NJani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/56fe0662990289c647f998c11089133ca92ebb68.1476111629.git.jani.nikula@intel.com
-
由 Chris Wilson 提交于
If we want to know how many pages a VMA spans, we can use vma_pages() to find out. We have one such invocation inside our faulthandler, so convert it. (We have two other that want the size in bytes rather than pages, food for future thought.) Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/20161011090656.29554-1-chris@chris-wilson.co.ukReviewed-by: NMatthew Auld <matthew.auld@intel.com>
-
由 Chris Wilson 提交于
commit 1625e7e5 ("drm/i915: make compact dma scatter lists creation work with SWIOTLB backend") took a heavy handed approach to undo the scatterlist compaction in the face of SWIOTLB. (The compaction hit a bug whereby we tried to pass a segment larger than SWIOTLB could handle.) We can be a little more intelligent and try compacting the scatterlist up to the maximum SWIOTLB segment size (when using SWIOTLB). v2: Tidy sg_mark_end() and cpp Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> CC: Imre Deak <imre.deak@intel.com> CC: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20161011082021.14606-2-chris@chris-wilson.co.uk
-
由 Chris Wilson 提交于
When we notice the system under memory pressure, we try to evict some driver pages before asking the VM to shrink all caches. As a final step in that process, we tried to evict everything, including active buffers. This is harming ourselves, and we can mix shrinking all caches as well as our residual buffers (after the first pass of trying to shrink just our own buffers). Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Reviewed-by: NMichał Winiarski <michal.winiarski@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20161011082021.14606-1-chris@chris-wilson.co.uk
-
- 10 10月, 2016 16 次提交
-
-
由 Chris Wilson 提交于
The conflict resolution of v4.8-rc8 backmerge to drm-next pulled back in a few lines of dead code due to the code movement around i915_gem_reset(), fix that up. Fixes: ca09fb9f ("Merge tag 'v4.8-rc8' into drm-next") Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Dave Airlie <airlied@gmail.com> Signed-off-by: NJani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20161010125017.23911-1-chris@chris-wilson.co.uk
-
由 Chris Wilson 提交于
We reserve space in the GuC workqueue for submitting the request in the future. However, if we fail to construct the request, we need to give that reserved space back to the system. Fixes: dadd481b ("drm/i915/guc: Prepare for nonblocking execbuf submission") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97978Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: Michał Winiarski <michal.winiarski@intel.com> Reviewed-by: NMichał Winiarski <michal.winiarski@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20161007065327.24515-4-chris@chris-wilson.co.uk (cherry picked from commit 5ba89908) Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 Chris Wilson 提交于
Along with the interrupt, we want to restore the fake-irq and wait-timeout detection. If we use the breadcrumbs interface to setup the interrupt as it wants, the auxiliary timers will also be restored. v2: Cancel both timers as well, sanitize the IMR. Fixes: 821ed7df ("drm/i915: Update reset path to fix incomplete requests") Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: NMika Kuoppala <mika.kuoppala@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20161007065327.24515-3-chris@chris-wilson.co.uk (cherry picked from commit ad07dfcd) Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 Chris Wilson 提交于
If we run out of enough aperture space to fit the entire object, we fallback to trying to insert a single page. However, if that also fails, we currently fail to userspace with an unexpected ENOSPC. (ENOSPC means to userspace that their batch could not be fitted within the GTT.) Prior to commit e8cb909a ("drm/i915: Fallback to single page GTT mmappings for relocations") the approach is to fallback to using the slow CPU relocation path in case of iomapping failure, and that is the behaviour we need to restore. Fixes: e8cb909a ("drm/i915: Fallback to single page GTT mmappings...") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98101Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20161007065327.24515-2-chris@chris-wilson.co.uk (cherry picked from commit d7f76335) Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 Chris Wilson 提交于
In order not to trigger hangcheck on a idle-but-waiting engine, we need to distinguish between the pending request queue and the actual execution queue. This is done later in "drm/i915: Enable multiple timelines" but for now we need a temporary fix to prevent blaming the wrong engine for a GPU hang. (Note that this causes a temporary subtle change in how we decide when to allow a waitboost to be re-awarded back to the waiter, the temporary effect is that if the wait is upon the most current execution the wait is given for free, instead of checking to see if the client stalled itself. This will be repaired in "drm/i915: Enable multiple timelines".) Fixes: 0a046a0e ("drm/i915: Nonblocking request submission") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98104Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by: NMika Kuoppala <mika.kuoppala@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20161007065327.24515-1-chris@chris-wilson.co.uk (cherry picked from commit 8687b3ec) Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 Ville Syrjälä 提交于
Allow returning "connected" or "unknown" connector status for DP branch devices that don't have an EDID. Currently we'd claim the thing as "disconnected" if there is no EDID. This stuff used to broken already, I think, but it got more broken by commit f21a2198 ("drm/i915: Splitting intel_dp_detect") Cc: Damien Cassou <damien@cassou.me> Cc: freedesktop.org@gp.mailgun.org Cc: Arno <blouin.arno@gmail.com> Cc: Shubhangi Shrivastava <shubhangi.shrivastava@intel.com> Cc: Sivakumar Thulasimani <sivakumar.thulasimani@intel.com> Cc: Ander Conselvan de Oliveira <conselvan2@gmail.com> Cc: stable@vger.kernel.org Tested-by: NArno <blouin.arno@gmail.com> Fixes: f21a2198 ("drm/i915: Splitting intel_dp_detect") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=83348Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1475481316-8194-2-git-send-email-ville.syrjala@linux.intel.comReviewed-by: NAnder Conselvan de Oliveira <conselvan2@gmail.com> (cherry picked from commit 5cb651a7) Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 Ville Syrjälä 提交于
We can't rely on connector->status in the detect() hook if the long hpd was already handled by the dig_port_work as that won't update connector->status. Thus we have to defer the long hpd handling entirely until the hotplug work runs to avoid the double long hpd handling the "detect_done" flag is trying to prevent. We'll start to depend on connector->status being up to date in a following patch. Cc: Damien Cassou <damien@cassou.me> Cc: freedesktop.org@gp.mailgun.org Cc: Arno <blouin.arno@gmail.com> Cc: Shubhangi Shrivastava <shubhangi.shrivastava@intel.com> Cc: Sivakumar Thulasimani <sivakumar.thulasimani@intel.com> Cc: Ander Conselvan de Oliveira <conselvan2@gmail.com> Cc: stable@vger.kernel.org Tested-by: NArno <blouin.arno@gmail.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=83348Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1475481316-8194-1-git-send-email-ville.syrjala@linux.intel.comReviewed-by: NAnder Conselvan de Oliveira <conselvan2@gmail.com> (cherry picked from commit 27d4efc5) Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 Chris Wilson 提交于
On Braswell, at least, we observe that the context image is written in multiple phases. The first phase is to clear the register state, and subsequently rewrite it. A GPU reset at the right moment can interrupt the context update leaving it corrupt, and our update of the RING_HEAD is not sufficient to restart the engine afterwards. To recover, we need to reset the registers back to their original values. The context state is lost. What we need is a better mechanism to serialise the reset with pending flushes from the GPU. Fixes: 821ed7df ("drm/i915: Update reset path to fix incomplete requests") Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: NMika Kuoppala <mika.kuoppala@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20161004201132.21801-2-chris@chris-wilson.co.uk (cherry picked from commit a3aabe86) Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 Chris Wilson 提交于
When decoding the semaphores inside hangcheck, we need to use the hw-id and not the local array index. Fixes: de1add36 ("drm/i915: Decouple execbuf uAPI ...") Testcase: igt/gem_exec_whisper/hang # gen6-7 Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: stable@vger.kernel.org Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20161003124516.12388-3-chris@chris-wilson.co.uk (cherry picked from commit 348b9b11) Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 Chris Wilson 提交于
We use obj->phys_handle to choose the pread/pwrite path, but as obj->phys_handle is a union with obj->userptr, we then mistakenly use the phys_handle path for userptr objects within pread/pwrite. Testcase: igt/gem_userptr_blits/forbidden-operations Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97519Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: stable@vger.kernel.org Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20161003124516.12388-2-chris@chris-wilson.co.uk (cherry picked from commit 5f12b80a) Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 Chris Wilson 提交于
When we enable the per-register access mmiodebug, it is to detect which access is illegal. Reporting on earlier untraced access outside of the mmiodebug does not help debugging (as the suspicion is immediately put upon the current register which is not at fault)! References: https://bugs.freedesktop.org/show_bug.cgi?id=97985Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: NMika Kuoppala <mika.kuoppala@intel.com> Cc: stable@vger.kernel.org Link: http://patchwork.freedesktop.org/patch/msgid/20161003124516.12388-1-chris@chris-wilson.co.uk (cherry picked from commit dda96033) Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 Paulo Zanoni 提交于
We were previously adding all the planes owned by the CRTC even when the ddb partitioning didn't change for them. As a consequence, a lot of functions were being called when we were just moving the cursor around the screen, such as skylake_update_primary_plane(). This was causing flickering on the primary plane when moving the cursor. I'm not 100% sure which operation caused the flickering, but we were writing to a lot of registers, so it could be any of these writes. With this patch, just moving the mouse won't add the primary plane to the commit since it won't trigger a change in DDB partitioning. v2: Use skl_ddb_entry_equal() (Lyude). v3: Change Reported-and-bisected-by: to Reported-by: for checkpatch Fixes: 05a76d3d ("drm/i915/skl: Ensure pipes with changed wms get added to the state") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97888 Cc: Mike Lothian <mike@fireburn.co.uk> Cc: stable@vger.kernel.org Reported-by: NMike Lothian <mike@fireburn.co.uk> Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: NLyude <cpaul@redhat.com> Link: http://patchwork.freedesktop.org/patch/msgid/1475177808-29955-1-git-send-email-paulo.r.zanoni@intel.com (cherry picked from commit 7f60e200) Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 Ville Syrjälä 提交于
DPLL_SDVO_HIGH_SPEED must be set for SDVO/HDMI/DP, but nowhere is it forbidden to set it for LVDS/CRT as well. So let's also set it on CRT to make it possible to share the DPLL between HDMI and CRT. What that bit apparently does is enable the x5 clock to the port, which then pumps out the bits on both edges of the clock. The DAC doesn't need that clock since it's not pumping out bits, but I don't think it hurts to have the DPLL output that clock anyway. This is fairly important on IVB since it has only two DPLLs with three pipes. So trying to drive three or more PCH ports with three pipes is only possible when at least one of the DPLLs gets shared between two of the pipes. SNB doesn't really need to do this since it has only two pipes. It could be done to avoid enabling the second DPLL at all in certain cases, but I'm not sure that's such a huge win. So let's not do it for SNB, at least for now. On ILK it never makes sense as the DPLLs can't be shared. v2: Just always enable the high speed clock to keep things simple (Daniel) Beef up the commit message a bit (Daniel) Cc: Nick Yamane <nick.diego@gmail.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: stable@vger.kernel.org Tested-by: NNick Yamane <nick.diego@gmail.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97204Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1474878646-17711-1-git-send-email-ville.syrjala@linux.intel.comReviewed-by: NAnder Conselvan de Oliveira <conselvan2@gmail.com> (cherry picked from commit 7d7f8633) Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 Imre Deak 提交于
a277ca7d should've been a no-functional-change commit, but it removed the initialization of the dpll_hw_state for HDMI outputs, resulting in state mismatches and a failed modeset with blank screen. Fix this by reinstating the dpll_hw_state initialization. v2: - Make bxt_ddi_hdmi_set_dpll_hw_state() static. Cc: Manasi Navare <manasi.d.navare@intel.com> Cc: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Cc: Durgadoss R <durgadoss.r@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Fixes: a277ca7d ("drm/i915: Split bxt_ddi_pll_select()") Signed-off-by: NImre Deak <imre.deak@intel.com> Reviewed-by: NAnder Conselvan de Oliveira <conselvan2@gmail.com> Link: http://patchwork.freedesktop.org/patch/msgid/1474901671-22719-1-git-send-email-imre.deak@intel.com (cherry picked from commit a04139c4) Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 Paulo Zanoni 提交于
We forgot the "res_blocks += y_tile_minimum" that's described on step V of our documentation. Again, this should only affect the Y tiling cases. It looks like the relevant code was introduced in 0fda6568, but there's always the possibility that it matched our specification when it was introduced, and then the specification changed while the code stayed the same. So we can't really say this was a regression, but let's try to add a "Fixes" tag anyway to help backporting. v2: Try to add a "Fixes" tag (Maarten). Fixes: 0fda6568 ("drm/i915/skl: Update watermarks for Y tiling") Cc: stable@vger.kernel.org Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: NLyude <cpaul@redhat.com> Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1474578035-424-8-git-send-email-paulo.r.zanoni@intel.com (cherry picked from commit 75676ed4) Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 Paulo Zanoni 提交于
The confusing thing is that plane_blocks_per_line is listed as part of the method 2 calculation but is also used for other things. We calculated it in two different places and different ways: one inside skl_wm_method2() and the other inside skl_compute_plane_wm(). The skl_wm_method2() implementation is the one that matches the specification. With this patch we fix the skl_compute_plane_wm() calculation and just pass it as a parameter to skl_wm_method2(). We also take care to not modify the value of plane_bytes_per_line since we're going to rely on it having a correct value in later patches. This should affect the watermarks for Linear and Y-tiled. From my analysis, it looks like the two plane_blocks_per_line variables got out of sync on 0fda6568, but we can't really say that commit was a regression, it looks like just an incomplete fix. There's always the possibility that 0fda6568 matched our specification at that time, and then later the specification changed. v2: Try to add a "Fixes" tag (Maarten). Fixes: 0fda6568 ("drm/i915/skl: Update watermarks for Y tiling") Cc: stable@vger.kernel.org Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: NLyude <cpaul@redhat.com> Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1474578035-424-7-git-send-email-paulo.r.zanoni@intel.com (cherry picked from commit 7a1a8aed) Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-