summaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)Author
2026-02-10drm/xe/nvlp: Attach MOCS table for nvlpDnyaneshwar Bhadane
The MOCS table for NVL-P is same as for Xe2/Xe3 platforms. Signed-off-by: Dnyaneshwar Bhadane <dnyaneshwar.bhadane@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patch.msgid.link/20260206-nvl-p-upstreaming-v3-13-636e1ad32688@intel.com Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
2026-02-10drm/xe/nvlp: Add NVL-P platform definitionShekhar Chauhan
Add platform definition along with device IDs for NVL-P. Here is the list of device descriptor fields and associated Bspec references: .dma_mask_size (Bspec 74198) .has_cached_pt (Bspec 71582) .has_display (Bspec 74196) .has_flat_ccs (Bspec 74110) .has_page_reclaim_hw_assist (Bspec 73451) .max_gt_per_tile (Bspec 74196) .va_bits (Bspec 74198) .vm_max_level (Bspec 59507) v2: - Add list of descriptor fields and Bspec references. (Matt) Signed-off-by: Shekhar Chauhan <shekhar.chauhan@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patch.msgid.link/20260206-nvl-p-upstreaming-v3-12-636e1ad32688@intel.com Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
2026-02-10drm/xe/xe3p_lpg: Set STLB bank hash mode to 4KBAradhya Bhatia
Since the dominant size of the pages referred in an i-gpu, such as Xe3p_LPG, will be 4KB, the HW default of mix of 64K and 2M for STLB bank hash mode does not make sense. Allow the SW to change it to 4KB Mode, for Xe3p_LPG. v2: - Add Bspec reference. (Matt) Bspec: 78248 Signed-off-by: Aradhya Bhatia <aradhya.bhatia@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patch.msgid.link/20260206-nvl-p-upstreaming-v3-11-636e1ad32688@intel.com Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
2026-02-10drm/xe/xe3p_lpg: Update LRC sizesGustavo Sousa
Like with previous generations, the engine context images for of both RCS and CCS in Xe3p_LPG contain a common layout at the end for the context related to the "Compute Pipeline". The size of the memory area written to such section varies; it depends on the type of preemption has taken place during the execution and type of command streamer instruction that was used on the pipeline. For Xe3p_LPG, the maximum possible size, including NOOPs for cache line alignment, is 4368 dwords, which would be the case of a mid-thread preemption during the execution of a COMPUTE_WALKER_2 instruction. The maximum size has increased in such a way that we need to update xe_gt_lrc_size() to match the new sizing requirement. When we add that to the engine-specific parts, we have: - RCS context image: 6672 dwords = 26688 bytes -> 7 pages - CCS context image: 5024 dwords = 20096 bytes -> 5 pages Bspec: 65182, 55793, 73590 Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patch.msgid.link/20260206-nvl-p-upstreaming-v3-10-636e1ad32688@intel.com Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
2026-02-10drm/xe/xe3p_lpg: Extend 'group ID' mask sizeMatt Roper
Xe3p_LPG extends the 'group ID' register mask by one bit. Since the new upper bit (12) was unused on previous platforms, we can safely extend the existing mask size without worrying about adding conditional version checks to the register programming. Bspec: 67175 Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Dnyaneshwar Bhadane <dnyaneshwar.bhadane@intel.com> Link: https://patch.msgid.link/20260206-nvl-p-upstreaming-v3-9-636e1ad32688@intel.com Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
2026-02-10drm/xe/xe3p_lpg: Drop unnecessary tuning settingsMatt Roper
From Xe3p onward, the desired settings are now the hardware's default values and the driver does not need to program them explicitly. Since 35.xx seems to be the starting point for "Xe3p" version numbers; we'll adjust the bounds of the old programming to stop at 34.99. Even though there's no platform with version 35.00 at the moment, this is simplest in case one does show up in the future. Bspec: 72161, 59928, 59930 Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Matt Atwood <matthew.s.atwood@intel.com> Link: https://patch.msgid.link/20260206-nvl-p-upstreaming-v3-8-636e1ad32688@intel.com Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
2026-02-10drm/xe/xe3p_lpg: Disable reporting of context switch status to GHWSPMatt Roper
By default the hardware reports context switch status into the global hardware status page. The Xe driver doesn't use this information for anything, and as of Xe3p, leaving this setting enabled will prevent other hardware optimizations from being enabled. Disable this reporting as suggested by the tuning guide. Bspec: 72161 Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Matt Atwood <matthew.s.atwood@intel.com> Link: https://patch.msgid.link/20260206-nvl-p-upstreaming-v3-7-636e1ad32688@intel.com Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
2026-02-10drm/xe/xe3p_lpg: Add LRC parsing for additional RCS engine stateMatt Roper
Xe3p_LPG adds some additional state instructions to the RCS engine's LRC. Add support for these to the debugfs LRC parser. Note that the bspec's LRC description page seems to have a few mistakes in the name/spelling of these new instructions (e.g., "3DSTATE_TASK_DATA_EXT" instead of "3DSTATE_TASK_SHADER_DATA_EXT" or "3DSTATE_VIEWPORT_STATE_POINTERS_CL_SF_2" instead of "3DSTATE_VIEWPORT_STATE_POINTERS_SF_CLIP_2"). Bspec: 65182 Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Matt Atwood <matthew.s.atwood@intel.com> Link: https://patch.msgid.link/20260206-nvl-p-upstreaming-v3-6-636e1ad32688@intel.com Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
2026-02-10drm/xe/xe3p_lpg: Add MCR steeringMatt Roper
Xe3p_LPG has nearly identical steering to Xe2 and Xe3. The only DSS/XeCore change from those IPs is an additional range from 0xDE00-0xDE7F that was previously reserved, so we can simply grow one of the existing ranges in the Xe2 table to include it. Similarly, the "instance0" table is also almost identical, but gains one additional PSMI range and requires a separate table. v2: - Drop reserved range from MEMPIPE range. (Dnyaneshwar) Bspec: 75242 Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Dnyaneshwar Bhadane <dnyaneshwar.bhadane@intel.com> Link: https://patch.msgid.link/20260206-nvl-p-upstreaming-v3-5-636e1ad32688@intel.com Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
2026-02-10drm/xe/xe3p_lpg: Add new PAT tableMatt Roper
PAT programming for Xe3p_LPG is more similar to Xe2 and Xe3 than it is to Xe3p_XPC. Compared to Xe2/Xe3 we have: * There's a slight update to the PAT table, where two new indices (18 and 19) are added to expose a new "WB - Transient App" L3 caching mode. * The PTA_MODE entry must be programmed differently according to the media type, and both differ from Xe2. There are no changes to the underlying registers, so the Xe2 ops can be re-used for Xe3p. Bspec: 71582, 74160 Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Matt Atwood <matthew.s.atwood@intel.com> Link: https://patch.msgid.link/20260206-nvl-p-upstreaming-v3-4-636e1ad32688@intel.com Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
2026-02-10drm/xe/pat: Differentiate between primary and media for PTAGustavo Sousa
Differently from currently supported platforms, in upcoming changes we will need to have different PAT entries for PTA based on the GT type. As such, let's prepare the code to support that by having two separate PTA-specific members in the pat struct, one for each type of GT. While at it, also fix the kerneldoc for pat_ats. Co-developed-by: Tejas Upadhyay <tejas.upadhyay@intel.com> Signed-off-by: Tejas Upadhyay <tejas.upadhyay@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patch.msgid.link/20260206-nvl-p-upstreaming-v3-3-636e1ad32688@intel.com Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
2026-02-10drm/xe/xe3p_lpg: Add initial workarounds for graphics version 35.10Shekhar Chauhan
Add the initial set of workarounds for Xe3p_LPG graphics version 35.10. v2: - Fix spacing style for field LOCALITYDIS. (Matt) - Drop unnecessary Wa_14025780377. (Matt) Signed-off-by: Shekhar Chauhan <shekhar.chauhan@intel.com> Co-developed-by: Nitin Gote <nitin.r.gote@intel.com> Signed-off-by: Nitin Gote <nitin.r.gote@intel.com> Co-developed-by: Tangudu Tilak Tirumalesh <tilak.tirumalesh.tangudu@intel.com> Signed-off-by: Tangudu Tilak Tirumalesh <tilak.tirumalesh.tangudu@intel.com> Co-developed-by: Mallesh Koujalagi <mallesh.koujalagi@intel.com> Signed-off-by: Mallesh Koujalagi <mallesh.koujalagi@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patch.msgid.link/20260206-nvl-p-upstreaming-v3-2-636e1ad32688@intel.com Co-developed-by: Gustavo Sousa <gustavo.sousa@intel.com> Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
2026-02-10drm/xe/xe3p_lpg: Add support for graphics IP 35.10Shekhar Chauhan
Add Xe3p_LPG graphics IP version 35.10. Xe3p_LPG supports all features described by XE2_GFX_FEATURES and also multi-queue feature on BCS and CCS engines. As such, create a new struct xe_graphics_desc named graphics_xe3p_lpg that inherits from XE2_GFX_FEATURES and also includes the necessary .multi_queue_engine_class_mask. Here is a list of fields and associated Bspec references for the members of the IP descriptor: .hw_engine_mask (Bspec 60149) .multi_queue_engine_class_mask (Bspec 74110) .has_asid (Bspec 71132) .has_atomic_enable_pte_bit (Bspec 59510, 74675) .has_indirect_ring_state (Bspec 67296) .has_range_tlb_inval (Bspec 71126) .has_usm (Bspec 59651) .has_64bit_timestamp (Bspec 60318) .num_geometry_xecore_fuse_regs (Bspec 62566, 67401, 67536) .num_compute_xecore_fuse_regs (Bspec 62565, 62561, 67537) v2: - Drop non-existing fields from the list in the commit message. (Matt) - Squash patch adding .multi_queue_engine_class_mask here. (Matt) - Rename graphics_xe3p to graphics_xe3p_lpg. (Matt) - Add fields .num_geometry_xecore_fuse_regs and .num_compute_xecore_fuse_regs after rebasing and inheriting commit 6acf3d3ed6c1 ("drm/xe: Move number of XeCore fuse registers to graphics descriptor"). (Gustavo) Signed-off-by: Shekhar Chauhan <shekhar.chauhan@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patch.msgid.link/20260206-nvl-p-upstreaming-v3-1-636e1ad32688@intel.com Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
2026-02-10drm/i915/overlay: remove dead code with MTL platform checksJani Nikula
Commit c5741c5c1122 ("drm/i915/display: Do not use stolen on MTL") added some checks for MTL in overlay code. However, this is never run on MTL. Clean it up. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260206125949.243643-1-jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-02-10drm/imagination: Mark FWCCB_CMD_UPDATE_STATS as knownMatt Coster
Suppress the "unknown type" warning when processing a FWCCB command of type CMD_UPDATE_STATS which is known but (currently) unused. Reviewed-by: Frank Binns <frank.binns@imgtec.com> Link: https://patch.msgid.link/20260206-improve-bad-fwccb-cmd-v1-2-831a852ca127@imgtec.com Signed-off-by: Matt Coster <matt.coster@imgtec.com>
2026-02-10drm/imagination: Improve handling of unknown FWCCB commandsMatt Coster
A couple small changes: - Validate the magic value at the head of FWCCB commands, and - Mask off the magic value before logging unknown command types to make them easier to interpret on sight. Reviewed-by: Frank Binns <frank.binns@imgtec.com> Link: https://patch.msgid.link/20260206-improve-bad-fwccb-cmd-v1-1-831a852ca127@imgtec.com Signed-off-by: Matt Coster <matt.coster@imgtec.com>
2026-02-10drm/i915/dp: Verify valid pipe BPP rangeImre Deak
Ensure that the pipe BPP range is valid after calculating the minimum and maximum pipe BPP values separately. Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260209133817.395823-2-imre.deak@intel.com
2026-02-10drm/i915/dp: Fix pipe BPP clamping due to HDRImre Deak
The pipe BPP value shouldn't be set outside of the source's / sink's valid pipe BPP range, ensure this when increasing the minimum pipe BPP value to 30 due to HDR. While at it debug print if the HDR mode was requested for a connector by setting the corresponding HDR connector property. This indicates if the requested HDR mode could not be enabled, since the selected pipe BPP is below 30, due to a sink capability or link BW limit. v2: - Also handle the case where the sink could support the target 30 BPP only in DSC mode due to a BW limit, but the sink doesn't support DSC or 30 BPP as a DSC input BPP. (Chaitanya) - Debug print the connector's HDR mode in the link config dump, to indicate if a BPP >= 30 required by HDR couldn't be reached. (Ankit) - Add Closes: trailer. (Ankit) - Don't print the 30 BPP-outside of valid BPP range debug message if the min BPP is already > 30 (and so a target BPP >= 30 required for HDR is ensured). Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/7052 Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/15503 Fixes: ba49a4643cf53 ("drm/i915/dp: Set min_bpp limit to 30 in HDR mode") Cc: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com> Cc: <stable@vger.kernel.org> # v6.18+ Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> # v1 Reviewed-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260209133817.395823-1-imre.deak@intel.com
2026-02-10drm/vc4: Switch private_obj initialization to atomic_create_stateMaxime Ripard
The vc4 driver relies on a drm_private_obj, that is initialized by allocating and initializing a state, and then passing it to drm_private_obj_init. Since we're gradually moving away from that pattern to the more established one relying on a atomic_create_state implementation, let's migrate this instance to the new pattern. Reviewed-by: Maíra Canal <mcanal@igalia.com> Link: https://patch.msgid.link/20260128-drm-private-obj-reset-v4-14-90891fa3d3b0@redhat.com Signed-off-by: Maxime Ripard <mripard@kernel.org>
2026-02-10drm/msm: dpu1: Switch private_obj initialization to atomic_create_stateMaxime Ripard
The MSM dpu1 driver relies on a drm_private_obj, that is initialized by allocating and initializing a state, and then passing it to drm_private_obj_init. Since we're gradually moving away from that pattern to the more established one relying on a atomic_create_state implementation, let's migrate this instance to the new pattern. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://patch.msgid.link/20260128-drm-private-obj-reset-v4-11-90891fa3d3b0@redhat.com Signed-off-by: Maxime Ripard <mripard@kernel.org>
2026-02-10drm/msm: mdp5: Switch private_obj initialization to atomic_create_stateMaxime Ripard
The MSM mdp5 driver relies on a drm_private_obj, that is initialized by allocating and initializing a state, and then passing it to drm_private_obj_init. Since we're gradually moving away from that pattern to the more established one relying on a atomic_create_state implementation, let's migrate this instance to the new pattern. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://patch.msgid.link/20260128-drm-private-obj-reset-v4-10-90891fa3d3b0@redhat.com Signed-off-by: Maxime Ripard <mripard@kernel.org>
2026-02-10drm/ingenic: Switch private_obj initialization to atomic_create_stateMaxime Ripard
The ingenic driver relies on two drm_private_objs, that are initialized by allocating and initializing a state, and then passing it to drm_private_obj_init. Since we're gradually moving away from that pattern to the more established one relying on a atomic_create_state implementation, let's migrate this instance to the new pattern. Acked-by: Paul Cercueil <paul@crapouillou.net> Link: https://patch.msgid.link/20260128-drm-private-obj-reset-v4-9-90891fa3d3b0@redhat.com Signed-off-by: Maxime Ripard <mripard@kernel.org>
2026-02-10drm/arm: komeda: Switch private_obj initialization to atomic_create_stateMaxime Ripard
The ARM komeda driver relies on a number of drm_private_objs, that are initialized by allocating and initializing a state, and then passing it to drm_private_obj_init. Since we're gradually moving away from that pattern to the more established one relying on a atomic_create_state implementation, let's migrate this instance to the new pattern. Acked-by: Liviu Dudau <liviu.dudau@arm.com> Acked-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://patch.msgid.link/20260128-drm-private-obj-reset-v4-8-90891fa3d3b0@redhat.com Signed-off-by: Maxime Ripard <mripard@kernel.org>
2026-02-10drm/dp_tunnel: Switch private_obj initialization to atomic_create_stateMaxime Ripard
The DP tunnel implementation relies on a drm_private_obj, that is initialized by allocating and initializing a state, and then passing it to drm_private_obj_init. Since we're gradually moving away from that pattern to the more established one relying on a atomic_create_state implementation, let's migrate this instance to the new pattern. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://patch.msgid.link/20260128-drm-private-obj-reset-v4-6-90891fa3d3b0@redhat.com Signed-off-by: Maxime Ripard <mripard@kernel.org>
2026-02-10drm/dp_mst: Switch private_obj initialization to atomic_create_stateMaxime Ripard
The DP MST implementation relies on a drm_private_obj, that is initialized by allocating and initializing a state, and then passing it to drm_private_obj_init. Since we're gradually moving away from that pattern to the more established one relying on a atomic_create_state implementation, let's migrate this instance to the new pattern. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://patch.msgid.link/20260128-drm-private-obj-reset-v4-5-90891fa3d3b0@redhat.com Signed-off-by: Maxime Ripard <mripard@kernel.org>
2026-02-10drm/bridge: Switch private_obj initialization to atomic_create_stateMaxime Ripard
The bridge implementation relies on a drm_private_obj, that is initialized by allocating and initializing a state, and then passing it to drm_private_obj_init. Since we're gradually moving away from that pattern to the more established one relying on a atomic_create_state implementation, let's migrate this instance to the new pattern. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patch.msgid.link/20260128-drm-private-obj-reset-v4-4-90891fa3d3b0@redhat.com Signed-off-by: Maxime Ripard <mripard@kernel.org>
2026-02-10drm/atomic-helper: Add private_obj atomic_create_state helperMaxime Ripard
Now that we have an atomic_create_state callback for drm_private_objs, we can provide a helper for it. It's somewhat different from the other similar helpers though, because we definitely expect drm_private_obj to be subclassed. It wouldn't make sense for a driver to use it as-is. So we can't provide a straight implementation of the atomic_create_state callback, but rather we provide the parts that will deal with the drm_private_obj initialization, and we will leave the allocation and initialization of the subclass to drivers. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patch.msgid.link/20260128-drm-private-obj-reset-v4-3-90891fa3d3b0@redhat.com Signed-off-by: Maxime Ripard <mripard@kernel.org>
2026-02-10drm/atomic: Add new atomic_create_state callback to drm_private_objMaxime Ripard
The drm_private_obj initialization was inconsistent with the rest of the KMS objects. Indeed, it required to pass a preallocated state in drm_private_obj_init(), while all the others objects would have a reset callback that would be called later on to create the state. However, reset really is meant to reset the hardware and software state. That it creates an initial state is a side-effect that has been used in all objects but drm_private_obj. This is made more complex since some drm_private_obj, the DisplayPort ones in particular, need to be persistent across and suspend/resume cycle, and such a cycle would call drm_mode_config_reset(). Thus, we need to add a new callback to allocate a pristine state for a given private object. This discussion has also came up during the atomic state readout discussion, so it might be introduced into the other objects later on. Until all drivers are converted to that new allocation pattern, we will only call it if the passed state is NULL. This will be removed eventually. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patch.msgid.link/20260128-drm-private-obj-reset-v4-2-90891fa3d3b0@redhat.com Signed-off-by: Maxime Ripard <mripard@kernel.org>
2026-02-10drm/atomic: Make drm_atomic_private_obj_init fallibleMaxime Ripard
Since we're going to move the drm_private_obj state allocation to a callback, we need to be able to deal with its possible failure. Make drm_private_obj_init return an error code on failure. Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patch.msgid.link/20260128-drm-private-obj-reset-v4-1-90891fa3d3b0@redhat.com Signed-off-by: Maxime Ripard <mripard@kernel.org>
2026-02-10drm/i915/color: Add failure handling in plane color pipeline initChaitanya Kumar Borah
The plane color pipeline initialization built up multiple colorop blocks inline, but did not reliably clean up partially constructed pipelines when an intermediate step failed. This could lead to leaked colorop objects and fragile error handling as the pipeline grows. Refactor the pipeline construction to use a common helper for adding colorop blocks. This centralizes allocation, initialization, and teardown logic, allowing the caller to reliably unwind all previously created colorops on failure. v2: - Refactor code to avoid repetition (Suraj) v3: - s/nvl/xe3plpd (Suraj) Signed-off-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://patch.msgid.link/20260202094202.2871478-10-chaitanya.kumar.borah@intel.com
2026-02-10drm/colorop: Use destroy callback for color pipeline teardownChaitanya Kumar Borah
Switch drm_colorop_pipeline_destroy() to use the driver-provided destroy callback instead of directly calling drm_colorop_cleanup() and freeing the object. This allows drivers that embed struct drm_colorop in driver-specific objects to perform correct teardown. Signed-off-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Reviewed-by: Alex Hung <alex.hung@amd.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://patch.msgid.link/20260202094202.2871478-9-chaitanya.kumar.borah@intel.com
2026-02-10drm/vkms: Remove drm_colorop_pipeline_destroy() from vkms_destroy()Chaitanya Kumar Borah
Now that colorops are cleaned from drm_mode_config_cleanup(), remove drm_colorop_pipeline_destroy() from vkms_destroy(). Signed-off-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Reviewed-by: Louis Chauvet <louis.chauvet@bootlin.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://patch.msgid.link/20260202094202.2871478-8-chaitanya.kumar.borah@intel.com
2026-02-10drm: Clean up colorop objects during mode_config cleanupChaitanya Kumar Borah
Tear down all registered drm_colorop objects during drm_mode_config_cleanup() by invoking their destroy callbacks. This ensures proper cleanup of color pipeline objects during DRM device removal. Signed-off-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Reviewed-by: Alex Hung <alex.hung@amd.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://patch.msgid.link/20260202094202.2871478-7-chaitanya.kumar.borah@intel.com
2026-02-10drm/i915/display: Hook up intel_colorop_destroyChaitanya Kumar Borah
i915 embeds struct drm_colorop inside struct intel_colorop, so the default drm_colorop_destroy() helper cannot be used. Add an intel_colorop_destroy() helper that performs common DRM cleanup and frees intel_colorop object. This ensures correct teardown of plane color pipeline objects. Signed-off-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://patch.msgid.link/20260202094202.2871478-6-chaitanya.kumar.borah@intel.com
2026-02-10drm/vkms: Hook up colorop destroy helper for plane pipelinesChaitanya Kumar Borah
Provide a drm_colorop_funcs instance for vkms color pipeline objects and hook up the common drm_colorop_destroy() helper as the destroy callback. Signed-off-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Reviewed-by: Alex Hung <alex.hung@amd.com> Reviewed-by: Louis Chauvet <louis.chauvet@bootlin.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://patch.msgid.link/20260202094202.2871478-5-chaitanya.kumar.borah@intel.com
2026-02-10drm/amd/display: Hook up colorop destroy helper for plane pipelinesChaitanya Kumar Borah
Provide a drm_colorop_funcs instance for amdgpu_dm color pipeline objects and hook up the common drm_colorop_destroy() helper as the destroy callback. Signed-off-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Reviewed-by: Alex Hung <alex.hung@amd.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://patch.msgid.link/20260202094202.2871478-4-chaitanya.kumar.borah@intel.com
2026-02-10drm: Allow driver-managed destruction of colorop objectsChaitanya Kumar Borah
Some drivers might want to embed struct drm_colorop inside driver-specific objects, similar to planes or CRTCs. In such cases, freeing only the drm_colorop is incorrect. Add a drm_colorop_funcs callback to allow drivers to provide a destroy hook that cleans up the full enclosing object. Make changes in helper functions to accept helper functions as argument. Pass NULL for now to retain current behavior. Signed-off-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Reviewed-by: Alex Hung <alex.hung@amd.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://patch.msgid.link/20260202094202.2871478-3-chaitanya.kumar.borah@intel.com
2026-02-10drm/colorop: Add destroy helper for colorop objectsChaitanya Kumar Borah
Add a helper that performs common cleanup and frees the associated object. This can be used by drivers if they do not require any driver-specific teardown. v2: - Add function documentation only before definition (Jani) Signed-off-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Reviewed-by: Alex Hung <alex.hung@amd.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://patch.msgid.link/20260202094202.2871478-2-chaitanya.kumar.borah@intel.com
2026-02-09Merge tag 'docs-7.0' of git://git.kernel.org/pub/scm/linux/kernel/git/docs/linuxLinus Torvalds
Pull documentation updates from Jonathan Corbet: "A slightly calmer cycle for docs this time around, though there is still a fair amount going on, including: - Some signs of life on the long-moribund Japanese translation - Documentation on policies around the use of generative tools for patch submissions, and a separate document intended for consumption by generative tools - The completion of the move of the documentation tools to tools/docs. For now we're leaving a /scripts/kernel-doc symlink behind to avoid breaking scripts - Ongoing build-system work includes the incorporation of documentation in Python code, better support for documenting variables, and lots of improvements and fixes - Automatic linking of man-page references -- cat(1), for example -- to the online pages in the HTML build ...and the usual array of typo fixes and such" * tag 'docs-7.0' of git://git.kernel.org/pub/scm/linux/kernel/git/docs/linux: (107 commits) doc: development-process: add notice on testing tools: sphinx-build-wrapper: improve its help message docs: sphinx-build-wrapper: allow -v override -q docs: kdoc: Fix pdfdocs build for tools docs: ja_JP: process: translate 'Obtain a current source tree' docs: fix 're-use' -> 'reuse' in documentation docs: ioctl-number: fix a typo in ioctl-number.rst docs: filesystems: ensure proc pid substitutable is complete docs: automarkup.py: Skip common English words as C identifiers Documentation: use a source-read extension for the index link boilerplate docs: parse_features: make documentation more consistent docs: add parse_features module documentation docs: jobserver: do some documentation improvements docs: add jobserver module documentation docs: kabi: helpers: add documentation for each "enum" value docs: kabi: helpers: add helper for debug bits 7 and 8 docs: kabi: system_symbols: end docstring phrases with a dot docs: python: abi_regex: do some improvements at documentation docs: python: abi_parser: do some improvements at documentation docs: add kabi modules documentation ...
2026-02-09Merge tag 'efi-next-for-v7.0' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi Pull EFI updates from Ard Biesheuvel: - Quirk the broken EFI framebuffer geometry on the Valve Steam Deck - Capture the EDID information of the primary display also on non-x86 EFI systems when booting via the EFI stub. * tag 'efi-next-for-v7.0' of git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi: efi: Support EDID information sysfb: Move edid_info into sysfb_primary_display sysfb: Pass sysfb_primary_display to devices sysfb: Replace screen_info with sysfb_primary_display sysfb: Add struct sysfb_display_info efi: sysfb_efi: Reduce number of references to global screen_info efi: earlycon: Reduce number of references to global screen_info efi: sysfb_efi: Fix efidrmfb and simpledrmfb on Valve Steam Deck efi: sysfb_efi: Convert swap width and height quirk to a callback efi: sysfb_efi: Fix lfb_linelength calculation when applying quirks efi: sysfb_efi: Replace open coded swap with the macro
2026-02-09Merge tag 'pm-6.20-rc1' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm Pull power management updates from Rafael Wysocki: "By the number of commits, cpufreq is the leading party (again) and the most visible change there is the removal of the omap-cpufreq driver that has not been used for a long time (good riddance). There are also quite a few changes in the cppc_cpufreq driver, mostly related to fixing its frequency invariance engine in the case when the CPPC registers used by it are not in PCC. In addition to that, support for AM62L3 is added to the ti-cpufreq driver and the cpufreq-dt-platdev list is updated for some platforms. The remaining cpufreq changes are assorted fixes and cleanups. Next up is cpuidle and the changes there are dominated by intel_idle driver updates, mostly related to the new command line facility allowing users to adjust the list of C-states used by the driver. There are also a few updates of cpuidle governors, including two menu governor fixes and some refinements of the teo governor, and a MAINTAINERS update adding Christian Loehle as a cpuidle reviewer. [Thanks for stepping up Christian!] The most significant update related to system suspend and hibernation is the one to stop freezing the PM runtime workqueue during system PM transitions which allows some deadlocks to be avoided. There is also a fix for possible concurrent bit field updates in the core device suspend code and a few other minor fixes. Apart from the above, several drivers are updated to discard the return value of pm_runtime_put() which is going to be converted to a void function as soon as everybody stops using its return value, PL4 support for Ice Lake is added to the Intel RAPL power capping driver, and there are assorted cleanups, documentation fixes, and some cpupower utility improvements. Specifics: - Remove the unused omap-cpufreq driver (Andreas Kemnade) - Optimize error handling code in cpufreq_boost_trigger_state() and make cpufreq_boost_trigger_state() return -EOPNOTSUPP if no policy supports boost (Lifeng Zheng) - Update cpufreq-dt-platdev list for tegra, qcom, TI (Aaron Kling, Dhruva Gole, and Konrad Dybcio) - Minor improvements to the cpufreq and cpumask rust implementation (Alexandre Courbot, Alice Ryhl, Tamir Duberstein, and Yilin Chen) - Add support for AM62L3 SoC to the ti-cpufreq driver (Dhruva Gole) - Update arch_freq_scale in the CPPC cpufreq driver's frequency invariance engine (FIE) in scheduler ticks if the related CPPC registers are not in PCC (Jie Zhan) - Assorted minor cleanups and improvements in ARM cpufreq drivers (Juan Martinez, Felix Gu, Luca Weiss, and Sergey Shtylyov) - Add generic helpers for sysfs show/store to cppc_cpufreq (Sumit Gupta) - Make the scaling_setspeed cpufreq sysfs attribute return the actual requested frequency to avoid confusion (Pengjie Zhang) - Simplify the idle CPU time granularity test in the ondemand cpufreq governor (Frederic Weisbecker) - Enable asym capacity in intel_pstate only when CPU SMT is not possible (Yaxiong Tian) - Update the description of rate_limit_us default value in cpufreq documentation (Yaxiong Tian) - Add a command line option to adjust the C-states table in the intel_idle driver, remove the 'preferred_cstates' module parameter from it, add C-states validation to it and clean it up (Artem Bityutskiy) - Make the menu cpuidle governor always check the time till the closest timer event when the scheduler tick has been stopped to prevent it from mistakenly selecting the deepest available idle state (Rafael Wysocki) - Update the teo cpuidle governor to avoid making suboptimal decisions in certain corner cases and generally improve idle state selection accuracy (Rafael Wysocki) - Remove an unlikely() annotation on the early-return condition in menu_select() that leads to branch misprediction 100% of the time on systems with only 1 idle state enabled, like ARM64 servers (Breno Leitao) - Add Christian Loehle to MAINTAINERS as a cpuidle reviewer (Christian Loehle) - Stop flagging the PM runtime workqueue as freezable to avoid system suspend and resume deadlocks in subsystems that assume asynchronous runtime PM to work during system-wide PM transitions (Rafael Wysocki) - Drop redundant NULL pointer checks before acomp_request_free() from the hibernation code handling image saving (Rafael Wysocki) - Update wakeup_sources_walk_start() to handle empty lists of wakeup sources as appropriate (Samuel Wu) - Make dev_pm_clear_wake_irq() check the power.wakeirq value under power.lock to avoid race conditions (Gui-Dong Han) - Avoid bit field races related to power.work_in_progress in the core device suspend code (Xuewen Yan) - Make several drivers discard pm_runtime_put() return value in preparation for converting that function to a void one (Rafael Wysocki) - Add PL4 support for Ice Lake to the Intel RAPL power capping driver (Daniel Tang) - Replace sprintf() with sysfs_emit() in power capping sysfs show functions (Sumeet Pawnikar) - Make dev_pm_opp_get_level() return value match the documentation after a previous update of the latter (Aleks Todorov) - Use scoped for each OF child loop in the OPP code (Krzysztof Kozlowski) - Fix a bug in an example code snippet and correct typos in the energy model management documentation (Patrick Little) - Fix miscellaneous problems in cpupower (Kaushlendra Kumar): * idle_monitor: Fix incorrect value logged after stop * Fix inverted APERF capability check * Use strcspn() to strip trailing newline * Reset errno before strtoull() * Show C0 in idle-info dump - Improve cpupower installation procedure by making the systemd step optional and allowing users to disable the installation of systemd's unit file (João Marcos Costa)" * tag 'pm-6.20-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: (65 commits) PM: sleep: core: Avoid bit field races related to work_in_progress PM: sleep: wakeirq: harden dev_pm_clear_wake_irq() against races cpufreq: Documentation: Update description of rate_limit_us default value cpufreq: intel_pstate: Enable asym capacity only when CPU SMT is not possible PM: wakeup: Handle empty list in wakeup_sources_walk_start() PM: EM: Documentation: Fix bug in example code snippet Documentation: Fix typos in energy model documentation cpuidle: governors: teo: Refine intercepts-based idle state lookup cpuidle: governors: teo: Adjust the classification of wakeup events cpufreq: ondemand: Simplify idle cputime granularity test cpufreq: userspace: make scaling_setspeed return the actual requested frequency PM: hibernate: Drop NULL pointer checks before acomp_request_free() cpufreq: CPPC: Add generic helpers for sysfs show/store cpufreq: scmi: Fix device_node reference leak in scmi_cpu_domain_id() cpufreq: ti-cpufreq: add support for AM62L3 SoC cpufreq: dt-platdev: Add ti,am62l3 to blocklist cpufreq/amd-pstate: Add comment explaining nominal_perf usage for performance policy cpufreq: scmi: correct SCMI explanation cpufreq: dt-platdev: Block the driver from probing on more QC platforms rust: cpumask: rename methods of Cpumask for clarity and consistency ...
2026-02-09drm/xe/mmio: Avoid double-adjust in 64-bit readsShuicheng Lin
xe_mmio_read64_2x32() was adjusting register addresses and then calling xe_mmio_read32(), which applies the adjustment again. This may shift accesses twice if adj_offset < adj_limit. There is no issue currently, as for media gt, adj_offset > adj_limit, so the 2nd adjust will be a no-op. But it may not work in future. To fix it, replace the adjusted-address comparison with a direct sanity check that ensures the MMIO address adjustment cutoff never falls within the 8-byte range of a 64-bit register. And let xe_mmio_read32() handle address translation. v2: rewrite the sanity check in a more natural way. (Matt) v3: Add Fixes tag. (Jani) Fixes: 07431945d8ae ("drm/xe: Avoid 64-bit register reads") Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Shuicheng Lin <shuicheng.lin@intel.com> Link: https://patch.msgid.link/20260130165621.471408-2-shuicheng.lin@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
2026-02-09drm/xe/vf: Allow VF to initialize MCR tablesMichal Wajdeczko
While VFs can't access MCR registers, it's still safe to initialize our per-platform MCR tables, as we might need them later in the LRC programming, as engines itself may access MCR steer registers and thanks to all our past fixes to the VF probe initialization order, VFs are able to use values of the fuse registers needed here. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Link: https://patch.msgid.link/20260207214428.5205-1-michal.wajdeczko@intel.com Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
2026-02-10nouveau: pci: quiesce GPU on shutdownLi Chen
Kexec reboot does not reset PCI devices. Invoking the full DRM/TTM teardown from ->shutdown can trigger WARNs when userspace still holds DRM file descriptors. Quiesce the GPU through the suspend path and then power down the PCI function so the next kernel can re-initialize the device from a consistent state. WARNING: drivers/gpu/drm/drm_mode_config.c:578 at drm_mode_config_cleanup+0x2e7/0x300, CPU#2: kexec/1300 Call Trace: <TASK> ? srso_return_thunk+0x5/0x5f ? enable_work+0x3a/0x100 nouveau_display_destroy+0x39/0x70 [nouveau c19e0da7fd83583a023f855c510d9a3903808734] nouveau_drm_device_fini+0x7b/0x1f0 [nouveau c19e0da7fd83583a023f855c510d9a3903808734] nouveau_drm_shutdown+0x52/0xc0 [nouveau c19e0da7fd83583a023f855c510d9a3903808734] pci_device_shutdown+0x35/0x60 device_shutdown+0x11c/0x1b0 kernel_kexec+0x13a/0x160 __do_sys_reboot+0x209/0x240 do_syscall_64+0x81/0x610 ? srso_return_thunk+0x5/0x5f ? __rtnl_unlock+0x37/0x70 ? srso_return_thunk+0x5/0x5f ? netdev_run_todo+0x63/0x570 ? netif_change_flags+0x54/0x70 ? srso_return_thunk+0x5/0x5f ? devinet_ioctl+0x1e5/0x790 ? srso_return_thunk+0x5/0x5f ? inet_ioctl+0x1e9/0x200 ? srso_return_thunk+0x5/0x5f ? srso_return_thunk+0x5/0x5f ? sock_do_ioctl+0x7d/0x130 ? srso_return_thunk+0x5/0x5f ? __x64_sys_ioctl+0x97/0xe0 ? srso_return_thunk+0x5/0x5f ? srso_return_thunk+0x5/0x5f ? do_syscall_64+0x23b/0x610 ? srso_return_thunk+0x5/0x5f ? put_user_ifreq+0x7a/0x90 ? srso_return_thunk+0x5/0x5f ? sock_do_ioctl+0x107/0x130 ? srso_return_thunk+0x5/0x5f ? __x64_sys_ioctl+0x97/0xe0 ? srso_return_thunk+0x5/0x5f ? do_syscall_64+0x81/0x610 ? srso_return_thunk+0x5/0x5f ? exc_page_fault+0x7e/0x1a0 entry_SYSCALL_64_after_hwframe+0x76/0x7e nouveau 0000:26:00.0: [drm] drm_WARN_ON(!list_empty(&fb->filp_head)) WARNING: drivers/gpu/drm/drm_framebuffer.c:833 at drm_framebuffer_free+0x73/0xa0, CPU#2: kexec/1300 Call Trace: <TASK> drm_mode_config_cleanup+0x248/0x300 ? __pfx___drm_printfn_dbg+0x10/0x10 ? drm_mode_config_cleanup+0x1dc/0x300 nouveau_display_destroy+0x39/0x70 [nouveau c19e0da7fd83583a023f855c510d9a3903808734] nouveau_drm_device_fini+0x7b/0x1f0 [nouveau c19e0da7fd83583a023f855c510d9a3903808734] nouveau_drm_shutdown+0x52/0xc0 [nouveau c19e0da7fd83583a023f855c510d9a3903808734] pci_device_shutdown+0x35/0x60 device_shutdown+0x11c/0x1b0 kernel_kexec+0x13a/0x160 __do_sys_reboot+0x209/0x240 do_syscall_64+0x81/0x610 ? srso_return_thunk+0x5/0x5f ? __rtnl_unlock+0x37/0x70 ? srso_return_thunk+0x5/0x5f ? netdev_run_todo+0x63/0x570 ? netif_change_flags+0x54/0x70 ? srso_return_thunk+0x5/0x5f ? devinet_ioctl+0x1e5/0x790 ? srso_return_thunk+0x5/0x5f ? inet_ioctl+0x1e9/0x200 ? srso_return_thunk+0x5/0x5f ? srso_return_thunk+0x5/0x5f ? sock_do_ioctl+0x7d/0x130 ? srso_return_thunk+0x5/0x5f ? __x64_sys_ioctl+0x97/0xe0 ? srso_return_thunk+0x5/0x5f ? srso_return_thunk+0x5/0x5f ? do_syscall_64+0x23b/0x610 ? srso_return_thunk+0x5/0x5f ? put_user_ifreq+0x7a/0x90 ? srso_return_thunk+0x5/0x5f ? sock_do_ioctl+0x107/0x130 ? srso_return_thunk+0x5/0x5f ? __x64_sys_ioctl+0x97/0xe0 ? srso_return_thunk+0x5/0x5f ? do_syscall_64+0x81/0x610 ? srso_return_thunk+0x5/0x5f ? exc_page_fault+0x7e/0x1a0 entry_SYSCALL_64_after_hwframe+0x76/0x7e WARNING: include/drm/ttm/ttm_resource.h:406 at nouveau_ttm_fini+0x257/0x270 [nouveau], CPU#2: kexec/1300 Call Trace: <TASK> nouveau_drm_device_fini+0x93/0x1f0 [nouveau c19e0da7fd83583a023f855c510d9a3903808734] nouveau_drm_shutdown+0x52/0xc0 [nouveau c19e0da7fd83583a023f855c510d9a3903808734] pci_device_shutdown+0x35/0x60 device_shutdown+0x11c/0x1b0 kernel_kexec+0x13a/0x160 __do_sys_reboot+0x209/0x240 do_syscall_64+0x81/0x610 ? srso_return_thunk+0x5/0x5f ? __rtnl_unlock+0x37/0x70 ? srso_return_thunk+0x5/0x5f ? netdev_run_todo+0x63/0x570 ? netif_change_flags+0x54/0x70 ? srso_return_thunk+0x5/0x5f ? devinet_ioctl+0x1e5/0x790 ? srso_return_thunk+0x5/0x5f ? inet_ioctl+0x1e9/0x200 ? srso_return_thunk+0x5/0x5f ? srso_return_thunk+0x5/0x5f ? sock_do_ioctl+0x7d/0x130 ? srso_return_thunk+0x5/0x5f ? __x64_sys_ioctl+0x97/0xe0 ? srso_return_thunk+0x5/0x5f ? srso_return_thunk+0x5/0x5f ? do_syscall_64+0x23b/0x610 ? srso_return_thunk+0x5/0x5f ? put_user_ifreq+0x7a/0x90 ? srso_return_thunk+0x5/0x5f ? sock_do_ioctl+0x107/0x130 ? srso_return_thunk+0x5/0x5f ? __x64_sys_ioctl+0x97/0xe0 ? srso_return_thunk+0x5/0x5f ? do_syscall_64+0x81/0x610 ? srso_return_thunk+0x5/0x5f ? exc_page_fault+0x7e/0x1a0 entry_SYSCALL_64_after_hwframe+0x76/0x7e Signed-off-by: Li Chen <me@linux.beauty> Reviewed-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com> Link: https://patch.msgid.link/20260121113646.111561-1-me@linux.beauty
2026-02-09drm/xe/guc: Add Wa_14025883347 for GuC DMA failure on resetSk Anirban
Prevent GuC firmware DMA failures during GuC-only reset by disabling idle flow and verifying SRAM handling completion. Without this, reset can be issued while SRAM handler is copying WOPCM to SRAM, causing GuC HW to get stuck. v2: Modify error message (Badal) Rename reg bit name (Daniele) Update WA skip condition (Daniele) Update SRAM handling logic (Daniele) v3: Reorder WA call (Badal) Wait for GuC ready status (Daniele) v4: Update reg name (Badal) Add comment (Daniele) Add extended graphics version (Daniele) Modify rules Signed-off-by: Sk Anirban <sk.anirban@intel.com> Reviewed-by: Badal Nilawar <badal.nilawar@intel.com> Acked-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Link: https://patch.msgid.link/20260202105313.3338094-4-sk.anirban@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
2026-02-09drm/i915/quirks: Fix device id for QUIRK_EDP_LIMIT_RATE_HBR2 entryAnkit Nautiyal
Update the device ID for Dell XPS 13 7390 2-in-1 in the quirk `QUIRK_EDP_LIMIT_RATE_HBR2` entry. The previous ID (0x8a12) was incorrect; the correct ID is 0x8a52. Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/5969 Fixes: 21c586d9233a ("drm/i915/dp: Add device specific quirk to limit eDP rate to HBR2") Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Cc: <stable@vger.kernel.org> # v6.18+ Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://patch.msgid.link/20251226043359.2553-1-ankit.k.nautiyal@intel.com (cherry picked from commit c7c30c4093cc11ff66672471f12599a555708343) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2026-02-09drm/xe: Add bounds check on pat_index to prevent OOB kernel read in madviseJia Yao
When user provides a bogus pat_index value through the madvise IOCTL, the xe_pat_index_get_coh_mode() function performs an array access without validating bounds. This allows a malicious user to trigger an out-of-bounds kernel read from the xe->pat.table array. The vulnerability exists because the validation in madvise_args_are_sane() directly calls xe_pat_index_get_coh_mode(xe, args->pat_index.val) without first checking if pat_index is within [0, xe->pat.n_entries). Although xe_pat_index_get_coh_mode() has a WARN_ON to catch this in debug builds, it still performs the unsafe array access in production kernels. v2(Matthew Auld) - Using array_index_nospec() to mitigate spectre attacks when the value is used v3(Matthew Auld) - Put the declarations at the start of the block Fixes: ada7486c5668 ("drm/xe: Implement madvise ioctl for xe") Reviewed-by: Matthew Auld <matthew.auld@intel.com> Cc: <stable@vger.kernel.org> # v6.18+ Cc: Matthew Brost <matthew.brost@intel.com> Cc: Shuicheng Lin <shuicheng.lin@intel.com> Cc: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Cc: "Thomas Hellström" <thomas.hellstrom@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Matthew Auld <matthew.auld@intel.com> Signed-off-by: Jia Yao <jia.yao@intel.com> Signed-off-by: Matthew Auld <matthew.auld@intel.com> Link: https://patch.msgid.link/20260205161529.1819276-1-jia.yao@intel.com
2026-02-09drm: verisilicon: suppress snprintf warning for pixel clock nameIcenowy Zheng
Although it's generally expected that the pixel clock ID will only have one decimal digit, this isn't enforced in vs_dc.c source code, and the compiler will argue about the buffer being not long enough. Enlarge the snprintf() buffer for generating pixel clock name to be enough for a UINT_MAX pixel clock ID in order to suppress the compiler warning. Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202602060154.ONBYvM9m-lkp@intel.com/ Signed-off-by: Icenowy Zheng <zhengxingda@iscas.ac.cn> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patch.msgid.link/20260207013255.2075294-1-zhengxingda@iscas.ac.cn
2026-02-09drm/self_refresh: replace use of system_wq with system_percpu_wqMarco Crivellari
Currently if a user enqueue a work item using schedule_delayed_work() the used wq is "system_wq" (per-cpu wq) while queue_delayed_work() use WORK_CPU_UNBOUND (used when a cpu is not specified). The same applies to schedule_work() that is using system_wq and queue_work(), that makes use again of WORK_CPU_UNBOUND. This lack of consistency cannot be addressed without refactoring the API. system_wq should be the per-cpu workqueue, yet in this name nothing makes that clear, so replace system_wq with system_percpu_wq. The old wq (system_wq) will be kept for a few release cycles. Suggested-by: Tejun Heo <tj@kernel.org> Signed-off-by: Marco Crivellari <marco.crivellari@suse.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patch.msgid.link/20251030162043.292468-4-marco.crivellari@suse.com
2026-02-09drm/probe-helper: replace use of system_wq with system_percpu_wqMarco Crivellari
Currently if a user enqueue a work item using schedule_delayed_work() the used wq is "system_wq" (per-cpu wq) while queue_delayed_work() use WORK_CPU_UNBOUND (used when a cpu is not specified). The same applies to schedule_work() that is using system_wq and queue_work(), that makes use again of WORK_CPU_UNBOUND. This lack of consistency cannot be addressed without refactoring the API. system_wq should be the per-cpu workqueue, yet in this name nothing makes that clear, so replace system_wq with system_percpu_wq. The old wq (system_wq) will be kept for a few release cycles. Suggested-by: Tejun Heo <tj@kernel.org> Signed-off-by: Marco Crivellari <marco.crivellari@suse.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patch.msgid.link/20251030162043.292468-3-marco.crivellari@suse.com
generated by cgit v1.2.3 (git 2.39.1) at 2026-08-11 11:22:00 +0000