- 19 Dec, 2023 40 commits
-
-
Matt Roper authored
Although our only multi-tile platform today (PVC) doesn't support display, it's possible that some future multi-tile platform will. If/when this happens, display interrupts (both traditional display and ASLE backlight interrupts raised as a Gunit interrupt) should be delivered to the primary tile. Save away tile0's master_ctl value so that it can still be used for display interrupt handling after the GT loop. Reviewed-by:
Lucas De Marchi <lucas.demarchi@intel.com> Link: https://lore.kernel.org/r/20230401002106.588656-9-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
Although the hardware team has set aside some register bits for extra media engines, no platform supported by the Xe driver today has VCS4-7 or VECS2-3. Drop the corresponding code (which was already commented out); we can bring it back easily enough if such engines show up on a future platform. Reviewed-by:
-
Matt Roper authored
The remaining "gen11_*" IRQ functions are common to all platforms supported by the Xe driver. Drop the unnecessary prefix. Reviewed-by:
-
Matt Roper authored
Platforms supported by the Xe driver handle top-level interrupts in one of two ways: - Xe_LP platforms only have a "graphics master" register and lack a "master tile" register, so top-level interrupt detection and enable/disable happens in the graphics master. - Xe_LP+ (aka DG1) and beyond have a "master tile" interrupt register that controls the enable/disable of top-level interrupts and must also be consulted to determine which tiles have received interrupts before the driver moves on the process the graphics master register. For functions that are only relevant to the first set of platforms, rename the function prefix to Xe_LP since "gen11" doesn't make sense in the Xe driver. Also add some comments briefly describing the two top-level handlers. Reviewed-by:
-
Matt Roper authored
Any interrupt registers that were introduced by platforms i915 considered to be "gen11" or "gen12" are present on all platforms that the Xe driver supports; drop the unnecessary prefixes. While working in the area, also convert a few open-coded bit manipulations over to REG_BIT and REG_FIELD_GET notation. Cc: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by:
-
Matt Roper authored
It's no longer necessary to wrap these operations in macros; a simple function will suffice. Also switch to function names that more clearly describe what operation is being performed: unmask_and_enable() and mask_and_disable(). Reviewed-by:
-
Matt Roper authored
For cases where IRQ_INIT and IRQ_RESET are used, the relevant interrupt registers are always consecutive and ordered ISR, IMR, IIR, IER. Adding helpers to look these up from a base offset will let us eliminate some of the CPP pasting and simplify other upcoming patches. v2: - s/_REGS/_OFFSET/ for consistency. (Lucas) - Move IMR/IIR/IER helpers into xe_irq.c; they aren't needed anywhere else. (Lucas) Cc: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by:
-
Matt Roper authored
"Gen" terminology should be avoided in the Xe driver and "gen3" refers to platforms that are 9 (!!) graphics generations earlier than the oldest supported by the Xe driver, so this prefix really doesn't make sense. Reviewed-by:
-
Chang, Bruce authored
Currently, unload pvc driver will generate a null dereference and the call stack is as below. [ 4850.618000] Call Trace: [ 4850.620740] <TASK> [ 4850.623134] ttm_bo_cleanup_memtype_use+0x3f/0x50 [ttm] [ 4850.628661] ttm_bo_release+0x154/0x2c0 [ttm] [ 4850.633317] ? drm_buddy_fini+0x62/0x80 [drm_buddy] [ 4850.638487] ? __kmem_cache_free+0x27d/0x2c0 [ 4850.643054] ttm_bo_put+0x38/0x60 [ttm] [ 4850.647190] xe_gem_object_free+0x1f/0x30 [xe] [ 4850.651945] drm_gem_object_free+0x1e/0x30 [drm] [ 4850.656904] ggtt_fini_noalloc+0x9d/0xe0 [xe] [ 4850.661574] drm_managed_release+0xb5/0x150 [drm] [ 4850.666617] drm_dev_release+0x30/0x50 [drm] [ 4850.671209] devm_drm_dev_init_release+0x3c/0x60 [drm] There are a couple issues, but the main one is due to TTM has only one TTM_PL_TT region, but since pvc has 2 tiles and tries to setup 1 TTM_PL_TT each tile. The second will overwrite the first one. During unload time, the first tile will reset the TTM_PL_TT manger and when the second tile is trying to free Bo and it will generate the null reference since the TTM manage is already got reset to 0. The fix is to use one global TTM_PL_TT manager. v2: make gtt mgr global and change the name to sys_mgr Cc: Stuart Summers <stuart.summers@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Vivi, Rodrigo <rodrigo.vivi@intel.com> Signed-off-by:
Bruce Chang <yu.bruce.chang@intel.com> Reviewed-by:
Matthew Brost <matthew.brost@intel.com> Signed-off-by:
-
Lucas De Marchi authored
Platform order in enum xe_platform started to be used by some parts of the code, like the GuC/HuC firmware loading logic. The order itself is not very important, but it's better to follow a convention: as was documented in the comment above the enum, reorder the platforms by graphics version. While at it, remove the gen terminology. v2: - Use "graphics version" instead of chronological order (Matt Roper) - Also change pciidlist to follow the same order - Remove "gen" from comments around enum xe_platform Signed-off-by:
-
Niranjana Vishwanathapura authored
In xe_migrate functions, use proper vram io offset of the tiles while calculating addresses. Reviewed-by:
Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com> Signed-off-by:
-
Niranjana Vishwanathapura authored
In xe_migrate_sanity_kunit test, use correct expected value as the expected value was not only used for the xe_migrate_clear(), but also for the xe_migrate_copy() operation. v2: Add 'Fixes' tag and update commit text Fixes: 11a2407e ("drm/xe: Stop accepting value in xe_migrate_clear") Reviewed-by:
-
Niranjana Vishwanathapura authored
In xe_migrate_sanity_kunit test, use proper batch base address by considering usm case. Reviewed-by:
-
Lucas De Marchi authored
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: -
Matt Roper authored
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.comSigned-off-by:
José Roberto de Souza <jose.souza@intel.com> Signed-off-by:
-
Matt Roper authored
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.comSigned-off-by:
-
Matt Roper authored
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.comSigned-off-by:
-
Matthew Brost authored
Add some error messages describing the problem when xe_gt_record_default_lrcs fails. Signed-off-by:
-
Chang, Bruce authored
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:
-
Matt Roper authored
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.comSigned-off-by:
-
Matthew Auld authored
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:
Matthew Auld <matthew.auld@intel.com> Reviewed-by:
Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Signed-off-by:
-
Matthew Auld authored
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:
-
Matt Roper authored
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:
-
Matt Roper authored
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:
-
Matt Roper authored
Replace the deprecated "GEN" terminology in the PAT definitions. Acked-by:
-
Matt Roper authored
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:
-
Matt Roper authored
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:
-
Matt Roper authored
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:
-
Matthew Brost authored
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:
-
José Roberto de Souza authored
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:
-
Anusha Srivatsa authored
Alderlake S uses TGL HuC. Signed-off-by:
Anusha Srivatsa <anusha.srivatsa@intel.com> Reviewed-by:
-
Anusha Srivatsa authored
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:
-
Matthew Brost authored
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:
Brian Welty <brian.welty@intel.com> Signed-off-by:
-
Matthew Brost authored
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 Auld authored
Make sure we pass along the correct errors. Signed-off-by:
-
Matthew Brost authored
Render / compute engines have additional caches (not just TLBs) that need to be invalidated each batch, reinstate these invalidations in ring ops. Reviewed-by:
-
Maarten Lankhorst authored
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:
-
Matthew Brost authored
Zero-length arrays as fake flexible arrays are deprecated and we are moving towards adopting C99 flexible-array members instead. Reviewed-by:
-
Matthew Auld authored
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 authored
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:
-
