- 25 Jul, 2019 4 commits
-
-
Daniele Ceraolo Spurio authored
We currently track fetch and load status separately, but the 2 are actually sequential in the uc lifetime (fetch must complete before we can attempt the load!). Unifying the 2 variables we can better follow the sequential states and improve our trackng of the uC state. Also, sprinkle some GEM_BUG_ON to make sure we transition correctly between states. v2: rename states, add the running state (Michal), drop some logs in the fetch path (Michal, Chris) v3: re-rename states, extend early status check to all helpers (Michal) Suggested-by:Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by:
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190725001813.4740-5-daniele.ceraolospurio@intel.com
-
Daniele Ceraolo Spurio authored
Instead of having 2 identical functions for GuC and HuC firmware selection, we can unify the selection logic and just use different lists based on FW type. Note that the revid is not relevant for current blobs, but the upcoming CML will be identified as CFL rev 5, so by considering the revid we're ready for that. v2: rework blob list defs (Michal), add order check (Chris), fuse GuC and HuC lists into one. v3: remove difference between no uC HW and no uC FW, simplify related selection code, check the whole fw list (Michal) Signed-off-by: -
Daniele Ceraolo Spurio authored
There are 2 issues around handling of missing uC support: - We treat lack of uC HW and lack of uC FW definition as 2 different cases, but both of them mean that we don't support the uC on the platform we're running on. - We rely on the modparam to decide if we can take uC paths or not, but we don't sanitize it if it is set incorrectly on platform with no uC support. To fix both of them, unify the 2 cases in a single one and sanitize the modparam on invalid configuration (after printing an error message). The log has been adapted as well, since the user doesn't care why we don't support GuC/HuC (no HW or no FW), just that we do not. Developers can easily find the answer based on the platform, so we can simplify the log. Correcting the modparam has been preferred over failing the load since this is what we usually do for non-supported feature (e.g. the now gone enable_ppgtt would fall back to the highest supported PPGTT mode if the selected one was not available). Note that this patch purposely doesn't change the behavior for platforms that do have uC support, in which case we will still fail if enable_guc is set and the firmware is not available on the system. Suggested-by:
-
Daniele Ceraolo Spurio authored
We have several HAS_* checks for GuC and HuC but we mostly use HAS_GUC and HAS_HUC, with only 1 exception. Since our HW always has either both uC or neither of them, just replace all the checks with a unified HAS_UC. v2: use HAS_GT_UC (Michal) v3: fix comment (Michal) Signed-off-by:
-
- 24 Jul, 2019 1 commit
-
-
Daniele Ceraolo Spurio authored
All the GuC objects are perma-pinned, so their offset can't change at runtime. We can therefore set (and log!) the parameters only once during boot. Suggested-by:
-
- 23 Jul, 2019 7 commits
-
-
Chuhong Yuan authored
Instead of using to_pci_dev + pci_get_drvdata, use dev_get_drvdata to make code simpler. Signed-off-by:
Chuhong Yuan <hslester96@gmail.com> Reviewed-by:
-
Daniele Ceraolo Spurio authored
Fix botched refactoring of the code that uncorrectly split a check on a bool, treating it as a u32. Reported-by:
Dan Carpenter <dan.carpenter@oracle.com> Fixes: 84b1ca2f ("drm/i915/uc: prefer intel_gt over i915 in GuC/HuC paths") Signed-off-by:
-
Chris Wilson authored
If the system is already idle, omit the GEM_TRACE saying we are about to wait for idle. It looks confusing in the logs to see a continual stream of wait-for-idle, as one immediately assumes it is stuck in a loop. Signed-off-by:
Stuart Summers <stuart.summers@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190723091218.5886-1-chris@chris-wilson.co.uk
-
Chris Wilson authored
Give the scheduler a chance to breathe by calling cond_resched() as some of the loops may take some time on slower machines, and so catch the attention of the watchdogs. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111196Signed-off-by:
Matthew Auld <matthew.william.auld@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190723095800.2820-1-chris@chris-wilson.co.uk
-
Daniele Ceraolo Spurio authored
The microcontrollers are part of GT so it makes logical sense to have them sanitized at the same time. This also fixed an issue with our status tracking where the FW load status is not reset around hibernation. Signed-off-by:
-
Daniele Ceraolo Spurio authored
This was the last place in gt/uc that was still using I915_READ with the global dev_priv. Signed-off-by:
-
Anshuman Gupta authored
To identify the HDCP capability of the display connected to CI systems, we need to add the hdcp capability probing in i915_display_info. This will also help to populate the HDCP capability of the CI systems to CI H/W logs maintained at https://intel-gfx-ci.01.org/hardware/. It will facilitate to determine the kms_content_protection behavior on a particular CI system. v2: Reused the intel_hdcp_info() in i915_hdcp_sink_capability_show(). [Ram] Shifted intel_hdcp_info() to the end of intel_dp_info. [Ram] v3: used seq_puts() instead of seq_pritnf(). [Ram] Cc: daniel.vetter@intel.com Cc: ramalingam.c@intel.com Signed-off-by:
Anshuman Gupta <anshuman.gupta@intel.com> Reviewed-by:
Ramalingam C <ramalingam.c@intel.com> Signed-off-by:
-
- 22 Jul, 2019 4 commits
-
-
Chris Wilson authored
Trust that we now have adequate protection over the low level structures via the engine->active.lock to allow ourselves to capture the GPU error state without the heavy hammer of stop_machine(). Sadly this does mean that we have to forgo some of the lesser used information (not derived from the active state) that is not controlled by the active locks. This includes the list of buffers in the ppGTT and pinned globally in the GGTT. Originally this was used to manually verify relocations, but hasn't been required for sometime and modern mesa now has the habit of ensuring that all interesting buffers within a batch are captured in their entirety (that are the auxiliary state buffers, but not the textures). A useful side-effect is that this allows us to restore error capturing for Braswell and Broxton. v2: Use pagevec for a typical arbitrary number of preallocated pages Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190722222847.24178-1-chris@chris-wilson.co.uk
-
Chris Wilson authored
Prior to freeing the struct, call the fini function to cleanup the common members. Currently this only calls the debug functions to mark the structs as destroyed, but may be extended to real work in future. Signed-off-by:
-
Chris Wilson authored
Remove the outer layer cleanup of engine stubs; as i915_drv itself no longer tries to preallocate and so is not responsible for either the allocation or free. By the time we call the cleanup function, we already have cleaned up the engines. v2: Lack of symmetry between mmio_probe and mmio_release for handling the error cleanup. engine->destroy() is a compound function that is called earlier in the normal release as it ties together other bits of state. Signed-off-by:
-
Chris Wilson authored
The top-level page directory for 36b is a single entry, not multiple like 32b. Fix up the rounding on the calculation of the size of the top level so that we populate the 4th level correctly for 36b. Reported-by:
Jose Souza <jose.souza@intel.com> Signed-off-by:
Abdiel Janulgue <abdiel.janulgue@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190719130737.5835-1-chris@chris-wilson.co.uk
-
- 19 Jul, 2019 13 commits
-
-
YueHaibing authored
Fixes gcc '-Wunused-but-set-variable' warning: drivers/gpu/drm/i915/display/icl_dsi.c: In function 'gen11_dsi_set_transcoder_timings': drivers/gpu/drm/i915/display/icl_dsi.c:768:6: warning: variable 'hfront_porch' set but not used [-Wunused-but-set-variable] It is never used and can be removed. Reported-by:
Hulk Robot <hulkci@huawei.com> Signed-off-by:
YueHaibing <yuehaibing@huawei.com> Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190719015136.103988-1-yuehaibing@huawei.com
-
Michal Wajdeczko authored
When __gen8_ppgtt_alloc fails without allocating anything we should not try to call __gen8_ppgtt_clear as there is nothing to clear and underlying code will complain with: [ 157.861645] gen8_pd_range:881 GEM_BUG_ON(start >= end) Signed-off-by:
-
Chris Wilson authored
Since the underlying __gen8_ppgtt_clear takes the shifted address, we must remember to provide it with the shifted original start address. Reported-by:
-
Tvrtko Ursulin authored
This reverts commit 0629d4da. If GuC firmware is not present on the filesystem driver crashes the machine on boot. Signed-off-by:
Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Fixes: 0629d4da ("drm/i915: Update description of i915.enable_guc modparam") Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: intel-gfx@lists.freedesktop.org Link: https://patchwork.freedesktop.org/patch/msgid/20190719094845.6242-3-tvrtko.ursulin@linux.intel.com
-
Tvrtko Ursulin authored
This reverts commit f774f096. If GuC firmware is not present on the filesystem driver crashes the machine on boot. Signed-off-by:
-
Tvrtko Ursulin authored
We were missing this workaround which can cause hangs if fine grained coherency was used. Signed-off-by:
-
Tvrtko Ursulin authored
Having fixed the incorect MCR programming in an earlier patch, we can now stop ignoring read back of GEN8_L3SQCREG4 during engine workaround verification. Signed-off-by:
-
Tvrtko Ursulin authored
Access to 0xb100 - 0xb3ff mmio range is controlled by the MCR selector which only affects CPU MMIO. Therefore these registers cannot be realiably read with MI_SRM from the command streamer so skip their verification. Signed-off-by:
-
Tvrtko Ursulin authored
A couple issues were present in this code: 1. fls() usage was incorrect causing off by one in subslice mask lookup, which in other words means subslice mask of all zeroes is always used (subslice mask of a slice which is not present, or even out of bounds array access), rendering the checks in wa_init_mcr either futile or random. 2. Condition in WARN_ON was not correct. It is doing a bitwise and operation between a positive (present subslices) and negative mask (disabled L3 banks). This means that with corrected fls() usage the assert would always incorrectly fail. We could fix this by inverting the fuse bits in the check, but instead do one better and improve the code so it not only asserts, but finds the first common index between the two masks and only warns if no such index can be found. v2: * Simplify check for logic and redability. * Improve commentary explaining what is really happening ie. what the assert is really trying to check and why. v3: * Find first common index instead of just asserting. Signed-off-by:
-
Tvrtko Ursulin authored
Instead of re-calculating the MCR selector in read_subslice_reg do the rwm on its existing value and restore it when done. This consolidates MCR programming to one place for cnl+, and avoids re-calculating its default value on older platforms during hangcheck. Signed-off-by:
-
Tvrtko Ursulin authored
fls returns bit positions starting from one for the lsb and the MCR register expects zero based (sub)slice addressing. Incorrent MCR programming can have the effect of directing MMIO reads of registers in the 0xb100-0xb3ff range to invalid subslice returning zeroes instead of actual content. Signed-off-by:
-
YueHaibing authored
Fixes gcc '-Wunused-but-set-variable' warning: drivers/gpu/drm/i915/display/intel_sprite.c: In function 'g4x_sprite_check_scaling': drivers/gpu/drm/i915/display/intel_sprite.c:1494:13: warning: variable 'src_y' set but not used [-Wunused-but-set-variable] Reported-by:
-
Chris Wilson authored
As we unwind the requests for a preemption event, we return a virtual request back to its original virtual engine (so that it is available for execution on any of its siblings). In the process, this means that its breadcrumb should no longer be associated with the original physical engine, and so we are forced to decouple it. Previously, as the request could not complete without our awareness, we would move it to the next real engine without any danger. However, preempt-to-busy allowed for requests to continue on the HW and complete in the background as we unwound, which meant that we could end up retiring the request before fixing up the breadcrumb link. [51679.517943] INFO: trying to register non-static key. [51679.517956] the code is fine but needs lockdep annotation. [51679.517960] turning off the locking correctness validator. [51679.517966] CPU: 0 PID: 3270 Comm: kworker/u8:0 Tainted: G U 5.2.0+ #717 [51679.517971] Hardware name: Intel Corporation NUC7i5BNK/NUC7i5BNB, BIOS BNKBL357.86A.0052.2017.0918.1346 09/18/2017 [51679.518012] Workqueue: i915 retire_work_handler [i915] [51679.518017] Call Trace: [51679.518026] dump_stack+0x67/0x90 [51679.518031] register_lock_class+0x52c/0x540 [51679.518038] ? find_held_lock+0x2d/0x90 [51679.518042] __lock_acquire+0x68/0x1800 [51679.518047] ? find_held_lock+0x2d/0x90 [51679.518073] ? __i915_sw_fence_complete+0xff/0x1c0 [i915] [51679.518079] lock_acquire+0x90/0x170 [51679.518105] ? i915_request_cancel_breadcrumb+0x29/0x160 [i915] [51679.518112] _raw_spin_lock+0x27/0x40 [51679.518138] ? i915_request_cancel_breadcrumb+0x29/0x160 [i915] [51679.518165] i915_request_cancel_breadcrumb+0x29/0x160 [i915] [51679.518199] i915_request_retire+0x43f/0x530 [i915] [51679.518232] retire_requests+0x4d/0x60 [i915] [51679.518263] i915_retire_requests+0xdf/0x1f0 [i915] [51679.518294] retire_work_handler+0x4c/0x60 [i915] [51679.518301] process_one_work+0x22c/0x5c0 [51679.518307] worker_thread+0x37/0x390 [51679.518311] ? process_one_work+0x5c0/0x5c0 [51679.518316] kthread+0x116/0x130 [51679.518320] ? kthread_create_on_node+0x40/0x40 [51679.518325] ret_from_fork+0x24/0x30 [51679.520177] ------------[ cut here ]------------ [51679.520189] list_del corruption, ffff88883675e2f0->next is LIST_POISON1 (dead000000000100) Fixes: 22b7a426 ("drm/i915/execlists: Preempt-to-busy") Signed-off-by:
-
- 18 Jul, 2019 6 commits
-
-
Dhinakaran Pandiyan authored
A single 32-bit PSR2 training pattern field follows the sixteen element array of PSR table entries in the VBT spec. But, we incorrectly define this PSR2 field for each of the PSR table entries. As a result, the PSR1 training pattern duration for any panel_type != 0 will be parsed incorrectly. Secondly, PSR2 training pattern durations for VBTs with bdb version >= 226 will also be wrong. Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: José Roberto de Souza <jose.souza@intel.com> Cc: stable@vger.kernel.org Cc: stable@vger.kernel.org #v5.2 Fixes: 88a0d960 ("drm/i915/vbt: Parse and use the new field with PSR2 TP2/3 wakeup time") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111088 Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=204183Signed-off-by:
Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Reviewed-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Tested-by:
François Guerraz <kubrick@fgv6.net> Signed-off-by:
-
Chris Wilson authored
As recently disovered by forcing big-core (!llc) machines to use the GTT paths, we need our full GTT write flush before manipulating the GTT PTE or else the writes may be directed to the wrong page. Signed-off-by:
-
Chris Wilson authored
Inside pread, we only ever read from the GTT so the serialising wmb() instructions around the GGTT PTE updates are pointless. Signed-off-by:
-
Ville Syrjälä authored
On VLV/CHV there is some kind of linkage between the cdclk frequency and the DP link frequency. The spec says: "For DP audio configuration, cdclk frequency shall be set to meet the following requirements: DP Link Frequency(MHz) | Cdclk frequency(MHz) 270 | 320 or higher 162 | 200 or higher" I suspect that would more accurately be expressed as "cdclk >= DP link clock", and in any case we can express it like that in the code because of the limited set of cdclk (200, 266, 320, 400 MHz) and link frequencies (162 and 270 MHz) we support. Without this we can end up in a situation where the cdclk is too low and enabling DP audio will kill the pipe. Happens eg. with 2560x1440 modes where the 266MHz cdclk is sufficient to pump the pixels (241.5 MHz dotclock) but is too low for the DP audio due to the link frequency being 270 MHz. v2: Spell out the cdclk and link frequencies we actually support Cc: stable@vger.kernel.org Tested-by:
Stefan Gottwald <gottwald@igel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111149Signed-off-by:
-
Vivek Kasireddy authored
Although, DPLL4 enable and disable is associated with MGPLL1_ENABLE register, we can use ICL_DPLL_CFGCR0/CR1 macros to access this dpll's CR0 and CR1 registers by passing an id of 4 to these macros. Reported-by:
Vivek Kasireddy <vivek.kasireddy@intel.com> Signed-off-by:
-
Ville Syrjälä authored
Reduce the clutter a bit by introducing gen8_de_pipe_fault_mask(). Signed-off-by:
-
- 17 Jul, 2019 5 commits
-
-
Michel Thierry authored
Reuse Gen11 stolen memory changes since Tiger Lake uses the same BSM register (and format). Cc: Ingo Molnar <mingo@redhat.com> Cc: Borislav Petkov <bp@alien8.de> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: x86@kernel.org Signed-off-by:
Michel Thierry <michel.thierry@intel.com> Signed-off-by:
Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by:
Thomas Gleixner <tglx@linutronix.de> Link: https://patchwork.freedesktop.org/patch/msgid/20190712210238.5622-1-lucas.demarchi@intel.com
-
Chris Wilson authored
Push the engine stop into the back reset_prepare (where it already was!) This allows us to avoid dangerously setting the RING registers to 0 for logical contexts. If we clear the register on a live context, those invalid register values are recorded in the logical context state and replayed (with hilarious results). Signed-off-by:
-
Chris Wilson authored
By stopping the rings, we may trigger an arbitration point resulting in a premature context-switch (i.e. a completion event before the request is actually complete). This clears the active context before the reset, but we must remember to rewind the incomplete context for replay upon resume. Fixes: 1863e302 ("drm/i915/execlists: Always reset the context's RING registers") Signed-off-by:
-
Tvrtko Ursulin authored
Commit f774f096 ("drm/i915/guc: Turn on GuC/HuC auto mode") changed the default from 0 to -1 but forgot to update the description. Signed-off-by:
-
Chris Wilson authored
Avoid a global idle barrier by reconfiguring each context by rewriting them with MI_STORE_DWORD from the kernel context. v2: We only need to determine the desired register values once, they are the same for all contexts. v3: Don't remove the kernel context from the list of known GEM contexts; the world is not ready for that yet. Signed-off-by:
Lionel Landwerlin <lionel.g.landwerlin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190716213443.9874-1-chris@chris-wilson.co.uk
-
