- 17 Feb, 2023 3 commits
-
-
John Harrison authored
Direction from hardware is that stolen memory should never be used for ring buffer allocations on platforms with LLC. There are too many caching pitfalls due to the way stolen memory accesses are routed. So it is safest to just not use it. Signed-off-by:
John Harrison <John.C.Harrison@Intel.com> Fixes: c58b735f ("drm/i915: Allocate rings from stolen") Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Cc: intel-gfx@lists.freedesktop.org Cc: <stable@vger.kernel.org> # v4.9+ Tested-by:
Jouni Högander <jouni.hogander@intel.com> Reviewed-by:
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230216011101.1909009-2-John.C.Harrison@Intel.com
-
Tvrtko Ursulin authored
As the logic for selecting the register and corresponsing values grew, the code become a bit unsightly. Consolidate by storing the required values at engine init time in the engine itself, and by doing so minimise the amount of invariant platform and engine checks during each and every TLB invalidation. v2: * Fail engine probe if TLB invlidations registers are unknown. v3: * Rebase. v4: * Fix handling of GEN8_M2TCR. (Andrzej) v5: * Tidy checkpatch warnings. Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Andrzej Hajda <andrzej.hajda@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com> # v1 Reviewed-by:
Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230216092123.159085-1-tvrtko.ursulin@linux.intel.com
-
Thomas Weißschuh authored
Since commit ee6d3dd4 ("driver core: make kobj_type constant.") the driver core allows the usage of const struct kobj_type. Take advantage of this to constify the structure definitions to prevent modification at runtime. Signed-off-by:
Thomas Weißschuh <linux@weissschuh.net> Reviewed-by:
Jani Nikula <jani.nikula@intel.com> Signed-off-by:
-
- 15 Feb, 2023 1 commit
-
-
Matt Roper authored
MCR range tables use the final MMIO offset of a register (including the 0x380000 GSI offset when applicable). Since the i915_mcr_reg_t passed as a parameter during steering lookup does not include the GSI offset, we need to add it back in for GSI registers before searching the tables. Fixes: a7ec65fc ("drm/i915/xelpmp: Add multicast steering for media GT") Signed-off-by:
Radhakrishna Sripada <radhakrishna.sripada@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230214001906.1477370-1-matthew.d.roper@intel.com
-
- 10 Feb, 2023 1 commit
-
-
Matt Roper authored
Although registers in the L3 bank/node configuration ranges are marked as having "DEV" reset characteristics in the bspec, this appears to be a hold-over from pre-Xe_HP platforms. In reality, these registers maintain their values across engine resets, meaning that workarounds and tuning settings targeting them should be placed on the GT workaround list rather than an engine workaround list. Note that an extra clue here is that these registers moved from the RENDER forcewake domain to the GT forcewake domain in Xe_HP; generally RCS/CCS engine resets should not lead to the reset of a register that lives outside the RENDER domain. Re-applying these registers on engine resets wouldn't actually hurt anything, but is unnecessary and just makes it more confusing to anyone trying to decipher how these registers really work. v2: - Also move DG2's Wa_14010648519 to the GT list. (Gustavo) Cc: Gustavo Sousa <gustavo.sousa@intel.com> Signed-off-by:
Gustavo Sousa <gustavo.sousa@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230209232228.859317-1-matthew.d.roper@intel.com
-
- 09 Feb, 2023 8 commits
-
-
John Harrison authored
Update a bunch more debug prints to use the new GT based scheme. Signed-off-by:
Michal Wajdeczko <michal.wajdeczko@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230207050717.1833718-7-John.C.Harrison@Intel.com
-
John Harrison authored
Update a bunch more debug prints to use the new GT based scheme. v2: Also change prints to use %pe for error values (MichalW). Signed-off-by:
-
John Harrison authored
Update a bunch more debug prints to use the new GT based scheme. v2: Also change prints to use %pe for error values (MichalW). Fix a context leak on error due to a -- being too early. Use the correct header file for the debug macros. Signed-off-by:
-
John Harrison authored
Update a bunch more debug prints to use the new GT based scheme. v2: Upgrade the no node found message to a warning on the grounds of it being quite important if the error capture can't find any register state information. Signed-off-by:
Alan Previn <alan.previn.teres.alexis@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230207050717.1833718-4-John.C.Harrison@Intel.com
-
John Harrison authored
Update a bunch more debug prints to use the new GT based scheme. v2: Also change prints to use %pe for error values (MichalW). Signed-off-by:
-
John Harrison authored
Update a bunch more debug prints to use the new GT based scheme. v2: Also change prints to use %pe for error values (MichalW). Signed-off-by:
-
Lucas De Marchi authored
INF_UNIT_LEVEL_CLKGATE is not replicated, but since it's not actually used it can just be removed. Signed-off-by:
Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by:
-
Lucas De Marchi authored
Register 0x9424 is not replicated on any platform, so it shouldn't be declared with REG_MCR(). Declaring it with _MMIO() is basically duplicate of the GEN7 version, so just remove the GEN8 and change all the callers to use the right functions. Old versions of the gen8 bspec page used to contain a table with MCR registers, apparently implying 0x9400 - 0x94ff registers were replicated. However that table went away and there is no information related to the ranges for gen8 anymore. Moreover the current behavior of the driver wouldn't do anything special for 0x9424 since there is no equivalent table in intel_gt_mcr.c: the driver would just fallback to intel_uncore_{read,write}(). Therefore, do not care about the possible special case for gen8 and just use the register as non-MCR for all the platforms. One place doing read + write is also converted to intel_uncore_rmw(). v2: Reword commit message adding the justification wrt gen8 Fixes: a9e69428 ("drm/i915: Define MCR registers explicitly") Cc: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Gustavo Sousa <gustavo.sousa@intel.com> Cc: Matt Atwood <matthew.s.atwood@intel.com> Cc: Ashutosh Dixit <ashutosh.dixit@intel.com> Signed-off-by:
-
- 08 Feb, 2023 4 commits
-
-
Matt Roper authored
The UNSLICE_UNIT_LEVEL_CLKGATE register programmed by this workaround has 'BUS' style reset, indicating that it does not lose its value on engine resets. Furthermore, this register is part of the GT forcewake domain rather than the RENDER domain, so it should not be impacted by RCS engine resets. As such, we should implement this on the GT workaround list rather than an engine list. Bspec: 19219 Fixes: 3551ff92 ("drm/i915/gen11: Moving WAs to rcs_engine_wa_init()") Signed-off-by:
-
Matt Roper authored
XEHPC_LNCFMISCCFGREG0 and XEHPC_L3SCRUB are both in MCR register ranges on PVC (with HALFBSLICE and L3BANK replication respectively), so they should be explicitly declared as MCR registers and use MCR-aware workaround handlers. The workarounds/tuning settings should still be applied properly on PVC even without the MCR annotation, but readback verification on CONFIG_DRM_I915_DEBUG_GEM builds could potentitally give false positive "workaround lost on load" warnings on parts fused such that a unicast read targets a terminated register instance. Fixes: a9e69428 ("drm/i915: Define MCR registers explicitly") Signed-off-by:
-
Jani Nikula authored
__le64 and friends should go through the cpu_to_* and *_to_cpu accessors: drivers/gpu/drm/i915/pxp/intel_pxp_huc.c:41:35: warning: incorrect type in assignment (different base types) drivers/gpu/drm/i915/pxp/intel_pxp_huc.c:41:35: expected restricted __le64 [assigned] [usertype] huc_base_address drivers/gpu/drm/i915/pxp/intel_pxp_huc.c:41:35: got unsigned long long [assigned] [usertype] huc_phys_addr Cc: Tomas Winkler <tomas.winkler@intel.com> Cc: Alan Previn <alan.previn.teres.alexis@intel.com> Signed-off-by:
Tomas Winkler <tomas.winkler@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230207124026.2105442-4-jani.nikula@intel.com
-
Jani Nikula authored
Annotate intel_gt_mcr_lock() and intel_gt_mcr_unlock() to fix sparse warnings: drivers/gpu/drm/i915/gt/intel_gt_mcr.c:397:9: warning: context imbalance in 'intel_gt_mcr_lock' - wrong count at exit drivers/gpu/drm/i915/gt/intel_gt_mcr.c:412:6: warning: context imbalance in 'intel_gt_mcr_unlock' - unexpected unlock Cc: Matt Roper <matthew.d.roper@intel.com> Signed-off-by:
-
- 07 Feb, 2023 2 commits
-
-
Aravind Iddamsetty authored
During module load the punit might still be busy with its booting routines. During this time we try to communicate with it but we fail because we don't receive any feedback from it and we return immediately with a -EINVAL fatal error. At this point the driver load is "dramatically" aborted. The following error message notifies us about it. i915 0000:4d:00.0: drm_WARN_ON_ONCE(timeout_base_ms > 3) It would be enough to wait a little in order to give the punit the chance to come up bright and shiny, ready to interact with the driver. Wait up 10 seconds for the punit to settle and complete any outstanding transactions upon module load. If it still fails try again with a longer timeout, 180s, 3 minutes. If it still fails then return -EPROBE_DEFER, in order to give the punit a second chance. Even if these timers might look long, we should consider that the punit, depending on the platforms, might need long times to complete its routines. Besides we want to try anything possible to move forward before deciding to abort the driver's load. The issue has been reported in: https://gitlab.freedesktop.org/drm/intel/-/issues/7814 The changes in this patch are valid only and uniquely during boot. The common transactions with the punit during the driver's normal operation are not affected. Signed-off-by:
Aravind Iddamsetty <aravind.iddamsetty@intel.com> Co-developed-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Andi Shyti <andi.shyti@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by:
Andrzej Hajda <andrzej.hajda@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230206183236.109908-1-andi.shyti@linux.intel.com
-
Michal Wajdeczko authored
Like we did it for GuC, introduce some helper print macros for HuC to have unified format of messages that also include GT#. While around improve some messages and use %pe if possible. v2: update GSC/PXP timeout message Signed-off-by:
-
- 06 Feb, 2023 3 commits
-
-
Bagas Sanjaya authored
Stephen Rothwell reported htmldocs warnings: Documentation/gpu/i915:64: drivers/gpu/drm/i915/gt/intel_workarounds.c:32: WARNING: Inline emphasis start-string without end-string. Documentation/gpu/i915:64: drivers/gpu/drm/i915/gt/intel_workarounds.c:57: WARNING: Inline emphasis start-string without end-string. Documentation/gpu/i915:64: drivers/gpu/drm/i915/gt/intel_workarounds.c:66: WARNING: Inline emphasis start-string without end-string. Escape wildcards in *_ctx_workarounds_init(), *_gt_workarounds_init(), and *_whitelist_build() to fix above warnings. Link: https://lore.kernel.org/linux-next/20230203134622.0b6315b9@canb.auug.org.au/ Fixes: 0c3064cf ("drm/i915/doc: Document where to implement register workarounds") Reported-by:
Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by:
Bagas Sanjaya <bagasdotme@gmail.com> Reviewed-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
-
Aravind Iddamsetty authored
Obj flags for shmem objects is not being set correctly. Fixes in setting BO_ALLOC_USER flag which applies to shmem objs as well. v2: Add fixes tag (Tvrtko, Matt A) Fixes: 13d29c82 ("drm/i915/ehl: unconditionally flush the pages on acquire") Cc: <stable@vger.kernel.org> # v5.15+ Cc: Matthew Auld <matthew.auld@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by:
Matthew Auld <matthew.auld@intel.com> Signed-off-by:
-
Rob Clark authored
Because eb_composite_fence_create() drops the fence_array reference after creation of the sync_file, only the sync_file holds a ref to the fence. But fd_install() makes that reference visable to userspace, so it must be the last thing we do with the fence. Signed-off-by:
Rob Clark <robdclark@chromium.org> Fixes: 00dae4d3 ("drm/i915: Implement SINGLE_TIMELINE with a syncobj (v4)") Cc: <stable@vger.kernel.org> # v5.15+ [tursulin: Added stable tag.] Reviewed-by:
-
- 03 Feb, 2023 1 commit
-
-
Nirmoy Das authored
DSM granularity is 1MB so make sure we stick to that. The address set by firmware in GEN12_DSMBASE in driver initialization doesn't mean "anything above that and until end of lmem is part of DSM". In fact, there may be a few KB that is not part of DSM on the end of lmem. How large is that space is platform-dependent, but since it's always less than the DSM granularity, it can be simplified by simply aligning the size down. v2: replace "1 * SZ_1M" with SZ_1M (Andrzej). v3: reword commit message to explain why the round down is needed (Lucas) Cc: Matthew Auld <matthew.auld@intel.com> Suggested-by:Nirmoy Das <nirmoy.das@intel.com> Reviewed-by:
-
- 02 Feb, 2023 2 commits
-
-
Michal Wajdeczko authored
Just recently we switched over to new GuC oriented log macros but in the meantime yet another message was added that we missed to update. While around improve that new message by adding engine name and use existing helpers to check for context state. Signed-off-by:
-
Nirmoy Das authored
Use sysfs_emit() and sysfs_emit_at() in show() callback as recommended by Documentation/filesystems/sysfs.rst Cc: Andi Shyti <andi.shyti@linux.intel.com> Signed-off-by:
-
- 01 Feb, 2023 1 commit
-
-
Chris Wilson authored
Check that we invalidate the TLB cache, the updated physical addresses are immediately visible to the HW, and there is no retention of the old physical address for concurrent HW access. Signed-off-by:
-
- 31 Jan, 2023 9 commits
-
-
John Harrison authored
Wa_22011802037 requires waiting for an engine-specific register to clear. A missing entry for GSC engine in the register table is flagged as a drm_err. The drm_err was originally intended to catch missing register entries for newer engines, however, it was later found that the WA is only required for 'legacy' engines. So just drop the drm_err. Signed-off-by:
Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230124231111.1786429-1-umesh.nerlige.ramappa@intel.com
-
Michal Wajdeczko authored
Use new macros to have common prefix that also include GT#. v2: pass gt to print_fw_ver v3: prefer guc_dbg in suspend/resume logs Signed-off-by:
-
Michal Wajdeczko authored
Use new macros to have common prefix that also include GT#. v2: improve few existing messages Signed-off-by:
-
Michal Wajdeczko authored
Use new macros to have common prefix that also include GT#. v2: drop redundant GuC strings, minor improvements v3: more message improvements Signed-off-by:
-
Michal Wajdeczko authored
Use new macros to have common prefix that also include GT#. Signed-off-by:
-
Michal Wajdeczko authored
Use new macros to have common prefix that also include GT#. v2: drop unused helpers Signed-off-by:
-
Michal Wajdeczko authored
Use new macros to have common prefix that also include GT#. Signed-off-by:
-
Michal Wajdeczko authored
Use new macros to have common prefix that also include GT#. v2: drop now redundant "GuC" word from the message Signed-off-by:
-
Michal Wajdeczko authored
While we do have GT oriented print macros, add few more GuC specific to have common look and feel across all messages related to the GuC and to avoid chasing the gt pointer. We will use these macros shortly in upcoming patches. Signed-off-by:
-
- 30 Jan, 2023 1 commit
-
-
Rob Clark authored
A userspace with multiple threads racing I915_GEM_SET_TILING to set the tiling to I915_TILING_NONE could trigger a double free of the bit_17 bitmask. (Or conversely leak memory on the transition to tiled.) Move allocation/free'ing of the bitmask within the section protected by the obj lock. Signed-off-by:
-
- 27 Jan, 2023 4 commits
-
-
John Harrison authored
The GuC specific register state entry in the error capture object was just called 'capture'. Although the companion 'node' entry was called 'guc_capture_node'. Rename the base entry to be 'guc_capture' instead so that it is a) more consistent and b) more obvious what it is. Signed-off-by:
-
John Harrison authored
For understanding bug reports, it can be useful to have an explicit dmesg print when a reset notification is received from GuC. As opposed to simply inferring that this happened from other messages. Signed-off-by:
-
John Harrison authored
Engine resets are supposed to never fail. But in the case when one does (due to unknown reasons that normally come down to a missing w/a), it is useful to get as much information out of the system as possible. Given that the GuC intentionally dies on such a situation, it is not possible to get a guilty context notification back. So do a manual search instead. Given that GuC is dead, this is safe because GuC won't be changing the engine state asynchronously. v2: Change comment to be less alarming (Tvrtko) Signed-off-by:
-
John Harrison authored
A hang situation has been observed where the only requests on the context were either completed or not yet started according to the breaadcrumbs. However, the register state claimed a batch was (maybe) in progress. So, allow capture of the pending request on the grounds that this might be better than nothing. v2: Reword 'not started' warning message (Tvrtko) Signed-off-by:
-
