- Jun 11, 2024
-
-
Vignesh Raman authored
Signed-off-by:Vignesh Raman <vignesh.raman@collabora.com>
-
Vignesh Raman authored
Add job that runs igt on top of vkms. Acked-by:
Maíra Canal <mcanal@igalia.com> Acked-by:
Helen Koike <helen.koike@collabora.com> Signed-off-by:
Jessica Zhang <quic_jesszhan@quicinc.com> Tested-by:
Maxime Ripard <mripard@kernel.org> Signed-off-by:
-
- May 28, 2024
-
-
Vignesh Raman authored
Now the testlist is used from IGT build, so update xfails with the new testlist. Set the timeout of all i915 jobs to 1h30m since some jobs takes more than 1 hour to complete. Reviewed-by:
Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by:
-
- May 27, 2024
-
-
Vignesh Raman authored
Skip driver specific tests and skip kms tests for panfrost driver since it is not a kms driver. Reviewed-by:
-
Vignesh Raman authored
test-list.txt and test-list-full.txt are not generated for cross-builds and they are required by drm-ci for testing arm32 targets. This is fixed in igt-gpu-tools. So uprev IGT to include the commit which fixes this issue. Also disable building xe driver tests for non-intel platforms. Reviewed-by:
-
Vignesh Raman authored
Stop vendoring the testlist into the kernel. Instead, use the testlist from the IGT build to ensure we do not miss renamed or newly added tests. Signed-off-by: -
Vignesh Raman authored
Mesa uses structured logs for logging and debug purpose, https://mesa.pages.freedesktop.org/-/mesa/-/jobs/59165650/artifacts/results/job_detail.json Since drm-ci uses the mesa scripts, add the farm variable and update the device type for missing jobs. Signed-off-by:
-
Vignesh Raman authored
zlib.net is not allowing tarball download anymore and results in below error in kernel+rootfs_arm32 container build, urllib.error.HTTPError: HTTP Error 403: Forbidden urllib.error.HTTPError: HTTP Error 415: Unsupported Media Type Uprev mesa to latest version which includes a fix for this issue. mesa/mesa@908f444e Use id_tokens for JWT authentication. Since s3 bucket is migrated to mesa-rootfs, update the variables accordingly. Also copy helper scripts to install, so that the ci jobs can use these scripts for logging. Signed-off-by:
-
- May 08, 2024
-
-
Lucas De Marchi authored
-
Lucas De Marchi authored
-
Lucas De Marchi authored
-
Lucas De Marchi authored
# Conflicts: # drivers/gpu/drm/xe/xe_device.h # drivers/gpu/drm/xe/xe_vm.c
-
Lucas De Marchi authored
-
Lucas De Marchi authored
-
Lucas De Marchi authored
-
Lucas De Marchi authored
-
Lucas De Marchi authored
# Conflicts: # drivers/gpu/drm/xe/compat-i915-headers/i915_drv.h
-
Lucas De Marchi authored
-
Lucas De Marchi authored
-
- May 07, 2024
-
-
Lucas De Marchi authored
Zero-length arrays are deprecated and flexible arrays should be used instead: https://www.kernel.org/doc/html/v6.9-rc7/process/deprecated.html#zero-length-and-one-element-arrays Reported-by:
kernel test robot <lkp@intel.com> Reported-by:
Julia Lawall <julia.lawall@inria.fr> Closes: https://lore.kernel.org/r/202405051824.AmjAI5Pg-lkp@intel.com/ Fixes: dd08ebf6 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Cc: Matthew Brost <matthew.brost@intel.com> Reviewed-by:
Matthew Brost <matthew.brost@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240506141917.205714-1-lucas.demarchi@intel.com Signed-off-by:
Lucas De Marchi <lucas.demarchi@intel.com>
-
mwajdecz authored
Some explicit includes are needed only from the xe_device.c. And there is no need for redundant forward declarations. Signed-off-by:
Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240507110959.2747-4-michal.wajdeczko@intel.com
-
mwajdecz authored
While xe_force_wake.h is now included from the xe_device.h, we want to drop that include as we don't need it there. Explicitly include xe_force_wake.h where needed. Signed-off-by:
-
mwajdecz authored
While xe_assert.h is now included and used by the xe_force_wake.h, we want to stop include xe_force_wake.h from xe_device.h as it's not needed there. Explicitly include xe_assert.h where needed. Signed-off-by:
-
When user closes exec queue soon after job submission, we are generating error coredump. Instead check if exec queue is killed during job timeout then skip error coredump capture. V2: - Just skip error capture - MattB Signed-off-by:
Tejas Upadhyay <tejas.upadhyay@intel.com> Reviewed-by:
-
Janusz Krzysztofik authored
This reverts commit 1f33dc0c. There was a patch supposed to fix an issue of illegal attempts to free a still active i915 VMA object when parking a GT believed to be idle, reported by CI on 2-GT Meteor Lake. As a solution, an extra wakeref for a Primary GT was acquired from i915_gem_do_execbuffer() -- see commit f56fe3e9 ("drm/i915: Fix a VMA UAF for multi-gt platform"). However, that fix occurred insufficient -- the issue was still reported by CI. That wakeref was released on exit from i915_gem_do_execbuffer(), then potentially before completion of the request and deactivation of its associated VMAs. Moreover, CI reports indicated that single-GT platforms also suffered sporadically from the same race. Since that issue was fixed by another commit f3c71b2d ("drm/i915/vma: Fix UAF on destroy against retire race"), the changes introduced by that insufficient fix were dropped as no longer useful. However, that series resulted in another VMA UAF scenario now being triggered in CI. <4> [260.290809] ------------[ cut here ]------------ <4> [260.290988] list_del corruption. prev->next should be ffff888118c5d990, but was ffff888118c5a510. (prev=ffff888118c5a510) <4> [260.291004] WARNING: CPU: 2 PID: 1143 at lib/list_debug.c:62 __list_del_entry_valid_or_report+0xb7/0xe0 .. <4> [260.291055] CPU: 2 PID: 1143 Comm: kms_plane Not tainted 6.9.0-rc2-CI_DRM_14524-ga25d180c6853+ #1 <4> [260.291058] Hardware name: Intel Corporation Meteor Lake Client Platform/MTL-P LP5x T3 RVP, BIOS MTLPFWI1.R00.3471.D91.2401310918 01/31/2024 <4> [260.291060] RIP: 0010:__list_del_entry_valid_or_report+0xb7/0xe0 ... <4> [260.291087] Call Trace: <4> [260.291089] <TASK> <4> [260.291124] i915_vma_reopen+0x43/0x80 [i915] <4> [260.291298] eb_lookup_vmas+0x9cb/0xcc0 [i915] <4> [260.291579] i915_gem_do_execbuffer+0xc9a/0x26d0 [i915] <4> [260.291883] i915_gem_execbuffer2_ioctl+0x123/0x2a0 [i915] ... <4> [260.292301] </TASK> ... <4> [260.292506] ---[ end trace 0000000000000000 ]--- <4> [260.292782] general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6ca3: 0000 [#1] PREEMPT SMP NOPTI <4> [260.303575] CPU: 2 PID: 1143 Comm: kms_plane Tainted: G W 6.9.0-rc2-CI_DRM_14524-ga25d180c6853+ #1 <4> [260.313851] Hardware name: Intel Corporation Meteor Lake Client Platform/MTL-P LP5x T3 RVP, BIOS MTLPFWI1.R00.3471.D91.2401310918 01/31/2024 <4> [260.326359] RIP: 0010:eb_validate_vmas+0x114/0xd80 [i915] ... <4> [260.428756] Call Trace: <4> [260.431192] <TASK> <4> [639.283393] i915_gem_do_execbuffer+0xd05/0x26d0 [i915] <4> [639.305245] i915_gem_execbuffer2_ioctl+0x123/0x2a0 [i915] ... <4> [639.411134] </TASK> ... <4> [639.449979] ---[ end trace 0000000000000000 ]--- We defer actually closing, unbinding and destroying a VMA until next idle point, or until the object is freed in the meantime. By postponing the unbind, we allow for the VMA to be reopened by the client, avoiding the work required to rebind the VMA. Starting from commit b0647a5e ("drm/i915: Avoid live-lock with i915_vma_parked()"), we assume that as long as a GT is held idle, no VMA would be reopened while we destroy them. That assumption is no longer true in multi-GT configurations, where a VMA we reopen may be handled by a GT different from the one that we already keep active via its engine while we set up an execbuf request. Restoring the extra GT0 PM wakeref removed from i915_gem_do_execbuffer() processing path seems to fix this issue. Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/10608 Signed-off-by:
Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Nirmoy Das <nirmoy.das@linux.intel.com> Reviewed-by:
Nirmoy Das <nirmoy.das@linux.intel.com> Fixes: 1f33dc0c ("drm/i915: Remove extra multi-gt pm-references") Link: https://patchwork.freedesktop.org/patch/msgid/20240506180253.96858-2-janusz.krzysztofik@linux.intel.com Signed-off-by:
-
Francois Dugast authored
Fix some typos and add / remove / change a few words to improve readability and prevent some ambiguities. Signed-off-by:
Francois Dugast <francois.dugast@intel.com> Reviewed-by:
-
Douglas Anderson authored
The debug print clearly lacks a \n at the end. Add it. Fixes: 8f86c82a ("drm/connector: demote connector force-probes for non-master clients") Reviewed-by:
Abhinav Kumar <quic_abhinavk@quicinc.com> Reviewed-by:
Simon Ser <contact@emersion.fr> Reviewed-by:
Douglas Anderson <dianders@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240502153234.1.I2052f01c8d209d9ae9c300b87c6e4f60bd3cc99e@changeid
-
Karthikeyan Ramasubramanian authored
Starting BDB version 239, hdr_dpcd_refresh_timeout is introduced to backlight BDB data. Commit 70003456 ("drm/i915/bios: Define more BDB contents") updated the backlight BDB data accordingly. This broke the parsing of backlight BDB data in VBT for versions 236 - 238 (both inclusive) and hence the backlight controls are not responding on units with the concerned BDB version. backlight_control information has been present in backlight BDB data from at least BDB version 191 onwards, if not before. Hence this patch extracts the backlight_control information for BDB version 191 or newer. Tested on Chromebooks using Jasperlake SoC (reports bdb->version = 236). Tested on Chromebooks using Raptorlake SoC (reports bdb->version = 251). v2: removed checking the block size of the backlight BDB data [vsyrjala: this is completely safe thanks to commit e163cfb4 ("drm/i915/bios: Make copies of VBT data blocks")] Fixes: 70003456 ("drm/i915/bios: Define more BDB contents") Cc: stable@vger.kernel.org Cc: Jani Nikula <jani.nikula@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
Karthikeyan Ramasubramanian <kramasub@chromium.org> Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240221180622.v2.1.I0690aa3e96a83a43b3fc33f50395d334b2981826@changeid Signed-off-by:
-
Ville Syrjälä authored
drm_color_ctm_3x4 is some undocumented amgdpu private uapi and thus has no business being in drm_mode.h. At least move it to some amdgpu specific header, albeit with the wrong namespace as maybe something somewhere is using this already? Cc: Harry Wentland <harry.wentland@amd.com> Cc: Joshua Ashton <joshua@froggi.es> Cc: Alex Deucher <alexander.deucher@amd.com> Fixes: 6872a189 ("drm/amd/display: Add 3x4 CTM support for plane CTM") Signed-off-by:
Harry Wentland <harry.wentland@amd.com>
-
Starting BDB version 239, hdr_dpcd_refresh_timeout is introduced to backlight BDB data. Commit 70003456 ("drm/i915/bios: Define more BDB contents") updated the backlight BDB data accordingly. This broke the parsing of backlight BDB data in VBT for versions 236 - 238 (both inclusive) and hence the backlight controls are not responding on units with the concerned BDB version. backlight_control information has been present in backlight BDB data from at least BDB version 191 onwards, if not before. Hence this patch extracts the backlight_control information for BDB version 191 or newer. Tested on Chromebooks using Jasperlake SoC (reports bdb->version = 236). Tested on Chromebooks using Raptorlake SoC (reports bdb->version = 251). v2: removed checking the block size of the backlight BDB data [vsyrjala: this is completely safe thanks to commit e163cfb4 ("drm/i915/bios: Make copies of VBT data blocks")] Fixes: 70003456 ("drm/i915/bios: Define more BDB contents") Cc: stable@vger.kernel.org Cc: Jani Nikula <jani.nikula@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
mwajdecz authored
We don't need to include <linux/types.h>. We don't use struct xe_exec_queue here. We should sort forward declarations. Signed-off-by:
Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240506205254.2659-1-michal.wajdeczko@intel.com
-
- May 06, 2024
-
-
Chaitanya Kumar Borah authored
Intel hardware is capable of programming the Maud/Naud SDPs on its own based on real-time clocks. While doing so, it takes care of any deviations from the theoretical values. Programming the registers explicitly with static values can interfere with this logic. Therefore, let the HW decide the Maud and Naud SDPs on it's own. Cc: stable@vger.kernel.org # v5.17 Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/8097 Co-developed-by:
Kai Vehmanen <kai.vehmanen@intel.com> Signed-off-by:
Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com> Reviewed-by:
Uma Shankar <uma.shankar@intel.com> Signed-off-by:
Animesh Manna <animesh.manna@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240430091825.733499-1-chaitanya.kumar.borah@intel.com (cherry picked from commit 8e056b50) Signed-off-by:
-
Andi Shyti authored
We missed setting the CCS mode during resume and engine resets. Create a workaround to be added in the engine's workaround list. This workaround sets the XEHP_CCS_MODE value at every reset. The issue can be reproduced by running: $ clpeak --kernel-latency Without resetting the CCS mode, we encounter a fence timeout: Fence expiration time out i915-0000:03:00.0:clpeak[2387]:2! Fixes: 6db31251 ("drm/i915/gt: Enable only one CCS for compute workload") Reported-by:
Gnattu OC <gnattuoc@me.com> Closes: drm/i915/kernel#10895 Signed-off-by:
Andi Shyti <andi.shyti@linux.intel.com> Cc: Chris Wilson <chris.p.wilson@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: <stable@vger.kernel.org> # v6.2+ Tested-by:
Krzysztof Gibala <krzysztof.gibala@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240426000723.229296-1-andi.shyti@linux.intel.com (cherry picked from commit 4cfca03f) Signed-off-by:
-
Matthew Brost authoredSystem work queues are shared, use a dedicated work queue for G2H processing to avoid G2H processing getting block behind system tasks. Fixes: dd08ebf6 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Cc: <stable@vger.kernel.org> Signed-off-by:
-
This is useful to check mocs configuration. Tests/Tools can use this debugfs entry to get mocs info. v2: Address review comments. Change debugfs output style similar to pat debugfs. (Lucas De Marchi) v3: rebase. v4: Address review comments. Use function pointer inside ops struct. Update Test-with links. Remove usage of flags wherever not required. (Lucas De Marchi) v5: Address review comments. Move register defines. Modify mocs info struct to avoid holes. (Luca De Marchi) Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by:
Janga Rahul Kumar <janga.rahul.kumar@intel.com> Reviewed-by:
-
Relocate regs_are_mcr funciton to a higher position in the file for improved visibility. Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by:
-
Nirmoy Das authored
The default behavior of device atomics depends on the VM type and buffer allocation types. Device atomics are expected to function with all types of allocations for traditional applications/APIs. Additionally, in compute/SVM API scenarios with fault mode or LR mode VMs, device atomics must work with single-region allocations. In all other cases device atomics should be disabled by default also on platforms where we know device atomics doesn't on work on particular allocations types. v3: fault mode requires LR mode so only check for LR mode to determine compute API(Jose). Handle SMEM+LMEM BO's migration to LMEM where device atomics is expected to work. (Brian). v2: Fix platform checks to correct atomics behaviour on PVC. Acked-by:Michal Mrozek <michal.mrozek@intel.com> Reviewed-by:
Oak Zeng <oak.zeng@intel.com> Acked-by:
Lionel Landwerlin <lionel.g.landwerlin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240430162529.21588-6-nirmoy.das@intel.com Signed-off-by:
Nirmoy Das <nirmoy.das@intel.com>
-
Nirmoy Das authored
A new helper function xe_bo_has_single_placement() to check if a BO has single placement. Reviewed-by:
José Roberto de Souza <jose.souza@intel.com> Acked-by:
-
Nirmoy Das authored
Add has_device_atomics_on_smem to specify that a device supports device atomics on system memory. Currently XE2 supports this so set this for XE2. v2: Set has_device_atomics_on_smem for all platform but PVC. Reviewed-by: -
Nirmoy Das authored
Move vm bind bo validation to a helper function to make the xe_vm_bind_ioctl() more readable. v2: Capture ret value of xe_vm_bind_ioctl_validate_bo(Matt B). Remove redundant coh_mode param. Reviewed-by:
-
