- 22 Dec, 2017 19 commits
-
-
Chris Wilson authored
We already emit a GEM_TRACE for when we start preemption, but we lack one to show when the preemption is completed and we return to the regular queue. This is to continue the investigation into the mysterious <0>[ 197.854177] <idle>-0 1..s1 197837017us : execlists_submission_tasklet: rcs0 cs-irq head=0 [0], tail=0 [0] <0>[ 197.854209] drv_self-6008 2.... 197837390us : reset_common_ring: rcs0 seqno=15515 <0>[ 197.854240] drv_self-6008 2.... 197837415us : reset_common_ring: bcs0 seqno=0 <0>[ 197.854270] drv_self-6008 2.... 197837443us : reset_common_ring: vcs0 seqno=0 <0>[ 197.854300] drv_self-6008 2.... 197837463us : reset_common_ring: vcs1 seqno=0 <0>[ 197.854330] drv_self-6008 2.... 197837482us : reset_common_ring: vecs0 seqno=0 <0>[ 197.854360] ksoftirq-23 2..s. 197838341us : execlists_submission_tasklet: bcs0 in[0]: ctx=0.1, seqno=1dce7 <0>[ 197.854392] <idle>-0 1..s1 197838347us : execlists_submission_tasklet: bcs0 cs-irq head=0 [0], tail=0 [0] <0>[ 197.854423] ksoftirq-23 2..s. 197838354us : execlists_submission_tasklet: vcs0 in[0]: ctx=0.1, seqno=1d027 <0>[ 197.854456] ksoftirq-23 2.Ns. 197838361us : execlists_submission_tasklet: vcs1 in[0]: ctx=0.1, seqno=1e738 <0>[ 197.854488] ksoftirq-23 2.Ns. 197838366us : execlists_submission_tasklet: vecs0 in[0]: ctx=0.1, seqno=235aa <0>[ 197.854520] ksoftirq-23 2.Ns. 197838376us : execlists_submission_tasklet: rcs0 in[0]: ctx=0.1, seqno=15518 <0>[ 197.854552] <idle>-0 1..s1 197853285us : execlists_submission_tasklet: rcs0 cs-irq head=0 [0], tail=7 [7] <0>[ 197.854584] <idle>-0 1..s1 197853285us : execlists_submission_tasklet: rcs0 csb[1]: status=0x00000018:0x00000000 <0>[ 197.854616] <idle>-0 1..s1 197853286us : execlists_submission_tasklet: rcs0 out[0]: ctx=0.0, seqno=0 Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171222132742.4272-1-chris@chris-wilson.co.ukReviewed-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com>
-
https://github.com/intel/gvt-linuxRodrigo Vivi authored
gvt-next-2017-12-22: - more mmio switch optimization (Weinan) - cleanup i915_reg_t vs. offset usage (Zhenyu) - move write protect handler out of mmio handler (Zhenyu) Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171222085141.vgewlvvni37dljdt@zhen-hp.sh.intel.com
-
Ville Syrjälä authored
We have plenty of global registers and whatnot programmed without any further locking by the modeset code. Currently non-bocking modesets are allowed to execute in parallel which could corrupt said registers. To avoid the problem let's run all non-blocking modesets on an ordered workqueue. We still put page flips etc. to system_unbound_wq allowing page flips on one pipe to execute in parallel with page flips or a modeset on a another pipe (assuming no known state is shared between them, at which point they would have been added to the same atomic commit and serialized that way). Blocking modesets are already serialized with each other by connection_mutex, and thus are safe. To serialize them with non-blocking modesets we just flush the workqueue before executing blocking modesets. Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Fixes: 94f05024 ("drm/i915: nonblocking commit") Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171113133622.8593-1-ville.syrjala@linux.intel.comAcked-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
-
Ville Syrjälä authored
Gen9+ need to disable GMBUS clock gating when doing multi part transfers. Otherwise clock gating will kick in when GMBUS is in the WAIT state and presumably that will corrupt the transfer. This is documented as Display WA #0868. Apparently older hardware doesn't allow clock gating in the WAIT state and thus are unaffected by this problem. v2: Limit the PCH w/a to gen9 and gen10 only (DK) Actually change it to check the PCH type instead since it's the PCH that actually contains the GMBUS hardware Signed-off-by: -
Ville Syrjälä authored
Give a proper name for the GMBUS clock gating disable bit on PNV, and rename intel_i2c_quirk_set() to pnv_gmbus_clock_gating() for clarity. Signed-off-by:
-
Ville Syrjälä authored
GMBUS lives in PG1, so no need to power up PG2. We do want to prevent the DMC from making a mess of things though, so add GMBUS to the DC off power well. Signed-off-by:
Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
-
Ville Syrjälä authored
Prevent the DMC from destroying GMBUS transfers on GLK. GMBUS lives in PG1 so DC off is all we need. Cc: stable@vger.kernel.org Signed-off-by:
-
Changbin Du authored
Our QA reported a problem caused by movntdqa instructions. Currently, the KVM hypervisor doesn't support VEX-prefix instructions emulation. If users passthrough a GPU to guest with vfio option 'x-no-mmap=on', then all access to the BARs will be trapped and emulated. The KVM hypervisor would raise an inertal error to qemu which cause the guest killed. (Since 'movntdqa' ins is not supported.) This patch try not to enable movntdqa optimization if the driver is running in hypervisor guest. Signed-off-by:
Changbin Du <changbin.du@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1513924309-3113-1-git-send-email-changbin.du@intel.comReviewed-by:
-
Michal Wajdeczko authored
We are dumping device info separately for sw_only and runtime part but to simplify the code we can also do it from one place once we complete driver load. v2: use dedicated welcome function (Chris) Signed-off-by:
Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171221185334.17396-8-michal.wajdeczko@intel.comReviewed-by:
-
Michal Wajdeczko authored
During initialization of the runtime part of the intel_device_info we are dumping that part using DRM_DEBUG_DRIVER mechanism. As we already have pretty printer for const part of the info, make similar function for the runtime part and use it separately. v2: add runtime dump to debugfs (Chris) Signed-off-by:
-
Michal Wajdeczko authored
As we try to follow object-verb pattern in our functions, update intel_device_info_runtime_init() parameter from dev_priv to info. Signed-off-by:
-
Michal Wajdeczko authored
We already keep intel_device_info functions in dedicated file. Add matching header file and move related definitions there. v2: add gen boundaries (Chris) Signed-off-by:
-
Michal Wajdeczko authored
We already have dedicated file for opregion related code, dedicated header will make our life easier. v2: reorder includes (Chris) Signed-off-by:
-
Michal Wajdeczko authored
We already have separate files for display related code, there is no reason to keep all display definitions in master header. Signed-off-by:
-
Michal Wajdeczko authored
We have dedicated header file for utility functions and macros. Signed-off-by:
-
Zhenyu Wang authored
It's a bit confusing that page write protect handler is live in mmio emulation handler. This moves it to stand alone gvt ops. Also remove unnecessary check of write protected page access in mmio read handler and cleanup handling of failsafe case. v2: rebase Reviewed-by:
Xiong Zhang <xiong.y.zhang@intel.com> Signed-off-by:
Zhenyu Wang <zhenyuw@linux.intel.com>
-
Zhenyu Wang authored
We had previous hack that tried to accept either i915_reg_t or offset value to access vGPU virtual/shadow regs which broke that purpose to be type safe in context. This one trys to explicitly separate the usage of typed mmio reg with real offset. Old vgpu_vreg(offset) helper is used only for offset now with new vgpu_vreg_t(reg) is used for i915_reg_t only. Convert left usage of that to new helper. Also fixed left KASAN warning issues caused by previous hack. v2: rebase, fixup against recent mmio switch change Reviewed-by:
Zhi Wang <zhi.a.wang@intel.com> Signed-off-by:
-
Xiaolin Zhang authored
observed igt drv_module_reload test case failure on 4.15.0 rc2 kernel with panic due to no active pipe available. the gpu will reset during unload/load and make pipe config reg lost which can cause kernel panic issue happen. this patch is to move pipe enabling to emulate_mointor_status_chagne to handle vgpu reset case as well. Fixes: 7e605902 ("drm/i915/gvt: enabled pipe A default on creating vgpu") Signed-off-by:
Xiaolin Zhang <xiaolin.zhang@intel.com> Signed-off-by:
-
Zhenyu Wang authored
Always requires properly defined i915_reg_t type for MMIO handler definition. Fix kasan warning of "drivers/gpu/drm/i915/gvt/handlers.c:2397:1: error: the frame size of 32120 bytes is larger than 8192 bytes" Reviewed-by:
-
- 21 Dec, 2017 3 commits
-
-
Chris Wilson authored
Include the pending update from the FBC worker in i915_fbc_status. Signed-off-by:
Paulo Zanoni <paulo.r.zanoni@intel.com>
-
Ville Syrjälä authored
We don't need any active planes during load detection, so just disable them all. This saves us from having to come up with a suitable framebuffer. And we also avoid leaving sprite/cursor planes on and potentially presenting them at a peculiar location during the load detection. Changes since v1 (Maarten): - Add missing call to add_all_affected_planes. Signed-off-by:
-
Gabriel Krisman Bertazi authored
Current code advertises (on the modifiers blob property) support for CCS modifier for pipe C on GLK, only to reject it later when validating the request before the atomic commit. This fixes the tests igt@kms_ccs@pipe-c-*, which should skip on GLK for pipe C (see bug 104096). A relevant discussion is archived at: https://lists.freedesktop.org/archives/intel-gfx/2017-December/150646.html Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104096Signed-off-by:
Gabriel Krisman Bertazi <krisman@collabora.co.uk> Cc: Ben Widawsky <ben@bwidawsk.net> Reviewed-by:
Ben Widawsky <ben@bwidawsk.net> Signed-off-by:
-
- 20 Dec, 2017 3 commits
-
-
Rodrigo Vivi authored
Spec has been updated with more reserved IDs for existent SKUs. Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Anusha Srivatsa <anusha.srivatsa@intel.com> Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Cc: Anuj Phogat <anuj.phogat@gmail.com> Signed-off-by:
-
Chris Wilson authored
Looking at the coordination of resets with the submission of execlists, it will be useful to have a GEM_TRACE for when we issue the reset. Whilst there tidy up the other GEM_TRACE to always include the engine name, and be careful not to trust any pointers prior to asserts. Signed-off-by:
-
Dhinakaran Pandiyan authored
Commit 77affa31 ("drm/i915/psr: Fix compiler warnings for hsw_psr_disable()") swapped status and control registers while fixing indentation. The _ctl at the end of the status register name must have to led to this. Fixes: 77affa31 ("drm/i915/psr: Fix compiler warnings for hsw_psr_disable()") References: https://www.mrc-cbu.cam.ac.uk/people/matt.davis/cmabridge/ Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
-
- 19 Dec, 2017 10 commits
-
-
Chris Wilson authored
A lesson that has to be relearnt over and over again is that the request does not keep a reference to the context and so we cannot freely dereference the context from inside the execlists_submission_tasklet. In particular, we try to do so in the new GEM_TRACE() so convert those over to the port->context_id we keep for GEM debugging. This means the tracing now depends on DRM_I915_GEM_DEBUG. Fixes: bccd3b83 ("drm/i915: Use trace_printk to provide a death rattle for GEM") References: https://bugs.freedesktop.org/show_bug.cgi?id=104066 References: https://bugs.freedesktop.org/show_bug.cgi?id=104162 References: https://bugs.freedesktop.org/show_bug.cgi?id=104242 References: https://bugs.freedesktop.org/show_bug.cgi?id=104310Signed-off-by:
Michel Thierry <michel.thierry@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171219220916.30882-1-chris@chris-wilson.co.uk
-
Chris Wilson authored
Use the local on-stack struct directly rather than hide it behind a pointer. This should be both clearer for the reader and the compiler (we rely on the compiler seeing through the functions to spot uninitialized uses of the local). Signed-off-by:
-
Chris Wilson authored
Useful for verifying our bookkeeper when we encounter is knowing whether we think the engine is idle at the time of the GPU hang. References: https://bugs.freedesktop.org/show_bug.cgi?id=104305Signed-off-by:
-
Rafael Antognolli authored
There seems to be another clock gating issue which the workaround is described as: "WA: Set 0xE4F0[1] = 1 to disable Early EOT of thread." Signed-off-by:
Rafael Antognolli <rafael.antognolli@intel.com> Reviewed-by:
Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by:
-
Rafael Antognolli authored
This workaround supposedly fixes some hangs in the VF unit. Signed-off-by:
-
Michal Wajdeczko authored
We dump modparams in few places (debugfs, gpu_error) using different functions. Lets add reusable function to avoid code duplication. add/remove: 1/0 grow/shrink: 0/2 up/down: 1096/-2339 (-1243) Function old new delta i915_params_dump - 1096 +1096 i915_capabilities 1353 185 -1168 i915_error_state_to_str 5507 4336 -1171 Total: Before=1285716, After=1284473, chg -0.10% v2: use forward decl rather than include (Chris) Signed-off-by:
-
Michal Wajdeczko authored
Convert intel_device_info_dump into pretty printer to be consistent with the rest of the driver code. Suggested-by:
-
Michal Wajdeczko authored
We dump device flags in few places (init_early, debugfs, gpu_error) using different functions. Lets add reusable function to avoid code duplication. add/remove: 1/0 grow/shrink: 0/3 up/down: 1296/-3572 (-2276) Function old new delta intel_device_info_dump_flags - 1296 +1296 i915_capabilities 2435 1353 -1082 i915_error_state_to_str 6642 5507 -1135 intel_device_info_dump 1507 152 -1355 Total: Before=1287992, After=1285716, chg -0.18% Signed-off-by:
-
Chris Wilson authored
drivers/gpu/drm/i915/intel_ddi.c:2098 intel_ddi_clk_select() warn: inconsistent indenting References: 8edcda12 ("drm/i915: Protect DDI port to DPLL map from theoretical race.") Signed-off-by:
-
Chris Wilson authored
After a reset, the state of the CSB registers are scrubbed and not valid until a powercontext is reloaded. We only know when a powercontext has been reloaded once we see a CS-interrupt, before then we must ignore the CSB registers within the execlists_submission_tasklet. However, glk is sporadically dying with an illegal CSB pointer value (both in the HSWP and mmio) suggesting that it is running with the CS-interrupt bit set before the powercontext has been reloaded. Make sure the clearing of that bit is serialised on reset with the re-enabling of the tasklet. References: https://bugs.freedesktop.org/show_bug.cgi?id=104262Signed-off-by:
-
- 18 Dec, 2017 5 commits
-
-
Joonas Lahtinen authored
CNL supports horizontal plane flipping on non-linear plane formats. v2: - Avoid BUG unlike elsewhere in the code (Ville) - Hoist the rotation-tiling restriction check (Ville) v3 (Rodrigo): - Rebased after a while. - Fix small indentation issues. Bspec: 7656 Suggested-by:
Anusha Srivatsa <anusha.srivatsa@intel.com> Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Anusha Srivatsa <anusha.srivatsa@intel.com> Signed-off-by:
Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by:
-
Rodrigo Vivi authored
In case we have multiple modesets for different connectors happening in parallel we could have a race on the RMW on these shared registers. This possibility was initially raised by Paulo when reviewing commit '555e38d2 ("drm/i915/cnl: DDI - PLL mapping")' but the original possibility comes from commit '5416d871 ("drm/i915/skl: Set the eDP link rate on DPLL0")'. Or maybe later when atomic commits entered into picture. Apparently the discussion around this topic showed that the right solution would be on serializing the atomic commits in a way that we don't have the possibility of races here since if that parallel modeset happenings apparently many other things will be on fire. Code is there since SKL and there was no report of issue, but since we never looked back to that serialization possibility, and also we don't have an igt case for that it is better to at least protect this corner. Suggested-by:
-
Chris Wilson authored
Now that we skip a per-engine reset on an idle engine, we need to update the selftest to take that into account. In the process, we find that we were not stressing the per-engine reset very hard, so add those missing active resets. v2: Actually test i915_reset_engine() by loading it with requests. Fixes: f6ba181a ("drm/i915: Skip an engine reset if it recovered before our preparations") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104313Signed-off-by:
-
Lionel Landwerlin authored
When monitoring the GPU with i915 perf, reports are tagged with a hw id. Gem context creation tracepoints already have a hw_id field, unfortunately you only get this correlation between a process id and a hw context id once when the context is created. It doesn't help if you started monitoring after the process was initialized or if the drm fd was transfered from one process to another. This change adds the hw_id field to gem requests, so that correlation can also be done on submission. v2: Place hw_id at the end of the tracepoint to not disrupt too much existing tools (Chris) v3: Reorder hw_id field again (Chris) v4: Add missing hw_id to i915_gem_request_wait_begin tracepoint (Chris) Signed-off-by:Lionel Landwerlin <lionel.g.landwerlin@intel.com> Reviewed-by:
-
Lionel Landwerlin authored
Let's make the order of the fields of the tracepoints involving gem request match across i915. This makes userspace processing of tracepoint a bit easier. Suggested-by:
-
