- 01 Aug, 2019 2 commits
-
-
Wei Yongjun authored
'ksv_fifo' is malloced in intel_hdcp_auth_downstream() and should be freed before leaving from the error handling cases, otherwise it will cause memory leak. Fixes: f26ae6a6 ("drm/i915: SRM revocation check for HDCP1.4 and 2.2") Signed-off-by:
Wei Yongjun <weiyongjun1@huawei.com> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190704104534.12508-1-weiyongjun1@huawei.com
-
Chris Wilson authored
If we skip the reset as we found the engine inactive at the time of the reset, we still need to clear the residual inflight & pending request bookkeeping to reflect the current state of HW. Otherwise, we may end up stuck in a loop like: <7> [416.490346] hangcheck rcs0 <7> [416.490371] hangcheck Awake? 1 <7> [416.490376] hangcheck Hangcheck: 8003 ms ago <7> [416.490380] hangcheck Reset count: 0 (global 0) <7> [416.490383] hangcheck Requests: <7> [416.491210] hangcheck RING_START: 0x0017b000 <7> [416.491983] hangcheck RING_HEAD: 0x00000048 <7> [416.491992] hangcheck RING_TAIL: 0x00000048 <7> [416.492006] hangcheck RING_CTL: 0x00000000 <7> [416.492037] hangcheck RING_MODE: 0x00000200 [idle] <7> [416.492044] hangcheck RING_IMR: 00000000 <7> [416.492809] hangcheck ACTHD: 0x00000000_9ca00048 <7> [416.492824] hangcheck BBADDR: 0x00000000_00001004 <7> [416.492838] hangcheck DMA_FADDR: 0x00000000_00000000 <7> [416.492845] hangcheck IPEIR: 0x00000000 <7> [416.492852] hangcheck IPEHR: 0x00000000 <7> [416.492863] hangcheck Execlist status: 0x00018001 00000000, entries 12 <7> [416.492869] hangcheck Execlist CSB read 1, write 1, tasklet queued? no (enabled) <7> [416.492938] hangcheck Pending[0] ring:{start:0017b000, hwsp:fedf9000, seqno:00016fd6}, rq: 20ffa:16fd6!+ prio=-4094 @ 8307ms: signaled <7> [416.492972] hangcheck Queue priority hint: -4093 <7> [416.492979] hangcheck Q 20ffa:16fd8- prio=-4093 @ 8307ms: [i915] <7> [416.492985] hangcheck Q 20ffa:16fda prio=-4094 @ 8307ms: [i915] <7> [416.492990] hangcheck Q 20ffa:16fdc prio=-4094 @ 8307ms: [i915] <7> [416.492996] hangcheck Q 20ffa:16fde prio=-4094 @ 8307ms: [i915] <7> [416.493001] hangcheck Q 20ffa:16fe0 prio=-4094 @ 8307ms: [i915] <7> [416.493007] hangcheck Q 20ffa:16fe2 prio=-4094 @ 8307ms: [i915] <7> [416.493013] hangcheck Q 20ffa:16fe4 prio=-4094 @ 8307ms: [i915] <7> [416.493021] hangcheck ...skipping 21 queued requests... <7> [416.493027] hangcheck Q 20ffa:17010 prio=-4094 @ 8307ms: [i915] <7> [416.493081] hangcheck HWSP: <7> [416.493089] hangcheck [0000] 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 <7> [416.493094] hangcheck * <7> [416.493100] hangcheck [0040] 10008002 00000000 10000018 00000000 10000018 00000000 10000001 00000000 <7> [416.493106] hangcheck [0060] 10000018 00000000 10000001 00000000 10000018 00000000 10000001 00000000 <7> [416.493111] hangcheck * <7> [416.493117] hangcheck [00a0] 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000001 <7> [416.493123] hangcheck [00c0] 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 <7> [416.493127] hangcheck * <7> [416.493132] hangcheck Idle? no <6> [416.512124] i915 0000:00:02.0: GPU HANG: ecode 11:0:0x00000000, hang on rcs0 <6> [416.512205] [drm] GPU hangs can indicate a bug anywhere in the entire gfx stack, including userspace. <6> [416.512207] [drm] Please file a _new_ bug report on bugs.freedesktop.org against DRI -> DRM/Intel <6> [416.512208] [drm] drm/i915 developers can then reassign to the right component if it's not a kernel issue. <6> [416.512210] [drm] The gpu crash dump is required to analyze gpu hangs, so please always attach it. <6> [416.512212] [drm] GPU crash dump saved to /sys/class/drm/card0/error <5> [416.513602] i915 0000:00:02.0: Resetting rcs0 for hang on rcs0 <7> [424.489258] hangcheck rcs0 <7> [424.489263] hangcheck Awake? 1 <7> [424.489267] hangcheck Hangcheck: 5954 ms ago <7> [424.489271] hangcheck Reset count: 1 (global 0) <7> [424.489274] hangcheck Requests: <7> [424.490128] hangcheck RING_START: 0x00000000 <7> [424.490870] hangcheck RING_HEAD: 0x00000000 <7> [424.490877] hangcheck RING_TAIL: 0x00000000 <7> [424.490887] hangcheck RING_CTL: 0x00000000 <7> [424.490897] hangcheck RING_MODE: 0x00000200 [idle] <7> [424.490904] hangcheck RING_IMR: 00000000 <7> [424.490917] hangcheck ACTHD: 0x00000000_00000000 <7> [424.490930] hangcheck BBADDR: 0x00000000_00000000 <7> [424.490943] hangcheck DMA_FADDR: 0x00000000_00000000 <7> [424.490950] hangcheck IPEIR: 0x00000000 <7> [424.490956] hangcheck IPEHR: 0x00000000 <7> [424.490968] hangcheck Execlist status: 0x00000001 00000000, entries 12 <7> [424.490972] hangcheck Execlist CSB read 11, write 11, tasklet queued? no (enabled) <7> [424.490983] hangcheck Pending[0] ring:{start:0017b000, hwsp:fedf9000, seqno:00016fd6}, rq: 20ffa:16fd6!+ prio=-4094 @ 16305ms: signaled <7> [424.490989] hangcheck Queue priority hint: -4093 <7> [424.490996] hangcheck Q 20ffa:16fd8- prio=-4093 @ 16305ms: [i915] <7> [424.491001] hangcheck Q 20ffa:16fda prio=-4094 @ 16305ms: [i915] <7> [424.491006] hangcheck Q 20ffa:16fdc prio=-4094 @ 16305ms: [i915] <7> [424.491011] hangcheck Q 20ffa:16fde prio=-4094 @ 16305ms: [i915] <7> [424.491016] hangcheck Q 20ffa:16fe0 prio=-4094 @ 16305ms: [i915] <7> [424.491022] hangcheck Q 20ffa:16fe2 prio=-4094 @ 16305ms: [i915] <7> [424.491048] hangcheck Q 20ffa:16fe4 prio=-4094 @ 16305ms: [i915] <7> [424.491057] hangcheck ...skipping 21 queued requests... <7> [424.491063] hangcheck Q 20ffa:17010 prio=-4094 @ 16305ms: [i915] <7> [424.491095] hangcheck HWSP: <7> [424.491102] hangcheck [0000] 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 <7> [424.491106] hangcheck * <7> [424.491113] hangcheck [0040] 10008002 00000000 10000018 00000000 10000018 00000000 10000001 00000000 <7> [424.491118] hangcheck [0060] 10000018 00000000 10000001 00000000 10000018 00000000 10000001 00000000 <7> [424.491122] hangcheck * <7> [424.491127] hangcheck [00a0] 00000000 00000000 00000000 00000000 00000000 00000000 00000000 0000000b <7> [424.491133] hangcheck [00c0] 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 <7> [424.491136] hangcheck * <7> [424.491141] hangcheck Idle? no <5> [424.491834] i915 0000:00:02.0: Resetting rcs0 for hang on rcs0 Where not having cleared the pending array on reset, it persists indefinitely. Fixes: fff8102a ("drm/i915/execlists: Process interrupted context on reset") Signed-off-by:Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by:
Andi Shyti <andi.shyti@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190730133035.1977-2-chris@chris-wilson.co.uk
-
- 31 Jul, 2019 11 commits
-
-
José Roberto de Souza authored
Specification states that DDI_CLK_SEL needs to be mapped to MG clock even if MG do not exist on EHL, this will ungate those DDIs. BSpec: 20845 Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Vivek Kasireddy <vivek.kasireddy@intel.com> Signed-off-by:
José Roberto de Souza <jose.souza@intel.com> Reviewed-by:
Matt Roper <matthew.d.roper@intel.com> Tested-by:
-
Tvrtko Ursulin authored
Hide the details of MOCS setup from i915_gem by moving both current calls into one in intel_mocs_init. Cc: Stuart Summers <stuart.summers@intel.com> Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by:
Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by:
Stuart Summers <stuart.summers@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190713010940.17711-21-lucas.demarchi@intel.com Link: https://patchwork.freedesktop.org/patch/msgid/20190730180407.5993-6-lucas.demarchi@intel.com
-
Michel Thierry authored
Until Icelake, each engine had its own set of 64 MOCS registers. In order to simplify, Tigerlake moves to only 64 Global MOCS registers, which are no longer part of the engine context. Since these registers are now global, they also only need to be initialized once. >From Gen12 onwards, MOCS must specify the target cache (3:2) and LRU management (5:4) fields and cannot be programmed to 'use the value from Private PAT', because these fields are no longer part of the PPAT. Also cacheability control (1:0) field has changed, 00 no longer means 'use controls from page table', but uncacheable (UC). v2 (Lucas): - Move the changes to the fault registers to a separate commit - the old ones overlap with the range used by the new global MOCS (requested by Daniele) v3 (Lucas): - Clarify comment about setting the unused entries to the same value of index 0, that is the invalid entry (requested by Daniele) - Move changes to DONE_REG and ERROR_GEN6 to a separate commit (requested by Daniele) Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by:Michel Thierry <michel.thierry@intel.com> Signed-off-by:
Tomasz Lis <tomasz.lis@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190730180407.5993-5-lucas.demarchi@intel.com
-
Tomasz Lis authored
The MOCS table is published as part of bspec, and versioned. Entries are supposed to never be modified, but new ones can be added. Adding entries increases table version. The patch includes version 1 entries. Two of the 3 legacy entries used for gen9 are no longer expected to work. Although we are changing the gen11 table, those changes are supposed to be backward compatible since we are only touching previously undefined entries. v2: Add the missing entries in 49-51 range and replace "HW reserved" terminology to what it actually is: L1 is implicitly enabled (from Daniele) v3: Use a different table for Tiger Lake since entries 0 and 1 are not the same (from Daniele) Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by:Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190730180407.5993-4-lucas.demarchi@intel.com
-
Lucas De Marchi authored
These registers have been removed on gen12. v2: merge common branch for IS_GEN_RANGE(i915, 6, 11) Signed-off-by:
-
Lucas De Marchi authored
The fault registers moved to another offset. The old location is now taken by the global MOCS registers, to be added in a follow up change. Based on previous patches by Michel Thierry <michel.thierry@intel.com>. Signed-off-by:
-
Lucas De Marchi authored
Commit 20a7f2fc ("drm/i915: Convert intel_mocs_init_l3cc_table to intel_gt") removed the only user. Signed-off-by:
-
Daniele Ceraolo Spurio authored
The register we write are not WOPCM regs but uC ones related to how GuC and HuC are going to use the WOPCM, so it makes logical sense for them to be programmed as part of uc_init_hw. The WOPCM map on the other side is not uC-specific (although that is our main use-case), so keep that separate. v2: move write_and_verify to uncore, fix log, re-use err_out tag, add intel_wopcm_guc_base, fix log Signed-off-by:Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by:
-
Daniele Ceraolo Spurio authored
When coming out of S3/S4 we sanitize and re-init the HW, which includes enabling communication during uc_init_hw. We therefore don't want to do that again in uc_resume and can just tell GuC to reload its state. v2: split uc_resume and uc_runtime_resume to match the suspend functions and to better differentiate the expected state in the 2 scenarios (Chris) Signed-off-by: -
Chris Wilson authored
Teach igt_spinner to only use our internal structs, decoupling the interface from the GEM contexts. This makes it easier to avoid requiring ce->gem_context back references for kernel_context that may have them in future. v2: Lift engine lock to verify_wa() caller. v3: Less than v2, but more so Signed-off-by:
-
Chris Wilson authored
My plan for the future is to have kernel contexts not to have a GEM context backpointer (as they will not belong to any GEM context). In a few places, we use ce->gem_context to simply obtain the i915 backpointer, for which we can use ce->engine->i915 instead. Signed-off-by:
-
- 30 Jul, 2019 9 commits
-
-
Lucas De Marchi authored
Fix build breakage: In file included from <command-line>: ./drivers/gpu/drm/i915/i915_selftest.h:125:1: error: unknown type name ‘bool’ 125 | bool __igt_timeout(unsigned long timeout, const char *fmt, ...); | ^~~~ Signed-off-by: -
Lucas De Marchi authored
For Tiger Lake the DE Port Interrupt Definition bits changed, so use the new bit definitions. Cc: Jose Souza <jose.souza@intel.com> Signed-off-by:
Anusha Srivatsa <anusha.srivatsa@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190713010940.17711-7-lucas.demarchi@intel.com Link: https://patchwork.freedesktop.org/patch/msgid/20190725234813.27179-4-lucas.demarchi@intel.com
-
José Roberto de Souza authored
TGL has 3 combophys and 6 TC/TBT ports, so it has 2 more TC/TBT ports than ICL and the PORT_C on TGL is a combophy. So here adding a new hpd north table and function to detect long pulse for TGL. Signed-off-by:
-
Lucas De Marchi authored
Add hotdplug detection for all ports on TGP. icp_hpd_detection_setup() is refactored to be shared with TGP. While we increase the number of pins, add a BUILD_BUG_ON() to avoid going over the number of bits allowed. v2: use BITS_PER_TYPE and correct type for BUILD_BUG_ON() check (requested by Ville) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Jose Souza <jose.souza@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: -
Rodrigo Vivi authored
Signed-off-by:Rodrigo Vivi <rodrigo.vivi@intel.com>
-
Chris Wilson authored
Track the currently bound address space used by the HW context. Minor conversions to use the local intel_context.vm are made, leaving behind some more surgery required to make intel_context the primary through the selftests. Signed-off-by:
-
Chris Wilson authored
The aliasing_ppgtt provides a PIN_USER alias for the global gtt, so move it under the i915_ggtt to simplify later transformations to enable intel_context.vm. Signed-off-by:
-
Chris Wilson authored
We only use the init_context vfunc once while recording the default context state, and we use the same sequence in each backend (eliding steps that do not apply). Remove the vfunc for simplicity and de-duplication. Signed-off-by:
-
Jani Nikula authored
Throw out our local hacks of header tests now that the more generic kbuild versions are upstream. At least for now, continue to keep the header tests behind CONFIG_DRM_I915_WERROR=y knob. Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
-
- 29 Jul, 2019 4 commits
-
-
Michal Wajdeczko authored
HuC is usually not a critical component, so we can safely ignore firmware load or authentication failures unless HuC was explicitly requested by the user. v2: add convenient way to disable loading (Chris) Signed-off-by:
-
Rodrigo Vivi authored
Catching up with 5.3-rc* Signed-off-by: -
Chris Wilson authored
As the gen6_ppgtt may refer back to the GGTT for their page-directory slots, make sure those __i915_vm_release are completed prior to shutting down the GGTT. Fixes: b32fa811 ("drm/i915/gtt: Defer address space cleanup to an RCU worker") Signed-off-by:
-
Chris Wilson authored
Smatch spotted that we test at the start of hang_fini for a valid (h->gt is only set after a request is created) but then used it regardless later on. v2: Alternatively, we do not need to check as we now always prime h->gt in hang_init() References: cb823ed9 ("drm/i915/gt: Use intel_gt as the primary object for handling resets") Signed-off-by:
-
- 27 Jul, 2019 1 commit
-
-
Chris Wilson authored
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c:194: warning: Function parameter or member 'i915' not described in 'intel_uc_fw_fetch' drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c:194: warning: Excess function parameter 'dev_priv' description in 'intel_uc_fw_fetch' Fixes: 97dee74b ("drm/i915/uc: Reorder params in intel_uc_fw_fetch") Signed-off-by:
-
- 26 Jul, 2019 13 commits
-
-
Mahesh Kumar authored
In GEN 12 PORT_C DDI clk_off bit is not equally distanced to A/B, it's at offset 24. Similarly TC port (5/6) clk off bits are at offset 22/23. Extend the macros to cover the additional ports. Cc: Matt Roper <matthew.d.roper@intel.com> Signed-off-by:
Mahesh Kumar <mahesh1.kumar@intel.com> Signed-off-by:
Matt Atwood <matthew.s.atwood@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190713010940.17711-4-lucas.demarchi@intel.com
-
Mahesh Kumar authored
Bit definitions for port-select got changed for TRANS_CLK_SEL & TRANS_DDI_FUNC_CTL registers in TGL. v2 (Lucas): - Nuke TRANS_DDI_PORT_NONE since it's 0: we are already clearing {TGL_,}TRANS_DDI_PORT_MASK (suggested by Ville) - Also cover haswell_get_ddi_port_state() in intel_display.c that was missing - Define macros using the _SHIFT macros so we don't lose other users Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: -
Lucas De Marchi authored
According to the spec when initializing the display in TGL we should not set PORT_CL_DW12 for the Aux channel of the combo PHYs. We will re-use the power well hooks from ICL so only set this register on gen < 12. v2: Generalize check for gen 12 (suggested by José) v3: Rebase after enum phy introduction Cc: Imre Deak <imre.deak@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Signed-off-by:
-
Michal Wajdeczko authored
According to Firmware layout definition, RSA signature is located after CSS header and uCode so actual RSA offset in the blob can be easily calculated when needed (and we need it only once). Signed-off-by:
-
Michal Wajdeczko authored
According to Firmware layout definition, uCode is located right after CSS header, so ucode offset is always same as header size. Signed-off-by:
-
Michal Wajdeczko authored
According to Firmware layout definition, CSS header is located in front of the firmware blob, so header offset is always 0. Similarly, size of the CSS header is constant and currently used version is exactly 128. While here, move type/status enums up and keep them together. v2: use sizeof consistently (Daniele), update commit message Signed-off-by:
-
Chris Wilson authored
Modifying a remote context requires careful serialisation with requests on that context, and that serialisation requires us to take their timeline->mutex. Make it so. Note that while struct_mutex rules, we can't create more than one request in parallel, but that age is soon coming to an end. v2: Though it doesn't affect the current users, contexts may share timelines so check if we already hold the right mutex. Signed-off-by:
-
Michal Wajdeczko authored
We are already storing runtime value of log level in private field, so there is no need to modify modparam. Signed-off-by:
-
Tvrtko Ursulin authored
for_each_engine_masked caches the engine mask but what does the caller know. Cache it explicitly for clarity and while at it correct the type to match. Signed-off-by:
-
Chris Wilson authored
Smatch warning that the loop may be empty causing us to check err before it had been set. Ensure that it is initialised to 0, just in case. v2: Refactor the inner loop for better scooping and clarity Fixes: a9877da2 ("drm/i915/oa: Reconfigure contexts on the fly") Signed-off-by:
Lionel Landwerlin <lionel.g.landwerlin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190726131458.8310-1-chris@chris-wilson.co.uk
-
Daniele Ceraolo Spurio authored
guc->stage_desc_pool is required as part of the init parameters and there is no reason we have to init them after HuC. This fixes a NULL ptr dereference due to guc->stage_desc_pool not being set (no fixes tag since GuC submission can't be enabled yet). Signed-off-by:
-
Michal Wajdeczko authored
All intel_uc_fw_* functions are taking uc_fw as first param except intel_uc_fw_fetch() which is taking i915. Fix that. Signed-off-by:
-
Chris Wilson authored
Currently we use the engine->active.lock to ensure that the request is not retired as we capture the data. However, we only need to ensure that the vma are not removed prior to use acquiring their contents, and since we have already relinquished our stop-machine protection, we assume that the user will not be overwriting the contents before we are able to record them. In order to capture the vma outside of the spinlock, we acquire a reference and mark the vma as active to prevent it from being unbound. However, since it is tricky allocate an entry in the fence tree (doing so would require taking a mutex) while inside the engine spinlock, we use an atomic bit and special case the handling for i915_active_wait. The core benefit is that we can use some non-atomic methods for mapping the device pages, we can remove the slow compression phase out of atomic context (i.e. stop antagonising the nmi-watchdog), and no we longer need large reserves of atomic pages. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111215Signed-off-by:
Matthew Auld <matthew.william.auld@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190725223843.8971-1-chris@chris-wilson.co.uk
-
