- 05 Jun, 2024 1 commit
-
-
Tejas Upadhyay authored
For xe2_lpm Wa_14020756599 is applied to all steppings and when RCS is present on graphics GT. V5(MattR): - Add more comments about new API V4: - Make it part of lrc wa - Check for RCS as rtp rule V3(MattR): - Rename rtp api name - Use MEDIA_VERx100 V2: - Remove engine filter video decode - Fix typo GRAPHICS/MEDIA/s - Himal Reviewed-by:
Matt Roper <matthew.d.roper@intel.com> Signed-off-by:
Tejas Upadhyay <tejas.upadhyay@intel.com> Signed-off-by:
Matthew Brost <matthew.brost@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240603104951.705603-2-tejas.upadhyay@intel.com
-
- 31 May, 2024 3 commits
-
-
Niranjana Vishwanathapura authored
Add kernel-doc to xe_lrc_create/destroy and xe_lrc_get/put interfaces. v2: Fix kernel-doc for xe_lrc_create(), drop Fixes tag. (Matt Brost, Michal Wajdeczko) Signed-off-by:Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com> Reviewed-by:
Rodrigo Vivi <rodrigo.vivi@intel.com>
-
Matthew Brost authored
Kernel VM do not have an Xe file. Include a check for Xe file in the VM before trying to get pid from VM's Xe file when taking a devcoredump. Fixes: b10d0c5e ("drm/xe: Add process name to devcoredump") Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: José Roberto de Souza <jose.souza@intel.com> Cc: stable@vger.kernel.org Signed-off-by:
José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240530203341.1795181-1-matthew.brost@intel.com
-
Michal Wajdeczko authored
The LMTT must be updated whenever we change the VF LMEM configuration. We missed that step when freeing the whole VF GT config, which could result in stale PTE in LMTT or LMTT PT object leaks. Fix that. Fixes: ac6598ae ("drm/xe/pf: Add support to configure SR-IOV VFs") Signed-off-by:
Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by:
Piotr Piórkowski <piotr.piorkowski@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240527115408.1064-1-michal.wajdeczko@intel.com
-
- 30 May, 2024 10 commits
-
-
Michal Wajdeczko authored
The initialization order of GT topology, MCR, PAT and GuC HWconfig as done today by native/PF driver, can't be followed as-is by the VF driver, since fuse registers used in GT topology discovery will be obtained by the VF driver from the GuC in HWconfig step. While native/PF drivers need to program the HW PAT table prior to loading the GuC, this requires only multicast writes support from the MCR code, which could be initialized separately from the full MCR support that requires the GT topology to setup steering data. Split MCR initialization into two steps to avoid introducing VF specific code paths. This also fixes duplicated spin_lock inits. Signed-off-by:
-
Michal Wajdeczko authored
VF drivers will obtain VRAM configuration from the GuC as part of the VF self config. Use that configuration instead of trying to read inaccessible registers. Signed-off-by:
-
Michal Wajdeczko authored
There is no point in mixing register access and VRAM code in the same file. Move and rename the VRAM probe function to a new file (there are no other changes other then new simple kernel-doc). Signed-off-by:
-
Michal Wajdeczko authored
Rename static functions to align with our typical coding style. While at it, downgrade the existing kernel-doc for internal function to normal comment. Suggested-by:
-
Michal Wajdeczko authored
We should keep all hardware definitions separated from the driver code. Move LMEM_BAR definition to new regs/xe_bars.h file and also add there GTTMMADR_BAR definition to avoid using magic 0 resource. Signed-off-by:
-
Michal Wajdeczko authored
We should not define registers directly in the code while we have dedicated files for all register definitions. Move XEHP_MTCFG_ADDR to regs/xe_regs.h Signed-off-by:
-
Daniele Ceraolo Spurio authored
This reverts commit cd506a33. The gt_remove function was explicitly added as part of the remove flow instead of using drmm/devm automatic cleanup due to it being illegal to remove a component after the driver has been detached from the pci device; the GSC proxy component is removed as part of gt_remove, so we need to do it in the pci cleanup flow. The function already has a comment above it to explain this. Note that the change to use the devm also caused an invalid pointer deref in the gsc_proxy unbind function, but I didn't bother to debug which pointer was bad since we shouldn't be calling the unbind that late anyway and this revert fixes it. Both issue were not seen in CI because the GSC loading is temporarily disabled due to a critical bug, which means we're not binding the component. Signed-off-by:
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Matthew Auld <matthew.auld@intel.com> Cc: Andrzej Hajda <andrzej.hajda@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by:
Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240528182354.1200424-1-daniele.ceraolospurio@intel.com
-
Arnd Bergmann authored
Using snprintf() with a format string from task->comm is a bit dangerous since the string may be controlled by unprivileged userspace: drivers/gpu/drm/xe/xe_devcoredump.c: In function 'devcoredump_snapshot': drivers/gpu/drm/xe/xe_devcoredump.c:184:9: error: format not a string literal and no format arguments [-Werror=format-security] 184 | snprintf(ss->process_name, sizeof(ss->process_name), process_name); | ^~~~~~~~ In this case there is no reason for an snprintf(), so use a simpler string copy. Fixes: b10d0c5e ("drm/xe: Add process name to devcoredump") Signed-off-by:Arnd Bergmann <arnd@arndb.de> Reviewed-by:
Thomas Hellström <thomas.hellstrom@linux.intel.com> Signed-off-by:
-
Niranjana Vishwanathapura authored
Decouple xe_lrc from xe_exec_queue and reference count xe_lrc. Removing hard coupling between xe_exec_queue and xe_lrc allows flexible design where the user interface xe_exec_queue can be destroyed independent of the hardware/firmware interface xe_lrc. v2: Fix lrc indexing in wq_item_append() Signed-off-by:
-
Niranjana Vishwanathapura authored
Do not hold xef->exec_queue.lock mutex while parsing the xarray xef->exec_queue.xa in xe_file_close() as it is not needed and will cause an unwanted dependency between this lock and the vm->lock. This lock protects the exec queue lookup and reference taking which doesn't apply to this code path. When FD is closing, IOCTLs presumably can't be modifying the xarray. v2: Update commit text (Matt Brost) v3: Add more code comment (Rodrigo Vivi) v4: Further expand code comment (Rodirgo Vivi) Signed-off-by:
Jagmeet Randhawa <jagmeet.randhawa@intel.com> Acked-by:
-
- 29 May, 2024 5 commits
-
-
Michal Wajdeczko authored
We don't have to use exact names of the enumerators as the potentially user-facing platform names. When constructing platform descriptor fields, use the unique platform tag and add the XE_ prefix only to the generated enum field. Signed-off-by:
Lucas De Marchi <lucas.demarchi@intel.com>
-
Karthik Poosa authored
In BMG there are separate registers for card/platform power and energy. These are exposed through channel 0 i.e power_1/energy1_xxx. Signed-off-by:
Karthik Poosa <karthik.poosa@intel.com> Reviewed-by:
Badal Nilawar <badal.nilawar@intel.com> Link: https://lore.kernel.org/r/20240523144351.4040131-3-balasubramani.vivekanandan@intel.comSigned-off-by:
Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240529050758.442056-3-balasubramani.vivekanandan@intel.comSigned-off-by:
-
Karthik Poosa authored
Add HWMON support for BMG. Exposing the pkg power, current, energy info. Signed-off-by:
-
Nirmoy Das authored
Add engine name to the engine reset and cat error log which should be useful while debugging. v2: Add logical mask and engine class(Matt) Use xe_gt_{info|dbg} (Michal) Cc: Matthew Brost <matthew.brost@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by:Nirmoy Das <nirmoy.das@intel.com>
-
Nirmoy Das authored
Use lock that is meant to use for accessing the BO pin list. Reviewed-by:
-
- 28 May, 2024 9 commits
-
-
John Harrison authored
The debug prints about how long the GuC load takes have a loop counter. However that was neither initialised nor incremented! Plus, counting loops is no longer meaningful given the wait function returns early for any change in the status value. So fix it to only count loops due to actual timeouts. Signed-off-by:
John Harrison <John.C.Harrison@Intel.com> Reported-by:
kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202405250151.IbH0l8FG-lkp@intel.com/ Fixes: b0ac1b42 ("drm/xe/guc: Port over the slow GuC loading support from i915") Cc: John Harrison <John.C.Harrison@Intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Oded Gabbay <ogabbay@kernel.org> Cc: "Thomas Hellström" <thomas.hellstrom@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Fei Yang <fei.yang@intel.com> Cc: intel-xe@lists.freedesktop.org Reviewed-by:
-
Oded Gabbay authored
Because I left Intel, I'm removing myself from the list of Xe driver maintainers. Signed-off-by:
Oded Gabbay <ogabbay@kernel.org> Acked-by:
-
Riana Tauro authored
Enable power gating for all units and sub-pipes that are disabled by default. v2: change the init function name use symmetric calls for enable/disable pg re-pharase commit message (Rodrigo) modify the sub-pipe power gating condition v3: set hysteresis value for render and media when GuC PC is disabled skip CPG for PVC (Vinay) v4: rebase Signed-off-by:Riana Tauro <riana.tauro@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> #v2 Reviewed-by:
Vinay Belgaumkar <vinay.belgaumkar@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240524070916.143022-3-riana.tauro@intel.comSigned-off-by:
-
Riana Tauro authored
Standardize power gate registers No functional changes v2: change commit message (Rodrigo) Signed-off-by:
-
Matt Roper authored
During engine LRC initialization a number of registers need to be programmed as general setup. This programming is not a "workaround" so naming the RTP table as "lrc_was" is misleading; switch to the name "lrc_setup" to more accurately describe what the table is actually for. Signed-off-by:
Gustavo Sousa <gustavo.sousa@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240524230444.1447797-2-matthew.d.roper@intel.com
-
Michal Wajdeczko authored
We can now use more user-friendly platform name instead of previosly used magic platform enumerator value: [ ] xe 0000:00:02.0: [drm] Assertion `false` failed! platform: ALDERLAKE_S ... [ ] xe 0000:03:00.0: [drm] Assertion `false` failed! platform: DG2 ... vs [ ] xe 0000:00:02.0: [drm] Assertion `false` failed! platform: 3 ... [ ] xe 0000:03:00.0: [drm] Assertion `false` failed! platform: 7 ... Signed-off-by: -
Michal Wajdeczko authored
We already maintain the platform name as part of the device descriptor, but in xe_device.info we only store platform enum, which is not the best for use in any user-facing messages. Signed-off-by:
-
Andrzej Hajda authored
xe_res_cursor code does not depend on the alignment. On the other side unaligned accesses are useful from pread/pwrite point of view. Signed-off-by:
Andrzej Hajda <andrzej.hajda@intel.com> Reviewed-by:
-
Andrzej Hajda authored
Tests show that user fence signalling requires kind of write barrier, otherwise not all writes performed by the workload will be available to userspace. It is already done for render and compute, we need it also for the rest: video, gsc, copy. v2: added gsc and copy engines, added fixes and r-b tags Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/1488 Fixes: dd08ebf6 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Signed-off-by:
-
- 27 May, 2024 9 commits
-
-
Umesh Nerlige Ramappa authored
The current code is running into a use after free case where xe file is closed before the exec queue run_ticks can be updated. This is occurring in the xe_file_close path. To fix that, do not access xe file when updating the exec queue run_ticks. Instead store the exec queue run_ticks locally in the exec queue object and accumulate it when the user dumps the drm client stats. We know that the xe file is valid when user is dumping the run_ticks for the drm client, so this effectively removes the dependency on xe file object in xe_exec_queue_update_run_ticks(). v2: - Fix the accumulation of q->run_ticks delta into xe file run_ticks - s/runtime/run_ticks/ (Rodrigo) Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/1908 Fixes: 6109f24f ("drm/xe: Add helper to accumulate exec queue runtime") Signed-off-by:
Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Reviewed-by:
-
Umesh Nerlige Ramappa authored
Note that runtime is also used in the pm context, so it is confusing to use the same name to denote run time of the drm client. Use a more appropriate name for the client utilization. While at it, drop the incorrect multi-lrc comment in the helper description v2: s/show_runtime/show_run_ticks/ (Rodrigo) Signed-off-by:
-
Thomas Hellström authored
In order to be able to run gpu jobs from reclaim context, move job creation (where allocation takes place) out of the struct xe_migrate::job_mutex, and prime that mutex as reclaim tainted. Jobs that may need to run from reclaim context include CCS metadata extraction at shrinking time. Signed-off-by:
-
Thomas Hellström authored
It's not used anymore. Signed-off-by:
-
Thomas Hellström authored
Pre-allocate but don't initialize fences at xe_sched_job_create(), and initialize / arm them instead at xe_sched_job_arm(). This makes it possible to move xe_sched_job_create() with its memory allocation out of any lock that is required for fence initialization, and that may not allow memory allocation under it. Replaces the struct dma_fence_array for parallell jobs with a struct dma_fence_chain, since the former doesn't allow a split-up between allocation and initialization. v2: - Rebase. - Don't always use the first lrc when initializing parallel lrc fences. - Use dma_fence_chain_contained() to access the lrc fences. v4: - Add an assert that job->lrc_seqno == fence->seqno. (Matthew Brost) Signed-off-by:
-
Thomas Hellström authored
Since sometimes a lock is required to initialize a seqno fence, and it might be desirable not to hold that lock while performing memory allocations, split the lrc seqno fence creation up into an allocation phase and an initialization phase. Since lrc seqno fences under the hood are hw_fences, do the same for these and remove the xe_hw_fence_create() function since it is not used anymore. Signed-off-by:
-
Matthew Brost authored
Tightly coupling these seqno presents problems if alternative fences for jobs are used. Decouple these for correctness. v2: - Slightly reword commit message (Thomas) - Make sure the lrc fence ops are used in comparison (Thomas) - Assume seqno is unsigned rather than signed in format string (Thomas) Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Signed-off-by:
-
Michal Wajdeczko authored
Each VF is assigned a limited range of the GGTT address space. To ensure that the VF driver does not use GGTT allocations outside of the assigned region, explicitly reserve GGTT space below and above this region when initializing GGTT. Signed-off-by:
Michał Winiarski <michal.winiarski@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240527112015.1020-1-michal.wajdeczko@intel.com
-
Michal Wajdeczko authored
Each VF will be assigned with only a limited range of the GGTT address space. Make sure that VF driver will read its own GGTT configuration before starting any GGTT initialization. Signed-off-by:
-
- 24 May, 2024 3 commits
-
-
Michal Wajdeczko authored
While the GMDID registers are not part of the runtime register list shared by the PF driver, we may still return cached values from our VF specific read32() helper function. Signed-off-by:
-
Michal Wajdeczko authored
Read and cache value of the GMDID register as part of the config query that VF driver is doing over MMIO. While the VF driver likely already obtained the value of the GMDID register once during the early driver probe, we couldn't cache it then as the GT structures were not ready yet. Cache it now, in case the driver needs it later when the GuC MMIO communication, required to query GMDID from GuC, could be no longer desired as it will be replaced by the CTB communication. While around, assert that we will query GMDID only when applicable. Signed-off-by:
-
Michal Wajdeczko authored
VFs do not have direct access to the GMDID register and must obtain its value from the GuC. Since we need GMDID value very early in the driver probe flow, before we even start the full setup of GT and GuC data structures, we must do some early initializations ourselves. Additionally, since we also need GMDID for the media GT, which isn't created yet, temporarly tweak the root GT type into MEDIA to allow communication with the correct GuC, as only it can provide the value of the media GMDID register. Signed-off-by:
-
