- 06 Jun, 2024 7 commits
-
-
Riana Tauro authored
The rc6 registers used in disable_c6 function belong to the GT forcewake domain. Hence change the forcewake assertion to check GT forcewake domain. v2: add fixes tag (Himal) Fixes: 975e4a37 ("drm/xe: Manually setup C6 when skip_guc_pc is set") Signed-off-by: Riana Tauro <riana.tauro@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240606100842.956072-2-riana.tauro@intel.comSigned-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
-
Jonathan Cavitt authored
We currently have debugfs support that allows the userspace to initiate an asynchronous gt reset on command. However, userspace may also wish to wait for the completion of the gt reset before performing any additional work. To that end, add a version of the force_reset gt debugfs function that operates synchronously. Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/1068Suggested-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Jonathan Cavitt <jonathan.cavitt@intel.com> CC: John Harrison <john.c.harrison@intel.com> CC: Stuart Summers <stuart.summers@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240605150828.2736396-1-jonathan.cavitt@intel.comSigned-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
-
Matthew Brost authored
job->fence is not assigned until xe_sched_job_arm(), check for job->fence in xe_sched_job_seqno() so any usage of this function (trace points) do not result in NULL ptr dereference. Also check job->fence before assigning error in job trace points. Fixes: 0ac7a2c7 ("drm/xe: Don't initialize fences at xe_sched_job_create()") Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240605055041.2082074-1-matthew.brost@intel.com
-
Michal Wajdeczko authored
Only few steps from the GT restart phase are applicable for the VF drivers, as initialization of PAT, WOPCM, MOCS or CCS mode can be done only by the native or PF drivers. Use custom GT restart function if running in VF mode. 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/20240604212231.1416-5-michal.wajdeczko@intel.com
-
Michal Wajdeczko authored
The VF drivers can't trigger real GuC firmware reset using GDRST register, but for the VF drivers it is sufficient to send VF_RESET message to reset any VF specific state maintained by the GuC. Use our existing VF bootstrap function as VF_RESET is part of it. 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/20240604212231.1416-4-michal.wajdeczko@intel.com
-
Michal Wajdeczko authored
VF drivers can't modify WOPCM registers nor upload firmwares to GuC, HuC or GSC. Modify xe_uc initialization functions to skip those steps if running in the VF mode, or defer to a new custom helper function that would not include those steps. 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/20240604212231.1416-3-michal.wajdeczko@intel.com
-
Michal Wajdeczko authored
Only GuC/HuC firmwares can be used by the VFs, don't claim support for any other firmware (like GSC) even if the driver can support it. 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/20240604212231.1416-2-michal.wajdeczko@intel.com
-
- 05 Jun, 2024 8 commits
-
-
Matthew Brost authored
Overmapping the identity VRAM mapping is triggering hardware bugs on certain platforms. Use 2M pages for the last unaligned (to 1G) VRAM chunk. v2: - Always use 2M pages for last chunk (Fei Yang) - break loop when 2M pages are used - Add assert for usable_size being 2M aligned v3: - Fix checkpatch Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Fei Yang <fei.yang@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Fei Yang <fei.yang@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240603181824.1927675-1-matthew.brost@intel.com
-
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. Fixes: dd08ebf6 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Signed-off-by: Andrzej Hajda <andrzej.hajda@intel.com> Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240605-fix_user_fence_posted-v3-2-06e7932f784a@intel.com
-
Andrzej Hajda authored
This reverts commit 38007fa9. Signaling user-fence after seqno write does not seem to be good solution. Instead of changing order separate barrier should be put before user-fence, this will be done in separate patch. v2: added fixes tag in case reverted patch gets backported to stable Fixes: 38007fa9 ("drm/xe: flush gtt before signalling user fence on all engines") Signed-off-by: Andrzej Hajda <andrzej.hajda@intel.com> Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240605-fix_user_fence_posted-v3-1-06e7932f784a@intel.com
-
Thorsten Blum authored
The if condition !A || A && B can be simplified to !A || B. Fixes the following Coccinelle/coccicheck warning reported by excluded_middle.cocci: WARNING !A || A && B is equivalent to !A || B Compile-tested only. Signed-off-by: Thorsten Blum <thorsten.blum@toblux.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240603180005.191578-1-thorsten.blum@toblux.com
-
Jani Nikula authored
Since commit a61ddb43 ("drm: enable (most) W=1 warnings by default across the subsystem"), most of the extra warnings in the driver Makefile are redundant. Remove them. Note that -Wmissing-declarations and -Wmissing-prototypes are always enabled by default in scripts/Makefile.extrawarn. Acked-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/958a67adcbb64d3a387d2a07d83b05d71176e938.1716471145.git.jani.nikula@intel.com
-
Nirmoy Das authored
Add missing lock that is protecting relay->incoming_actions. Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240603081723.18775-1-nirmoy.das@intel.comSigned-off-by: Nirmoy Das <nirmoy.das@intel.com>
-
Tejas Upadhyay authored
For xe2_lpg render Wa_14020756599 is applied to all steppings. Reviewed-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@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-3-tejas.upadhyay@intel.com
-
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: Matthew Brost <matthew.brost@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240531161230.32317-1-niranjana.vishwanathapura@intel.comSigned-off-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: Matthew Brost <matthew.brost@intel.com> Reviewed-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 <michal.wajdeczko@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Michał Winiarski <michal.winiarski@intel.com> Cc: Zhanjun Dong <zhanjun.dong@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240530115814.1284-1-michal.wajdeczko@intel.com
-
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 <michal.wajdeczko@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240530133527.1328-6-michal.wajdeczko@intel.com
-
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 <michal.wajdeczko@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240530133527.1328-5-michal.wajdeczko@intel.com
-
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: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240530133527.1328-4-michal.wajdeczko@intel.com
-
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 <michal.wajdeczko@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240530133527.1328-3-michal.wajdeczko@intel.com
-
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: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240530133527.1328-2-michal.wajdeczko@intel.com
-
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: Thomas Hellström <thomas.hellstrom@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240528133251.2310868-1-arnd@kernel.org
-
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 <niranjana.vishwanathapura@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240530032211.29299-1-niranjana.vishwanathapura@intel.com
-
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: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Jagmeet Randhawa <jagmeet.randhawa@intel.com> Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240529221639.23117-1-niranjana.vishwanathapura@intel.com
-
- 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: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240521142257.756-3-michal.wajdeczko@intel.comSigned-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: Rodrigo Vivi <rodrigo.vivi@intel.com>
-
Karthik Poosa authored
Add HWMON support for BMG. Exposing the pkg power, current, energy info. Signed-off-by: Karthik Poosa <karthik.poosa@intel.com> Reviewed-by: Badal Nilawar <badal.nilawar@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://lore.kernel.org/r/20240523144351.4040131-2-balasubramani.vivekanandan@intel.comSigned-off-by: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240529050758.442056-2-balasubramani.vivekanandan@intel.comSigned-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
-
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: Matthew Brost <matthew.brost@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240528101445.27688-1-nirmoy.das@intel.comSigned-off-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: Matthew Brost <matthew.brost@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240528115408.22094-1-nirmoy.das@intel.comSigned-off-by: Nirmoy Das <nirmoy.das@intel.com>
-
- 28 May, 2024 7 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: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240524202603.4011656-1-John.C.Harrison@Intel.com
-
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: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240515162222.12958-3-ogabbay@kernel.orgSigned-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
-
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: Rodrigo Vivi <rodrigo.vivi@intel.com>
-
Riana Tauro authored
Standardize power gate registers No functional changes v2: change commit message (Rodrigo) Signed-off-by: Riana Tauro <riana.tauro@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240524070916.143022-2-riana.tauro@intel.comSigned-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
-
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: Matt Roper <matthew.d.roper@intel.com> Reviewed-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 <michal.wajdeczko@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240521142257.756-4-michal.wajdeczko@intel.com
-
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: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240521142257.756-2-michal.wajdeczko@intel.com
-