aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2023-12-21drm/xe/display: Add i915_gem.h compatibility headerJouni Högander2-0/+10
Add i915_gem.h compatibility header and include it in i915_drv.h. Add empty GEM_BUG_ON definition for fbc code. Signed-off-by: Jouni Högander <[email protected]> Reviewed-by: Maarten Lankhorst <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
2023-12-21drm/xe/display: Xe stolen memory handling for fbc supportJouni Högander2-0/+80
Add Xe stolen memory handling for fbc. v3: - v2: Add parenthesis around parameter in i915_gem_stolen_node_allocated v2: - define i915_gem_stolen_area_address/size as !WARN_ON(1) - squash common type addition into this patch Signed-off-by: Jouni Högander <[email protected]> Signed-off-by: Maarten Lankhorst <[email protected]> Reviewed-by: Maarten Lankhorst <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
2023-12-21drm/xe/display: Add empty define for i915_ggtt_clear_scanoutJouni Högander1-0/+1
Add empty define for i915_ggtt_clear_scanout to avoid build failure. Signed-off-by: Jouni Högander <[email protected]> Reviewed-by: Maarten Lankhorst <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
2023-12-21drm/xe/display: Add empty def for i915_gem_object_flush_if_displayJouni Högander1-0/+2
We don't need i915_gem_object_flush_if_display on Xe side. Add empty define to tackle compilation errors with display code where it's used. Signed-off-by: Jouni Högander <[email protected]> Reviewed-by: Maarten Lankhorst <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
2023-12-21drm/xe/display: Add i915_active.h compatibility headerJouni Högander1-0/+22
Add empty definitions for i915_active_init/fini to kill ifdefs from frontbuffer tracking code. Signed-off-by: Jouni Högander <[email protected]> Reviewed-by: Maarten Lankhorst <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
2023-12-21drm/xe/display: Add frontbuffer setter/getter for xe_boJouni Högander1-0/+12
Xe is not carrying frontbuffer pointer in xe_bo. Define it's getter as NULL. Setter simply returns pointer which was provided as a parameter. v3: Do not take any references v2: Handle xe_bo_put as well Signed-off-by: Jouni Högander <[email protected]> Reviewed-by: Maarten Lankhorst <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
2023-12-21drm/xe/display: Add macro to get i915 device from xe_boJouni Högander1-0/+3
Add helper macro to kill couple of #ifdefs Signed-off-by: Jouni Högander <[email protected]> Reviewed-by: Maarten Lankhorst <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
2023-12-21drm/xe/display: Add struct i915_active for XeJouni Högander1-0/+13
Add empty definition for struct i915_active to kill ifdefs from frontbuffer tracking code. Signed-off-by: Jouni Högander <[email protected]> Reviewed-by: Maarten Lankhorst <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
2023-12-21drm/xe/display: Use acpi_target_system_state only if ACPI_SLEEP is enabledFrancois Dugast1-2/+11
This fixes the build error below with CONFIG_ACPI_SLEEP=n: drivers/gpu/drm/xe/xe_display.c:334:23: error: implicit declaration of function ‘acpi_target_system_state’; did you mean ‘acpi_get_system_info’? [-Werror=implicit-function-declaration] 334 | bool s2idle = acpi_target_system_state() < ACPI_STATE_S3; Signed-off-by: Francois Dugast <[email protected]> Reviewed-by: Rodrigo Vivi <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
2023-12-21drm/xe/display: fix error handling flow when device probing failsKoby Elbaz1-2/+2
Upon device probe failure, rolling back the initialization should be done in reversed order. Signed-off-by: Koby Elbaz <[email protected]> Reviewed-by: Ohad Sharabi <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
2023-12-21drm/xe/display: ensure clear-color surfaces are cpu mappableMatthew Auld1-0/+17
The KMD needs to access the clear-color value stored in the buffer via the CPU. On small-bar systems reject any buffers that are potentially not CPU accessible. 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]> Reviewed-by: José Roberto de Souza <[email protected]> Reviewed-by: Gwan-gyeong Mun <[email protected]> [ Split display-related changes from small-bar support ] Signed-off-by: Lucas De Marchi <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
2023-12-21drm/xe/display: Silence kernel-doc warnings related to displayLucas De Marchi1-0/+2
Add a "private:" comment to the part of the struct that is not expected to be documented, the one with display-related fields. This silence the following warnings: $ find drivers/gpu/drm/xe -name '*.[ch]' -not -path 'drivers/gpu/drm/xe/display/*' | xargs ./scripts/kernel-doc -Werror -none drivers/gpu/drm/xe/xe_device_types.h:316: warning: Function parameter or member 'display' not described in 'xe_device' drivers/gpu/drm/xe/xe_device_types.h:316: warning: Function parameter or member 'pch_type' not described in 'xe_device' drivers/gpu/drm/xe/xe_device_types.h:316: warning: Function parameter or member 'pch_id' not described in 'xe_device' drivers/gpu/drm/xe/xe_device_types.h:316: warning: Function parameter or member 'wm_lv_0_adjust_needed' not described in 'xe_device' drivers/gpu/drm/xe/xe_device_types.h:316: warning: Function parameter or member 'num_channels' not described in 'xe_device' drivers/gpu/drm/xe/xe_device_types.h:316: warning: Function parameter or member 'symmetric_memory' not described in 'xe_device' drivers/gpu/drm/xe/xe_device_types.h:316: warning: Function parameter or member 'type' not described in 'xe_device' drivers/gpu/drm/xe/xe_device_types.h:316: warning: Function parameter or member 'num_qgv_points' not described in 'xe_device' drivers/gpu/drm/xe/xe_device_types.h:316: warning: Function parameter or member 'num_psf_gv_points' not described in 'xe_device' drivers/gpu/drm/xe/xe_device_types.h:316: warning: Function parameter or member 'dram_info' not described in 'xe_device' drivers/gpu/drm/xe/xe_device_types.h:316: warning: Function parameter or member 'runtime_pm' not described in 'xe_device' drivers/gpu/drm/xe/xe_device_types.h:316: warning: Function parameter or member 'sb_lock' not described in 'xe_device' drivers/gpu/drm/xe/xe_device_types.h:316: warning: Function parameter or member 'skl_preferred_vco_freq' not described in 'xe_device' drivers/gpu/drm/xe/xe_device_types.h:316: warning: Function parameter or member 'max_dotclk_freq' not described in 'xe_device' drivers/gpu/drm/xe/xe_device_types.h:316: warning: Function parameter or member 'hti_state' not described in 'xe_device' drivers/gpu/drm/xe/xe_device_types.h:316: warning: Function parameter or member 'snps_phy_failed_calibration' not described in 'xe_device' drivers/gpu/drm/xe/xe_device_types.h:316: warning: Function parameter or member 'modeset_restore_state' not described in 'xe_device' drivers/gpu/drm/xe/xe_device_types.h:316: warning: Function parameter or member 'global_obj_list' not described in 'xe_device' drivers/gpu/drm/xe/xe_device_types.h:316: warning: Function parameter or member 'de_irq_mask' not described in 'xe_device' drivers/gpu/drm/xe/xe_device_types.h:316: warning: Function parameter or member 'display_irqs_enabled' not described in 'xe_device' drivers/gpu/drm/xe/xe_device_types.h:316: warning: Function parameter or member 'enabled_irq_mask' not described in 'xe_device' drivers/gpu/drm/xe/xe_device_types.h:316: warning: Function parameter or member 'params' not described in 'xe_device' 22 warnings as Errors Fixes: 44e694958b95 ("drm/xe/display: Implement display support") Signed-off-by: Lucas De Marchi <[email protected]> Acked-by: Jani Nikula <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Rodrigo Vivi <[email protected]>
2023-12-21drm/xe/display: Improve s2idle handling.Maarten Lankhorst3-14/+4
We accidentally always pass true as s2idle argument, instead of calculating it in the same way as i915. Suspend modes were removed to achieve compatibility with i915, but accidentally left in the source code. While at it, fix all other cases too, s2idle will go into a D1 state and setting a lower power state should be handled by PCI core. Maybe my laptop stops draining so much power during suspend now? I can only hope.. Signed-off-by: Maarten Lankhorst <[email protected]> Reviewed-by: Rodrigo Vivi <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
2023-12-21drm/xe/display: Implement display supportMaarten Lankhorst59-51/+2873
As for display, the intent is to share the display code with the i915 driver so that there is maximum reuse there. We do this by recompiling i915/display code twice. Now that i915 has been adapted to support the Xe build, we can add the xe/display support. This initial work is a collaboration of many people and unfortunately this squashed patch won't fully honor the proper credits. But let's try to add a few from the squashed patches: Co-developed-by: Matthew Brost <[email protected]> Co-developed-by: Jani Nikula <[email protected]> Co-developed-by: Lucas De Marchi <[email protected]> Co-developed-by: Matt Roper <[email protected]> Co-developed-by: Mauro Carvalho Chehab <[email protected]> Co-developed-by: Rodrigo Vivi <[email protected]> Co-developed-by: Dave Airlie <[email protected]> Signed-off-by: Maarten Lankhorst <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]> Signed-off-by: Lucas De Marchi <[email protected]>
2023-12-21drm/xe: Use pool of ordered wq for GuC submissionMatthew Brost2-4/+71
To appease lockdep, use a pool of ordered wq for GuC submission rather tha leaving the ordered wq allocation to the drm sched. Without this change eventually lockdep runs out of hash entries (MAX_LOCKDEP_CHAINS is exceeded) as each user allocated exec queue adds more hash table entries to lockdep. A pool old of 256 ordered wq should be enough to have similar behavior with and without lockdep enabled. Signed-off-by: Matthew Brost <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
2023-12-21drm/xe: Raise GT frequency before GuC/HuC loadVinay Belgaumkar4-2/+57
Starting GT freq is usually RPn. Raising freq to RP0 will help speed up GuC load times. As an example, this data was collected on DG2- GuC Load time @RPn ~ 41 ms GuC Load time @RP0 ~ 11 ms v2: Raise GT freq before hwconfig init. This will speed up both HuC and GuC loads. Address review comments (Rodrigo). Also add a small usleep after requesting frequency which gives pcode some time to react. v3: Address checkpatch issue Cc: Rodrigo Vivi <[email protected]> Reviewed-by: Rodrigo Vivi <[email protected]> Signed-off-by: Vinay Belgaumkar <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
2023-12-21drm/xe: Fix build with KUNIT=mLucas De Marchi1-1/+1
Due to the current integration between "live" xe kunit tests and kunit, it's not possible to have a build with the following combination: CONFIG_DRM_XE=y CONFIG_KUNIT=m ... even if kconfig doesn't block it. The reason for the failure is that some compilation units are pulled in xe.ko: drivers/gpu/drm/xe/xe_bo.c:#include "tests/xe_bo.c" drivers/gpu/drm/xe/xe_dma_buf.c:#include "tests/xe_dma_buf.c" drivers/gpu/drm/xe/xe_migrate.c:#include "tests/xe_migrate.c" drivers/gpu/drm/xe/xe_pci.c:#include "tests/xe_pci.c" Those files shouldn't use symbols from kunit, which should be reserved to the tests/*_test.c files. Detangling this dependency doesn't seem very straightforward, so fix the immediate issue instructing kconfig to block the problematic configuration. Reviewed-by: Rodrigo Vivi <[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: Drop EXECLIST_CONTROL from error state dumpMatt Roper2-6/+0
EXECLIST_CONTROL ($enginebase + 0x550) is a write-only register; we shouldn't be trying to read or report it as part of the device error state. Bspec: 45910, 60335 Cc: Rodrigo Vivi <[email protected]> Reviewed-by: Rodrigo Vivi <[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/tests: Fix migrate testPallavi Mishra1-1/+1
Pass a valid vm to xe_migrate_update_pgtables. Resolves NPD crash seen with igt@xe_live_ktest@migrate Reviewed-by: Brian Welty <[email protected]> Reviewed-by: Matthew Brost <[email protected]> Signed-off-by: Pallavi Mishra <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
2023-12-21drm/xe/gsc: enable pvc supportAlexander Usyskin3-1/+12
Configure and enable PVC HECI GSC support. Signed-off-by: Alexander Usyskin <[email protected]> Reviewed-by: Daniele Ceraolo Spurio <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
2023-12-21drm/xe: Add Wa_14019877138Haridhar Kalvala1-0/+4
Enable Force Dispatch Ends Collection for DG2. BSpec: 46001 Signed-off-by: Haridhar Kalvala <[email protected]> Reviewed-by: Matt Roper <[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: clear the serviced bits on INTR_IDENTITY_REGJonathan Cavitt1-1/+1
The spec for this register, like many other interrupt related ones, asks software to write back '1' to clear the serviced bits. Let's respect the spec. v2: - Update commit message - Add missing CC Signed-off-by: Jonathan Cavitt <[email protected]> CC: Daniele Spurio Ceraolo <[email protected]> CC: Lucas De Marchi <[email protected]> CC: Rodrigo Vivi <[email protected]> CC: Paulo Zanoni <[email protected]> Reviewed-by: Rodrigo Vivi <[email protected]> Signed-off-by: Lucas De Marchi <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
2023-12-21drm/xe: move the lmem verification code into a separate functionKoby Elbaz1-11/+21
If lmem (VRAM) is not fully initialized, the punit will power down the GT, which will prevent register access from the driver side. That code moved into a corresponding function (xe_verify_lmem_ready) to make the code clearer. Signed-off-by: Koby Elbaz <[email protected]> Reviewed-by: Lucas De Marchi <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Rodrigo Vivi <[email protected]>
2023-12-21drm/xe: Fix unbind of unaccessed VMA (fault mode)Brian Welty1-4/+4
In fault mode, page table binding is deferred until fault handler. Thus vma->tile_present will be unset unless the VMA is accessed by GPU. During a later unbind, the logic doesn't account for the fact that local fence variable will be NULL in this case, leading to pass NULL into dma_fence_add_callback() and causing few WARN_ONs to print to console. The fix is already present in the code, just hoist the fence variable computation to be done earlier. Resolves warnings seen with igt@xe_exec_fault_mode@once-invalid-fault Signed-off-by: Brian Welty <[email protected]> Reviewed-by: Matthew Brost <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
2023-12-21drm/xe/xelpmp: Add Wa_16021867713Gustavo Sousa2-0/+9
This workaround applies to all steppings of Xe_LPM+. Implement the KMD part. Reviewed-by: Matt Roper <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Gustavo Sousa <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
2023-12-21drm/xe: Update SPDX deprecated license identifierThomas Hellström5-5/+5
The "GPL-2.0" SPDX license identifier is deprecated. Update the code to use "GPL-2.0-only" instead. Choose this identifier over "GPL-2.0-or-later" since it's the most restrictive of the two and it's not fully clear that "GPL-2.0" also allows "GPL-2.0-or-later". Cc: Francois Dugast <[email protected]> Cc: Rodrigo Vivi <[email protected]> Signed-off-by: Thomas Hellström <[email protected]> Reviewed-by: Francois Dugast <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Rodrigo Vivi <[email protected]>
2023-12-21drm/xe: Fix pagefault and access counter worker functionsBrian Welty1-34/+48
When processing G2H messages for pagefault or access counters, we queue a work item and call queue_work(). This fails if the worker thread is already queued to run. The expectation is that the worker function will do more than process a single item and return. It needs to either process all pending items or requeue itself if items are pending. But requeuing will add latency and potential context switch can occur. We don't want to add unnecessary latency and so the worker should process as many faults as it can within a reasonable duration of time. We also do not want to hog the cpu core, so here we execute in a loop and requeue if still running after more than 20 ms. This seems reasonable framework and easy to tune this futher if needed. This resolves issues seen with several igt@xe_exec_fault_mode subtests where the GPU will hang when KMD ignores a pending pagefault. v2: requeue the worker instead of having an internal processing loop. v3: implement hybrid model of v1 and v2 now, run for 20 msec before we will requeue if still running v4: only requeue in worker if queue is non-empty (Matt B) Signed-off-by: Brian Welty <[email protected]> Reviewed-by: Matthew Brost <[email protected]> Reviewed-by: Stuart Summers <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
2023-12-21drm/xe: implement driver initiated function-resetAndrzej Hajda4-0/+90
Driver initiated function-reset (FLR) is the highest level of reset that we can trigger from within the driver. In contrast to PCI FLR it doesn't require re-enumeration of PCI BAR. It can be useful in case GT fails to reset. It is also the only way to trigger GSC reset from the driver and can be used in future addition of GSC support. v2: - use regs from xe_regs.h - move the flag to xe.mmio - call flr only on root gt - use BIOS protection check - copy/paste comments from i915 v3: - flr code moved to xe_device.c v4: - needs_flr_on_fini moved to xe_device Signed-off-by: Andrzej Hajda <[email protected]> Reviewed-by: Daniele Ceraolo Spurio <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
2023-12-21drm/xe: stringify the argument to avoid potential vulnerabilityCarlos Santa1-1/+1
This error gets printed inside a sandbox with warnings turned on. /mnt/host/source/src/third_party/kernel/v5.15/drivers/ gpu/drm/xe/xe_gt_idle_sysfs.c:87:26: error: format string is not a string literal (potentially insecure) [-Werror,-Wformat-security] return sysfs_emit(buff, gtidle->name); ^~~~~~~~~~~~ /mnt/host/source/src/third_party/kernel/v5.15/drivers/ gpu/drm/xe/xe_gt_idle_sysfs.c:87:26: note: treat the string as an argument to avoid this return sysfs_emit(buff, gtidle->name); ^ "%s", 1 error generated. CC: Rodrigo Vivi <[email protected]> Signed-off-by: Carlos Santa <[email protected]> Reviewed-by: Rodrigo Vivi <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
2023-12-21drm/xe: Add Wa_14019821291Matt Roper4-1/+29
This workaround is primarily implemented by the BIOS. However if the BIOS applies the workaround it will reserve a small piece of our DSM (which should be at the top, right below the WOPCM); we just need to keep that region reserved so that nothing else attempts to re-use it. v2 (Gustavo): - Check for NULL media_gt - Mask bits [5:0] to avoid potential issues in future platforms Signed-off-by: Matt Roper <[email protected]> Reviewed-by: Gustavo Sousa <[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/mtl: Use 16.67 Mhz freq scale factor to get rpXBadal Nilawar1-5/+5
For mtl and above 16.67 Mhz is the scale factor to calculate rpX frequencies. v2: Fix review comment (Ashutosh) Signed-off-by: Badal Nilawar <[email protected]> Reviewed-by: Ashutosh Dixit <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Rodrigo Vivi <[email protected]>
2023-12-21drm/xe/xe2: Program correct MOCS registersMatt Roper1-11/+13
The LNCFCMOCS registers no longer exist on Xe2 so there's no need to attempt to program them. Since GLOB_MOCS is the only set of MOCS registers now, it's expected to be used for all platforms (both igpu and dgpu) going forward, so adjust the MOCS programming flags accordingly. v2: - Fix typo (global mocs condition is >=, not >) Bspec: 71582 Reviewed-by: Pallavi Mishra <[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: Fix dequeue of access counter work itemBrian Welty1-2/+5
The access counters worker function is fixed to advance the head pointer when dequeuing from the acc_queue. This now matches the similar logic in get_pagefault(). Signed-off-by: Bruce Chang <[email protected]> Signed-off-by: Brian Welty <[email protected]> Reviewed-by: Stuart Summers <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
2023-12-21drm/xe: Adjust tile_present mask when skipping rebindsMatthew Brost1-2/+13
If a rebind is skipped the tile_present mask needs to be updated for the newly created vma to properly reflect the state of the vma. Reported-by: <[email protected]> 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: Dump CTB during TLB timeoutPallavi Mishra1-0/+2
Print CTB info during TLB invalidation timeout event. Reviewed-by: Matthew Brost <[email protected]> Signed-off-by: Pallavi Mishra <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
2023-12-21drm/xe: Replace usage of mem_type_to_tileBrian Welty1-25/+38
Currently mem_type_to_tile() is being used to access the tile's underlying tile.mem.vram. However, this function makes the assumption that a mem_type will only ever map to a single tile. Now that the TTM vram manager contains a pointer to the memory_region, make use of this in xe_bo.c. As such, introduce a helper function res_to_mem_region() to get the ttm_vram_mgr->vram from the BO's resource, and use this to replace usage of mem_type_to_tile(). xe_tile is still needed to choose the migration context, so this part is unchanged. But as this is only renaming usage, function is renamed now to mem_type_to_migrate(). Signed-off-by: Brian Welty <[email protected]> Reviewed-by: Matthew Brost <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
2023-12-21drm/xe: Remove unused xe_bo_to_tileBrian Welty2-15/+0
Unused and would like to remove the memtype_to_tile() which it calls. Signed-off-by: Brian Welty <[email protected]> Reviewed-by: Matthew Brost <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
2023-12-21drm/xe: Replace xe_ttm_vram_mgr.tile with xe_mem_regionBrian Welty2-7/+6
Replace the xe_ttm_vram_mgr.tile pointer with a xe_mem_region pointer instead. The former is currently unused. TTM VRAM regions are exposing device vram and is better to store a pointer directly to the xe_mem_region instead of the tile. This allows to cleanup unnecessary usage of xe_tile from xe_bo.c in later patch. Signed-off-by: Brian Welty <[email protected]> Reviewed-by: Matthew Brost <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
2023-12-21drm/xe/hwmon: Expose power1_max_intervalBadal Nilawar3-1/+169
Expose power1_max_interval, that is the tau corresponding to PL1, as a custom hwmon attribute. Some bit manipulation is needed because of the format of PKG_PWR_LIM_1_TIME in PACKAGE_RAPL_LIMIT register (1.x * power(2,y)) v2: Get rpm wake ref while accessing power1_max_interval v3: %s/hwmon/xe_hwmon/ v4: - As power1_max_interval is rw attr take lock in read function as well - Refine comment about val to fix point conversion (Andi) - Update kernel version and date in doc v5: Fix review comments (Anshuman) Acked-by: Rodrigo Vivi <[email protected]> Reviewed-by: Himal Prasad Ghimiray <[email protected]> Reviewed-by: Anshuman Gupta <[email protected]> Signed-off-by: Badal Nilawar <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Rodrigo Vivi <[email protected]>
2023-12-21drm/xe/hwmon: Protect hwmon rw attributes with hwmon_lockBadal Nilawar1-11/+24
Take hwmon_lock while accessing hwmon rw attributes. For readonly attributes its not required to take lock as reads are protected by sysfs layer and therefore sequential. Cc: Ashutosh Dixit <[email protected]> Cc: Anshuman Gupta <[email protected]> Signed-off-by: Badal Nilawar <[email protected]> Reviewed-by: Anshuman Gupta <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Rodrigo Vivi <[email protected]>
2023-12-21drm/xe/hwmon: Add kernel doc and refactor xe hwmonBadal Nilawar1-110/+91
Add kernel doc and refactor some of the hwmon functions, there is no functionality change. Cc: Anshuman Gupta <[email protected]> Cc: Ashutosh Dixit <[email protected]> Signed-off-by: Badal Nilawar <[email protected]> Reviewed-by: Anshuman Gupta <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Rodrigo Vivi <[email protected]>
2023-12-21drm/xe/bo: sync kernel fences for KMD buffersMatthew Auld1-0/+31
With things like pipelined evictions, VRAM pages can be marked as free and yet still have some active kernel fences, with the idea that the next caller to allocate the memory will respect them. However it looks like we are missing synchronisation for KMD internal buffers, like page-tables, lrc etc. For userspace objects we should already have the required synchronisation for CPU access via the fault handler, and likewise for GPU access when vm_binding them. To fix this synchronise against any kernel fences for all KMD objects at creation. This should resolve some severe corruption seen during evictions. v2 (Matt B): - Revamp the comment explaining this. Also mention why USAGE_KERNEL is correct here. v3 (Thomas): - Make sure to use ctx.interruptible for the wait. Testcase: igt@xe-evict-ccs Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/853 Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/855 Reported-by: Zbigniew Kempczyński <[email protected]> Signed-off-by: Matthew Auld <[email protected]> Cc: Thomas Hellström <[email protected]> Cc: Matthew Brost <[email protected]> Reviewed-by: Thomas Hellström <[email protected]> Tested-by: Zbigniew Kempczyński <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
2023-12-21drm/xe/bo: consider dma-resv fences for clear jobMatthew Auld1-2/+14
There could be active fences already in the dma-resv for the object prior to clearing. Make sure to input them as dependencies for the clear job. v2 (Matt B): - We can use USAGE_KERNEL here, since it's only the move fences we care about here. Also add a comment. Signed-off-by: Matthew Auld <[email protected]> Cc: Thomas Hellström <[email protected]> Cc: Matthew Brost <[email protected]> Reviewed-by: Thomas Hellström <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
2023-12-21drm/xe/migrate: fix MI_ARB_ON_OFF usageMatthew Auld2-16/+2
Spec says: "This is a privileged command; it will not be effective (will be converted to a no-op) if executed from within a non-privileged batch buffer." However here it looks like we are just emitting it inside some bb which was jumped to via the ppGTT, which should be considered a non-privileged address space. It looks like we just need some way of preventing things like the emit_pte() and later copy/clear being preempted in-between so rather just emit directly in the ring for migration jobs. Bspec: 45716 Signed-off-by: Matthew Auld <[email protected]> Cc: Thomas Hellström <[email protected]> Cc: Matthew Brost <[email protected]> Reviewed-by: Matt Roper <[email protected]> Reviewed-by: Thomas Hellström <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
2023-12-21drm/xe/xelpmp: Extend Wa_22016670082 to Xe_LPM+Shekhar Chauhan2-0/+8
Add Xe_LPM+ support to an existing workaround. BSpec: 51762 Signed-off-by: Shekhar Chauhan <[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/xe_exec_queue: Add check for access counter granularityPriyanka Dandamudi2-0/+17
Add conditional check for access counter granularity. This check will return -EINVAL if granularity is beyond 64M which is a hardware limitation. v2: Defined XE_ACC_GRANULARITY_128K 0 XE_ACC_GRANULARITY_2M 1 XE_ACC_GRANULARITY_16M 2 XE_ACC_GRANULARITY_64M 3 as part of uAPI. So, that user can also use it.(Oak) v3: Move uAPI to proper location and give proper documentation.(Brian, Oak) Cc: Oak Zeng <[email protected]> Cc: Janga Rahul Kumar <[email protected]> Cc: Brian Welty <[email protected]> Signed-off-by: Priyanka Dandamudi <[email protected]> Reviewed-by: Oak Zeng <[email protected]> Reviewed-by: Oak Zeng <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
2023-12-21drm/xe: Fix WA 14010918519 write to wrong registerLucas De Marchi1-2/+2
FORCE_SLM_FENCE_SCOPE_TO_TILE and FORCE_UGM_FENCE_SCOPE_TO_TILE are in the up dword of LSC_CHICKEN_BIT_0 register. Also, the 14010918519 workaround only applies to early steppings, A*. Eventually those should be dropped, like they were in commit eaeb4b361452 ("drm/i915/dg2: Drop pre-production GT workarounds"), so let's make sure they are annotated appropriately. Reviewed-by: Gustavo Sousa <[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/huc: Define HuC for MTLDaniele Ceraolo Spurio1-6/+7
MTL uses a versionless GSC-enabled binary. v2: don't use the filename to identify the header type (Lucas) v3: fix commit msg (Lucas) Signed-off-by: Daniele Ceraolo Spurio <[email protected]> Cc: Alan Previn <[email protected]> Cc: John Harrison <[email protected]> Cc: Lucas De Marchi <[email protected]> Reviewed-by: Lucas De Marchi <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
2023-12-21drm/xe/huc: Don't re-auth HuC if it's already authenticatedDaniele Ceraolo Spurio1-0/+6
On newer platforms the HuC survives reset and stays authenticated, so no need to re-authenticate it. Signed-off-by: Daniele Ceraolo Spurio <[email protected]> Cc: Alan Previn <[email protected]> Cc: John Harrison <[email protected]> Reviewed-by: Lucas De Marchi <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
2023-12-21drm/xe/huc: HuC is not supported on GTs that don't have video enginesDaniele Ceraolo Spurio1-1/+10
On MTL-style multi-gt platforms, the HuC is only available on the media GT, so we need to consider it as not supported on the render GT. Signed-off-by: Daniele Ceraolo Spurio <[email protected]> Cc: Alan Previn <[email protected]> Cc: John Harrison <[email protected]> Reviewed-by: Lucas De Marchi <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.