- 07 Mar, 2024 1 commit
-
-
Dawei Li authored
Kernel test robot reports building error: drivers/gpu/drm/xe/xe_lrc.c:544:1: error: unused function '__xe_lrc_regs_ggtt_addr' [-Werror,-Wunused-function] 544 | DECL_MAP_ADDR_HELPERS(regs) | ^~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/gpu/drm/xe/xe_lrc.c:536:19: note: expanded from macro 'DECL_MAP_ADDR_HELPERS' 536 | static inline u32 __xe_lrc_##elem##_ggtt_addr(struct xe_lrc *lrc) \ Declare __xe_lrc_*_ggtt_addr with __maybe_unused to address it. Reported-by:
kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202402010928.g3j2aSBL-lkp@intel.com/Signed-off-by:
Dawei Li <dawei.li@shingroup.cn> Link: https://patchwork.freedesktop.org/patch/msgid/20240204062324.3548268-1-dawei.li@shingroup.cnSigned-off-by:
Lucas De Marchi <lucas.demarchi@intel.com>
-
- 06 Mar, 2024 11 commits
-
-
Rodrigo Vivi authored
There's no reason to proceed with applying workaround and initing sysfs if we are going to abort the probe upon failure. Fixes: e5a845fd ("drm/xe: Add sysfs entry for tile") Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Matthew Auld <matthew.auld@intel.com> Reviewed-by:
Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240306203110.146387-1-rodrigo.vivi@intel.comSigned-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com>
-
Nirmoy Das authored
The 'create' parameter in exec_queue_user_extensions was always true. This commit removes the dead parameter and all the relevant dead code. v2: rebase. Signed-off-by:
Nirmoy Das <nirmoy.das@intel.com> Reviewed-by:
-
Lucas De Marchi authored
With dynamic load-balancing disabled on the compute side, there's no reason left to enable WA 16015675438. Drop it from both PVC and DG2. Note that this can be done because now the driver always set a fixed partition of EUs during initialization via the ccs_mode configuration. Cc: Mateusz Jablonski <mateusz.jablonski@intel.com> Cc: Michal Mrozek <michal.mrozek@intel.com> Reviewed-by:
Michal Mrozek <michal.mrozek@intel.com> Acked-by:
Mateusz Jablonski <mateusz.jablonski@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240304233103.1687412-1-lucas.demarchi@intel.comSigned-off-by:
-
Suraj Kandpal authored
Enable HDCP for Xe by defining functions which take care of interaction of HDCP as a client with the GSC CS interface. Add intel_hdcp_gsc_message to Makefile and add corresponding changes to xe_hdcp_gsc.c to make it build. --v2 -add kfree at appropriate place [Daniele] -remove useless define [Daniele] -move host session logic to xe_gsc_submit.c [Daniele] -call xe_gsc_check_and_update_pending directly in an if condition [Daniele] -use xe_device instead of drm_i915_private [Daniele] --v3 -use xe prefix for newly exposed function [Daniele] -remove client specific defines from intel_gsc_mtl_header [Daniele] -add missing kfree() [Daniele] -have NULL check for hdcp_message in finish function [Daniele] -dont have too many variable declarations in the same line [Daniele] --v4 -don't point the hdcp_message structure in xe_device to anything until it properly gets initialized [Daniele] --v5 -Squash commits for buildability --v6 -Order includes alphabetically [Lucas] Signed-off-by:
Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by:
Arun R Murthy <arun.r.murthy@intel.com> Signed-off-by:
Mika Kahola <mika.kahola@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240306024247.1857881-6-suraj.kandpal@intel.com
-
Suraj Kandpal authored
Expose gsc_proxy_init_done so that we can check if gsc proxy has been initialized or not. --v2 -Check if GSC FW is enabled before taking forcewake ref [Daniele] --v3 -Directly call proxy check function inside if condition Signed-off-by:
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by:
-
Suraj Kandpal authored
Use xe_device struct instead of drm_i915_private so as to not cause confusion and comply with Xe standards as drm_i915_private is xe_device under the hood. --v2 -Fix commit message [Daniele] Signed-off-by:
-
Suraj Kandpal authored
Move intel_hdcp_gsc_message definition into intel_hdcp_gsc.c so that intel_hdcp_gsc_message can be redefined for xe as needed. --v2 -Correct commit message to reflect what patch is actually doing [Arun] Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Signed-off-by:
-
Matthew Brost authored
Forcewakes are not required for communication with the GuC via CTB as it is a memory based interfaced. Acquring forcewakes takes considerable time. With that, do not grab a forcewake when issuing a GGTT TLB invalidation via the GuC. Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Signed-off-by:
Matthew Brost <matthew.brost@intel.com> Reviewed-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240229194520.200642-1-matthew.brost@intel.com
-
Matt Roper authored
ARL-H uses the same media and display IP as MTL, and a version 12.74 graphics IP (referred to as Xe_LPG+). From a driver point of view, we should be able to just treat the whole platform as MTL and rely on GRAPHICS_VERx100 checks to handle any spots where ARL's Xe_LPG+ needs different handling from MTL's Xe_LPG (i.e., workarounds). v2: Resolve conflict and Reorder PCI ids in sorted order v3: Append signed-off-by commiter to this commit Bspec: 55420 Signed-off-by:
Dnyaneshwar Bhadane <dnyaneshwar.bhadane@intel.com> Reviewed-by:
Matt Atwood <matthew.s.atwood@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240229070806.3402641-4-dnyaneshwar.bhadane@intel.com
-
Matt Roper authored
A handful of Xe_LPG workarounds are also relevant to graphics version 12.74 as well. Extend the graphics version range for these workarounds accordingly. Signed-off-by:
-
Matt Roper authored
Graphics version 12.74 (which is technically called "Xe_LPG+") should be handled the same as versions Xe_LPG 12.70/12.71 by the KMD. Only the workaround lists (handled in the next patch) will be a bit different. Bspec: 55420 Signed-off-by:
-
- 05 Mar, 2024 1 commit
-
-
Matthew Brost authored
Rather than waiting for each evict / restore of pinned BOs to complete just wait on migrate exec queue to be idle once during suspend / resume. Cc: Matthew Auld <matthew.auld@intel.com> Signed-off-by:
Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240305173503.285223-1-matthew.brost@intel.com
-
- 04 Mar, 2024 7 commits
-
-
Rodrigo Vivi authored
With mem_access going away and pm_runtime getting called instead, we need to protect these against recursions. The put is asynchronous so there's no need to block it. However, for a proper balance, we need to ensure that the references are taken and restored regardless of the flow. So, let's convert them all to void and use some direct linux/pm_runtime functions. v2: Rebased and update commit message (Matt). Cc: Matthew Auld <matthew.auld@intel.com> Reviewed-by:
-
Rodrigo Vivi authored
Introduce the resume and get to fulfill the display need for checking if the device was actually resumed (or it is awake) and the reference was taken. Then we can convert the remaining cases to a void function and have individual functions for individual cases. Also, already start this new function protected from the runtime recursion, since runtime_pm will need to call for display functions for a proper D3Cold flow. Cc: Anshuman Gupta <anshuman.gupta@intel.com> Reviewed-by:
Anshuman Gupta <anshuman.gupta@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240301180526.643505-2-rodrigo.vivi@intel.comSigned-off-by:
-
Rodrigo Vivi authored
i915's intel_runtime_pm_get_if_in_use actually calls the pm_runtime_get_if_active() with ign_usage_count = false, but Xe was erroneously calling it with true because of the mem_access cases. This can lead to unnecessary references getting hold here and device never getting into the runtime suspended state. Let's use directly the 'if_in_use' function provided by linux/pm_runtime. Also, already start this new function protected from the runtime recursion, since runtime_pm will need to call for display functions for a proper D3Cold flow. v2: Update commit message based on Matt's feedback. Fix return condition of pm_runtime_get_if_in_use (Matt) Cc: Anshuman Gupta <anshuman.gupta@intel.com> Cc: Matthew Auld <matthew.auld@intel.com> Reviewed-by: -
Maarten Lankhorst authored
Dump the HWCTX and HWSP as part of LRC capture. Changes since v1: - Use same layout for HWSP and HWCTX as VM bo's, to simplify dumping. Signed-off-by:
José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240227131248.92910-3-maarten.lankhorst@linux.intel.com
-
Maarten Lankhorst authored
Add a xe_guc_exec_queue_snapshot_capture_delayed and xe_lrc_snapshot_capture_delayed function to capture the contents of LRC in the next patch. Signed-off-by:
-
Maarten Lankhorst authored
This allows the dumping of HWSP and HW Context without exporting more functions. Changes since v1: - GFP_KERNEL -> GFP_NOWAIT. (Souza) Signed-off-by:
-
Dafna Hirschfeld authored
Since 'grouped target' is used only in 'make' 4.3, it should be avoided. Replace it with 'multi-target pattern rule' which has the same behavior. Fixes: 9616e74b ("drm/xe: Add support for OOB workarounds") Signed-off-by:
Dafna Hirschfeld <dhirschfeld@habana.ai> Reviewed-by:
-
- 01 Mar, 2024 7 commits
-
-
Matthew Brost authored
If a page fault occurs on VM not in fault a ref can be leaked. Fix this. Fixes: dd08ebf6 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Signed-off-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240301041036.238471-1-matthew.brost@intel.com
-
Lucas De Marchi authored
LNCFCMOCS31[31:16] is read-only for DG2 and MTL, so it's not possible to check set it. While trying to set doesn't cause any issue, later when it's read back to check if the value got correctly recorded causes the test to fail. Now that test is reliable for an odd number of entries, reduce it so the last entry is ignored. Bspec: 55267 Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/1253 Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/1233 Cc: Matt Roper <matthew.d.roper@intel.com> Reviewed-by:
-
Lucas De Marchi authored
Refactor the mocs/l3cc kunit test to support odd number of entries. This switches out from the "check the register value" approach to check the entry value if it makes sense from the register read. This provides an easier output to reason about and cross check with bspec. Some code reordering and variable re-use was also done so the 2 functions follow more or less the same logic. Reviewed-by:
-
Lucas De Marchi authored
The warn-once in __init_mocs_table() to make sure there's an index set for unused entries is more a sanity check that should be done as the first thing in that function. The kunit test replicates the same check, so also move it up and turn it into a failure condition for the test. Reviewed-by:
-
Lucas De Marchi authored
Make sure to log if number of entries are l3cc or mocs so it doesn't depend on the context. Reviewed-by:
-
Lucas De Marchi authored
There's no reason to keep the assignment an condition in the same statement, particularly making use of the comma operator. Improve readability by doing each step on its own statement. This will make supporting odd number of entries more easily. Reviewed-by:
-
Matthew Brost authored
Need to include io-64-nonatomic-lo-hi.h for writeq function. Commit 3121fed0 ("drm/xe: Cleanup some layering in GGTT") removed the xe_mmio.h include so lost the indirect include. Add it where it's needed. Fixes: 3121fed0 ("drm/xe: Cleanup some layering in GGTT") Closes: https://lore.kernel.org/oe-kbuild-all/202402241903.R5J8hKVI-lkp@intel.com/Reported-by:
-
- 29 Feb, 2024 3 commits
-
-
Matt Roper authored
The LRCs on some of our newer platforms appear to contain a few GPU instructions that weren't handled in our LRC parser. Add the relevant instruction names and opcodes so that our debugfs LRC dumps will properly indicate what these are. Bspec: 55866, 64848, 46931 Signed-off-by:
Ravi Kumar Vodapalli <ravi.kumar.vodapalli@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240222184009.6857-2-matthew.d.roper@intel.com
-
Mika Kuoppala authored
When sync binds were reworked and worker removed, async_ops became obsolete. Remove it. Fixes: f3e9b1f4 ("drm/xe: Remove async worker and rework sync binds") Signed-off-by:
Francois Dugast <francois.dugast@intel.com> Signed-off-by:
-
Priyanka Dandamudi authored
Add move_lacks_source detail to xe_bo_move trace to make it readable that is to check if it is migrate clear or migrate copy. Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Signed-off-by:
Priyanka Dandamudi <priyanka.dandamudi@intel.com> Reviewed-by:
Thomas Hellström <thomas.hellstrom@linux.intel.com> Fixes: a0df2cc8 ("drm/xe/xe_bo_move: Enhance xe_bo_move trace") Signed-off-by:
-
- 28 Feb, 2024 6 commits
-
-
Zhanjun Dong authored
init_steering_dss need topology dss mask to be init ahead. Fixed by moving xe_gt_topology_init ahead of xe_gt_mcr_init Fixes: bf8ec3c3 ("drm/xe: Initialize GuC earlier during probe") Cc: Michał Winiarski <michal.winiarski@intel.com> Signed-off-by:
Zhanjun Dong <zhanjun.dong@intel.com> Reviewed-by:
-
Arnd Bergmann authored
This function does not build on 32-bit targets when the compiler fails to reduce DIV_ROUND_UP() into a shift: ld.lld: error: undefined symbol: __aeabi_uldivmod >>> referenced by xe_migrate.c >>> drivers/gpu/drm/xe/xe_migrate.o:(pte_update_size) in archive vmlinux.a There are two instances in this function. Change the first to use an open-coded shift with the same behavior, and the second one to a 32-bit calculation, which is sufficient here as the size is never more than 2^32 pages (16TB). Fixes: 237412e4 ("drm/xe: Enable 32bits build") Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Reviewed-by:
-
Arnd Bergmann authored
clang complains about a nonsensical test on builds with a 32-bit phys_addr_t, which means resizing will always fail: drivers/gpu/drm/xe/xe_mmio.c:109:23: error: result of comparison of constant 4294967296 with expression of type 'resource_size_t' (aka 'unsigned int') is always false [-Werror,-Wtautological-constant-out-of-range-compare] 109 | root_res->start > 0x100000000ull) | ~~~~~~~~~~~~~~~ ^ ~~~~~~~~~~~~~~ Previously, BAR resize was always disallowed on 32-bit kernels, but this apparently changed recently. Since 32-bit machines can in theory support PAE/LPAE for large address spaces, this may end up useful, so change the driver to shut up the warning but still work when phys_addr_t/resource_size_t is 64 bit wide. Fixes: 9a6e6c14 ("drm/xe/mmio: Use non-atomic writeq/readq variant for 32b") Fixes: 237412e4 ("drm/xe: Enable 32bits build") Signed-off-by: -
Arnd Bergmann authored
When the driver is built-in but the tests are in loadable modules, the helpers don't actually get put into the driver: ERROR: modpost: "xe_kunit_helper_alloc_xe_device" [drivers/gpu/drm/xe/tests/xe_test.ko] undefined! Change the Makefile to ensure they are always part of the driver even when the rest of the kunit tests are in loadable modules. Fixes: 5095d13d ("drm/xe/kunit: Define helper functions to allocate fake xe device") Signed-off-by:
-
Mika Kuoppala authored
If user fence was provided for MAP in vm_bind_ioctl and it has still not been signalled, deny UNMAP of said vma with EBUSY as long as unsignalled fence exists. This guarantees that MAP vs UNMAP sequences won't escape under the radar if we ever want to track the client's state wrt to completed and accessible MAPs. By means of intercepting the ufence release signalling. v2: find ufence with num_fences > 1 (Matt) v3: careful on clearing vma ufence (Matt) Link: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/1159 Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Signed-off-by:
-
Mika Kuoppala authored
By allowing getting reference to user fence, we can control the lifetime outside of sync entries. This is needed to allow vma to track the associated user fence that was provided with bind ioctl. v2: xe_user_fence can be kept opaque (Jani, Matt) v3: indent fix (Matt) Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Signed-off-by:
-
- 26 Feb, 2024 4 commits
-
-
Matthew Brost authored
Timing out of signaled jobs can happen during regular operations (e.g. an exec queue closed immediately after last fence signaled). The TDR can pass the worker which free jobs. Rather than running through the TDR if signaled job is found, simply free it without any debug messages. Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reported-by:
-
Paulo Zanoni authored
Mesa has been issuing a single bind operation per ioctl since xe.ko changed to GPUVA due xe.ko bug #746. If I change Mesa to try again to issue every single bind operation it can in the same ioctl, it hits the MAX_BINDS assertion when running Vulkan conformance tests. Test dEQP-VK.sparse_resources.transfer_queue.3d.rgba32i.1024_128_8 issues 960 bind operations in a single ioctl, it's the most I could find in the conformance suite. I don't see a reason to keep the MAX_BINDS restriction: it doesn't seem to be preventing any specific issue. If the number is too big for the memory allocations, then those will fail. Nothing related to num_binds seems to be using the stack. Let's just get rid of it. Fixes: dd08ebf6 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Testcase: dEQP-VK.sparse_resources.transfer_queue.3d.rgba32i.1024_128_8 References: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/746 Cc: Matthew Brost <matthew.brost@intel.com> Signed-off-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by:
-
Matthew Brost authored
Use vmalloc in effort to allow a user pass in a large number of binds in an IOCTL (mesa use case). Also use array allocations rather open coding the size calculation. v2: Use __GFP_ACCOUNT for allocations (Thomas) Fixes: dd08ebf6 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Signed-off-by:
-
Francois Dugast authored
The infrastructure to query GuC firmware version is already in place. It is extended with a new micro-controller type to query the HuC firmware version. It can be used from user space to know if HuC is running. Cc: John Harrison <John.C.Harrison@Intel.com> Cc: Francois Dugast <francois.dugast@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by:
John Harrison <John.C.Harrison@Intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240208183539.185095-2-jose.souza@intel.com
-
