aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2023-12-21drm/xe/mmio: update gt_count when probing multi-tileMatthew Auld1-0/+6
It looks like the single-tile PVC in CI dies during module load when doing the pcode init. From the logs we try to access the address 0000000000138124 which doesn't map to anything, however 0x138124 also looks to be the PCODE_MAILBOX register. So looks like the per-tile mmio register mapping is NULL. During probe the tile count is potentially trimmed, since we don't know the real count until we actually probe the device. This seems to be the case for single-tile PVC or similar devices. However it looks like the gt_count is never adjusted to respect this updated tile count. As a result when later doing some for_each_gt() loop, like we do for the pcode, we can get back some GT that maps to some non-existent tile which hasn't been properly set up, leading to crashes. Try to fix this by adjusting the gt_count after probing the tiles for real. v2: Fix typo so it actually builds References: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/383 Signed-off-by: Matthew Auld <[email protected]> Cc: Lucas De Marchi <[email protected]> Cc: Matt Roper <[email protected]> Reviewed-by: Ofir Bitton <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
2023-12-21drm/xe: handle TLB invalidations from CT fast-pathMatthew Auld3-60/+91
In various test cases that put the system under a heavy load, we can sometimes see errors with missed TLB invalidations. In such cases we see the interrupt arrive for the invalidation from the GuC, however the actual processing of the completion is pushed onto a workqueue and handled with all the other CT stuff, which might take longer than expected. Since we expect TLB invalidations to complete within a reasonable amount of time (at most ~250ms), and they do seem pretty critical, allow handling directly from the CT fast-path. v2 (José): - Actually use the correct spinlock/unlock_irq, since pending_lock is grabbed from IRQ. v3: - Don't publish the TLB fence on the list until after we fully initialize it and successfully do the CT send. The list is now only protected by the spin_lock pending_lock and we can't hold that across the entire TLB send operation. v4 (Matt Brost): - Be careful with racing against fast CT path writing the seqno, before we have actually published the fence. References: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/297 References: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/320 References: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/449 Signed-off-by: Matthew Auld <[email protected]> Cc: Matthew Brost <[email protected]> Cc: José Roberto de Souza <[email protected]> Reviewed-by: Matthew Brost <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
2023-12-21drm/xe/ct: update g2h outstanding for CTB captureMatthew Auld1-0/+1
Looks to always to be zero when inspecting the CTB dump. Signed-off-by: Matthew Auld <[email protected]> Cc: José Roberto de Souza <[email protected]> Cc: Rodrigo Vivi <[email protected]> Cc: Matthew Brost <[email protected]> Reviewed-by: Matthew Brost <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
2023-12-21drm/xe/tlb: print seqno_recv on fence TLB timeoutMatthew Auld1-2/+2
To help debugging, sample the current seqno_recv and dump it out if we encounter a TLB timeout for the fences path. Signed-off-by: Matthew Auld <[email protected]> Cc: Matthew Brost <[email protected]> Cc: José Roberto de Souza <[email protected]> Reviewed-by: Matthew Brost <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
2023-12-21drm/xe/tlb: also update seqno_recv during resetMatthew Auld1-2/+22
We might have various kworkers waiting for TLB flushes to complete which are not tracked with an explicit TLB fence, however at this stage that will never happen since the CT is already disabled, so make sure we signal them here under the assumption that we have completed a full GT reset. v2: - We need to use seqno - 1 here. After acquiring ct->lock the seqno is actually the next users seqno and not the pending one. Signed-off-by: Matthew Auld <[email protected]> Cc: Matthew Brost <[email protected]> Cc: José Roberto de Souza <[email protected]> Reviewed-by: Matthew Brost <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
2023-12-21drm/xe/gt: tweak placement for signalling TLB fences after GT resetMatthew Auld1-1/+2
Assumption here is that submission is disabled along with CT, and full GT reset will also nuke TLBs, so should be safe to signal all in-flight TLB fences, but only after the actual reset so move the placement slightly. Signed-off-by: Matthew Auld <[email protected]> Cc: Matthew Brost <[email protected]> Cc: José Roberto de Souza <[email protected]> Reviewed-by: Matthew Brost <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
2023-12-21drm/xe/ct: serialise fast_lock during CT disableMatthew Auld1-2/+6
The fast-path CT could be running as we enter a runtime-suspend or potentially a GT reset, however here we only use the ct->fast_lock and not the full ct->lock. Before disabling the CT, also serialise against the fast_lock to ensure any in-progress work finishes before we start nuking the CT related stuff. Once we disable ct->enabled and drop the lock, any new work should fail gracefully, and anything that was in progress should be finished. Signed-off-by: Matthew Auld <[email protected]> Cc: Matthew Brost <[email protected]> Cc: José Roberto de Souza <[email protected]> Reviewed-by: Matthew Brost <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
2023-12-21drm/xe/tlb: increment next seqno after successful CT sendMatthew Auld1-5/+6
If we are in the middle of a GT reset or similar the CT might be disabled, such that the CT send fails. However we already incremented gt->tlb_invalidation.seqno which might lead to warnings, since we effectively just skipped a seqno: 0000:00:02.0: drm_WARN_ON(expected_seqno != msg[0]) Signed-off-by: Matthew Auld <[email protected]> Cc: Matthew Brost <[email protected]> Cc: José Roberto de Souza <[email protected]> Reviewed-by: Matthew Brost <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
2023-12-21drm/xe/ct: hold fast_lock when reserving space for g2hMatthew Auld1-7/+15
Reserving and checking for space on the g2h side relies on the fast_lock, and not the CT lock since we need to release space from the fast CT path. Make sure we hold it when checking for space and reserving it. The main concern is calling __g2h_release_space() as we are reserving something and since the info.space and info.g2h_outstanding operations are not atomic we can get some nonsense values back. Signed-off-by: Matthew Auld <[email protected]> Cc: Matthew Brost <[email protected]> Cc: José Roberto de Souza <[email protected]> Reviewed-by: Matthew Brost <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
2023-12-21drm/xe: hold mem_access.ref for CT fast-pathMatthew Auld3-1/+10
Just checking xe_device_mem_access_ongoing() is not enough, we also need to hold the reference otherwise the ref can transition from 1 -> 0 as we enter g2h_read(), leading to warnings. While we can't do a full rpm sync in the IRQ, we can keep the device awake if the ref is non-zero. Introduce a new helper for this and set it to work in for the CT fast-path. Signed-off-by: Matthew Auld <[email protected]> Cc: Matthew Brost <[email protected]> Cc: José Roberto de Souza <[email protected]> Reviewed-by: Matthew Brost <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
2023-12-21drm/xe/tlb: ensure we access seqno_recv onceMatthew Auld1-6/+6
Ensure we load gt->tlb_invalidation.seqno_recv once, and use that for our seqno checking. The gt->tlb_invalidation_seqno_past is a shared global variable and can potentially change at any point here. However the checks here need to operate on a stable version of seqno_recv for this to make any sense. Signed-off-by: Matthew Auld <[email protected]> Cc: Matthew Brost <[email protected]> Cc: José Roberto de Souza <[email protected]> Reviewed-by: Matthew Brost <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
2023-12-21drm/xe/tlb: drop unnecessary smp_wmb()Matthew Auld1-1/+4
wake_up_all() and wait_event_timeout() already have the correct barriers as per https://www.kernel.org/doc/Documentation/memory-barriers.txt. This should ensure that the seqno_recv write can't be re-ordered wrt to the actual wake_up_all() i.e we get woken up but there is no write. The reader side with wait_event_timeout() also has the correct barriers. With that drop the hand rolled smp_wmb(), which is anyway missing some kind of matching barrier on the reader side. Signed-off-by: Matthew Auld <[email protected]> Cc: Matthew Brost <[email protected]> Cc: José Roberto de Souza <[email protected]> Reviewed-by: Matthew Brost <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
2023-12-21drm/xe: Port Xe to GPUVAMatthew Brost14-1177/+1175
Rather than open coding VM binds and VMA tracking, use the GPUVA library. GPUVA provides a common infrastructure for VM binds to use mmap / munmap semantics and support for VK sparse bindings. The concepts are: 1) xe_vm inherits from drm_gpuva_manager 2) xe_vma inherits from drm_gpuva 3) xe_vma_op inherits from drm_gpuva_op 4) VM bind operations (MAP, UNMAP, PREFETCH, UNMAP_ALL) call into the GPUVA code to generate an VMA operations list which is parsed, committed, and executed. v2 (CI): Add break after default in case statement. v3: Rebase v4: Fix some error handling v5: Use unlocked version VMA in error paths v6: Rebase, address some review feedback mainly Thomas H v7: Fix compile error in xe_vma_op_unwind, address checkpatch Signed-off-by: Matthew Brost <[email protected]> Reviewed-by: Thomas Hellström <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
2023-12-21drm/xe: Remove __xe_vm_bind forward declarationMatthew Brost1-5/+0
Not needed so remove it. Reviewed-by: Thomas Hellström <[email protected]> Signed-off-by: Matthew Brost <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
2023-12-21drm/xe: Add helpers to hide struct xe_vma internalsMatthew Brost9-165/+211
This will help with the GPUVA port as the internals of struct xe_vma will change. v2: Update comment around helpers Reviewed-by: Thomas Hellström <[email protected]> Signed-off-by: Matthew Brost <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
2023-12-21drm/xe: Ban a VM if rebind worker hits an errorMatthew Brost7-46/+107
We cannot recover a VM if a rebind worker hits an error, ban the VM if happens to ensure we do not attempt to place this VM on the hardware again. A follow up will inform the user if this happens. v2: Return -ECANCELED in exec VM closed or banned, check for closed or banned within VM lock. v3: Fix lockdep splat by looking engine outside of vm->lock v4: Fix error path when engine lookup fails v5: Add debug message in rebind worker on error, update comments wrt locking, add xe_vm_close helper Reviewed-by: Thomas Hellström <[email protected]> Signed-off-by: Matthew Brost <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
2023-12-21drm/xe: Use internal VM flags in xe_vm_createMatthew Brost1-2/+2
xe_vm_create used the IOCTL create flags in a few places rather than the internal VM flags and this just happened to work as these values matched. This is risky (and incorrect) as the internal flag values are free to change. Fix this and use the internal VM flag values. Signed-off-by: Matthew Brost <[email protected]> Reviewed-by: Matthew Auld <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
2023-12-21drm/xe: make kobject type struct as constantTejas Upadhyay1-1/+1
Since commit ee6d3dd4ed48 ("driver core: make kobj_type constant.") the driver core allows the usage of const struct kobj_type. Take advantage of this to constify the structure definition to prevent modification at runtime. Reviewed-by: Nirmoy Das <[email protected]> Signed-off-by: Tejas Upadhyay <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
2023-12-21drm/xe: make GT sysfs init return voidTejas Upadhyay2-10/+15
Currently return from xe_gt_sysfs_init() is ignored and also a failure in xe_gt_sysfs_init() isn't fatal so make it return void. V2 : - add drm_warn in error paths - Himal - Edit commit message - Nirmoy Acked-by: Ashutosh Dixit <[email protected]> Reviewed-by: Himal Prasad Ghimiray <[email protected]> Reviewed-by: Nirmoy Das <[email protected]> Signed-off-by: Tejas Upadhyay <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
2023-12-21drm/xe/guc: Fix h2g_write usage of GUC_CTB_MSG_MAX_LENAlan Previn1-13/+19
In the ABI header, GUC_CTB_MSG_MIN_LEN is '1' because GUC_CTB_HDR_LEN is 1. This aligns with H2G/G2H CTB specification where all command formats are defined in units of dwords so that '1' is a dword. Accordingly, GUC_CTB_MSG_MAX_LEN is 256-1 (i.e. 255 dwords). However, h2g_write was incorrectly assuming that GUC_CTB_MSG_MAX_LEN was in bytes. Fix this. v3: Fix nit on #define location.(Matt) v2: By correctly treating GUC_CTB_MSG_MAX_LEN as dwords, it causes a local array to consume 4x the stack size. Rework the function to avoid consuming stack even if the action size is large. (Matt) Signed-off-by: Alan Previn <[email protected]> Reviewed-by: Matthew Brost <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
2023-12-21drm/xe/mmio: add xe_mmio_read16()Jani Nikula1-0/+10
Little by little, make stuff feature complete. Signed-off-by: Jani Nikula <[email protected]> Reviewed-by: Lucas De Marchi <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
2023-12-21drm/xe: Make page-table updates using the default engine happen in orderThomas Hellström1-1/+2
If the default engine m->eng was used, there is no check for idle and a cpu page-table update may thus happen in parallel with a gpu one. Don't allow CPU page-table updates with the default engine until the engine is idle. Signed-off-by: Thomas Hellström <[email protected]> Reviewed-by: Matthew Brost <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Rodrigo Vivi <[email protected]>
2023-12-21drm/xe: Enable PCI device earlierMatt Roper1-11/+11
Newer Intel platforms require that inspect the contents of the GMD_ID registers very early in the driver initialization process to determine the IP version (and proper init sequences), of the platform. Move the general PCI device setup and enablement slightly earlier, before we start trying to peek at the GMD_ID registers. Reviewed-by: Gustavo Sousa <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Matt Roper <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
2023-12-21drm/xe: Print proper revid value for unknown media revisionMatt Roper1-1/+1
If the GMD_ID register reports a higher media revision ID than we're expecting, print the media revid, not the graphics revid, in the debug message. Reviewed-by: Gustavo Sousa <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Matt Roper <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
2023-12-21drm/xe: Don't raise error on fused-off mediaMatt Roper1-0/+4
It's legitimate for the media GMD_ID register to read back as 0x0 if media functionality is fused off or otherwise not present on the platform. Avoid printing an "unknown media version" error message for this case. Reviewed-by: Gustavo Sousa <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Matt Roper <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
2023-12-21drm/xe: Return GMD_ID revid properlyMatt Roper1-10/+13
peek_gmdid() returns the IP version, not the raw value of the GMD_ID register. Make sure we extract and return the rev_id field as well so that it can be used to determine the IP steppings properly. Reviewed-by: Lucas De Marchi <[email protected]> Reviewed-by: Gustavo Sousa <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Matt Roper <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
2023-12-21drm/xe: Make usable size of VRAM readableTejas Upadhyay6-10/+18
Current size member of vram struct does not give complete information as what "size" contains. Does it contain reserved portions or not. Name it usable size and accordingly describe other size members as well. Reviewed-by: Matthew Brost <[email protected]> Reviewed-by: Lucas De Marchi <[email protected]> Signed-off-by: Tejas Upadhyay <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
2023-12-21drm/xe: Add sysfs entry to report per tile memory sizeTejas Upadhyay3-0/+25
Add sysfs entry to read per tile physical memory including stolen memory. V5: - rename var name and make it part of vram struct - Lucas V4: - %s/addr_range/physical_vram_size_byes, make it user readable name - Joonas/Aravind - Display in bytes - Joonas/Aravind V3: - Exclude DG1, replace sysfs_create_file/files - Aravind V2: - Use DEVICE_ATTR_RO - Aravind - Dont put kobj on sysfs_file_create fail - Himal - Skip addr_range sysfs create for non dgfx - Himal Reviewed-by: Aravind Iddamsetty <[email protected]> Signed-off-by: Tejas Upadhyay <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
2023-12-21drm/xe: Add GTs under respective tile sysfsTejas Upadhyay1-2/+2
With the separation of xe_tile and xe_gt, We now consider a PCI device (xe_device) to contain one or more tiles (struct xe_tile). Each tile will contain one or more GTs (struct xe_gt). So lets align sysfs paths accordingly. TODO: Currently we have gt0 under tile0 and gt1 under tile1 on multi-tile. This GT indexing still under discussion, when it is concluded we need to revisit this change. Reviewed-by: Aravind Iddamsetty <[email protected]> Signed-off-by: Tejas Upadhyay <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
2023-12-21drm/xe: Add sysfs entry for tileTejas Upadhyay7-0/+114
We have recently introduced tile for each gpu, so lets add sysfs entry per tile for userspace to provide required information specific to tile. V5: - define ktype as const V4: - Reorder headers - Aravind V3: - Make API to return void and add drm_warn - Aravind V2: - Add logs in failure path Reviewed-by: Aravind Iddamsetty <[email protected]> Signed-off-by: Tejas Upadhyay <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
2023-12-21drm/xe: Use nanoseconds instead of jiffies in uapi for user fenceZbigniew Kempczyński2-12/+51
Using jiffies as a timeout from userspace is weird even if theoretically exists possiblity of acquiring jiffies via getconf. Unfortunately this method is unreliable and the returned value may vary from the one configured in the kernel config. Now timeout is expressed in nanoseconds and its interpretation depends on setting DRM_XE_UFENCE_WAIT_ABSTIME flag. Relative timeout (flag is not set) means fence expire at now() + timeout. Absolute timeout (flag is set) means that the fence expires at exact point of time. Passing negative timeout means we will wait "forever" by setting wait time to MAX_SCHEDULE_TIMEOUT. Cc: Andi Shyti <[email protected]> Reviewed-by: Andi Shyti <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Zbigniew Kempczyński <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
2023-12-21drm/xe: properly check bounds for xe_wait_user_fence_ioctl()Paulo Zanoni1-0/+3
If !no_engines, then we use copy_from_user to copy to the 'eci' array, which has XE_HW_ENGINE_MAX_INSTANCE members. The amount of members copied is given by the user in args->num_engines, so add code to check that args->num_engines does not exceed XE_HW_ENGINE_MAX_INSTANCE. It's an unsigned value so there's no need to check for negative values. Fixes error messages such as: Buffer overflow detected (54 < 18446744073709551520)! Reviewed-by: José Roberto de Souza <[email protected]> Signed-off-by: Paulo Zanoni <[email protected]> Reviewed-by: Lucas De Marchi <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Lucas De Marchi <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
2023-12-21drm/xe: fix bounds checking for 'len' in xe_engine_create_ioctlPaulo Zanoni1-1/+1
There's this shared machine running xe.ko and I often log in to see my tmux corrupted by messages such as: usercopy: Kernel memory overwrite attempt detected to wrapped address (offset 0, size 18446660151965198754)! I also sometimes see: kernel BUG at mm/usercopy.c:102! Someone is running a program that's definitely submitting random numbers to this ioctl. If you pass width=65535 and num_placements=32769 then you get a negative 'len', which avoids the EINVAL check, leading to the bug. Switch 'len' to u32. It is the result of the multiplication of two u16 numbers, so it won't be able to overflow back into smaller numbers as an u32. v2: Make len u32 instead of checking for <=0 (José). Signed-off-by: Paulo Zanoni <[email protected]> Reviewed-by: José Roberto de Souza <[email protected]> Reviewed-by: Matthew Brost <[email protected]> Reviewed-by: Lucas De Marchi <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Lucas De Marchi <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
2023-12-21drm/xe/slpc: Start SLPC before GuC submission on resetDaniele Ceraolo Spurio1-5/+1
The SLPC code has a strict 5ms timeout from when the start command is queued to when we expect the reply to appear in memory. This works if the CT channel is empty, but if the channel is busy there might be an extra delay that causes the process to exceeded the timeout. We see this issue when a reset occurs while userspace keeps submitting, because the submission code is re-enabled first and it will start using the channel to service those submissions. To fix this, we can simply start SLPC before re-enabling submission. This has also the benefit of not allowing submissions to go through with an uninitialized SLPC. Link: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/375 Signed-off-by: Daniele Ceraolo Spurio <[email protected]> Cc: Vinay Belgaumkar <[email protected]> Cc: Matthew Brost <[email protected]> Reviewed-by: Vinay Belgaumkar <[email protected]> Reviewed-by: Matthew Brost <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Rodrigo Vivi <[email protected]>
2023-12-21drm/xe: fix HuC FW ordering for DG1Daniele Ceraolo Spurio1-1/+1
The firmware definitions must be ordered based on platform, from newer to older, which means that the DG1 FW must come before the ADL one. Link: https://gitlab.freedesktop.org/drm/intel/-/issues/8699 Signed-off-by: Daniele Ceraolo Spurio <[email protected]> Reviewed-by: Matthew Brost <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Rodrigo Vivi <[email protected]>
2023-12-21drm/xe: Add missing ADL entries to xe_test_waAnusha Srivatsa1-0/+3
With the fake device creation fix in the previous patch, adding Alderlake P platform in xe_wa_test. With this, driver is able to run the kunit test for ADLP properly. Cc: Lucas De Marchi <[email protected]> Signed-off-by: Anusha Srivatsa <[email protected]> Reviewed-by: Lucas De Marchi <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Lucas De Marchi <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
2023-12-21drm/xe/kunit: Handle fake device creation for all platform/subplatform casesAnusha Srivatsa1-3/+0
For platform like Alderlake P there are subplatforms and just Alderlake P. Unlike DG2 in which every flavour is either a G10,G11 or G12 variant. In this case(Alderlake P/S), the Kunit test evaluates the subplatform to NONE and is unable to create a fake device. Removing the condition in xe_pci_fake_device_init() to support this corner case so driver can proceed with the unit testing. Cc: Lucas De Marchi <[email protected]> Signed-off-by: Anusha Srivatsa <[email protected]> Reviewed-by: Lucas De Marchi <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Lucas De Marchi <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
2023-12-21drm/xe/pm: Disable PM on unbounded pcie parent bridgeAnshuman Gupta3-0/+16
Intel Discrete GFX cards gfx may have multiple PCIe endpoints, they connects to root port via pcie upstream switch port(USP) and virtual pcie switch port(VSP), sometimes VSP pcie devices doesn't bind to pcieport driver. Without pcieport driver, pcie PM comes without any warranty and with unbounded VSP gfx card won't transition to low power pcie Device and Link states therefore assert drm_warn on unbounded VSP and disable xe driver PM support. v2: - Disable Xe PCI PM support. [Rodrigo] v3: - Changed subject and Rebase. v4: - %s/xe_pci_unbounded_bridge_disable_pm/xe_assert_on_unbounded_bridge. [Rodrigo] - Use device_set_pm_not_required() instead of dev_pm_ops NULL assignment. Cc: Rodrigo Vivi <[email protected]> Signed-off-by: Anshuman Gupta <[email protected]> Reviewed-by: Rodrigo Vivi <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Rodrigo Vivi <[email protected]>
2023-12-21drm/xe: Fix vm refcount racesThomas Hellström1-14/+12
Fix a race in xe_vm_lookup() where the vm could disappear after the lookup mutex unlock but before the get. The xe_vm_get() call must be inside the lookup mutex. Also fix a vm close race where multiple callers could potentially succeed in calling xe_vm_close_and_put(). Reported-by: Oded Gabbay <[email protected]> Link: https://lists.freedesktop.org/archives/intel-xe/2023-May/004704.html Signed-off-by: Thomas Hellström <[email protected]> Reviewed-by: Matthew Brost <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Rodrigo Vivi <[email protected]>
2023-12-21drm/xe/bo: Evict VRAM to TT rather than to systemThomas Hellström3-11/+22
The main difference is that we don't bounce and sync on eviction, allowing for pipelined eviction. Moving forward we also need to be careful with dma mappings which can be released in SYSTEM but may remain in TT. v2: - Remove a stale comment (Matthew Brost) Signed-off-by: Thomas Hellström <[email protected]> Reviewed-by: Matthew Brost <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Rodrigo Vivi <[email protected]>
2023-12-21drm/xe/bo: Gracefully handle errors from ttm_bo_move_accel_cleanup().Thomas Hellström1-0/+5
The function ttm_bo_move_accel_cleanup() attempts to help pipeline a move, and in doing so, needs memory allocations which may fail. Rather than failing in a state where the new resource may freed while accessed by the copy engine, sync uninterruptible and do a failsafe cleanup. v2: - Don't try to attach the signaled fence on ttm_bo_move_accel_cleanup() error. Signed-off-by: Thomas Hellström <[email protected]> Reviewed-by: Matthew Auld <[email protected]> Reviewed-by: Matthew Brost <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Rodrigo Vivi <[email protected]>
2023-12-21drm/xe/bo: Avoid creating a system resource when allocating a fresh VRAM boThomas Hellström1-21/+27
When creating a new bo, on the first move the bo->resource is typically NULL. Our move callback rejected that instructing TTM to create a system resource. In addition a struct ttm_tt with a page-vector was created, although not populated with pages. Similarly when the clearing of VRAM was complete, the system resource was put on a ghost object and freed using the TTM delayed destroy mechanism. This is a lot of pointless work. So avoid creating the system resource and instead change the code to cope with a NULL bo->resource. v2: - Add some code comments (Matthew Brost) v3: - Fix a dereference of old_mem which might be NULL. Signed-off-by: Thomas Hellström <[email protected]> Reviewed-by: Matthew Auld <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Rodrigo Vivi <[email protected]>
2023-12-21drm/xe/bo: Fix swapin when moving to VRAMThomas Hellström1-2/+5
When a source system resource had been swapped out, we incorrectly assumed that we were lacking source data for a move and therefore cleared the destination instead of swapping in and copying the swapped-out data. Fix this. Signed-off-by: Thomas Hellström <[email protected]> Reviewed-by: Matthew Brost <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Rodrigo Vivi <[email protected]>
2023-12-21drm/xe/mtl: Add support to get C6 residency/status of MTLBadal Nilawar4-17/+52
Add the registers to get C6 residency of MTL SAMedia and C6 status of MTL gts v2: - move register definitions to regs header (Anshuman) - correct reg definition for mtl rc status - make idle_status function common (Badal) v3: - remove extra line in commit message - use only media type check in initialization - use graphics ver check (Anshuman) v4: - remove extra lines (Anshuman) Bspec: 66300 Signed-off-by: Badal Nilawar <[email protected]> Signed-off-by: Riana Tauro <[email protected]> Reviewed-by: Andi Shyti <[email protected]> Reviewed-by: Anshuman Gupta <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
2023-12-21drm/xe: add a new sysfs directory for gtidle propertiesRiana Tauro8-29/+239
1) Add a new sysfs directory under devices/gt#/ called gtidle to contain idle properties of GT such as name, idle_status, idle_residency_ms 2) Remove forcewake calls for residency counter v2: - abstract using function pointers (Anshuman) - remove forcewake calls for residency counter - use device_attr (Badal) - move rc functions to guc_pc - change name to gt_idle (Rodrigo) v3: - return error for drmm_add_action_or_reset - replace file and functions with gt_idle prefix to gt_idle_sysfs (Himal) - use enum for gt idle state - move multiplier to gt idle and initialize (Anshuman) - correct doc annotation (Rodrigo) - remove return variable - use kobj_gt instead of new gtidle kobj - move residency_ms to gtidle file - retain xe_guc_pc prefix for functions in guc_rc file (Michal) v4: - fix doc errors in xe_guc_pc file - change u64 to u32 for reading residency counter - keep gtidle states generic GT_IDLE_C[0/6] (Anshuman) v5: - update commit message to include removal of forcewake calls (Anshuman) - return void from sysfs initialization function and add warnings (Andi) v6: - remove extra lines (Anshuman) Signed-off-by: Riana Tauro <[email protected]> Acked-by: Rodrigo Vivi <[email protected]> Reviewed-by: Anshuman Gupta <[email protected]> Reviewed-by: Andi Shyti <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
2023-12-21drm/xe/bo: consider bo->flags in xe_bo_migrate()Matthew Auld1-0/+13
For VRAM allocations the bo->flags can control some characteristics of the underlying memory, like whether it needs to be contiguous, and in the future whether it needs to be in the CPU visible portion. Rather use add_vram() in xe_bo_migrate() which should take care of such things for us. Signed-off-by: Matthew Auld <[email protected]> Cc: Thomas Hellström <[email protected]> Cc: José Roberto de Souza <[email protected]> Reviewed-by: José Roberto de Souza <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
2023-12-21drm/doc: include xe_drm.hMatthew Auld1-0/+5
Make sure the uapi gets picked up by the normal docs build. Signed-off-by: Matthew Auld <[email protected]> Cc: Francois Dugast <[email protected]> Cc: Lucas De Marchi <[email protected]> Reviewed-by: Francois Dugast <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
2023-12-21drm/xe/uapi: silence kernel-doc errorsMatthew Auld1-4/+7
./include/uapi/drm/xe_drm.h:263: warning: Function parameter or member 'gts' not described in 'drm_xe_query_gts' ./include/uapi/drm/xe_drm.h:854: WARNING: Inline emphasis start-string without end-string. With the idea to also include the uapi file in the pre-merge CI hooks when building the kernel-doc, so first make sure it's clean: https://gitlab.freedesktop.org/drm/xe/ci/-/merge_requests/16 v2: (Francois) - It makes more sense to just fix the kernel-doc for 'gts' Signed-off-by: Matthew Auld <[email protected]> Cc: Francois Dugast <[email protected]> Cc: Lucas De Marchi <[email protected]> Reviewed-by: Francois Dugast <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
2023-12-21drm/xe/uapi: add some kernel-doc for region queryMatthew Auld1-15/+71
Since we need to extend this, we should also take the time to add some basic kernel-doc here for the existing bits. Note that this is all still subject to change when upstreaming. Also convert XE_MEM_REGION_CLASS_* into an enum, so we can more easily create links to it from other parts of the uapi. Suggested-by: Gwan-gyeong Mun <[email protected]> Signed-off-by: Matthew Auld <[email protected]> Cc: Maarten Lankhorst <[email protected]> Cc: Thomas Hellström <[email protected]> Cc: Lucas De Marchi <[email protected]> Cc: José Roberto de Souza <[email protected]> Cc: Filip Hazubski <[email protected]> Cc: Carl Zhang <[email protected]> Cc: Effie Yu <[email protected]> Reviewed-by: Gwan-gyeong Mun <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
2023-12-21drm/xe/uapi: restrict system wide accountingMatthew Auld1-3/+9
Since this is considered an info leak (system wide accounting), rather hide behind perfmon_capable(). v2: - Without perfmon_capable() it likely makes more sense to report as zero, instead of reporting as used == total size. This should give similar behaviour as i915 which rather tracks free instead of used. Signed-off-by: Matthew Auld <[email protected]> Cc: Maarten Lankhorst <[email protected]> Cc: Thomas Hellström <[email protected]> Cc: Gwan-gyeong Mun <[email protected]> Cc: Lucas De Marchi <[email protected]> Cc: José Roberto de Souza <[email protected]> Cc: Filip Hazubski <[email protected]> Cc: Carl Zhang <[email protected]> Cc: Effie Yu <[email protected]> Cc: Gwan-gyeong Mun <[email protected]> Reviewed-by: José Roberto de Souza <[email protected]> Reviewed-by: Gwan-gyeong Mun <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.