- 21 Dec, 2023 40 commits
-
-
Matt Roper authored
MI_STORE_DATA_IMM can store either dword values or qword values, and can store more than one value if the instruction's length field is large enough. Create explicit defines to specify the number of dwords/qwords to be stored, which will set the instruction length correctly and, if necessary, turn on the 'store qword' bit. While we're here, also replace an open-coded version of MI_STORE_DATA_IMM with the common macros. Bspec: 60246 Reviewed-by:
Lucas De Marchi <lucas.demarchi@intel.com> Link: https://lore.kernel.org/r/20231016163449.1300701-11-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
Keeping the number of registers to be loaded as a separate macro from the instruction opcode will simplify some upcoming LRC parsing code. Reviewed-by:
-
Matt Roper authored
Despite its name, MI_FLUSH_DW instruction can write an immediate value of either dword size or qword size, depending on the 'length' field of the instruction. Since "length" excludes the first two dwords of the instruction, a value of 2 in the length field implies a dword write and a value of 3 implies a qword write. Even in cases where the flush instruction's post-sync operation is set to "no write" we're still expected to size the overall instruction as if we were doing a dword or qword write (i.e., a length of 1 shouldn't be used on modern platforms). Rather than baking a size of "1" into the #define and then adding another unexplained "+ 1" at all the spots where the definition gets used, lets just create MI_FLUSH_IMM_DW and MI_FLUSH_IMM_QW definitions that should be OR'd into the instruction header to make it more explicit what behavior we're requesting. Bspec: 60229 Reviewed-by:
-
Vitaly Lubart authored
Create mei-gscfi auxiliary device and configure interrupts to be consumed by mei-gsc device driver. Reviewed-by:
Vitaly Lubart <vitaly.lubart@intel.com> Signed-off-by:
Alexander Usyskin <alexander.usyskin@intel.com> Signed-off-by:
-
Vitaly Lubart authored
Mark support of MEI-GSC interaction per device. Add has_heci_gscfi indication to xe_device and xe_pci structures. Mark DG1 and DG2 devices as supported. Reviewed-by:
-
Vitaly Lubart authored
Add HECI2 register offsets for DG1 and DG2 to regs/xe_regs.h Reviewed-by:
-
Shekhar Chauhan authored
The bspec was recently updated to remove PCI ID 0x5698; this ID is actually reserved for future use and should not be treated as DG2-G11. BSpec: 44477 Signed-off-by:
Shekhar Chauhan <shekhar.chauhan@intel.com> Reviewed-by:
-
Shekhar Chauhan authored
Add recently added PCI IDs for DG2 BSpec: 44477 Signed-off-by:
-
José Roberto de Souza authored
Without this if a atomic operation is executed in Xe2 integrated GPUs it causes engine memory catastrophic error. This fixes at least 3 failures in piglit sanity and 2 failures in crucible for LNL. v3: - only add PTE_AE to smem in integrated Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by:
José Roberto de Souza <jose.souza@intel.com> Signed-off-by:
-
Koby Elbaz authored
In future ASICs, there will be an additional MMIO extension space for all tiles altogether, residing on top of MMIO address space. Signed-off-by:
Koby Elbaz <kelbaz@habana.ai> Reviewed-by:
Ofir Bitton <obitton@habana.ai> Reviewed-by:
Moti Haimovski <mhaimovski@habana.ai> Signed-off-by:
-
Koby Elbaz authored
When MMIO BAR is initially mapped, the driver assumes a single tile device. However, former memory allocations take all tiles into account. First, a common standard for resource usage is needed here. Second, with the next (6th) patch in this series, the MMIO BAR remapping will be done only if a reduced-tile device is attached. Signed-off-by:
-
Koby Elbaz authored
Besides the regular MMIO space that exists by default, MMIO extension support & MMIO extension tile size should both be defined per device, and updated from the device's descriptor. Signed-off-by:
-
Koby Elbaz authored
Skip reading this register as it is not relevant in the new devices. Signed-off-by:
-
Koby Elbaz authored
A distinction has to be made when addressing the MMIO space or the additional MMIO extension space. Signed-off-by:
-
Koby Elbaz authored
Xe driver currently supports 22-bit addresses for MMIO access. Future platforms will have additional MMIO extension with larger address spaces, and to access them, the driver will have to support wider address representation. Please note that while the XE_REG macro is used for MMIO access, XE_REG_EXT macro will be used for MMIO-extension access. Signed-off-by:
-
Matthew Auld authored
In a future patch userspace will be able to directly set the pat_index as part of vm_bind. To support this we need to get away from using xe_cache_level in the low level routines and rather just use the pat_index directly. v2: Rebase v3: Some missed conversions, also prefer tile_to_xe() (Niranjana) v4: remove leftover const (Lucas) Signed-off-by:
Matthew Auld <matthew.auld@intel.com> Cc: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com> Cc: Pallavi Mishra <pallavi.mishra@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Reviewed-by:
Pallavi Mishra <pallavi.mishra@intel.com> Signed-off-by:
-
Matthew Auld authored
We don't seem to use the 4-7 pat indexes, even though they are defined by the HW. In a future patch userspace will be able to directly set the pat_index as part of vm_bind and we don't want to allow setting 4-7. Simplest is to just ignore them here. Suggested-by:
-
Anusha Srivatsa authored
With all ADl platforms and subplatforms added, also add support to xe_wa_test kunit tests for checking their WAs. Cc: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by:
Anusha Srivatsa <anusha.srivatsa@intel.com> Reviewed-by:
-
Anusha Srivatsa authored
Add stepping-substepping info. Though it looks weird, the revision ID for the newer stepping is indeed backwards and is in accordance to the spec. v2: s/RPLS/RAPTORLAKE_S (Anusha) v3: rebase (Anusha) Signed-off-by:
-
Anusha Srivatsa authored
Add RPLS support that was missing apart from the PCI IDs. v2: Also add the support in xe_wa_test kunit v3: rebased. Cc: Dnyaneshwar Bhadane <dnyaneshwar.bhadane@intel.com> Signed-off-by:
-
Anusha Srivatsa authored
i915 now uses full names for platforms. So we now have ALDERLAKE instead of ADL. Extend this to xe driver as well. This will make it easier for macro magic usages. v2: Do not make changes to compat-i915-headers/i915_drv.h file with the rest of the changes (Jani) Cc: Jani Nikula <jani.nikula@intel.com> Cc: Dnyaneshwar Bhadane <dnyaneshwar.bhadane@intel.com> Signed-off-by:
-
Gustavo Sousa authored
Replace the paragraph that was meant for XE_RTP_RULES with one proper for XE_RTP_ACTIONS. Signed-off-by:
Gustavo Sousa <gustavo.sousa@intel.com> Reviewed-by:
-
Lucas De Marchi authored
When failing on early initialization, one cause may be that the PAT configuration is not correct. Dump it for ease of debugging. Reviewed-by:
-
Lucas De Marchi authored
This is useful to debug cache issues, to double check if the PAT indexes match what they were supposed to be set to from spec. v2: Add separate functions for XeHP, XeHPC and XeLPG so it correctly reads the index based on MCR/REG registers and also decodes the fields (Matt Roper) v3: Starting with XeHPC, do not translate values to human-readable formats as the main goal is to make it easy to compare the table with the spec. Also, share a single array for xelp/xehp str map (Matt Roper) Reviewed-by: -
Lucas De Marchi authored
Xe2 adds one more bit to cover all the possible 32 entries. Although those entries are not used by internal kernel code paths, it's expected that userspace will make use of it. Bspec: 59510, 67095 Reviewed-by:
-
Matt Roper authored
The PAT tables become significantly more complicated on Xe2 platforms. They now control L3, L4, and coherency settings, as well as additional characteristics such as compression. Aside from the main PAT table, there's an additional register that also needs to be programmed with PAT settings for PCI Address Translation Services. Bspec: 71582 Signed-off-by:
Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com> Link: https://lore.kernel.org/r/20231006182325.3617685-1-lucas.demarchi@intel.comSigned-off-by:
-
David Kershner authored
Add missing kunit test to migrate a bo from vram to vram Reviewed-by:
Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com> Reviewed-by:
"Michael J. Ruhl" <michael.j.ruhl@intel.com> Signed-off-by:
David Kershner <david.kershner@intel.com> Signed-off-by:
-
David Kershner authored
Device Physical Address (DPA) is the starting offset device memory. Update xe_migrate identity map base PTE entries to start at dpa_base instead of 0. The VM offset value should be 0 relative instead of DPA relative. Reviewed-by:
-
Lucas De Marchi authored
Register GUC_TLB_INV_CR is gone in xe2. When GuC submission is not yet enabled, make sure to follow the same path as XeHPC. Signed-off-by:
-
Lucas De Marchi authored
When xelp_pte_encode_addr() was added in commit 23c8495e ("drm/xe/migrate: Do not hand-encode pte"), there was no xe pointer for using xe_assert(). This is not the case anymore, so prefer it over XE_WARN_ON(). Signed-off-by:
-
Matt Atwood authored
Force indirect state sampler data to only be in the dynamic state pool, which is more convienent for the UMD. Behavior change mirrors similar change for i915 in commit 16fc9c08 ("drm/i915: disable sampler indirect state in bindless heap") v2: split out per engine tuning into separate patch, commit message (Lucas) v3: rebase v4: Change to match render only, g.ver 1200 to 1271 (MattR) Acked-by:
Lionel Landwerlin <lionel.g.landwerlin@intel.com> Reviewed-by:
Matt Atwood <matthew.s.atwood@intel.com> Signed-off-by:
-
Matt Atwood authored
Add the infrastructure for per engine tuning in preparation for disable indirect state. v3: Rebase v4: Fix rebasing issues Reviewed-by:
-
Matthew Auld authored
It doesn't look like you can mix and match devm_ and drmmm_ for a managed resource. For drmmm the resources are all tracked in drm with its own list, and there is only one devm_ resource for the entire list. If the driver itself also adds some of its own devm resources, then those will be released first. In the case of hwmon the devm_kzalloc will be freed before the drmmm_ action to destroy the mutex allocated within, leading to uaf. Since hwmon itself wants to use devm, rather use that for the mutex destroy. Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/766Signed-off-by:
-
Lucas De Marchi authored
Add index 4 so WB on both L3 and L4 can be used by userspace. Bspec: 71582 Link: https://lore.kernel.org/all/7oqovb356dx2hm5muop3xjqr4kv7m5fzjisch3vmsmxm33ygtv@eib4jielia35/Reviewed-by:
-
José Roberto de Souza authored
This register don't exist in gfx12+, so here dropping the readout and print in devcoredump. Reviewed-by:
-
José Roberto de Souza authored
It was reading (base) + 0x8c but that is not a valid register and instead it should read (base) + 0x68. So here reading the correct register and removing the wrong and duplicated. Reviewed-by:
-
José Roberto de Souza authored
Fix a typo in RING_MI_MODE label. Signed-off-by:
-
Paulo Zanoni authored
We're already using the half-open interval notation "[A, B)", that "- 1" there makes it wrong. Also, getting rid of the "-1" makes it much easier to grep for the logs when you're looking for an address that's the end of a vma and the start of another. Signed-off-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by:
-
Paulo Zanoni authored
I would imagine that it's more efficient to fetch ops_list->prev than to walk the whole list forward. Signed-off-by:
-
Paulo Zanoni authored
Unions are cool, until they aren't. Signed-off-by:
-
