- 19 Dec, 2023 40 commits
-
-
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 <matthew.d.roper@intel.com> Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com>
-
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:
Lucas De Marchi <lucas.demarchi@intel.com> Link: https://lore.kernel.org/r/20230419213703.3993439-1-matthew.d.roper@intel.comSigned-off-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:
Matthew Brost <matthew.brost@intel.com> Signed-off-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:
Thomas Hellström <thomas.hellstrom@linux.intel.com> Signed-off-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:
Francois Dugast <francois.dugast@intel.com> Reviewed-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:
Gustavo Sousa <gustavo.sousa@intel.com> Reviewed-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: -
Lucas De Marchi authored
Stop using i915 types for registers. Use our own types. Differently from i915, this will keep under the register definition the knowledge for the different types of registers. For now, the "flags"/"options" are mcr and masked, although only the former is being used. Additionally MCR registers have their own type. The only place that should really look inside a xe_mcr_reg_t is that code dealing with the steering and using other APIs when the register is MCR has been a source of problem in the past. Most of the driver is agnostic to the register differences since they either use the definition from the header or already call the correct MCR_REG()/_MMIO() macros. By embeding the struct xe_reg inside the struct it's also possible to guarantee the compiler will break if using RANDOM_MCR_REG.reg is attempted, since now the u32 is inside the inner struct. v2: - Deep a dedicated type for MCR registers to avoid misuse (Matt Roper, Jani) - Drop the typedef and just use a struct since it's not an opaque type (Jani) - Add more kernel-doc v3: - Use only 22 bits for the register address since all the platforms supported so far have only 4MB of MMIO per tile (Matt Roper) Reviewed-by: -
Lucas De Marchi authored
Clarify a few things related to the PAT programming, particularly on MTL: - The register type doesn't change depending on the GT - what happens is that media GT writes to other set of registers that are not MCR - Remove "UNICAST": otherwise it's confusing why it's not using MCR registers with the unicast function variant Also, there isn't much reason to keep those parts as macros: promote them to proper functions and let the compiler inline if it sees fit. Reviewed-by:
-
Lucas De Marchi authored
Convert the macro declarations to the equivalent GENMASK and and bitfield prep for all registers. v2 (Matt Roper): - Fix wrong conversion of RPM_CONFIG0_CRYSTAL_CLOCK_FREQ_MASK - Reorder fields of XEHP_SLICE_UNIT_LEVEL_CLKGATE for consistency - Simplify CTC_SOURCE_* by only defining CTC_SOURCE_DIVIDE_LOGIC as REG_BIT(0) v3: Also remove DOP_CLOCK_GATE_ENABLE that is unused and wrongly defined Reviewed-by:Matt Atwood <matthew.s.atwood@intel.com> Link: https://lore.kernel.org/r/20230427223256.1432787-4-lucas.demarchi@intel.comSigned-off-by:
-
Lucas De Marchi authored
The defines for the registers were brought over from i915 while bootstrapping the driver. As xe supports TGL and later only, it doesn't make sense to keep the GEN* prefixes and suffixes in the registers: TGL is graphics version 12, previously called "GEN12". So drop the prefix everywhere. v2: - Also drop _TGL suffix and reword commit message as suggested by Matt Roper. While at it, rename VSUNIT_CLKGATE_DIS_TGL to VSUNIT_CLKGATE2_DIS with the additional "2", so it doesn't clash with the define for the other register Reviewed-by: -
Lucas De Marchi authored
Cleanup GuC register declarations by converting them to use REG_FIELD, REG_BIT and REG_GENMASK. While converting, also reorder the bitfields so they follow the convention of declaring the higher bits first. v2: - Drop unused HUC_LOADING_AGENT_VCR and DMA_ADDRESS_SPACE_GTT (Matt Roper) - Simplify HUC_LOADING_AGENT_GUC define (Matt Roper) Reviewed-by:
-
Maarten Lankhorst authored
Commit 7aaec3a6 ("drm/xe: Let's return last value read on xe_mmio_wait32.") mentions that we should return the last value read, but we never actually return it. This breaks display which depends on the value being actually returned where needed. Signed-off-by:
-
Lucas De Marchi authored
There's no good reason to keep the GuC registers outside the regs/ directory: move the header with GuC registers under that. Signed-off-by:
-
Lucas De Marchi authored
That register is a completely different register, it's not the same as SOFT_SCRATCH for GEN11 and beyond. Rename to to the same name as the bspec uses, including the new variant for media. Also, move the definitions to the guc header. Signed-off-by:
-
Lucas De Marchi authored
There was both BLT_DEPTH_32 and XY_FAST_COLOR_BLT_DEPTH_32 - also add the prefix to the first to make it clear this is about the FAST_**COPY** operation. While at it, remove the GEN9_ prefix. Signed-off-by:
-
Lucas De Marchi authored
Follow up commits will mass-remove the gen prefix/suffix. For GEN6_RC0 and GEN6_RC6 that would make the variable too short and easy to conflict. So, add "GT_" prefix that is also part of the register name. Signed-off-by:
-
Lucas De Marchi authored
Rename the following defines to lose the GEN* prefixes since they don't make sense for xe: GEN8_PTE_SHIFT -> XE_PTE_SHIFT GEN8_PAGE_SIZE -> XE_PAGE_SIZE GEN8_PTE_MASK -> XE_PTE_MASK GEN8_PDE_SHIFT -> XE_PDE_SHIFT GEN8_PDES -> XE_PDES GEN8_PDE_MASK -> XE_PDE_MASK GEN8_64K_PTE_SHIFT -> XE_64K_PTE_SHIFT GEN8_64K_PAGE_SIZE -> XE_64K_PAGE_SIZE GEN8_64K_PTE_MASK -> XE_64K_PTE_MASK GEN8_64K_PDE_MASK -> XE_64K_PDE_MASK GEN8_PDE_PS_2M -> XE_PDE_PS_2M GEN8_PDPE_PS_1G -> XE_PDPE_PS_1G GEN8_PDE_IPS_64K -> XE_PDE_IPS_64K GEN12_GGTT_PTE_LM -> XE_GGTT_PTE_LM GEN12_USM_PPGTT_PTE_AE -> XE_USM_PPGTT_PTE_AE GEN12_PPGTT_PTE_LM -> XE_PPGTT_PTE_LM GEN12_PDE_64K -> XE_PDE_64K GEN12_PTE_PS64 -> XE_PTE_PS64 GEN8_PAGE_PRESENT -> XE_PAGE_PRESENT GEN8_PAGE_RW -> XE_PAGE_RW PTE_READ_ONLY -> XE_PTE_READ_ONLY Keep an XE_ prefix to make sure we don't mix the defines for the CPU (e.g. PAGE_SIZE) with the ones fro the GPU). Signed-off-by:
-
Rodrigo Vivi authored
On xe_hw_engine_print_state we were printing: value_of(0x510) + 4 instead of value_of(0x514) as desired. So, let's properly define a RING_EXECLIST_SQ_CONTENTS_HI register to fix the issue and also to avoid other issues like that. Signed-off-by:
-
Rodrigo Vivi authored
The main issue with buddy allocator was fixed, but then we ended up on other issues, so we need to step back and rethink our strategy with D3cold. So, let's update the comment with a todo list so we don't get tempted in removing it before we are really ready. Cc: Matthew Auld <matthew.auld@intel.com> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Cc: Riana Tauro <riana.tauro@intel.com> Signed-off-by:
-
José Roberto de Souza authored
ttm_global_init() imposes this limitation. Cc: Matthew Auld <matthew.auld@intel.com> Reviewed-by:
-
