summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2023-12-19drm/xe: Remove unused revid from firmware nameLucas De Marchi
The rev field is always 0 so it ends up never used. In i915 it was introduced because of CML: up to rev 5 it reuses the guc and huc firmware blobs from KBL. After that there is a specific firmware for that platform. This can be reintroduced later if ever needed. With the removal of revid the packed attribute in uc_fw_platform_requirement, which is there only for reducing the space these tables take, can also be removed since it has even more limited usefulness: currently there's only padding of 2 bytes. Remove the attribute to avoid the unaligned access. $ pahole -C uc_fw_platform_requirement build64/drivers/gpu/drm/xe/xe_uc_fw.o struct uc_fw_platform_requirement { enum xe_platform p; /* 0 4 */ const struct uc_fw_blob blob; /* 4 10 */ /* size: 16, cachelines: 1, members: 2 */ /* padding: 2 */ /* last cacheline: 16 bytes */ }; Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://lore.kernel.org/r/20230324051754.1346390-2-lucas.demarchi@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-19drm/xe: Don't emit extra MI_BATCH_BUFFER_END in WA batchbufferMatt Roper
The MI_BATCH_BUFFER_END is already added automatically by __xe_bb_create_job(); including it in the construction of the workaround batchbuffer results in an unnecessary duplicate. Link: https://lore.kernel.org/r/20230329173334.4015124-4-matthew.d.roper@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-19drm/xe: Adjust batchbuffer space warning when creating a jobMatt Roper
We should WARN (not BUG) when creating a job if the batchbuffer does not have sufficient space and padding. The hardware prefetch requirements should also be considered. Link: https://lore.kernel.org/r/20230329173334.4015124-3-matthew.d.roper@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-19drm/xe: Include hardware prefetch buffer in batchbuffer allocationsMatt Roper
The hardware prefetches several cachelines of data from batchbuffers before they are parsed. This prefetching only stops when the parser encounters an MI_BATCH_BUFFER_END instruction (or a nested MI_BATCH_BUFFER_START), so we must ensure that there is enough padding at the end of the batchbuffer to prevent the prefetcher from running past the end of the allocation and potentially faulting. Bspec: 45717 Link: https://lore.kernel.org/r/20230329173334.4015124-2-matthew.d.roper@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-19drm/xe: Better error messages for xe_gt_record_default_lrcsMatthew Brost
Add some error messages describing the problem when xe_gt_record_default_lrcs fails. Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-19drm/xe: don't auto fall back to execlist mode if guc failed to initChang, Bruce
In general, this is due to FW load failure, should just report error and fail the probe so that user can easily retry again. Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Bruce Chang <yu.bruce.chang@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-19drm/xe/pat: Define PAT tables as staticMatt Roper
The tables are only used within this file; there's no reason for them not to be static. Reviewed-by: Nirmoy Das <nirmoy.das@intel.com> Link: https://lore.kernel.org/r/20230327175824.2967914-1-matthew.d.roper@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-19drm/xe/bo: refactor try_add_vramMatthew Auld
Get rid of some of the duplication here. In a future patch we need to also consider [fpfn, lpfn], so better adjust in only one place. Suggested-by: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Matthew Auld <matthew.auld@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Reviewed-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-19drm/xe: add XE_BO_CREATE_VRAM_MASKMatthew Auld
So we don't have to keep repeating VRAM0 | VRAM1. Also if there are ever more instances, then we have less places to update. Suggested-by: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Matthew Auld <matthew.auld@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Reviewed-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-19drm/xe/mtl: Handle PAT_INDEX offset jumpMatt Roper
Starting with MTL, the number of entries in the PAT table increased to 16. The register offset jumped between index 7 and index 8, so a slight adjustment is needed to ensure the PAT_INDEX macros select the proper offset for the upper half of the table. Note that although there are 16 registers in the hardware, the driver is currently only asked to program the first 5, and we leave the rest at their hardware default values. That means we don't actually touch the upper half of the PAT table in the driver today and this patch won't have any functional effect [yet]. Bspec: 44235 Reviewed-by: Nirmoy Das <nirmoy.das@intel.com> Link: https://lore.kernel.org/r/20230324210415.2434992-7-matthew.d.roper@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-19drm/xe/mtl: Fix PAT table coherency settingsMatt Roper
Re-sync our MTL PAT table with the bspec. 1-way coherency should only be set on table entry 3. We do not want an incorrect setting here to accidentally paper over other bugs elsewhere in the driver. Bspec: 45101 Reviewed-by: Nirmoy Das <nirmoy.das@intel.com> Link: https://lore.kernel.org/r/20230324210415.2434992-6-matthew.d.roper@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-19drm/xe/pat: Clean up PAT register definitionsMatt Roper
Replace the deprecated "GEN" terminology in the PAT definitions. Acked-by: Nirmoy Das <nirmoy.das@intel.com> Link: https://lore.kernel.org/r/20230324210415.2434992-5-matthew.d.roper@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-19drm/xe/pat: Handle unicast vs MCR PAT registersMatt Roper
The PAT_INDEX registers are MCR registers on some platforms and unicast on others. On MTL the handling even varies between GTs: the primary GT uses MCR registers while the media GT uses unicast registers. Let's add proper MCR programming on the relevant platforms/GTs. Given that we PAT tables to change pretty regularly on future platforms, we'll make PAT programming an exception to the usual model of assuming new platforms should inherit the previous platform's behavior. Instead we'll raise a warning if the current platform isn't handled in the if/else ladder. This should help prevent subtle cache misbehavior if we forget to add the table for a new platform. Bspec: 66534, 67609, 67788 Reviewed-by: Nirmoy Das <nirmoy.das@intel.com> Link: https://lore.kernel.org/r/20230324210415.2434992-4-matthew.d.roper@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-19drm/xe/pat: Use table-based programming of PAT settingsMatt Roper
Provide per-platform tables of PAT values rather than per-platform functions. This will simplify the handling of unicast vs MCR registers in the upcoming patches. Reviewed-by: Nirmoy Das <nirmoy.das@intel.com> Link: https://lore.kernel.org/r/20230324210415.2434992-3-matthew.d.roper@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-19drm/xe/pat: Move PAT setup to a dedicated fileMatt Roper
PAT handling is growing in complexity and will continue to do so in upcoming platforms. Separate it out to a dedicated file to keep things tidy. The code is moved as-is here (aside from a few unused #define's that are just dropped); further changes will come in future patches. Reviewed-by: Nirmoy Das <nirmoy.das@intel.com> Link: https://lore.kernel.org/r/20230324210415.2434992-2-matthew.d.roper@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-19drm/xe: Decrement fault mode counts in xe_vm_close_and_putMatthew Brost
Rather waiting for the VM to be destroyed (all refs to VM go to zero), drop the fault mode counts when the VM is closed in xe_vm_close_and_put. This avoids a window where user space can create a faulting VM, close it, and a subsequent creation of a non-faulting VM fails. v2 (Lucas): Drop VLK reference in commit message Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Suggested-by: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-19drm/xe: Add max engine priority to xe queryJosé Roberto de Souza
Intel Vulkan driver needs to know what is the maximum priority to fill a device info struct for applications. Right now we getting this information by creating a engine and setting priorities from min to high to know what is the maximum priority for running process but this leads to info messages to be printed to dmesg: xe 0000:03:00.0: [drm] Ioctl argument check failed at drivers/gpu/drm/xe/xe_engine.c:178: value == DRM_SCHED_PRIORITY_HIGH && !capable(CAP_SYS_NICE) It does not cause any harm but when executing a test suite like crucible it causes thousands of those messages to be printed. So here adding one more property to drm_xe_query_config to fetch the max engine priority. Cc: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-19drm/xe: Load HuC on Alderlake SAnusha Srivatsa
Alderlake S uses TGL HuC. Signed-off-by: Anusha Srivatsa <anusha.srivatsa@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://lore.kernel.org/r/20230323224651.1187366-3-lucas.demarchi@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-19drm/xe/huc: Support for loading unversiond HuCAnusha Srivatsa
Follow the new direction of firmware and add macro support for loading unversioned HuC. Keep HuC versioned loading support as well for platforms that fall under force_probe support Add check to ensure driver does not do any version check for HuC if going through unversioned load. v2: unversioned firmware to be the default for platforms not under force_probe. Maintain versioned firmware macro support for platforms under force-probe protection. v3: Minor style and naming adjustments (Lucas) Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: Anusha Srivatsa <anusha.srivatsa@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://lore.kernel.org/r/20230323224651.1187366-2-lucas.demarchi@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-19drm/xe: Fix potential deadlock handling page faultsMatthew Brost
Within a class the GuC will hault scheduling if the head of the queue can't be scheduled the queue will block. This can lead to deadlock if BCS0-7 all have faults and another engine on BCS0-7 is at head of the GuC scheduling queue as the migration engine used to fix tthe fault will be blocked. To work around this set the migration engine to the highest priority when servicing page faults. v2 (Maarten): Set priority to kernel once at creation Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Brian Welty <brian.welty@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-19drm/xe: Use BO's GT to determine dma_offset when programming PTEsMatthew Brost
Rather than using the passed in GT, use the BO's GT determine dma_offset when programming PTEs as these two GT's could differ (i.e. mapping a BO from a remote GT). The BO's GT is correct GT to use as this where BO resides, while the passed in GT is where the mapping is created. v2: (Thomas) - Kernel doc, extra new line (CI) - Rebase to tip Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-19drm/xe/gt: some error handling fixesMatthew Auld
Make sure we pass along the correct errors. Signed-off-by: Matthew Auld <matthew.auld@intel.com> Reviewed-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-19drm/xe: Reinstate render / compute cache invalidation in ring opsMatthew Brost
Render / compute engines have additional caches (not just TLBs) that need to be invalidated each batch, reinstate these invalidations in ring ops. Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Suggested-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-19drm/xe: Use atomic instead of mutex for xe_device_mem_access_ongoingMaarten Lankhorst
xe_guc_ct_fast_path() is called from an irq context, and cannot lock the mutex used by xe_device_mem_access_ongoing(). Fortunately it is easy to fix, and the atomic guarantees are good enough to ensure xe->mem_access.hold_rpm is set before last ref is dropped. As far as I can tell, the runtime ref in device access should be killable, but don't dare to do it yet. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-19drm/xe: Drop zero length arraysMatthew Brost
Zero-length arrays as fake flexible arrays are deprecated and we are moving towards adopting C99 flexible-array members instead. Reviewed-by: Matthew Auld <matthew.auld@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-19drm/xe/buddy: add compatible and intersects hooksMatthew Auld
Copy this from i915. We need .compatible for vram -> vram transfers, so they don't just get nooped by ttm, if need to move something from mappable to non-mappble or vice versa. The .intersects is needed for eviction, to determine if a victim resource is worth eviction. e.g if we need mappable space there is no point in evicting a resource that has zero mappable pages. Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-19drm/xe/buddy: add visible trackingMatthew Auld
Replace the allocation code with the i915 version. This simplifies the code a little, and importantly we get the accounting at the mgr level, which is useful for debug (and maybe userspace), plus per resource tracking so we can easily check if a resource is using one or pages in the mappable part of vram (useful for eviction), or if the resource is completely within the mappable portion (useful for checking if the resource can be safely CPU mapped). v2: Fix missing PAGE_SHIFT v3: (Gwan-gyeong Mun) - Fix incorrect usage of ilog2(mm.chunk_size). - Fix calculation when checking for impossible allocation sizes, also check much earlier. v4: (Gwan-gyeong Mun) - Fix calculation when extending the [fpfn, lpfn] range due to the roundup_pow_of_two(). v5: (Gwan-gyeong Mun) - Move the check for running out of mappable VRAM to before doing any of the roundup_pow_of_two(). v6: (Jani) - Stop abusing BUG_ON(). We can easily just use WARN_ON() here and return a proper error to the caller, which is much nicer if we ever trigger these. Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Reviewed-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-19drm/xe: Stop accepting value in xe_migrate_clearBalasubramani Vivekanandan
Although xe_migrate_clear() has a value argument, currently the driver is only passing 0 at all the places this function is invoked with the exception the kunit tests are using the parameter to validate this function with different values. xe_migrate_clear() is failing on platforms with link copy engines because xe_migrate_clear() via emit_clear() is using the blitter instruction XY_FAST_COLOR_BLT to clear the memory. But this instruction is not supported by link copy engine. So the solution is to use the alternate instruction MEM_SET when platform contains link copy engine. But MEM_SET instruction accepts only 8-bit value for setting whereas the value agrument of xe_migrate_clear() is 32-bit. So instead of spreading this limitation around all invocations of xe_migrate_clear() and causing more confusion, it was decided to not accept any value itself as driver does not really need this currently. All the kunit tests are adapted as per the new function prototype. This will be followed by a patch to add support for link copy engines. Signed-off-by: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-19drm/xe: Use max wopcm size when validating the preset GuC wopcm sizeBalasubramani Vivekanandan
When the GuC wopcm base and size registers are populated by BIOS/IFWI, validate the parameters against the maximum allowed wopcm size. Bpsec: 44982 Signed-off-by: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-19drm/xe/buddy: remove the virtualized startMatthew Auld
Hopefully not needed anymore. We can add a .compatible() hook once we need to differentiate between mappable and non-mappable vram. If the allocation is not contiguous then the start value is kind of meaningless, so rather just mark as invalid. In upstream, TTM wants to eventually remove the ttm_resource.start usage. References: 544432703b2f ("drm/ttm: Add new callbacks to ttm res mgr") Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-19drm/xe/mcr: Separate version from engine type selectionLucas De Marchi
In order to improve readability and make it more future proof, split the engine type from the graphics/platform checks. Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://lore.kernel.org/r/20230317223441.3891073-1-lucas.demarchi@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-19drm/xe/vram: start tracking the io_sizeMatthew Auld
First step towards supporting small-bar is to track the io_size for vram. We can longer assume that the io_size == vram size. This way we know how much is CPU accessible via the BAR, and how much is not. Effectively giving us a two tiered vram, where in some later patches we can support different allocation strategies depending on if the memory needs to be CPU accessible or not. Note as this stage we still clamp the vram size to the usable vram size. Only in the final patch do we turn this on for real, and allow distinct io_size and vram_size. v2: (Lucas): - Improve the commit message, plus improve the kernel-doc for the io_size to give a better sense of what it actually is. Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-19drm/xe/vm: Defer vm rebind until next exec if nothing to executeThomas Hellström
If all compute engines of a vm in compute mode are idle, defer a rebind to the next exec to avoid the VM unnecessarily trying to make memory resident and compete with other VMs for available memory space. Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-19drm/xe/tests: Test both CPU- and GPU page-table updates with the migrate testThomas Hellström
Add a test parameter to force GPU page-table updates with the migrate test and test both CPU- and GPU updates. Also provide some timing results. Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-19drm/xe: Use a small negative initial seqnoThomas Hellström
Causes an early 32-bit wrap and may thus help CI catch wrapping errors that may otherwise not show early enough. Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-19drm/xe: Introduce xe_engine_is_idle()Thomas Hellström
Introduce xe_engine_is_idle, and replace the static function in xe_migrate.c. The latter had two flaws. First the seqno == 1 test might return a false true value each time the seqno counter wrapped, Second, the cur_seqno == next_seqno test would never return true. Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-19drm/xe/tests: Support CPU page-table updates in the migrate testThomas Hellström
The migrate test currently supports only GPU pagetable updates and will thus break if we fix the CPU pagetable update selection. Fix the migrate test first. Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-19drm/xe/migrate: Update cpu page-table updatesThomas Hellström
Don't wait for GPU to be able to update page-tables using CPU. Putting ourselves to sleep may be more of a problem than using GPU for page-table updates. Also allow the vm to be NULL since the migrate kunit test uses NULL for vm. Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-19drm/xe: Use a define to set initial seqno for fencesThomas Hellström
Also for HW fences, write the initial seqno - 1 to the HW completed seqno to initialize. v2: - Use __dma_fence_is_later() to compare hw fence seqnos. (Matthew Auld) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-19drm/xe/xe_uc_fw: Use firmware files from standard locationsMauro Carvalho Chehab
The GuC/HuC firmware files used by Xe drivers are the same as used by i915. Use the already-known location to find those firmware files, for a couple of reasons: 1. Avoid having the same firmware placed on two different places on MODULE_FIRMWARE(), if both 915 and xe drivers are compiled; 2. Having firmware files located on different locations may end creating bigger initramfs, as the same files will be copied twice my mkinitrd/dracut/...; 3. this is the place where those firmware files are located at https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git Upstream doesn't expect them to have on other places; 4. When built with display support, DMC firmware will be loaded from i915/ directory. It is very confusing to have some firmware files on a different place for the same driver. Cc: Matthew Brost <matthew.brost@intel.com> Cc: Lucas de Marchi <lucas.demarchi@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Thomas Hellstrom <thomas.hellstrom@linux.intel.com> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: David Airlie <airlied@gmail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org> [ Mostly agree with the direction of "use the firmware blobs from upstream at their current location for these platforms". Previous directory was not wrong as the plan was to have it handled in the upstream firmware repo. For future platforms the location can be changed if the support is only in xe ] Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://lore.kernel.org/r/20230310081338.3275583-1-mauro.chehab@linux.intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-19drm/xe/irq: the irq handler local variable need not be staticJani Nikula
It's just a local variable. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-19drm/xe: Replace i915 with xe in uapiLucas De Marchi
All structs and defines had already been renamed to "xe", but some comments with "i915" were left over. Rename them. Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://lore.kernel.org/r/20230313211628.2492587-1-lucas.demarchi@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-19drm/xe: Add missing LRC workarounds for graphics 1200Lucas De Marchi
Synchronize LRC workarounds for graphics version 1200 with i915 up to commit 7cdae9e9ee5e ("drm/i915: Move DG2 tuning to the right function"). These were probably missed for TGL/RKL before because in i915 it uses a !IS_DG1() condition. Avoid a similar issue by just checking the graphics version 1200 since DG1 is 1210. Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://lore.kernel.org/r/20230314003012.2600353-14-lucas.demarchi@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-19drm/xe: Add missing ADL-P engine workaroundLucas De Marchi
Add the one missing workaround for ADL-P when comparing to i915 up to commit 7cdae9e9ee5e ("drm/i915: Move DG2 tuning to the right function"). Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://lore.kernel.org/r/20230314003012.2600353-13-lucas.demarchi@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-19drm/xe: Add missing DG2 lrc workaroundsLucas De Marchi
Synchronize with i915 the DG2 lrc workarounds as of commit 4d14d7717f19 ("drm/i915/selftest: Fix ktime_get() and h/w access order"). A few simplifications were done when the WA should be applied to some steps of a subplatform and all the steppings of the other subplatforms. In this case, it was simply applied to all the steppings, which only means applying it to a few more A* steppings. The implementation of the workaround 16011186671 triggers a bug in the RTP infra: it's not possible to set the flag the usual way when having multiple actions in the entry. This may be fixed later, but for now it's sufficient to just set the flag directly without the helper macro. v2: Fix 14014947963 to use FIELD_SET (Matt Roper) Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://lore.kernel.org/r/20230314003012.2600353-12-lucas.demarchi@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-19drm/xe: Add missing DG2 lrc tuningsLucas De Marchi
Synchronize with i915 the DG2 tunings as of commit 4d14d7717f19 ("drm/i915/selftest: Fix ktime_get() and h/w access order"). Contrary to the tuning "gang timer" for TGL, there is no quick justification for why the read back is disabled in i915. Keep it with that flag for now. That can be tentatively removed later when the read values are checked. v2: Use XEHP_FF_MODE2 instead of GEN12_FF_MODE2 (Matt Roper) Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://lore.kernel.org/r/20230314003012.2600353-11-lucas.demarchi@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-19drm/xe: Add missing DG2 engine workaroundsLucas De Marchi
Synchronize with i915 the DG2 gt workarounds as of commit 4d14d7717f19 ("drm/i915/selftest: Fix ktime_get() and h/w access order"). A few simplifications were done when the WA should be applied to some steps of a subplatform and all the steppings of the other subplatforms. This happened with Wa_1509727124, Wa_22012856258 and a few others. In figure the pre-production steppings will be removed, so this can be already simplified a little bit. v2: - Make 1308578152 conditional on first gslice fused off - Add the missing Wa_1608949956/Wa_14010198302 (Matt Roper) v3: - Do not duplicate the implementation of 18019627453 since it's already covered by other WA numbers in graphics versions 1200 and 1210 Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://lore.kernel.org/r/20230314003012.2600353-10-lucas.demarchi@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-19drm/xe: Add missing DG2 gt workarounds and tuningsLucas De Marchi
Synchronize with i915 the DG2 gt workarounds as of commit 4d14d7717f19 ("drm/i915/selftest: Fix ktime_get() and h/w access order"). Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://lore.kernel.org/r/20230314003012.2600353-9-lucas.demarchi@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-19drm/xe: Add PVC engine workaroundsLucas De Marchi
Sync PVC engine workarounds with i915. v2: Remove 16016694945. It was added by mistake. It's a GT workaround, already present in the GT table (Matt Roper) Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://lore.kernel.org/r/20230314003012.2600353-8-lucas.demarchi@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-19drm/xe: Add PVC gt workaroundsLucas De Marchi
Synchronize with i915 the PVC gt workarounds as of committ commit 4d14d7717f19 ("drm/i915/selftest: Fix ktime_get() and h/w access order"). v2: Add masked flag to XEHPC_LNCFMISCCFGREG0 (Matt Roper) Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://lore.kernel.org/r/20230314003012.2600353-7-lucas.demarchi@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
generated by cgit (git 2.34.1) at 2025-09-15 08:13:13 +0000