- 22 Dec, 2017 13 commits
-
-
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:
Chris Wilson <chris@chris-wilson.co.uk>
-
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:
Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171221185334.17396-5-michal.wajdeczko@intel.comSigned-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:
-
- 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:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171220090626.31643-1-chris@chris-wilson.co.uk
-
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 8 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:
-
Chris Wilson authored
A useful bit of information for inspecting GPU stalls from intel_engine_dump() are the error registers, IPEIR and IPEHR. v2: Fixup gen changes in register offsets (Tvrtko) v3: Old FADDR location as well v4: Use I915_READ64_2x32 Signed-off-by:
-
Matthew Auld authored
We have an existing helper for testing obj->mm.pages, so use it. Signed-off-by:
Matthew Auld <matthew.auld@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20171218103855.25274-1-matthew.auld@intel.comReviewed-by:
-
Chris Wilson authored
Inside i915_gem_reset(), we start touching the HW and so require the low-level HW to be re-enabled, in particular the PCI BARs. Fixes: 7b6da818 ("drm/i915: Restore the kernel context after a GPU reset on an idle engine") References: 0db8c961 ("drm/i915: Re-enable GTT following a device reset") Testcase: igt/drv_hangman #i915g/i915gm Signed-off-by:
-
- 17 Dec, 2017 1 commit
-
-
Michal Wajdeczko authored
Instead of trying different seq_puts messages, lets use common -ENODEV error code to indicate missing/unsupported feature. v2: don't forget about guc_log_control fops (Sagar) Suggested-by:
-
- 16 Dec, 2017 2 commits
-
-
Chris Wilson authored
As part of the system requirement for powersaving is that we always have a context loaded. Upon boot and resume, we load the kernel_context to ensure that some valid state is set before powersaving kicks in, we should do so after a full GPU reset as well. We only need to do so for an idle engine, as any active engines will restart by executing the stuck request, loading its context. For the idle engine, we create a new request to load the kernel_context instead. For whatever reason, perfoming a dummy execute on the idle engine after reset papers over a subsequent GPU hang in rare circumstances, even on machines not using contexts (e.g. Pineview). Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104259 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104261Signed-off-by:
-
Chris Wilson authored
At the beginning of a reset, we disable the submission method and find the stuck request. We expect to find a stuck request for we have declared the engine stalled. However, if we find no active request, the engine must have recovered from its stall before we could issue a reset, so let the engine continue on without a reset. If the engine is truly stuck, we will back soon enough with the next reset attempt. v2: Remove the stale debug message. Signed-off-by:
-
