- 01 Mar, 2023 2 commits
-
-
Andrea Righi authored
It seems that commit bc3c5e08 ("drm/i915/sseu: Don't try to store EU mask internally in UAPI format") exposed a potential out-of-bounds access, reported by UBSAN as following on a laptop with a gen 11 i915 card: UBSAN: array-index-out-of-bounds in drivers/gpu/drm/i915/gt/intel_sseu.c:65:27 index 6 is out of range for type 'u16 [6]' CPU: 2 PID: 165 Comm: systemd-udevd Not tainted 6.2.0-9-generic #9-Ubuntu Hardware name: Dell Inc. XPS 13 9300/077Y9N, BIOS 1.11.0 03/22/2022 Call Trace: <TASK> show_stack+0x4e/0x61 dump_stack_lvl+0x4a/0x6f dump_stack+0x10/0x18 ubsan_epilogue+0x9/0x3a __ubsan_handle_out_of_bounds.cold+0x42/0x47 gen11_compute_sseu_info+0x121/0x130 [i915] intel_sseu_info_init+0x15d/0x2b0 [i915] intel_gt_init_mmio+0x23/0x40 [i915] i915_driver_mmio_probe+0x129/0x400 [i915] ? intel_gt_probe_all+0x91/0x2e0 [i915] i915_driver_probe+0xe1/0x3f0 [i915] ? drm_privacy_screen_get+0x16d/0x190 [drm] ? acpi_dev_found+0x64/0x80 i915_pci_probe+0xac/0x1b0 [i915] ... According to the definition of sseu_dev_info, eu_mask->hsw is limited to a maximum of GEN_MAX_SS_PER_HSW_SLICE (6) sub-slices, but gen11_sseu_info_init() can potentially set 8 sub-slices, in the !IS_JSL_EHL(gt->i915) case. Fix this by reserving up to 8 slots for max_subslices in the eu_mask struct. Reported-by:
Emil Renner Berthing <emil.renner.berthing@canonical.com> Signed-off-by:
Andrea Righi <andrea.righi@canonical.com> Fixes: bc3c5e08 ("drm/i915/sseu: Don't try to store EU mask internally in UAPI format") Reviewed-by:
Matt Roper <matthew.d.roper@intel.com> Signed-off-by:
-
Tvrtko Ursulin authored
After the abandonment of i915->kernel_context and since we have started to create per-gt engine->kernel_context, these tests need to be updated to instantiate the batch buffer VMA in the correct PPGTT for the context used to execute each spinner. v2(Tejas): - Clean commit message - Matt - Add BUG_ON to match vm v3(Tejas): - Fix dim checkpatch warnings Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by:
Tejas Upadhyay <tejas.upadhyay@intel.com> Reviewed-by:
Andi Shyti <andi.shyti@linux.intel.com> Signed-off-by:
-
- 28 Feb, 2023 2 commits
-
-
Matt Roper authored
Xe_HP architecture already makes the CS_CTX_TIMESTAMP readable by userspace on all engines; there's no longer a need to add it to the software-managed whitelist for the non-RCS engines. Bspec: 45545 Signed-off-by:
Gustavo Sousa <gustavo.sousa@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230224002300.3578985-2-matthew.d.roper@intel.com
-
Matt Roper authored
A recommended tuning setting for both gen12 and Xe_HP platforms requires that we grant userspace r/w access to the COMMON_SLICE_CHICKEN3 register. Bspec: 73993, 73994, 31870, 68331 Cc: Dongwon Kim <dongwon.kim@intel.com> Signed-off-by:
-
- 27 Feb, 2023 1 commit
-
-
Andi Shyti authored
It has become common practice to refer to the drm_i915_private structures as "i915". However, there are still instances where they are referred to as "dev_priv". This inconsistency can make grepping for information more difficult and does not maintain a cohesive style throughout the code. Rename all the "dev_priv" structures in the gt/* directory to "i915". Signed-off-by:
Nirmoy Das <nirmoy.das@intel.com> Acked-by:
-
- 24 Feb, 2023 4 commits
-
-
Matt Roper authored
MTL's primary GT can continue to use the same engine TLB invalidation programming as past Xe_HP-based platforms. However the media GT needs some special handling: * Invalidation registers on the media GT are singleton registers (unlike the primary GT where they are still MCR). * Since the GSC is now exposed as an engine, there's a new register to use for TLB invalidation. The offset is identical to the compute engine offset, but this is expected --- compute engines only exist on the primary GT while the GSC only exists on the media GT. * Although there's only a single GSC engine instance, it inexplicably uses bit 1 to request invalidations rather than bit 0. v2: - Add a 'regs == xelpmp_regs' condition to the GSC instance handling. If the registers change on a future platform, the GSC-specific handling is likely to change as well. (Andrzej) Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Andrzej Hajda <andrzej.hajda@intel.com> Signed-off-by:
Andrzej Hajda <andrzej.hajda@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230224012009.3594691-1-matthew.d.roper@intel.com
-
Jonathan Cavitt authored
Refactor the supports_x_tiling and fast_blit_ok helper functions in the live client selftest to better reflect when XY_FAST_COPY_BLT supports X-tile and can be used. Bspec: 47982 Signed-off-by:
Jonathan Cavitt <jonathan.cavitt@intel.com> Reviewed-by:
Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Signed-off-by:
-
Matthew Auld authored
This was mostly needed to differentiate between mappable and non-mappable lmem, such that ttm would understand non-mappable -> mappable moves (or vice versa), and not just turn them into noops. We have since gained proper .intersects() and .compatible() hooks for the resource manager, which takes care of this for us. Signed-off-by:
Matthew Auld <matthew.auld@intel.com> Cc: Nirmoy Das <nirmoy.das@intel.com> Cc: Andrzej Hajda <andrzej.hajda@intel.com> Reviewed-by:
-
Matthew Auld authored
At the very least, we have some tests that force the BAR size for testing purposes, which would result in different BAR size with stolen-lmem vs normal lmem, since the BAR is only resized as part of the normal lmem probing. Signed-off-by:
-
- 17 Feb, 2023 4 commits
-
-
John Harrison authored
Direction from hardware is that ring buffers should never be mapped via the BAR on systems with LLC. There are too many caching pitfalls due to the way BAR accesses are routed. So it is safest to just not use it. Signed-off-by:
John Harrison <John.C.Harrison@Intel.com> Fixes: 9d80841e ("drm/i915: Allow ringbuffers to be bound anywhere") 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-3-John.C.Harrison@Intel.com
-
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:
-
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:
-
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:
-
- 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:
-
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:
-
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:
-
- 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 4 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:
-
