- 18 Jan, 2024 9 commits
-
-
Fei Yang authored
In function write_pgtable, the calculation of chunk in the do-while loop is wrong, we should always compare against remaining size instead of the total size update->qwords. Signed-off-by:
Fei Yang <fei.yang@intel.com> Reviewed-by:
Matt Roper <matthew.d.roper@intel.com> Signed-off-by:
-
Daniele Ceraolo Spurio authored
The GSC notifies us of a proxy request via the HECI2 interrupt. The interrupt must be enabled both in the HECI layer and in our usual gt irq programming; for the latter, the interrupt is enabled via the same enable register as the GSC CS, but it does have its own mask register. When the interrupt is received, we also need to de-assert it in both layers. The handling of the proxy request is deferred to the same worker that we use for GSC load. New flags have been added to distinguish between the init case and the proxy interrupt. v2: rename irq define, fix include ordering (Alan) Signed-off-by:
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Alan Previn <alan.previn.teres.alexis@intel.com> Cc: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by:
Alan Previn <alan.previn.teres.alexis@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240117182621.2653049-3-daniele.ceraolospurio@intel.com
-
Daniele Ceraolo Spurio authored
The GSC uC needs to communicate with the CSME to perform certain operations. Since the GSC can't perform this communication directly on platforms where it is integrated in GT, the graphics driver needs to transfer the messages from GSC to CSME and back. The proxy flow must be manually started after the GSC is loaded to signal to GSC that we're ready to handle its messages and allow it to query its init data from CSME. Note that the component must be removed before the pci_remove call completes, so we can't use a drmm helper for it and we need to instead perform the cleanup as part of the removal flow. v2: add function documentation, more targeted memory clear, clearer logs and variable names (Alan) Signed-off-by:
-
Michal Wajdeczko authored
Add initial documentation for recently updated xe_guc_ct_send_recv(). Signed-off-by:
Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Reviewed-by:
Matthew Brost <matthew.brost@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240112102554.761-2-michal.wajdeczko@intel.com
-
Michal Wajdeczko authored
Most of the synchronous GuC HXG action responses are defined in such a way that only mandatory DATA0 from the HXG header is used and only in few cases it is more than MBZ (must be zero). For those cases where HXG action returns just DATA0, return that value if caller didn't provide buffer for the full response. Signed-off-by:
-
Michal Wajdeczko authored
The mapping between HW IP version and its description is const, so mark it as such. Signed-off-by:
Gustavo Sousa <gustavo.sousa@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240116120207.1133-1-michal.wajdeczko@intel.com
-
Karthik Poosa authored
The GuC handles the WA, the KMD just needs to set the flag to enable it on the appropriate platforms. v2: - Fixed CI checkpatch warning, alignment should match open parenthesis. - Fixed GUC FW version check to use XE_UC_FW_VER_RELEASE which points to current GUC FW version instead of XE_UC_FW_VER_COMPATIBILITY which holds GUC FW I/F version (Badal). v3: - Removed extra character in debug print. Signed-off-by:Karthik Poosa <karthik.poosa@intel.com> Reviewed-by:
Badal Nilawar <badal.nilawar@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240117055035.2417711-1-karthik.poosa@intel.comSigned-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com>
-
Thomas Hellström authored
The last argument of xe_pcode_read() is a pointer. Use NULL instead of 0. Fixes: 92d44a42 ("drm/xe/hwmon: Expose card reactive critical power") Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by:
Francois Dugast <francois.dugast@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240117134048.165425-6-thomas.hellstrom@linux.intel.com
-
Thomas Hellström authored
It is not referenced outside of the xe_dma_buf.c source file. Fixes: dd08ebf6 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Signed-off-by:
-
- 16 Jan, 2024 2 commits
-
-
Lucas De Marchi authored
Creating one module for each compilation unit to be tested seems excessive as the number of tests increase. Group them all in a single kunit test module called xe_test.ko. The tests requiring the physical device, aka "live" tests, are still kept in separate modules since they are normally triggered via igt, and not via kunit.py. After igt is converted, those can be merged in a single module as well. Signed-off-by:
Lucas De Marchi <lucas.demarchi@intel.com> Acked-by:
-
Michal Wajdeczko authored
There is no need to copy string step by step, use existing helper. Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by:
-
- 12 Jan, 2024 6 commits
-
-
Jani Nikula authored
Remove the DRM_XE_DISPLAY config dependency on EXPERT. I can only presume the idea was only experts should be able to disable it, but the effect is the opposite. Reported-by:
Eero Tamminen <eero.t.tamminen@intel.com> Reviewed-by:
Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240111104716.3548744-1-jani.nikula@intel.com
-
Brian Welty authored
Requesting all memory regions on PVC will fill bo->placements up to XE_BO_MAX_PLACEMENTS. The subsequent call to try_add_stolen() will trip over the bounds checking even though XE_PL_STOLEN is not expected to be used in this case. This is hit with igt@xe_exec_fault_mode@once-basic-prefetch: xe 0000:8c:00.0: [drm] Assertion `*c < (sizeof(bo->placements) / sizeof((bo->placements)[0]) + ((int)(sizeof(struct { int:(-!!(__builtin_types_compatible_p(typeof((bo->placements)), typeof(&(bo->placements)[0])))); }))))` failed! WARNING: CPU: 30 PID: 6161 at drivers/gpu/drm/xe/xe_bo.c:203 __xe_bo_placement_for_flags+0x218/0x240 [xe] Is fixed here by moving the bounds checks closer to where we actually write into the bo->placement array. Fixes: 8c54ee8a ("drm/xe: Ensure that we don't access the placements array out-of-bounds") Link: https://patchwork.freedesktop.org/patch/msgid/20240111002111.10190-1-brian.welty@intel.comSigned-off-by:Brian Welty <brian.welty@intel.com> Reviewed-by:
-
Matt Roper authored
Although MI_STORE_DATA_IMM's "length" field is 10-bits, 0x3FE is considered the largest legal value accepted. Since that instruction field is always encoded in (val-2) format, this translates to 0x400 dwords for the true maximum length of the instruction. Subtracting the instruction header (1 dword) and address (2 dwords), that leaves 0x3FD dwords (i.e., 0x1FE qwords) for PTE values. Bspec: 60246, 45753 Reviewed-by:
-
Michal Wajdeczko authored
If Doorbell Manager is in unclean state during fini phase, for debug purposes we try to print it's state, but we missed the fact that we are already holding a lock so the xe_guc_db_mgr_print() will deadlock since it also attempts to grab the same lock. Fixes: 587c7334 ("drm/xe: Introduce GuC Doorbells Manager") Cc: Piotr Piórkowski <piotr.piorkowski@intel.com> Reviewed-by:
Piotr Piórkowski <piotr.piorkowski@intel.com> Link: https://lore.kernel.org/r/20240111185603.673-1-michal.wajdeczko@intel.comSigned-off-by:
-
Michal Wajdeczko authored
Soon we will be required to exclude some of the GGTT addresses from the allocations, since on some platforms running the SR-IOV VF mode, we will be able to use only selected range of the GGTT space. Add helper functions to manage such GGTT range exclusions, and follow the naming from the similar concept used by GVT-g. Reviewed-by:
-
Michal Wajdeczko authored
While parsing and processing CTB G2H messages we should extract underlying HXG message and use HXG definitions on such message. Using outer CTB layer message in HXG definitions require use of shifted dword index, which might be confusing: FIELD_GET(GUC_HXG_MSG_0_xxx, msg[1]) instead of: FIELD_GET(GUC_HXG_MSG_0_xxx, hxg[0]) Cc: Matthew Brost <matthew.brost@intel.com> Reviewed-by:
-
- 11 Jan, 2024 7 commits
-
-
Michal Wajdeczko authored
Not all CTB responses from the GuC are fixed size and we need to pass response length to the caller, if there was a response_buffer. Easiest solution is to return it as positive value from all xe_guc_ct_send_recv() functions. The CTB response length is always between 1 and 254 (ie. GUC_HXG_MSG_MIN_LEN and GUC_CTB_MAX_DWORDS - GUC_HXG_MSG_MIN_LEN). Cc: Matthew Brost <matthew.brost@intel.com> Reviewed-by:
-
Michal Wajdeczko authored
Once GuC replied with GUC_HXG_TYPE_NO_RESPONSE_BUSY message then we may expect that only RESPONSE_SUCCESS or FAILURE message will be sent, anything else is a violation of the HXG protocol. Cc: Matthew Brost <matthew.brost@intel.com> Reviewed-by:
-
Michal Wajdeczko authored
Soon we will be trying to communicate with the GuC firmware very early during VF driver probe, before we finish normal init steps. Split GuC communication initialization code so the GuC MMIO based communication xe_guc_mmio_send() functions will work where needed. Cc: Matthew Brost <matthew.brost@intel.com> Reviewed-by:
-
Thomas Hellström authored
Since the migrate code is using the identity map for addressing VRAM, copy chunks may become as small as 64K if the VRAM resource is fragmented. However, a chunk size smaller that 1MiB may lead to the *next* chunk's offset into the CCS metadata backup memory may not be page-aligned, and the XY_CTRL_SURF_COPY_BLT command can't handle that, and even if it could, the current code doesn't handle the offset calculaton correctly. To fix this, make sure we align the size of VRAM copy chunks to 1MiB. If the remaining data to copy is smaller than that, that's not a problem, so use the remaining size. If the VRAM copy cunk becomes fragmented due to the size alignment restriction, don't use the identity map, but instead emit PTEs into the page-table like we do for system memory. v2: - Rebase v3: - Future proof somewhat by taking into account the real data size to flat CCS metadata size ratio. (Matt Roper) - Invert a couple of if-statements for better readability. - Fix support for 4K-granularity VRAM sizes. (Tested on DG1). v4: - Fix up code comments - Fix debug printout format typo. v5: - Add a Fixes: tag. Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Matthew Auld <matthew.william.auld@gmail.com> Cc: Matthew Brost <matthew.brost@intel.com> Fixes: e89b384c ("drm/xe/migrate: Update emit_pte to cope with a size level than 4k") Signed-off-by:
Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240110163415.524165-1-thomas.hellstrom@linux.intel.com
-
Dan Carpenter authored
Drop the "&vm->lock" before returning. Fixes: 24f947d5 ("drm/xe: Use DRM GPUVM helpers for external- and evicted objects") Signed-off-by:
Dan Carpenter <dan.carpenter@linaro.org> Signed-off-by:
-
Dan Carpenter authored
Check if "bo" is an error pointer before calling xe_bo_lock() on it. Fixes: d6abc18d ("drm/xe/xe2: Modify xe_bo_test for system memory") Signed-off-by:
-
Dan Carpenter authored
This error path should clean up before returning. Smatch detected this bug: drivers/gpu/drm/xe/xe_device.c:487 xe_device_probe() warn: missing unwind goto? Fixes: 4cb12b71 ("drm/xe/xe2: Determine bios enablement for flat ccs on igfx") Signed-off-by:
-
- 10 Jan, 2024 9 commits
-
-
Matthew Brost authored
Convention for queues in Linux is the producer moves the head and consumer moves the tail. Fix the access counter queue to conform to this convention. Cc: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by:
-
Matthew Brost authored
If ACC_QUEUE_NUM_DW % ACC_MSG_LEN_DW != 0 then the access counter queue logic does not work when wrapping occurs. Add a build bug on to assert ACC_QUEUE_NUM_DW % ACC_MSG_LEN_DW == 0 to enforce this restriction and document the code. v2: - s/NUM_ACC_QUEUE/ACC_QUEUE_NUM_DW (Brian) Cc: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by:
-
Matthew Brost authored
Convention for queues in Linux is the producer moves the head and consumer moves the tail. Fix the page fault queue to conform to this convention. Cc: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by:
-
Matthew Brost authored
If PF_QUEUE_NUM_DW % PF_MSG_LEN_DW != 0 then the page fault queue logic does not work when wrapping occurs. Add a build bug on to assert PF_QUEUE_NUM_DW % PF_MSG_LEN_DW == 0 to enforce this restriction and document the code. v2: - s/NUM_PF_QUEUE/PF_QUEUE_NUM_DW (Brian) Cc: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by:
-
Brian Welty authored
This function is no longer used as the job_timeout is now updated prior to calling queue_ops.init(). Signed-off-by:
-
Brian Welty authored
Setting of exec_queue user extensions is moved from the end of the ioctl function earlier, into __xe_exec_queue_alloc(). This fixes bug in that the USM attributes for access counters were being applied too late, and effectively were ignored. However, in order to apply user extensions this early, we can no longer call q->ops functions. Instead, make it more efficient. The user extension functions can simply update the q->sched_props values and they will be applied by the backend during q->ops->init(). v2: minor changes for readability (Matt) Signed-off-by:
-
Brian Welty authored
The purpose here is to allow to optimize exec_queue_set_job_timeout() in follow-on patch. Currently it does q->ops->set_job_timeout(...). But we'd like to apply exec_queue_user_extensions much earlier and q->ops cannot be called before __xe_exec_queue_init(). It will be much more efficient to instead only have to set q->sched_props.job_timeout_ms when applying user extensions. That value will then be used during q->ops->init(). Signed-off-by:
-
Brian Welty authored
Split __xe_exec_queue_create() into two functions, alloc and init. We have an issue in that exec_queue_user_extensions are applied too late. In the case of USM properties, these need to be set prior to xe_lrc_init(). Refactor the logic here, so we can resolve this in follow-on. We only need the xe_vm_lock held during the exec_queue_init function. Signed-off-by:
-
Paul E. McKenney authored
Building drivers/gpu/drm/xe/xe_gt_pagefault.c with GCC 11 results in the following build errors: ./include/linux/fortify-string.h:57:33: error: writing 16 bytes into a region of size 0 [-Werror=stringop-overflow=] 57 | #define __underlying_memcpy __builtin_memcpy | ^ ./include/linux/fortify-string.h:644:9: note: in expansion of macro ‘__underlying_memcpy’ 644 | __underlying_##op(p, q, __fortify_size); \ | ^~~~~~~~~~~~~ ./include/linux/fortify-string.h:689:26: note: in expansion of macro ‘__fortify_memcpy_chk’ 689 | #define memcpy(p, q, s) __fortify_memcpy_chk(p, q, s, \ | ^~~~~~~~~~~~~~~~~~~~ drivers/gpu/drm/xe/xe_gt_pagefault.c:340:17: note: in expansion of macro ‘memcpy’ 340 | memcpy(pf_queue->data + pf_queue->tail, msg, len * sizeof(u32)); | ^~~~~~ In file included from drivers/gpu/drm/xe/xe_device_types.h:17, from drivers/gpu/drm/xe/xe_vm_types.h:16, from drivers/gpu/drm/xe/xe_bo.h:13, from drivers/gpu/drm/xe/xe_gt_pagefault.c:16: drivers/gpu/drm/xe/xe_gt_types.h:102:25: note: at offset [1144, 265324] into destination object ‘tile’ of size 8 102 | struct xe_tile *tile; | ^~~~ Fix these by removing -Wstringop-overflow from drm/xe builds. Closes: https://lore.kernel.org/all/45ad1d0f-a10f-483e-848a-76a30252edbe@paulmck-laptop/ Fixes: 7a8bc117 ("drm/xe: Enable W=1 warnings by default") Suggested-by:Stephen Rothwell <sfr@rothwell.id.au> Signed-off-by:
Paul E. McKenney <paulmck@kernel.org> [ This particular warning is broken on GCC11. In future changes it will be moved to the normal C flags in the top level Makefile (out of Makefile.extrawarn), but accounting for the compiler support. Just remove it out of xe's forced extra warnings for now ] Signed-off-by:
-
- 09 Jan, 2024 7 commits
-
-
Vinay Belgaumkar authored
Don't set SLPC GuC feature ctl flag if skip_guc_pc is true. v2: Skip the freq related sysfs creation as well (Badal) v3: Remove unnecessary parenthesis (Lucas) Fixes: 975e4a37 ("drm/xe: Manually setup C6 when skip_guc_pc is set") Fixes: bef52b5c ("drm/xe: Create a xe_gt_freq component for raw management and sysfs") Reviewed-by:
Vinay Belgaumkar <vinay.belgaumkar@intel.com> Link: https://lore.kernel.org/r/20240108225842.966066-1-vinay.belgaumkar@intel.comSigned-off-by:
-
Sujaritha Sundaresan authored
Add vram frequency sysfs attributes under the below hierarchy; /device/tile#/memory/freq0 |-max_freq |-min_freq v2: Drop "vram" from attribute names (Rodrigo) v3: Add documentation for new sysfs (Riana) Drop prefix from XEHP_PCODE_FREQUENCY_CONFIG (Riana) v4: Create sysfs under tile#/freq0 after removal of physical_memsize attrbute v5: Revert back to creating sysfs under tile#/memory/freq0 Remove definition of GT_FREQUENCY_MULTIPLIER (Rodrigo) v6: Rename attributes to max/min_freq (Anshuman) Fix review comments (Rodrigo) v7: Make documentation more verbose Move sysfs to separate file (Anshuman) v8: Fix platform specific conditions and add kernel doc (Anshuman) Fix typos and remove redundant headers (Riana) v9: Fix typo (Riana) Change function name to include "sysfs" (Lucas) Signed-off-by:Sujaritha Sundaresan <sujaritha.sundaresan@intel.com> Reviewed-by:
Anshuman Gupta <anshuman.gupta@intel.com> Link: https://lore.kernel.org/r/20240109110418.2065101-1-sujaritha.sundaresan@intel.comSigned-off-by:
-
Brian Welty authored
After exec_queue has been created, we cannot simply modify q->priority. This needs to be done by the backend via q->ops. However in this case, it would be more efficient to simply pass a flag when creating the exec_queue and set the desired priority upfront during queue creation. To that end: new flag EXEC_QUEUE_FLAG_HIGH_PRIORITY is introduced. The priority field is moved to be with other scheduling properties and is now exec_queue.sched_props.priority. This is no longer set to initial value by the backend, but is now set within __xe_exec_queue_create(). Fixes: b4eecedc ("drm/xe: Fix potential deadlock handling page faults") Signed-off-by:
-
Brian Welty authored
We need to set q->priority prior to calling guc_exec_queue_add_msg() as that will call init_policies() and sets the scheduling properties to those stored in the exec_queue. Fixes: dd08ebf6 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Signed-off-by:
-
Shekhar Chauhan authored
Force max 128KB SLM during WMTP PASS1 Restore. BSpec: 70202 Signed-off-by:
Shekhar Chauhan <shekhar.chauhan@intel.com> Reviewed-by:
-
Thomas Hellström authored
The pointer points to IO memory, but the __iomem annotation was incorrectly placed. Annotate it correctly, update its usage accordingly and fix the corresponding sparse error. Fixes: d8b52a02 ("drm/xe: Implement stolen memory.") Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
-
Thomas Hellström authored
There are a couple of pointers pointing to MMIO space. Annotate them with __iomem and fix the corresponding sparse warnings. Fixes: dd08ebf6 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Fixes: 3b0d4a55 ("drm/xe: Move register MMIO into xe_tile") Fixes: 399a1332 ("drm/xe: add 28-bit address support in struct xe_reg") Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Koby Elbaz <kelbaz@habana.ai> Cc: Ofir Bitton <obitton@habana.ai> Cc: Moti Haimovski <mhaimovski@habana.ai> Signed-off-by:
-
