Revision tags: v6.6.26, v6.6.25, v6.6.24, v6.6.23, v6.6.16, v6.6.15, v6.6.14, v6.6.13, v6.6.12, v6.6.11, v6.6.10, v6.6.9, v6.6.8, v6.6.7, v6.6.6, v6.6.5, v6.6.4, v6.6.3, v6.6.2, v6.5.11, v6.6.1, v6.5.10, v6.6, v6.5.9, v6.5.8, v6.5.7, v6.5.6, v6.5.5, v6.5.4, v6.5.3, v6.5.2, v6.1.51, v6.5.1, v6.1.50, v6.5, v6.1.49, v6.1.48 |
|
#
ec84b2a4 |
| 21-Aug-2023 |
Matt Roper <matthew.d.roper@intel.com> |
drm/i915: Replace several IS_METEORLAKE with proper IP version checks
[ Upstream commit 14128d64090fa88445376cb8ccf91c50c08bd410 ]
Many of the IS_METEORLAKE conditions throughout the driver are sup
drm/i915: Replace several IS_METEORLAKE with proper IP version checks
[ Upstream commit 14128d64090fa88445376cb8ccf91c50c08bd410 ]
Many of the IS_METEORLAKE conditions throughout the driver are supposed to be checks for Xe_LPG and/or Xe_LPM+ IP, not for the MTL platform specifically. Update those checks to ensure that the code will still operate properly if/when these IP versions show up on future platforms.
v2: - Update two more conditions (one for pg_enable, one for MTL HuC compatibility). v3: - Don't change GuC/HuC compatibility check, which sounds like it truly is specific to the MTL platform. (Gustavo) - Drop a non-lineage workaround number for the OA timestamp frequency workaround. (Gustavo)
Cc: Gustavo Sousa <gustavo.sousa@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230821180619.650007-20-matthew.d.roper@intel.com Stable-dep-of: 186bce682772 ("drm/i915/mtl: Update workaround 14018575942") Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
#
b3749611 |
| 21-Aug-2023 |
Matt Roper <matthew.d.roper@intel.com> |
drm/i915: Eliminate IS_MTL_GRAPHICS_STEP
[ Upstream commit 5a213086a025349361b5cf75c8fd4591d96a7a99 ]
Several workarounds are guarded by IS_MTL_GRAPHICS_STEP. However none of these workarounds are
drm/i915: Eliminate IS_MTL_GRAPHICS_STEP
[ Upstream commit 5a213086a025349361b5cf75c8fd4591d96a7a99 ]
Several workarounds are guarded by IS_MTL_GRAPHICS_STEP. However none of these workarounds are actually tied to MTL as a platform; they only relate to the Xe_LPG graphics IP, regardless of what platform it appears in. At the moment MTL is the only platform that uses Xe_LPG with IP versions 12.70 and 12.71, but we can't count on this being true in the future. Switch these to use a new IS_GFX_GT_IP_STEP() macro instead that is purely based on IP version. IS_GFX_GT_IP_STEP() is also GT-based rather than device-based, which will help prevent mistakes where we accidentally try to apply Xe_LPG graphics workarounds to the Xe_LPM+ media GT and vice-versa.
v2: - Switch to a more generic and shorter IS_GT_IP_STEP macro that can be used for both graphics and media IP (and any other kind of GTs that show up in the future). v3: - Switch back to long-form IS_GFX_GT_IP_STEP macro. (Jani) - Move macro to intel_gt.h. (Andi) v4: - Build IS_GFX_GT_IP_STEP on top of IS_GFX_GT_IP_RANGE and IS_GRAPHICS_STEP building blocks and name the parameters from/until rather than begin/fixed. (Jani) - Fix usage examples in comment. v5: - Tweak comment on macro. (Gustavo)
Cc: Gustavo Sousa <gustavo.sousa@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Cc: Andi Shyti <andi.shyti@linux.intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230821180619.650007-15-matthew.d.roper@intel.com Stable-dep-of: 186bce682772 ("drm/i915/mtl: Update workaround 14018575942") Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
#
67f7fba8 |
| 21-Aug-2023 |
Matt Roper <matthew.d.roper@intel.com> |
drm/i915: Consolidate condition for Wa_22011802037
[ Upstream commit 28c46feec7f8760683ef08f12746630a3598173e ]
The workaround bounds for Wa_22011802037 are somewhat complex and are replicated in s
drm/i915: Consolidate condition for Wa_22011802037
[ Upstream commit 28c46feec7f8760683ef08f12746630a3598173e ]
The workaround bounds for Wa_22011802037 are somewhat complex and are replicated in several places throughout the code. Pull the condition out to a helper function to prevent mistakes if this condition needs to change again in the future.
Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230821180619.650007-12-matthew.d.roper@intel.com Stable-dep-of: 186bce682772 ("drm/i915/mtl: Update workaround 14018575942") Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
#
cd378c37 |
| 01-Dec-2023 |
Tvrtko Ursulin <tvrtko.ursulin@intel.com> |
drm/i915: Use internal class when counting engine resets
[ Upstream commit 1f721a93a528268fa97875cff515d1fcb69f4f44 ]
Commit 503579448db9 ("drm/i915/gsc: Mark internal GSC engine with reserved uabi
drm/i915: Use internal class when counting engine resets
[ Upstream commit 1f721a93a528268fa97875cff515d1fcb69f4f44 ]
Commit 503579448db9 ("drm/i915/gsc: Mark internal GSC engine with reserved uabi class") made the GSC0 engine not have a valid uabi class and so broke the engine reset counting, which in turn was made class based in cb823ed9915b ("drm/i915/gt: Use intel_gt as the primary object for handling resets").
Despite the title and commit text of the latter is not mentioning it (and has left the storage array incorrectly sized), tracking by class, despite it adding aliasing in hypthotetical multi-tile systems, is handy for virtual engines which for instance do not have a valid engine->id.
Therefore we keep that but just change it to use the internal class which is always valid. We also add a helper to increment the count, which aligns with the existing getter.
What was broken without this fix were out of bounds reads every time a reset would happen on the GSC0 engine, or during selftests when storing and cross-checking the counts in igt_live_test_begin and igt_live_test_end.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Fixes: 503579448db9 ("drm/i915/gsc: Mark internal GSC engine with reserved uabi class") [tursulin: fixed Fixes tag] Reported-by: Alan Previn Teres Alexis <alan.previn.teres.alexis@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231201122109.729006-2-tvrtko.ursulin@linux.intel.com (cherry picked from commit cf9cb028ac56696ff879af1154c4b2f0b12701fd) Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
Revision tags: v6.1.46, v6.1.45, v6.1.44, v6.1.43, v6.1.42, v6.1.41, v6.1.40, v6.1.39, v6.1.38 |
|
#
ed6dd32c |
| 05-Jul-2023 |
Tvrtko Ursulin <tvrtko.ursulin@intel.com> |
drm/i915: Remove some dead "code"
Commit 2caffbf11762 ("drm/i915: Revoke mmaps and prevent access to fence registers across reset") removed the temporary implementation of a reset under stop machine
drm/i915: Remove some dead "code"
Commit 2caffbf11762 ("drm/i915: Revoke mmaps and prevent access to fence registers across reset") removed the temporary implementation of a reset under stop machine but forgot to remove this one commented out define.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230705095518.3690951-1-tvrtko.ursulin@linux.intel.com
show more ...
|
Revision tags: v6.1.37, v6.1.36, v6.4, v6.1.35, v6.1.34, v6.1.33 |
|
#
848a4e5c |
| 08-Jun-2023 |
Luca Coelho <luciano.coelho@intel.com> |
drm/i915: add a dedicated workqueue inside drm_i915_private
In order to avoid flush_scheduled_work() usage, add a dedicated workqueue in the drm_i915_private structure. In this way, we don't need t
drm/i915: add a dedicated workqueue inside drm_i915_private
In order to avoid flush_scheduled_work() usage, add a dedicated workqueue in the drm_i915_private structure. In this way, we don't need to use the system queue anymore.
This change is mostly mechanical and based on Tetsuo's original patch[1].
v6 by Jani: - Also create unordered_wq for mock device
Link: https://patchwork.freedesktop.org/series/114608/ [1] Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/c816ebe17ef08d363981942a096a586a7658a65e.1686231190.git.jani.nikula@intel.com
show more ...
|
Revision tags: v6.1.32, v6.1.31, v6.1.30, v6.1.29, v6.1.28, v6.1.27, v6.1.26, v6.3, v6.1.25 |
|
#
476f62b8 |
| 19-Apr-2023 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915: use explicit includes for i915_reg.h and i915_irq.h
A lot of places include i915_reg.h implicitly via i915_irq.h, which gets included implicitly via intel_display_trace.h. Remove the inclu
drm/i915: use explicit includes for i915_reg.h and i915_irq.h
A lot of places include i915_reg.h implicitly via i915_irq.h, which gets included implicitly via intel_display_trace.h. Remove the includes from the headers, and include i915_reg.h and i915_irq.h explicitly where needed.
Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230419094243.366821-1-jani.nikula@intel.com
show more ...
|
#
59c6106e |
| 14-Apr-2023 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915/display: add intel_display_reset.[ch]
Split out the display reset functionality to a separate file to declutter intel_display.c. Rename the functions accordingly. The minor downside is havi
drm/i915/display: add intel_display_reset.[ch]
Split out the display reset functionality to a separate file to declutter intel_display.c. Rename the functions accordingly. The minor downside is having to expose __intel_display_resume().
Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/5e98e2fc5f0c09490e02d22250c8201342852288.1681465222.git.jani.nikula@intel.com
show more ...
|
Revision tags: v6.1.24, v6.1.23, v6.1.22 |
|
#
b7d70b8b |
| 23-Mar-2023 |
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> |
drm/i915/gsc: implement wa 14015076503
The WA states that we need to alert the GSC FW before doing a GSC engine reset and then wait for 200ms. The GuC owns engine reset, so on the i915 side we only
drm/i915/gsc: implement wa 14015076503
The WA states that we need to alert the GSC FW before doing a GSC engine reset and then wait for 200ms. The GuC owns engine reset, so on the i915 side we only need to apply this for full GT reset.
Given that we do full GT resets in the resume paths to cleanup the HW state and that a long wait in those scenarios would not be acceptable, a faster path has been introduced where, if the GSC is idle, we try first to individually reset the GuC and all engines except the GSC and only fall back to full reset if that fails.
Note: according to the WA specs, if the GSC is idle it should be possible to only wait for the uC wakeup time (~15ms) instead of the whole 200ms. However, the GSC FW team have mentioned that the wakeup time can change based on other things going on in the HW and pcode, so a good security margin would be required. Given that when the GSC is idle we already skip the wait & reset entirely and that this reduced wait would still likely be too long to use in resume paths, it's not worth adding support for this reduced wait.
v2: add comment to explain why it is safe to skip the GSC reset (John)
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: John Harrison <john.c.harrison@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: John Harrison <John.C.Harrison@Intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230323231857.2194435-2-daniele.ceraolospurio@intel.com
show more ...
|
#
625af472 |
| 23-Mar-2023 |
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> |
drm/i915: limit double GT reset to pre-MTL
Commit 3db9d590557d ("drm/i915/gt: Reset twice") modified the code to always hit the GDRST register twice when doing a reset, with the reported aim to fix
drm/i915: limit double GT reset to pre-MTL
Commit 3db9d590557d ("drm/i915/gt: Reset twice") modified the code to always hit the GDRST register twice when doing a reset, with the reported aim to fix invalid post-reset engine state on some platforms (Jasperlake being the only one actually mentioned).
This is a problem on MTL, due to the fact that we have to apply a time consuming WA (coming in the next patch) every time we hit the GDRST register in a way that can include the GSC engine. Even post MTL, the expectation is that we'll have some work to do before and after hitting the GDRST if the GSC is involved.
Since the issue requiring the double reset seems to be limited to older platforms, instead of trying to handle the double-reset on MTL and future platforms it is just easier to turn it off. The default on MTL is also for GuC to own engine reset, with i915 only covering full-GT reset.
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Andi Shyti <andi.shyti@linux.intel.com> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Cc: John Harrison <John.C.Harrison@Intel.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230323231857.2194435-1-daniele.ceraolospurio@intel.com
show more ...
|
Revision tags: v6.1.21, v6.1.20, v6.1.19, v6.1.18, v6.1.17, v6.1.16, v6.1.15, v6.1.14, v6.1.13, v6.2, v6.1.12, v6.1.11, v6.1.10, v6.1.9, v6.1.8, v6.1.7, v6.1.6, v6.1.5, v6.0.19, v6.0.18, v6.1.4, v6.1.3, v6.0.17, v6.1.2, v6.0.16, v6.1.1, v6.0.15, v6.0.14, v6.0.13 |
|
#
d3de5616 |
| 12-Dec-2022 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915/gt: Reset twice
After applying an engine reset, on some platforms like Jasperlake, we occasionally detect that the engine state is not cleared until shortly after the resume. As we try to r
drm/i915/gt: Reset twice
After applying an engine reset, on some platforms like Jasperlake, we occasionally detect that the engine state is not cleared until shortly after the resume. As we try to resume the engine with volatile internal state, the first request fails with a spurious CS event (it looks like it reports a lite-restore to the hung context, instead of the expected idle->active context switch).
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: stable@vger.kernel.org Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Reviewed-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221212161338.1007659-1-andi.shyti@linux.intel.com (cherry picked from commit 3db9d590557da3aa2c952f2fecd3e9b703dad790) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
show more ...
|
#
3db9d590 |
| 12-Dec-2022 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915/gt: Reset twice
After applying an engine reset, on some platforms like Jasperlake, we occasionally detect that the engine state is not cleared until shortly after the resume. As we try to r
drm/i915/gt: Reset twice
After applying an engine reset, on some platforms like Jasperlake, we occasionally detect that the engine state is not cleared until shortly after the resume. As we try to resume the engine with volatile internal state, the first request fails with a spurious CS event (it looks like it reports a lite-restore to the hung context, instead of the expected idle->active context switch).
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: stable@vger.kernel.org Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Reviewed-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221212161338.1007659-1-andi.shyti@linux.intel.com
show more ...
|
Revision tags: v6.1, v6.0.12, v6.0.11, v6.0.10, v5.15.80 |
|
#
4050e6f2 |
| 23-Nov-2022 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915/gt: remove some limited use register access wrappers
Remove rmw_set(), rmw_clear(), clear_register(), rmw_set_fw(), and rmw_clear_fw(). They're just one too many levels of abstraction for r
drm/i915/gt: remove some limited use register access wrappers
Remove rmw_set(), rmw_clear(), clear_register(), rmw_set_fw(), and rmw_clear_fw(). They're just one too many levels of abstraction for register access, for very specific purposes.
clear_register() seems like a micro-optimization bypassing the write when the register is already clear, but that trick has ceased to work since commit 06b975d58fd6 ("drm/i915: make intel_uncore_rmw() write unconditionally"). Just clear the register in the most obvious way.
Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221123164916.4128733-1-jani.nikula@intel.com
show more ...
|
Revision tags: v6.0.9, v5.15.79, v6.0.8, v5.15.78, v6.0.7, v5.15.77 |
|
#
178b8a36 |
| 02-Nov-2022 |
John Harrison <John.C.Harrison@Intel.com> |
drm/i915/guc: Don't deadlock busyness stats vs reset
The engine busyness stats has a worker function to do things like 64bit extend the 32bit hardware counters. The GuC's reset prepare function flus
drm/i915/guc: Don't deadlock busyness stats vs reset
The engine busyness stats has a worker function to do things like 64bit extend the 32bit hardware counters. The GuC's reset prepare function flushes out this worker function to ensure no corruption happens during the reset. Unforunately, the worker function has an infinite wait for active resets to finish before doing its work. Thus a deadlock would occur if the worker function had actually started just as the reset starts.
The function being used to lock the reset-in-progress mutex is called intel_gt_reset_trylock(). However, as noted it does not follow standard 'trylock' conventions and exit if already locked. So rename the current _trylock function to intel_gt_reset_lock_interruptible(), which is the behaviour it actually provides. In addition, add a new implementation of _trylock and call that from the busyness stats worker instead.
v2: Rename existing trylock to interruptible rather than trying to preserve the existing (confusing) naming scheme (review comments from Tvrtko).
Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Reviewed-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221102192109.2492625-3-John.C.Harrison@Intel.com
show more ...
|
Revision tags: v5.15.76, v6.0.6, v6.0.5, v5.15.75, v6.0.4, v6.0.3, v6.0.2, v5.15.74, v5.15.73, v6.0.1, v5.15.72, v6.0, v5.15.71, v5.15.70, v5.15.69 |
|
#
d24e7855 |
| 16-Sep-2022 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915/gt: Bump the reset-failure timeout to 60s
If attempting to perform a GT reset takes long than 5 seconds (including resetting the display for gen3/4), then we declare all hope lost and disca
drm/i915/gt: Bump the reset-failure timeout to 60s
If attempting to perform a GT reset takes long than 5 seconds (including resetting the display for gen3/4), then we declare all hope lost and discard all user work and wedge the device to prevent further misbehaviour. 5 seconds is too short a time for such drastic action, as we may be stuck on other timeouts and watchdogs. If we allow a little bit longer before hitting the big red button, we should at the very least capture other hung task indicators pointing towards the reason why the reset was hanging; and allow more marginal cases the extra headroom to complete the reset without further collateral damage.
Bug: https://gitlab.freedesktop.org/drm/intel/-/issues/6448 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220916204823.1897089-1-ashutosh.dixit@intel.com
show more ...
|
Revision tags: v5.15.68, v5.15.67, v5.15.66, v5.15.65 |
|
#
3bb6a442 |
| 01-Sep-2022 |
Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com> |
drm/i915: Rename ggtt_view as gtt_view
So far, different views (normal, partial, rotated and remapped) into the same object are only supported for GGTT mappings. But with the upcoming VM_BIND featur
drm/i915: Rename ggtt_view as gtt_view
So far, different views (normal, partial, rotated and remapped) into the same object are only supported for GGTT mappings. But with the upcoming VM_BIND feature, PPGTT will also use the partial view mapping. Hence rename ggtt_view to more generic gtt_view.
Signed-off-by: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com> Acked-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220901183854.3446-1-niranjana.vishwanathapura@intel.com
show more ...
|
Revision tags: v5.15.64, v5.15.63, v5.15.62, v5.15.61, v5.15.60, v5.15.59, v5.19, v5.15.58, v5.15.57, v5.15.56, v5.15.55, v5.15.54, v5.15.53, v5.15.52 |
|
#
1dab4561 |
| 29-Jun-2022 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915/reset: Handle reset timeouts under unrelated kernel hangs
When resuming after hibernate sometimes we see hangs in unrelated kernel subsystems. These hangs often result in the following i915
drm/i915/reset: Handle reset timeouts under unrelated kernel hangs
When resuming after hibernate sometimes we see hangs in unrelated kernel subsystems. These hangs often result in the following i915 trace:
i915 0000:00:02.0: [drm] *ERROR* \ intel_gt_reset_global timed out, cancelling all in-flight rendering
implying our reset task has been starved by the hanging kernel subsystem, causing us to inappropiately declare the system as wedged beyond recovery.
The trace would be caused by our synchronize_srcu_expedited() taking more than the allowed 5s due to the unrelated kernel hang. But we neither need to perform that synchronisation inside the reset watchdog, nor do we need such a short timeout before declaring the device as unrecoverable.
v2: Restore watchdog timeout to the previous 5 seconds (Ashutosh)
Bug: https://gitlab.freedesktop.org/drm/intel/-/issues/3575 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Ashutosh Dixit <ashutosh.dixit@intel.com> Reviewed-by: Ashutosh Dixit <ashutosh.dixit@intel.com> Signed-off-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220630043959.5708-1-ashutosh.dixit@intel.com
show more ...
|
#
b24dcf1d |
| 12-Jul-2022 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915/gt: Serialize GRDOM access between multiple engine resets
Don't allow two engines to be reset in parallel, as they would both try to select a reset bit (and send requests to common register
drm/i915/gt: Serialize GRDOM access between multiple engine resets
Don't allow two engines to be reset in parallel, as they would both try to select a reset bit (and send requests to common registers) and wait on that register, at the same time. Serialize control of the reset requests/acks using the uncore->lock, which will also ensure that no other GT state changes at the same time as the actual reset.
Cc: stable@vger.kernel.org # v4.4 and upper Reported-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: Andi Shyti <andi.shyti@intel.com> Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com> Acked-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/e0a2d894e77aed7c2e36b0d1abdc7dbac3011729.1657639152.git.mchehab@kernel.org (cherry picked from commit 336561a914fc0c6f1218228718f633b31b7af1c3) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
show more ...
|
#
336561a9 |
| 12-Jul-2022 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915/gt: Serialize GRDOM access between multiple engine resets
Don't allow two engines to be reset in parallel, as they would both try to select a reset bit (and send requests to common register
drm/i915/gt: Serialize GRDOM access between multiple engine resets
Don't allow two engines to be reset in parallel, as they would both try to select a reset bit (and send requests to common registers) and wait on that register, at the same time. Serialize control of the reset requests/acks using the uncore->lock, which will also ensure that no other GT state changes at the same time as the actual reset.
Cc: stable@vger.kernel.org # v4.4 and upper Reported-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: Andi Shyti <andi.shyti@intel.com> Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com> Acked-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/e0a2d894e77aed7c2e36b0d1abdc7dbac3011729.1657639152.git.mchehab@kernel.org
show more ...
|
Revision tags: v5.15.51, v5.15.50, v5.15.49, v5.15.48, v5.15.47, v5.15.46, v5.15.45, v5.15.44, v5.15.43, v5.15.42, v5.18 |
|
#
b409db08 |
| 19-May-2022 |
Tvrtko Ursulin <tvrtko.ursulin@intel.com> |
Revert "drm/i915: Drop has_reset_engine from device info"
This reverts commit 922abe4d19bd21b38298f3902674774b92a49293.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Acked-by: Joonas Lah
Revert "drm/i915: Drop has_reset_engine from device info"
This reverts commit 922abe4d19bd21b38298f3902674774b92a49293.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Acked-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220519090802.1294691-6-tvrtko.ursulin@linux.intel.com
show more ...
|
Revision tags: v5.15.41, v5.15.40, v5.15.39, v5.15.38, v5.15.37, v5.15.36 |
|
#
89e96d82 |
| 25-Apr-2022 |
Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> |
i915/guc/reset: Make __guc_reset_context aware of guilty engines
There are 2 ways an engine can get reset in i915 and the method of reset affects how KMD labels a context as guilty/innocent.
(1) Gu
i915/guc/reset: Make __guc_reset_context aware of guilty engines
There are 2 ways an engine can get reset in i915 and the method of reset affects how KMD labels a context as guilty/innocent.
(1) GuC initiated engine-reset: GuC resets a hung engine and notifies KMD. The context that hung on the engine is marked guilty and all other contexts are innocent. The innocent contexts are resubmitted.
(2) GT based reset: When an engine heartbeat fails to tick, KMD initiates a gt/chip reset. All active contexts are marked as guilty and discarded.
In order to correctly mark the contexts as guilty/innocent, pass a mask of engines that were reset to __guc_reset_context.
Fixes: eb5e7da736f3 ("drm/i915/guc: Reset implementation for new GuC interface") Signed-off-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Reviewed-by: Alan Previn <alan.previn.teres.alexis@intel.com> Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220426003045.3929439-1-umesh.nerlige.ramappa@intel.com (cherry picked from commit 303760aa914b7f5ac9602dbb4b471a2ad52eeb3e) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
show more ...
|
#
303760aa |
| 25-Apr-2022 |
Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> |
i915/guc/reset: Make __guc_reset_context aware of guilty engines
There are 2 ways an engine can get reset in i915 and the method of reset affects how KMD labels a context as guilty/innocent.
(1) Gu
i915/guc/reset: Make __guc_reset_context aware of guilty engines
There are 2 ways an engine can get reset in i915 and the method of reset affects how KMD labels a context as guilty/innocent.
(1) GuC initiated engine-reset: GuC resets a hung engine and notifies KMD. The context that hung on the engine is marked guilty and all other contexts are innocent. The innocent contexts are resubmitted.
(2) GT based reset: When an engine heartbeat fails to tick, KMD initiates a gt/chip reset. All active contexts are marked as guilty and discarded.
In order to correctly mark the contexts as guilty/innocent, pass a mask of engines that were reset to __guc_reset_context.
Fixes: eb5e7da736f3 ("drm/i915/guc: Reset implementation for new GuC interface") Signed-off-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Reviewed-by: Alan Previn <alan.previn.teres.alexis@intel.com> Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220426003045.3929439-1-umesh.nerlige.ramappa@intel.com
show more ...
|
#
922abe4d |
| 05-May-2022 |
José Roberto de Souza <jose.souza@intel.com> |
drm/i915: Drop has_reset_engine from device info
No need to have this parameter in intel_device_info struct as all platforms with graphics version 7 or newer can reset engines.
As a side effect of
drm/i915: Drop has_reset_engine from device info
No need to have this parameter in intel_device_info struct as all platforms with graphics version 7 or newer can reset engines.
As a side effect of the of removal this flag, it will not be printed in dmesg during driver load anymore and developers will have to rely on to check the macro and compare with platform being used and IP versions of it.
Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220505193524.276400-3-jose.souza@intel.com
show more ...
|
Revision tags: v5.15.35 |
|
#
dac38381 |
| 15-Apr-2022 |
Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> |
drm/i915/guc: Enable Wa_22011802037 for gen12 GuC based platforms
Initiating a reset when the command streamer is not idle or in the middle of executing an MI_FORCE_WAKE can result in a hang. Multip
drm/i915/guc: Enable Wa_22011802037 for gen12 GuC based platforms
Initiating a reset when the command streamer is not idle or in the middle of executing an MI_FORCE_WAKE can result in a hang. Multiple command streamers can be part of a single reset domain, so resetting one would mean resetting all command streamers in that domain.
To workaround this, before initiating a reset, ensure that all command streamers within that reset domain are either IDLE or are not executing a MI_FORCE_WAKE.
Enable GuC PRE_PARSER WA bit so that GuC follows the WA sequence when initiating engine-resets.
For gt-resets, ensure that i915 applies the WA sequence.
Opens to address in future patches: - The part of the WA to wait for pending forcewakes is also applicable to execlists backend. - The WA also needs to be applied for gen11
Signed-off-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220415224025.3693037-3-umesh.nerlige.ramappa@intel.com
show more ...
|
Revision tags: v5.15.34, v5.15.33, v5.15.32, v5.15.31 |
|
#
a6f0f9cf |
| 21-Mar-2022 |
Alan Previn <alan.previn.teres.alexis@intel.com> |
drm/i915/guc: Plumb GuC-capture into gpu_coredump
Add a flags parameter through all of the coredump creation functions. Add a bitmask flag to indicate if the top level gpu_coredump event is triggere
drm/i915/guc: Plumb GuC-capture into gpu_coredump
Add a flags parameter through all of the coredump creation functions. Add a bitmask flag to indicate if the top level gpu_coredump event is triggered in response to a GuC context reset notification.
Using that flag, ensure all coredump functions that read or print mmio-register values related to work submission or command-streamer engines are skipped and replaced with a calls guc-capture module equivalent functions to retrieve or print the register dump.
While here, split out display related register reading and printing into its own function that is called agnostic to whether GuC had triggered the reset.
For now, introduce an empty printing function that can filled in on a subsequent patch just to handle formatting.
Signed-off-by: Alan Previn <alan.previn.teres.alexis@intel.com> Reviewed-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220321164527.2500062-13-alan.previn.teres.alexis@intel.com
show more ...
|