- 22 Dec, 2017 2 commits
-
-
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 <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> Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Acked-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171221185334.17396-3-michal.wajdeczko@intel.com [ickle: quieten checkpatch] 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:
Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102707 Link: https://patchwork.freedesktop.org/patch/msgid/20171220093545.613-4-maarten.lankhorst@linux.intel.comReviewed-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
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:
Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171220043520.2599-1-dhinakaran.pandiyan@intel.comReviewed-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:
-
- 15 Dec, 2017 3 commits
-
-
Lucas De Marchi authored
CFL was missing from intel_early_ids[]. The PCI ID needs to be there to allow the memory region to be stolen, otherwise we could have RAM being arbitrarily overwritten if for example we keep using the UEFI framebuffer, depending on how BIOS has set up the e820 map. Fixes: b056f8f3 ("drm/i915/cfl: Add Coffee Lake PCI IDs for S Skus.") Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Acked-by:
Ingo Molnar <mingo@kernel.org> Signed-off-by:
-
Chris Wilson authored
Just printk the string, or at least do not double up on the newlines! Fixes: eef57324 ("drm/i915: setup bridge for HDMI LPE audio driver") Signed-off-by:
-
Chris Wilson authored
Internal objects consistent of scratch pages not subject to the persistence guarantees of user facing objects. They are used for example, in ring buffers where they are only required for temporary storage of commands that will be rewritten every time. As they are temporary constructs, quietly report -ENOMEM back along the callchain rather than subject the system to oomkiller if an allocation fails. Signed-off-by:
-
- 14 Dec, 2017 8 commits
-
-
Rodrigo Vivi authored
Signed-off-by: -
https://github.com/intel/gvt-linuxRodrigo Vivi authored
gvt-next-2017-12-14: - fixes for two coverity scan errors (Colin) - mmio switch code refine (Changbin) - more virtual display dmabuf fixes (Tina/Gustavo) - misc cleanups (Pei) Signed-off-by:
-
Sebastian Andrzej Siewior authored
The code has an ifdef and uses two functions to either init the bare spinlock or init it and set a lock-class. It is possible to do the same thing without an ifdef. With this patch (in debug case) we first use the "default" lock class which is later overwritten to the supplied one. Without lockdep the set name/class function vanishes. Reported-by:
kbuild test robot <fengguang.wu@intel.com> Signed-off-by:
Sebastian Andrzej Siewior <bigeasy@linutronix.de> Reviewed-by:
-
Chris Wilson authored
Knowing the state of the engine when hangcheck thinks it is stalling is useful for both debugging hangcheck itself and the potential cause of an unwanted stall. Signed-off-by:
-
Lionel Landwerlin authored
As suggested by Chris, we should make this more obvious for people working with newer generations. Suggested-by:
-
Michał Winiarski authored
We have the selftest that's checking doorbell create/destroy, so there's no need to check all doorbells delaying the reset every time. We do want to have that extra sanity check at module load/unload though. Signed-off-by:
Michał Winiarski <michal.winiarski@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by:
-
Michał Winiarski authored
We can now move the clients allocation to submission_init path, rather than keeping the condition inside submission_enable called on every reset. Signed-off-by:
-
Michał Winiarski authored
Full GPU reset causes GuC to be reset. This means that every time we're doing a reset, we need to talk to GuC and tell it about doorbells. Let's separate the communication part (create_doorbell) from our internal bookkeeping (reserve_doorbell) so that we can cleanly separate the initialization done at module load from reinitialization done at reset in the following patch. While I'm here, let's also add a proper (although slightly asymetric) cleanup that doesn't try to communicate with GuC after it's already gone, getting rid of "expected" warnings caused by GuC action failures on module unload. Note that I've also removed one of the tests (bitmap out of sync), since it doesn't make much sense anymore - bitmaps are now not expected to change during the lifetime of a client. Signed-off-by:
-
