- 19 Dec, 2023 40 commits
-
-
Rodrigo Vivi authored
These structs and definitions are only used for the guc_submit and they were added specifically for the parallel submission. While doing that also delete the unused struct guc_wq_item. v2: checkpatch fixes. Cc: Matthew Brost <matthew.brost@intel.com> Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by:
Matthew Brost <matthew.brost@intel.com>
-
Rodrigo Vivi authored
Let's start to move our existent logs to devcoredump one by one. Any format change should come on follow-up work. v2: Rebase and add the dma_fence locking annotation here. Signed-off-by:
-
Rodrigo Vivi authored
The goal is to allow for a snapshot capture to be taken at the time of the crash, while the print out can happen at a later time through the exposed devcoredump virtual device. v2: Handle memory allocation failures. (Matthew) Do not use GFP_ATOMIC on cases like debugfs prints. (Matthew) v3: checkpatch fixes v4: Do not use atomic in the g2h_worker_func (Matthew) Signed-off-by: -
Rodrigo Vivi authored
No functional change here. The goal is to have a clear split between the mapped portions of the CTB and the static information, so we can easily capture snapshots that will be used for later read out with the devcoredump infrastructure. Signed-off-by:
-
Rodrigo Vivi authored
Unfortunately devcoredump infrastructure does not provide and interface for us to force the device removal upon the pci_remove time of our device. The devcoredump is linked at the device level, so when in use it will prevent the module removal, but it doesn't prevent the call of the pci_remove callback. This callback cannot fail anyway and we end up clearing and freeing the entire pci device. Hence, after we removed the pci device, we shouldn't allow any read or free operations to avoid segmentation fault. Signed-off-by:
-
Rodrigo Vivi authored
The goal is to use devcoredump infrastructure to report error states captured at the crash time. The error state will contain useful information for GPU hang debug, such as INSTDONE registers and the current buffers getting executed, as well as any other information that helps user space and allow later replays of the error. The proposal here is to avoid a Xe only error_state like i915 and use a standard dev_coredump infrastructure to expose the error state. For our own case, the data is only useful if it is a snapshot of the time when the GPU crash has happened, since we reset the GPU immediately after and the registers might have changed. So the proposal here is to have an internal snapshot to be printed out later. Also, usually a subsequent GPU hang can be only a cause of the initial one. So we only save the 'first' hang. The dev_coredump has a delayed work queue where it remove the coredump and free all the data within a few moments of the error. When that happens we also reset our capture state and allow further snapshots. Right now this infra only print out the time of the hang. More information will be migrated here on subsequent work. Also, in order to organize the dump better, the goal is to propose dev_coredump changes itself to allow multiple files and different controls. But for now we start Xe usage of it without any dependency on dev_coredump core changes. v2: Add dma_fence annotation for capture that might happen during long running. (Thomas and Matt) Use xe->drm.primary->index on drm_info msg. (Jani) v3: checkpatch fixes v4: Fix building and locking issues found by Francois. Actually let's kill all of the locking in here. gt_reset serialization already guarantee that there will be only one capture at the same time. Also, the devcoredump has its own locking to protect the free and reads and drivers don't need to duplicate it. Besides this, the dma_fence locking was pushed to a following patch since it is not needed in this one. Fix a use after free identified by KASAN: Do not stash the faulty_engine since that will be freed somewhere else. v5: Fix Uptime - ktime_get_boottime actually returns the Uptime. (Francois) Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Francois Dugast <francois.dugast@intel.com> Signed-off-by: -
Michal Wajdeczko authored
Replace generic log messages with ones dedicated for the GT. While around replace errno logs from plain %d to pretty %pe. v2: rebased v3: unify errno logs Signed-off-by:
Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Reviewed-by:
Matt Roper <matthew.d.roper@intel.com> Signed-off-by:
-
Michal Wajdeczko authored
While debugging GT related problems, it's good to know which GT was reporting problems. Introduce helper macros to allow prefix GT logs with GT identifier. We will use them in upcoming patches. v2: use xe_ prefix (Lucas) v3: use correct include Signed-off-by:
-
Matthew Brost authored
This is allowed and encouraged by the dma-fencing rules. This along with allowing compute VMs to export dma-fences on binds will result in a simpler compute UMD. Signed-off-by:
Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by:
-
Matthew Brost authored
Binds are not long running jobs thus we can export dma-fences even if a VM is in compute mode. Signed-off-by:
-
Gustavo Sousa authored
Move xe_register_pci_driver() and xe_unregister_pci_driver() to init_funcs to make sure that exit functions are also called when xe_register_pci_driver() fails. Note that this also allows adding init functions to be run after xe_register_pci_driver(). v2: - Move functions to init_funcs instead of having a special case for xe_register_pci_driver(). (Jani) Cc: Jani Nikula <jani.nikula@intel.com> Reviewed-by:
Matt Atwood <matthew.s.atwood@intel.com> Signed-off-by:
Gustavo Sousa <gustavo.sousa@intel.com> Signed-off-by:
-
Gustavo Sousa authored
There is not much of a benefit from using that macro as of now and it hurts grepability or other ways of cross-referencing. Cc: Jani Nikula <jani.nikula@intel.com> Reviewed-by:
-
Francois Dugast authored
Signed-off-by:
Francois Dugast <francois.dugast@intel.com> Reviewed-by:
-
Lucas De Marchi authored
Alderlake P uses TGL HuC and it was not added together with ADL-S, because it was failing for unrelated reasons. Now that those are fixed, allow it to load HuC. # cat /sys/kernel/debug/dri/0/gt0/uc/huc_info HuC firmware: i915/tgl_huc.bin status: RUNNING version: wanted 0.0, found 7.9 uCode: 589504 bytes RSA: 256 bytes HuC status: 0x00090001 Reviewed-by:
Anusha Srivatsa <anusha.srivatsa@intel.com> Link: https://lore.kernel.org/r/20230512233649.3218736-1-lucas.demarchi@intel.comSigned-off-by:
Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by:
-
Matt Roper authored
ADL-N is pretty much the same as ADL-P (i.e., Xe_LP graphics + Xe_M media + Xe_LPD display). However unlike ADL-P, there's no GuC hwconfig support so the "tgl" GuC firmware should be loaded (i.e., the same situation as ADL-S). Acked-by:
Nirmoy Das <nirmoy.das@intel.com> Reviewed-by:
Ravi Kumar Vodapalli <ravi.kumar.vodapalli@intel.com> Link: https://lore.kernel.org/r/20230419213703.3993439-2-matthew.d.roper@intel.comSigned-off-by:
-
Matt Roper authored
Setup the mapping from PCI revid to IP stepping for ADL-P (and its RPL-P subplatform) in case this information becomes important for implementing workarounds. Bspec: 55376 Reviewed-by:
-
Matthew Auld authored
Checking seqno_recv >= seqno looks like it will incorrectly report true when the seqno has wrapped (not unlikely given TLB_INVALIDATION_SEQNO_MAX). Calling xe_gt_tlb_invalidation_wait() might then return before the flush has been completed by the GuC. Fix this by treating a large negative delta as an indication that the seqno has wrapped around. Similar to how we treat a large positive delta as an indication that the seqno_recv must have wrapped around, but in that case the seqno has likely also signalled. It looks like we could also potentially make the seqno use the full 32bits as supported by the GuC. Signed-off-by:
Matthew Auld <matthew.auld@intel.com> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Reviewed-by:
-
Lucas De Marchi authored
Fix the indent to align with open parenthesis, following the coding style. Reviewed-by:
-
Lucas De Marchi authored
Rename the address field to "addr" rather than "reg" so it's easier to understand what it is. Reviewed-by:
-
Lucas De Marchi authored
Convert all the callers to deal with xe_mmio_*() using struct xe_reg instead of plain u32. In a few places there was also a rename s/reg/reg_val/ when dealing with the value returned so it doesn't get mixed up with the register address. Reviewed-by:
-
Niranjana Vishwanathapura authored
With multiple active VMs, under memory pressure, it is possible that ttm_bo_validate() run into -EDEADLK in ttm_mem_evict_wait_busy() and return -ENOMEM. Until ttm properly handles locking in such scenarios, best thing the driver can do is unwind the lock and retry. Update xe_exec_begin to retry validating BOs with a timeout upon -ENOMEM. Reviewed-by:
Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com> Signed-off-by:
-
Niranjana Vishwanathapura authored
With multiple active VMs, under memory pressure, it is possible that ttm_bo_validate() run into -EDEADLK in ttm_mem_evict_wait_busy() and return -ENOMEM. Until ttm properly handles locking in such scenarios, best thing the driver can do is unwind the lock and retry. Update preempt worker to retry validating BOs with a timeout upon -ENOMEM. v2: revert retry timeout upon -EAGAIN (Thomas) Reviewed-by:
-
Mika Kuoppala authored
xe_file_close cleanups the xarrays but forgets to destroy them causing a memleak in xarray internals. Found with kmemleak. Signed-off-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by:
Christoph Manszewski <christoph.manszewski@intel.com> Reviewed-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by:
-
Nirmoy Das authored
Print GT info on TLB inv failure for better debugbility. Signed-off-by:
-
Nirmoy Das authored
Set atomic in xe_mmio_wait32() otherwise we would be scheduling in atomic context. Fixes: 7dc9b92d ("drm/xe: Remove i915_utils dependency from xe_pcode.") Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
-
Lucas De Marchi authored
guc_mmio_regset_write() had a flags for the registers to be added to the GuC's regset list. The only register actually using that was RCU_MODE, but it was setting the flags to a bogus value. From struct xe_guc_fwif.h, #define GUC_REGSET_MASKED BIT(0) #define GUC_REGSET_MASKED_WITH_VALUE BIT(2) #define GUC_REGSET_RESTORE_ONLY BIT(3) Cross checking with i915, the only flag to set in RCU_MODE is GUC_REGSET_MASKED. That can be done automatically from the register, as long as the definition is correct. Add the XE_REG_OPTION_MASKED annotation to RCU_MODE and kill the "flags" field in guc_mmio_regset_write(): guc_mmio_regset_write_one() can decide that based on the register being passed. Reviewed-by:
-
Lucas De Marchi authored
The rest of the driver doesn't really support PVC before B0 stepping. Drop the special handling in xe_guc.c. Reviewed-by:
-
Lucas De Marchi authored
On i915 the "see comment about Wa_22013088509" referred to the comment in the graphics version >= 11 branch, where there were more details about it. From the platforms supported by xe, only PVC needs Wa_22013088509, but as the comment says, it's simpler to do it for all platforms as there is no downside. Bring the missing comment over from i915 and reword it to fit xe better. Reviewed-by:
-
Lucas De Marchi authored
Additional programming annotated with Wa_<number> should be reserved to those that have a official workaround. Just pointing to a bug or additional reference can be done with something else. Copy what i915 does and refer to it as "hsdes: ....". Reviewed-by:
-
Christopher Snowhill authored
This is required at the minimum for the DRM UAPI to function from 32-bit userspace with a 64-bit kernel. Signed-off-by:
Christopher Snowhill <kode54@gmail.com> Reviewed-by:
-
Francois Dugast authored
Allow xe_bo_addr without lock to print debug information, such as from xe_analyze_vm. Signed-off-by:
-
José Roberto de Souza authored
copy cs instructions that dont have a explict MOCS field will use this default MOCS value. v2: - move to xe_hw_engine.c - remove BLIT_CCTL auxiliary macros - removed MASKED_REG v3: - rebased v4: - process workaround in hwe->reg_lrc v5: - add a new function and call it from xe_gt_record_default_lrcs() because hwe->reg_lrc is initialized later BSpec: 45807 Cc: Matt Roper <matthew.d.roper@intel.com> Signed-off-by:
José Roberto de Souza <jose.souza@intel.com> Reviewed-by:
-
José Roberto de Souza authored
CS instructions that dont have a explicit MOCS field will use this default MOCS value. To do this, it was necessary to initialize part of the mocs earlier and add new function that loads another array of rtp entries set during run-time. This is still missing to handle of mocs read for platforms with HAS_L3_CCS_READ(aka PVC). v2: - move to xe_hw_engine.c - remove CMD_CCTL auxiliary macros v3: - rebased Bspec: 45826 Cc: Matt Roper <matthew.d.roper@intel.com> Signed-off-by:
-
Gustavo Sousa authored
Things defined in <linux/init.h> are not really used by that header. Replace that with <linux/types.h>, to have bool and u32 available. Signed-off-by:
-
José Roberto de Souza authored
Raptorlake-P was tested and it is working as the same as Alderlake-P. Reviewed-by:
-
Lucas De Marchi authored
Reading the GMD_ID register on platforms before that register became available is not reliable. The assumption was that since the register was not allocated, it would return 0. But on PVC for example it returns garbage (or a very specific number), triggering the following error: xe 0000:8c:00.0: [drm] *ERROR* Hardware reports unknown media version 1025.55 Fix it by stop relying on the value returned by that registers on platforms before GMD_ID. Instead this relies on the graphics description struct being already pre-set on the device: this can only ever be true for platforms before the GMD_ID support. In that case, GMD_ID is skipped and the hardcoded values are used. This should also help on early bring-up in case the GMD_ID returns something not expected and we need to temporarily hardcode values. With this, PVC doesn't trigger the error and goes straight to: xe 0000:8c:00.0: [drm:xe_display_info_init [xe]] No display IP, skipping xe 0000:8c:00.0: [drm:xe_pci_probe [xe]] XE_PVC 0bd5:002f dgfx:1 gfx:Xe_HPC (12.60) media:none (0.00) dma_m_s:52 tc:2 xe 0000:8c:00.0: [drm:xe_pci_probe [xe]] Stepping = (G:C0, M:**, D:**, B:B3) Fixes: 5822bba9 ("drm/xe: Select graphics/media descriptors from GMD_ID") Reviewed-by:
-
Lucas De Marchi authored
The macros to handle the RTP tables are very scary, but shouldn't be used outside of the header adding the infra. Move it to a separate header and make sure it's only included when it can be. Reviewed-by:
-
Lucas De Marchi authored
Now that struct xe_reg and struct xe_reg_mcr are types that can be used by xe, convert more of the driver to use them. Some notes about the conversions: - The RTP tables don't need the MASKED flags anymore in the actions as that information now comes from the register definition - There is no need for the _XE_RTP_REG/_XE_RTP_REG_MCR macros and the register types on RTP infra: that comes from the register definitions. - When declaring the RTP entries, there is no need anymore to undef XE_REG and friends: the RTP macros deal with removing the cast where needed due to not being able to use a compound statement for initialization in the tables - The index in the reg-sr xarray is the register offset only. Otherwise we wouldn't catch mistakes about adding both a MCR-style and normal-style registers. For that, the register is now also part of the entry, so the options can be compared to check for compatible entries. In order to be able to accomplish this, some improvements are needed on the RTP macros. Change its implementation to concentrate on "pasting a prefix to each argument" rather than the more general "call any macro for each argument". Hopefully this will avoid trying to extend this infra and making it more complex. With the use of tuples for building the arguments, it's not possible to pass additional register fields and using xe_reg in the RTP tables. xe_mmio_* still need to be converted, from u32 to xe_reg, but that is left for another change. Reviewed-by:
-
Lucas De Marchi authored
Go over all registers used in xe_rtp tables and mark the registers as masked if they were passed a XE_RTP_ACTION_FLAG(MASKED_REG) flag. This will allow the flag to be removed in future when xe_rtp starts using the real xe_reg_t type. Reviewed-by:
-
Lucas De Marchi authored
These should replace the _MMIO() and MCR_REG() from i915, with the goal of being more extensible, allowing to pass the additional fields for struct xe_reg and struct xe_reg_mcr. Replace all uses of _MMIO() and MCR_REG() in xe. Since the RTP, reg-save-restore and WA infra are not ready to use the new type, just undef the macro like was done for the i915 types previously. That conversion will come later. v2: Remove MEDIA_SOFT_SCRATCH_COUNT/MEDIA_SOFT_SCRATCH re-added by mistake (Matt Roper) Reviewed-by:
-
