- 05 Aug, 2019 5 commits
-
-
Michal Wajdeczko authored
Since commit 301efe96 ("drm/i915/uc: Don't fail on HuC firmware failure") we can continue driver load after error during HuC firmware load or authentication, but we could still fail on any error during early HuC initialization. Change that by ignoring HuC related errors until hardware initialization phase where we can decide about next steps. Signed-off-by:
Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190804195052.31140-5-michal.wajdeczko@intel.com
-
Michal Wajdeczko authored
Since commit db81bc6e ("drm/i915/uc: Consider enable_guc modparam during fw selection") we have started using firmware status as main indicator of the GuC support. No need to use same checks twice. Signed-off-by:
-
Michal Wajdeczko authored
No need to dance with intel_uc_supports_huc(uc) as we can directly use intel_huc_is_supported(huc) Signed-off-by:
-
Michal Wajdeczko authored
No need to use intel_uc_supports_guc_submission(uc) as we can directly use intel_guc_is_submission_supported(guc) Signed-off-by:
-
Stanislav Lisovskiy authored
According to Bspec clock divisor registers in GeminiLake should be initialized by shifting 1(<<) to amount of correspondent divisor. While i915 was writing all this time that value as is. Surprisingly that it by accident worked, until we met some issues with Microtech Etab. v2: Added Fixes tag and cc v3: Added stable to cc as well. Signed-off-by:
Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Reviewed-by:
Vandita Kulkarni <vandita.kulkarni@intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108826 Fixes: bcc65700 ("drm/i915/glk: Program txesc clock divider for GLK") Cc: Deepak M <m.deepak@intel.com> Cc: Madhav Chauhan <madhav.chauhan@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: intel-gfx@lists.freedesktop.org Cc: stable@vger.kernel.org Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190712081938.14185-1-stanislav.lisovskiy@intel.com
-
- 04 Aug, 2019 2 commits
-
-
Chris Wilson authored
Switch to tracking activity via i915_active on individual nodes, only keeping a list of retired objects in the cache, and reaping the cache when the engine itself idles. Signed-off-by:
Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190804124826.30272-2-chris@chris-wilson.co.uk
-
Chris Wilson authored
In the next patch, we would like to couple into the engine wakeref to free the batch pool on idling. The caveat here is that we therefore want to track the engine wakeref more precisely and to hold it instead of the broader GT wakeref as we process the ioctl. v2: Avoid introducing odd semantics for a shortlived timeline->mutex acquisition interface. Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190804124826.30272-1-chris@chris-wilson.co.uk
-
- 02 Aug, 2019 14 commits
-
-
Chris Wilson authored
As we increase the number of RCU objects, it becomes easier for us to have several hundred thousand objects in the deferred RCU free queues. An example is gem_ctx_create/files which continually creates active contexts, which are not immediately freed upon close as they are kept alive by outstanding requests. This lack of backpressure allows the context objects to persist until they overwhelm and starve the system. We can increase our backpressure by flushing the freed object queue upon closing the device fd which should then not impact other clients. Testcase: igt/gem_ctx_create/*files Signed-off-by:
-
Chris Wilson authored
The shrinker cannot touch objects used by the contexts (logical state and ring). Currently we mark those as "pin_global" to let the shrinker skip over them, however, if we remove them from the shrinker lists entirely, we don't event have to include them in our shrink accounting. By keeping the unshrinkable objects in our shrinker tracking, we report a large number of objects available to be shrunk, and leave the shrinker deeply unsatisfied when we fail to reclaim those. The shrinker will persist in trying to reclaim the unavailable objects, forcing the system into a livelock (not even hitting the dread oomkiller). v2: Extend unshrinkable protection for perma-pinned scratch and guc allocations (Tvrtko) v3: Notice that we should be pinned when marking unshrinkable and so the link cannot be empty; merge duplicate paths. Signed-off-by:
-
Michal Wajdeczko authored
We don't have to immediately fail on WOPCM partitioning, we can wait until we will start programming WOPCM registers. This should give us more options if we decide to restore fallback in case of GuC failures. v3: rebased Signed-off-by:
-
Michal Wajdeczko authored
Inject probe errors into intel_uc_init_hw to make sure we correctly handle any uC initialization failure. To avoid complains from CI about injected errors use i915_probe_error to lower message level. v4: rebased after moving hot fixes moved to separate patches Signed-off-by:
-
Michal Wajdeczko authored
When we fail to load GuC and want to abort probe, we hit: <7> [229.915779] i915 0000:00:02.0: [drm:intel_uc_init_hw [i915]] GuC initialization failed -6 <7> [229.915813] i915 0000:00:02.0: [drm:i915_gem_init_hw [i915]] Enabling uc failed (-6) <4> [229.953354] ------------[ cut here ]------------ <4> [229.953355] WARN_ON(dev_priv->mm.shrink_count) <4> [229.953406] WARNING: CPU: 9 PID: 3287 at drivers/gpu/drm/i915/i915_gem.c:1684 i915_gem_cleanup_early+0xfc/0x110 [i915] <4> [229.953464] Call Trace: <4> [229.953489] i915_driver_late_release+0x19/0x60 [i915] <4> [229.953514] i915_driver_probe+0xb82/0x18a0 [i915] <4> [229.953519] ? __pm_runtime_resume+0x4f/0x80 <4> [229.953545] i915_pci_probe+0x43/0x1b0 [i915] ... <4> [229.962951] ------------[ cut here ]------------ <4> [229.962956] DEBUG_LOCKS_WARN_ON(lock->magic != lock) <4> [229.962959] WARNING: CPU: 8 PID: 2395 at kernel/locking/mutex.c:912 __mutex_lock+0x750/0x9b0 <4> [229.963091] Call Trace: <4> [229.963129] ? i915_vma_destroy+0x86/0x350 [i915] <4> [229.963166] ? i915_vma_destroy+0x86/0x350 [i915] <4> [229.963201] i915_vma_destroy+0x86/0x350 [i915] <4> [229.963236] __i915_gem_free_objects+0xb8/0x510 [i915] <4> [229.963270] __i915_gem_free_work+0x5a/0x90 [i915] <4> [229.963275] process_one_work+0x245/0x610 as since commit 6f76098f ("drm/i915/uc: Move uC early functions inside the GT ones") we cleanup uc after gem. Move captured GuC load error log to uc struct and release it in intel_uc_fini() instead of intel_uc_driver_late_release() Note that intel_uc_driver_late_release() is now empty, but we can leave it as a placeholder for future code. Signed-off-by:
-
Michal Wajdeczko authored
On Gen9 when we try to reload HuC due to GuC upload error, we hit: <7> [232.025927] [drm:intel_uc_init_hw [i915]] GuC fw load failed: -8; will reset and retry 2 more time(s) <7> [232.026004] [drm:intel_uc_fw_upload [i915]] HuC fw load i915/kbl_huc_ver02_00_1810.bin <7> [232.026686] [drm:intel_uc_fw_upload [i915]] HuC fw xfer completed <6> [232.026688] [drm] HuC: Loaded firmware i915/kbl_huc_ver02_00_1810.bin (version 2.0) <3> [232.026703] intel_uc_fw_copy_rsa:541 GEM_BUG_ON(!intel_uc_fw_is_available(uc_fw)) as firmware that previously failed to load was wrongly treated as unavailable since its status code was not matching status check logic. Signed-off-by:
-
Michal Wajdeczko authored
On Gen9 when we try to reload HuC due to GuC upload error, we hit: <7> [229.656688] [drm:intel_uc_init_hw [i915]] GuC fw load failed: -8; will reset and retry 2 more time(s) <7> [229.656739] [drm:intel_uc_fw_upload [i915]] HuC fw load i915/kbl_huc_ver02_00_1810.bin <3> [229.656740] intel_uc_fw_upload:425 GEM_BUG_ON(intel_uc_fw_is_loaded(uc_fw)) as we performed only pure reset and didn't sanitized HuC fw status. Signed-off-by:
-
Michal Wajdeczko authored
With i915 added to i915_inject_probe_failure we can use dedicated printk when injecting artificial load failure. Also make this function look like other i915 functions that return error code and make it more flexible to return any provided error code instead of previously assumed -ENODEV. Signed-off-by:
-
Chris Wilson authored
Since commit 64d6c500 ("drm/i915: Generalise GPU activity tracking"), we have been prepared for i915_vma_move_to_active() to fail. We can take advantage of this to report the failure for allocating the shared-fence slot in the reservation_object. Signed-off-by:
-
Michal Wajdeczko authored
Use section name "Return" and proper error code -ETIMEDOUT Signed-off-by:
-
Jani Nikula authored
Update the generated files to make the headers self-contained, switch to the kernel preferred SPDX comment format, and update the copyright year. Also add the Makefile stanza to run header tests on the files. Other changes produced by gputop i915-perf-kernelgen.py were manually stripped out, and left to the folks who actually know something about the OA stuff. Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Reviewed-by:
-
Chris Wilson authored
By placing our idle-barriers in the i915_active fence tree, we expose those for reuse by other components that are issuing requests along the kernel_context. Reusing the proto-barrier active_node is perfectly fine as the new request implies a context-switch, and so an opportune point to run the idle-barrier. However, the proto-barrier is not equivalent to a normal active_node and care must be taken to avoid dereferencing the ERR_PTR used as its request marker. v2: Comment the more egregious cheek v3: A glossary! Reported-by:
Lionel Landwerlin <lionel.g.landwerlin@intel.com> Fixes: ce476c80 ("drm/i915: Keep contexts pinned until after the next kernel context switch") Fixes: a9877da2 ("drm/i915/oa: Reconfigure contexts on the fly") Signed-off-by:
-
Chris Wilson authored
Recently discovered in commit bdae33b8 ("drm/i915: Use maximum write flush for pwrite_gtt") was that we needed to our full write barrier before changing the GGTT PTE to ensure that our indirect writes through the GTT landed before the PTE changed (and the writes end up in a different page). That also applies to our GGTT relocation path. Signed-off-by:
Prathap Kumar Valsan <prathap.kumar.valsan@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190730112151.5633-4-chris@chris-wilson.co.uk
-
Chris Wilson authored
Currently, we only sample if the intel_gt is awake, but we acquire our own runtime_pm wakeref. Since intel_gt has transitioned to tracking its own wakeref, we can atomically test and acquire that wakeref instead. v2: Take engine->wakeref for engine sampling Signed-off-by:
-
- 01 Aug, 2019 18 commits
-
-
Tvrtko Ursulin authored
RC6 is a GT state so make the function parameter reflect that. Signed-off-by:
-
Tvrtko Ursulin authored
Engines and frequencies are a GT thing so adjust sampling routines to match. Signed-off-by:
-
Tvrtko Ursulin authored
Drops one macro using implicit dev_priv. v2: * Use ENGINE_READ_FW. (Chris) Signed-off-by:
-
Tvrtko Ursulin authored
Just tidy the code a bit by removing a sea of overly verbose i915->pmu.*. Signed-off-by:
-
Jordan Justen authored
This enables the Mesa driver to advertise support for ARB_timer_query, and thus an OpenGL version higher than 3.2. Based on the ICL patch by Paulo Zanoni and CNL patch by Nanley Chery. Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
Jordan Justen <jordan.l.justen@intel.com> Signed-off-by:
Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190726002412.5827-3-lucas.demarchi@intel.com
-
José Roberto de Souza authored
Tiger Lake has a new register offset for DC5 and DC6 residency counters. v2: - Rename registers since they are not in the CSR memory range (requested by Anshuman) - Fix type (requested by Matthew) Signed-off-by:José Roberto de Souza <jose.souza@intel.com> Signed-off-by:
Anshuman Gupta <anshuman.gupta@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190726002412.5827-2-lucas.demarchi@intel.com
-
Michal Wajdeczko authored
As we already track GuC/HuC uses by other means than modparam there is no point in sanitizing it. Just scan modparam for major discrepancies between what was requested vs actual. v2: rebased, reworded info messages v3: oops Signed-off-by:
-
Michal Wajdeczko authored
Instead of relying on enable_guc modparam to represent actual GuC submission mode, use dedicated flag and look at modparam only to check if submission was explicitly disabled by the user. v2: rebased, simplified condition (Chris) Signed-off-by:
-
Michal Wajdeczko authored
We can use value of enable_guc modparam during firmware path selection and start using firmware status to see if GuC/HuC is being used. This is first step to make enable_guc modparam read-only. v2: rebased, don't care about <0 (Chris) v3: oops Signed-off-by:
-
Michal Wajdeczko authored
Rename intel_uc_is_using* into intel_uc_supports* to make clear distinction from actual state (compare intel_uc_fw_is_running) Suggested-by:
-
Daniele Ceraolo Spurio authored
To be called from the top level runtime functions, to hide the gt-specific bits (mainly related to intel_uc). v2: rebased Signed-off-by:
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Reviewed-by:
-
Daniele Ceraolo Spurio authored
uC is a subcomponent of GT, so initialize/clean it as part of it. The wopcm_init_early doesn't have to be happen before the uC one, but since in other parts of the code we consider WOPCM first do the same for consistency. v2: s/cleanup_early/late_release to match the caller v3: s/late_release/driver_late_release/ (Chris) Signed-off-by:
-
Daniele Ceraolo Spurio authored
We don't call the init_early function from within the gem code, so we shouldn't do it for the cleanup either. v2: while at it, s/gt_cleanup_early/gt_late_release (Chris) v3: s/late_release/driver_late_release/ (Chris) Signed-off-by:
-
Chris Wilson authored
We only compute the lrc_descriptor() on pinning the context, i.e. infrequently, so we do not benefit from storing the template as the addressing mode is also fixed for the lifetime of the intel_context. Signed-off-by:
-
Matt Roper authored
We're mostly re-using ICL's interrupt handling on EHL, but we still need to remember to account for the extra combo port that EHL has. Use TGP's mask (which includes combo port C) rather than ICP's mask when appropriate. Let's also skip reading TC-specific registers on this platform since EHL doesn't have any TC ports. v2: Base setup of SHOTPLUG_CTL_TC on whether the tc pin mask is non-zero rather than performing another PCH type check. (Jose) Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Vivek Kasireddy <vivek.kasireddy@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by:Matt Roper <matthew.d.roper@intel.com> Reviewed-by:
-
Jani Nikula authored
Apparently the empty Makefile has caused some confusion. Add the subdir-cc-flags-y as in 7fcc7ca5 ("drm/i915: add header search path to subdir Makefiles") which should be useful. The generated headers still aren't self-contained, so can't add that. References: http://marc.info/?i=80bf2204-558a-6d3f-c493-bf17b891fc8a@infradead.org Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by:
-
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:
-
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:Andi Shyti <andi.shyti@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190730133035.1977-2-chris@chris-wilson.co.uk
-
- 31 Jul, 2019 1 commit
-
-
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:
-
