summaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)Author
2026-02-19drm/xe/xe2hpg: Remove SRIOV VF check for Wa_18041344222Harish Chegondi
Engine WAs are not applied for SRIOV VF, even though they are processed. Remove the SRIOV VF check. Cc: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Harish Chegondi <harish.chegondi@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patch.msgid.link/4043a30d6a971cda3c13145e081e4eed7cc4e440.1770760591.git.harish.chegondi@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
2026-02-19drm/xe/xe3p_lpg: Add Wa_14026781792Nitin Gote
Wa_14026781792 applies Xe3p_LPG graphics version 35.10. Signed-off-by: Nitin Gote <nitin.r.gote@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patch.msgid.link/20260219082931.2199618-2-nitin.r.gote@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
2026-02-19drm/msm: Adjust msm_iommu_pagetable_prealloc_allocate() allocation typeKees Cook
In preparation for making the kmalloc family of allocators type aware, we need to make sure that the returned type from the allocation matches the type of the variable being assigned. (Before, the allocator would always return "void *", which can be implicitly cast to any pointer type.) The assigned type is "void **" but the returned type will be "void ***". These are the same allocation size (pointer size), but the types do not match. Adjust the allocation type to match the assignment. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://patch.msgid.link/20260206222151.work.016-kees@kernel.org Signed-off-by: Kees Cook <kees@kernel.org>
2026-02-19drm/amd/display: Remove unneeded DAC link encoder registerTimur Kristóf
Not needed anymore since we use the VBIOS function. Signed-off-by: Timur Kristóf <timur.kristof@gmail.com> Tested-by: Mauro Rossi <issor.oruam@gmail.com> Reviewed-by: Alex Hung <alex.hung@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-02-19drm/amd/display: Enable DAC in DCE link encoderTimur Kristóf
Ensure that the DAC output is enabled at the correct time by moving it to the DCE link encoder similarly to how digital outputs are enabled. This also removes the call to DAC1EncoderControl from the DCE HWSS, which always felt like it was a hacky solution. Fixes: 0fbe321a93ce ("drm/amd/display: Implement DCE analog link encoders (v2)") Signed-off-by: Timur Kristóf <timur.kristof@gmail.com> Tested-by: Mauro Rossi <issor.oruam@gmail.com> Reviewed-by: Alex Hung <alex.hung@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-02-19drm/amd/display: Set CRTC source for DAC using registersTimur Kristóf
Apparently the VBIOS SelectCRTC_Source function overwrites a few registers (such as FMT_*) which DC writes in a different place, which can cause problems. Instead of using the SelectCRTC_Source function from the VBIOS, use the DAC_SOURCE_SELECT register directly, similarly to how it is done for digital link encoders. Fixes: 3be26d81b150 ("drm/amd/display: Support DAC in dce110_hwseq") Signed-off-by: Timur Kristóf <timur.kristof@gmail.com> Tested-by: Mauro Rossi <issor.oruam@gmail.com> Reviewed-by: Alex Hung <alex.hung@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-02-19drm/amd/display: Initialize DAC in DCE link encoder using VBIOSTimur Kristóf
The VBIOS DAC1EncoderControl() function can initialize the DAC, by writing board-specific values to certain registers. Call this at link encoder hardware initialization time similarly to how the equivalent UNIPHYTransmitterControl initialization is done. This fixes DAC output on the Radeon HD 7790. Also remove the ENCODER_CONTROL_SETUP enum from the dac_encoder_control_prepare_params function which is actually not a supported operation for DAC encoders. Fixes: 0fbe321a93ce ("drm/amd/display: Implement DCE analog link encoders (v2)") Signed-off-by: Timur Kristóf <timur.kristof@gmail.com> Tested-by: Mauro Rossi <issor.oruam@gmail.com> Suggested-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Alex Hung <alex.hung@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-02-19drm/amd/display: Turn off DAC in DCE link encoder using VBIOSTimur Kristóf
Apparently, the VBIOS DAC1EncoderControl function is much more graceful about turning off the DAC. It writes various DAC registers in a specific sequence. Use that instead of just clearing the DAC_ENABLE register. Do this in just the dce110_link_encoder_disable_output function and remove it from the HWSS. Fixes: 0fbe321a93ce ("drm/amd/display: Implement DCE analog link encoders (v2)") Signed-off-by: Timur Kristóf <timur.kristof@gmail.com> Tested-by: Mauro Rossi <issor.oruam@gmail.com> Suggested-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Alex Hung <alex.hung@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-02-19drm/amd/display: Don't call find_analog_engine() twiceTimur Kristóf
The analog engine is already there in the link_analog_engine variable and assigned to enc_init_data.analog_engine already. I suspect this was a rebase mistake. Fixes: 436d0d22aa70 ("drm/amd/display: Pass proper DAC encoder ID to VBIOS") Signed-off-by: Timur Kristóf <timur.kristof@gmail.com> Tested-by: Mauro Rossi <issor.oruam@gmail.com> Reviewed-by: Alex Hung <alex.hung@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-02-19drm/amdgpu: fix 4-level paging if GMC supports 57-bit VA v2Christian König
It turned that using 4 level page tables on GMC generations which support 57bit VAs actually doesn't work at all. Background is that the GMC actually can't switch between 4 and 5 levels, but rather just uses a subset of address space when less than 5 levels are selected. Philip already removed the automatically switch to 4levels, now fix it as well should it be enabled by module parameters. v2: fix AMDGPU_GMC_HOLE_MASK as well, fix off by one issue pointed out by Philip Signed-off-by: Christian König <christian.koenig@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Philip Yang <philip.yang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-02-19drm/amdgpu: keep vga memory on MacBooks with switchable graphicsAlex Deucher
On Intel MacBookPros with switchable graphics, when the iGPU is enabled, the address of VRAM gets put at 0 in the dGPU's virtual address space. This is non-standard and seems to cause issues with the cursor if it ends up at 0. We have the framework to reserve memory at 0 in the address space, so enable it here if the vram start address is 0. Reviewed-and-tested-by: Mario Kleiner <mario.kleiner.de@gmail.com> Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4302 Cc: stable@vger.kernel.org Cc: Mario Kleiner <mario.kleiner.de@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-02-19drm/amdgpu: Set atomics to true for xgmiHarish Kasiviswanathan
xgmi support atomics between links. Set them to true. This only set for GFX12 onwards to avoid regression on older generations v2: Use correct xgmi flag that indicates CPU connection Signed-off-by: Harish Kasiviswanathan <Harish.Kasiviswanathan@amd.com> Reviewed-by: Felix Kuehling <felix.kuehling@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-02-19drm/amdkfd: Check for NULL return valuesAndrew Martin
This patch fixes issues when the code moves forward with a potential NULL pointer, without checking. Removed one redundant NULL check for a function parameter. This check is already done in the only caller. Signed-off-by: Andrew Martin <andrew.martin@amd.com> Reviewed-by: Felix Kuehling <felix.kuehling@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-02-19drm/amd/display: Use same max plane scaling limits for all 64 bpp formatsMario Kleiner
The plane scaling hw seems to have the same min/max plane scaling limits for all 16 bpc / 64 bpp interleaved pixel color formats. Therefore add cases to amdgpu_dm_plane_get_min_max_dc_plane_scaling() for all the 16 bpc fixed-point / unorm formats to use the same .fp16 up/downscaling factor limits as used by the fp16 floating point formats. So far, 16 bpc unorm formats were not handled, and the default: path returned max/min factors for 32 bpp argb8888 formats, which were wrong and bigger than what many DCE / DCN hw generations could handle. The result sometimes was misscaling of framebuffers with DRM_FORMAT_XRGB16161616, DRM_FORMAT_ARGB16161616, DRM_FORMAT_XBGR16161616, DRM_FORMAT_ABGR16161616, leading to very wrong looking display, as tested on Polaris11 / DCE-11.2. So far this went unnoticed, because only few userspace clients used such 16 bpc unorm framebuffers, and those didn't use hw plane scaling, so they did not experience this issue. With upcoming Mesa 26 exposing 16 bpc unorm formats under both OpenGL and Vulkan under Wayland, and the upcoming GNOME 50 Mutter Wayland compositor allowing for direct scanout of these formats, the scaling hw will be used on these formats if possible for HiDPI display scaling, so it is important to use the correct hw scaling limits to avoid wrong display. Tested on AMD Polaris 11 / DCE 11.2 with upcoming Mesa 26 and GNOME 50 on HiDPI displays with scaling enabled. The mutter Wayland compositor now correctly falls back to scaling via desktop compositing instead of direct scanout, thereby avoiding wrong image display. For unscaled mode, it correctly uses direct scanout. Fixes: 580204038f5b ("drm/amd/display: Enable support for 16 bpc fixed-point framebuffers.") Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com> Tested-by: Mario Kleiner <mario.kleiner.de@gmail.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Harry Wentland <harry.wentland@amd.com> Cc: Leo Li <sunpeng.li@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-02-19drm/amdgpu: Set vmid0 PAGE_TABLE_DEPTH for GFX12.1Harish Kasiviswanathan
GFX12.1 uses 2 level gart table. Set the context register appropriately Signed-off-by: Feifei Xu <Feifei.Xu@amd.com> Signed-off-by: Harish Kasiviswanathan <Harish.Kasiviswanathan@amd.com> Reviewed-by: Mukul Joshi <mukul.joshi@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-02-19drm/amdkfd: Disable MQD queue priorityAndrew Martin
This solves a priority inversion issue, caused by the language runtime making high-priority queues wait for activity on lower-priority queues. Signed-off-by: Andrew Martin <andrew.martin@amd.com> Reviewed-by: Felix Kuehling <felix.kuehling@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-02-19drm/amd/display: Remove conditional for shaper 3DLUT power-onAlex Hung
[Why] Shaper programming has high chance to fail on first time after power-on or reboot. This can be verified by running IGT's kms_colorop. [How] Always power on the shaper and 3DLUT before programming by removing the debug flag of low power mode. Reviewed-by: Aurabindo Pillai <aurabindo.pillai@amd.com> Signed-off-by: Alex Hung <alex.hung@amd.com> Signed-off-by: Ray Wu <ray.wu@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-02-19drm/amd/display: Check return of shaper curve to HW formatAlex Hung
[Why & How] Check return of cm3_helper_translate_curve_to_hw_format. This is reported as a CHECKED_RETURN error by Coverity. Reviewed-by: Aurabindo Pillai <aurabindo.pillai@amd.com> Signed-off-by: Alex Hung <alex.hung@amd.com> Signed-off-by: Ray Wu <ray.wu@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-02-19drm/amd/display: Correct logic check error for fastbootCharlene Liu
[Why] Fix fastboot broken in driver. This is caused by an open source backport change 7495962c. from the comment, the intended check is to disable fastboot for pre-DCN10. but the logic check is reversed, and causes fastboot to be disabled on all DCN10 and after. fastboot is for driver trying to pick up bios used hw setting and bypass reprogramming the hw if dc_validate_boot_timing() condition meets. Fixes: 7495962cbceb ("drm/amd/display: Disable fastboot on DCE 6 too") Cc: stable@vger.kernel.org Reviewed-by: Mario Limonciello <Mario.Limonciello@amd.com> Reviewed-by: Ovidiu Bunea <ovidiu.bunea@amd.com> Signed-off-by: Charlene Liu <Charlene.Liu@amd.com> Signed-off-by: Ray Wu <ray.wu@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-02-19drm/amd/display: Skip eDP detection when no sinkSaidireddy Yenugu
[Why & How] When there is no eDP panel connected and during s0ix resume, unnecessary eDP power sequence and HPD happening, resulting in ~2 seconds delay. Fixed the issue by avoiding link detect for eDP connection with no sink in dm_resume. Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Saidireddy Yenugu <Saidireddy.Yenugu@amd.com> Co-developed-by: ThummarDip Kishorbhai <ThummarDip.Kishorbhai@amd.com> Signed-off-by: ThummarDip Kishorbhai <ThummarDip.Kishorbhai@amd.com> Signed-off-by: Ray Wu <ray.wu@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-02-19Revert "drm/amd/display: Add Gfx Base Case For Linear Tiling Handling"Nicholas Carbones
This reverts commit 08a01ec306db ("drm/amd/display: Add Gfx Base Case For Linear Tiling Handling") Reason for revert: Got blank screen issues while doing PNP Reviewed-by: Joshua Aberback <joshua.aberback@amd.com> Signed-off-by: Nicholas Carbones <Nicholas.Carbones@amd.com> Signed-off-by: Ray Wu <ray.wu@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-02-19Revert "drm/amd/display: Correct hubp GfxVersion verification"Nicholas Carbones
This reverts commit 3303aa64e7a6 ("drm/amd/display: Correct hubp GfxVersion verification") Reason for revert: Got blank screen issues while doing PNP Reviewed-by: Joshua Aberback <joshua.aberback@amd.com> Signed-off-by: Nicholas Carbones <Nicholas.Carbones@amd.com> Signed-off-by: Ray Wu <ray.wu@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-02-19Revert "drm/amd/display: Add Handling for gfxversion DcGfxBase"Nicholas Carbones
This reverts commit 2e193f5b1b4f ("drm/amd/display: Add Handling for gfxversion DcGfxBase") Reason for revert: Cause some regressions Reviewed-by: Dillon Varone <dillon.varone@amd.com> Signed-off-by: Nicholas Carbones <Nicholas.Carbones@amd.com> Signed-off-by: Ray Wu <ray.wu@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-02-19drm/amd/display: Migrate DCCG registers access from hwseq to dccg component.Bhuvanachandra Pinninti
[Why] Direct DCCG register access in hwseq layer was creating register conflicts. [How] Migrated DCCG registers from hwseq-dccg component. Reviewed-by: Martin Leung <Martin.Leung@amd.com> Signed-off-by: Bhuvanachandra Pinninti <BhuvanaChandra.Pinninti@amd.com> Signed-off-by: Ray Wu <ray.wu@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-02-19drm/amd/display: Implementing ramless idle mouse triggerMuaaz Nisar
[Why & How] Adding mouse trigger in dc_stream to recover from low refresh rate idle state upon mouse movement without vsync interrupts. Reviewed-by: Aric Cyr <aric.cyr@amd.com> Signed-off-by: Muaaz Nisar <muaaz.nisar@amd.com> Signed-off-by: Ray Wu <ray.wu@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-02-19drm/amd/display: Disable SR feature on eDP1 by defaultCharlene Liu
[Why & How] Disable SR feature on eDP1 by default. Reviewed-by: Wenjing Liu <wenjing.liu@amd.com> Signed-off-by: Charlene Liu <Charlene.Liu@amd.com> Signed-off-by: Ray Wu <ray.wu@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-02-19drm/amd/display: Expose functions of other dcn useDmytro Laktyushkin
[Why & HOw] Expose some functions for later dcns to reuse Reviewed-by: Charlene Liu <charlene.liu@amd.com> Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Signed-off-by: Dmytro Laktyushkin <dmytro.laktyushkin@amd.com> Signed-off-by: Ray Wu <ray.wu@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-02-19drm/xe/reg_sr: Allow register_save_restore_check debugfs to verify LRC valuesMatt Roper
reg_sr programming that applies to an engines LRC cannot be verified by a simple CPU-based register readout because the reg_sr's values may not be in effect if no context is executing on the hardware at the time we check. Instead, we should verify correct reg_sr application by searching for the register in the default_lrc. Reviewed-by: Ashutosh Dixit <ashutosh.dixit@intel.com> Link: https://patch.msgid.link/20260218-sr_verify-v4-4-35d6deeb3421@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
2026-02-19drm/xe: Add facility to lookup the value of a register in a default LRCMatt Roper
An LRC is stored in memory as a special batchbuffer that hardware will execute to re-load state when switching to the context; it's a collection of register values (encoded as MI_LOAD_REGISTER_IMM commands) and other state instructions (e.g., 3DSTATE_*). The value that will be loaded for a given register can be determined by parsing the batchbuffer to find MI_LRI commands and extracting the value from the offset/value pairs it contains. Add functions to do this, which will be used in a future patch to help verify that our expected reg_sr programming is in place. The implementation here returns the value as soon as it finds a match in the LRC. Technically a register could appear multiple times (either due to memory corruption or a hardware defect) and the last value encountered would be the one in effect when the context resumes execution. We can adjust the logic to keep looking and return the last match instead of first in the future if we encounter real-world cases where this would assist with debugging. Reviewed-by: Ashutosh Dixit <ashutosh.dixit@intel.com> Link: https://patch.msgid.link/20260218-sr_verify-v4-3-35d6deeb3421@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
2026-02-19drm/xe/reg_sr: Add debugfs to verify status of reg_sr programmingMatt Roper
When applying save-restore register programming for workarounds, tuning settings, and general device configuration we assume the programming was successful. However there are a number of cases where the desired reg_sr programming can become lost: - workarounds implemented on the wrong RTP table might not get saved/restored at the right time leading to, for example, failure to re-apply the programming after engine resets - some hardware registers become "locked" and can no longer be updated after firmware or the driver finishes initializing them - sometimes the hardware teams just made a mistake when documenting the register and/or bits that needed to be programmed Add a debugfs entry that will read back the registers referenced on a GT's save-restore lists and print any cases where the desired programming is no longer in effect. Such cases might indicate the presence of a driver/firmware bug, might indicate that the documentation we were following has a mistake, or might be benign (occasionally registers have broken read-back capability preventing verification, but previous writes were still successful and effective). For now we only verify the GT and engine reg_sr lists. Verifying the LRC list will require checking the expected programming against the default_lrc contents, not the live registers (which may not reflect the reg_sr programming if no context is actively running). Reviewed-by: Ashutosh Dixit <ashutosh.dixit@intel.com> Link: https://patch.msgid.link/20260218-sr_verify-v4-2-35d6deeb3421@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
2026-02-19drm/xe/reg_sr: Don't process gt/hwe lists in VFMatt Roper
There are a few different reg_sr lists managed by the driver for workarounds/tuning: - gt->reg_sr - hwe->reg_sr - hwe->reg_lrc The first two are not relevant to SRIOV VFs; a VF KMD does not have access to the registers that appear on this list and it is the PF KMD's responsibility to apply such programming on behalf of the entire system. However the third list contains per-client values that the VF KMD needs to ensure are incorporated whenever a new LRC is created. Handling of reg_sr lists comes in two steps: processing an RTP table to build a reg_sr from the relevant entries, and then applying the contents of the reg_sr. Skipping the RTP processing (resulting in an empty reg_sr) or skipping the application of a reg_sr are both valid ways to avoid having a VF accidentally try to write registers it doesn't have access to. In commit c19e705ec981 ("drm/xe/vf: Stop applying save-restore MMIOs if VF") and commit 92a5bd302458 ("drm/xe/vf: Unblock xe_rtp_process_to_sr for VFs") we adjusted the drivers behavior to always process the RTP table into a reg_sr and just skipped the application step. This works fine functionally, but can lead to confusion during debugging since facilities like the debugfs 'register-save-restore' will still report a bunch of registers that the VF KMD isn't actually trying to handle. It will also mislead other upcoming debug changes. Let's go back to skipping the RTP => reg_sr processing step, but only for GT / hwe tables this time. This will allow LRC reg_sr handling to continue to work, but will ensure that gt->reg_sr and hwe->reg_sr remain empty and that debugfs reporting more accurately reflects the KMD's behavior. v2: - Also skip the hwe processing in hw_engine_setup_default_state() and xe_reg_whitelist_process_engine(). v3: - Handle skipping via an additional parameter passed to xe_rtp_process_to_sr() rather than adding conditions at each callsite. (Ashutosh) Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Ashutosh Dixit <ashutosh.dixit@intel.com> Cc: Harish Chegondi <harish.chegondi@intel.com> Reviewed-by: Ashutosh Dixit <ashutosh.dixit@intel.com> Link: https://patch.msgid.link/20260218-sr_verify-v4-1-35d6deeb3421@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
2026-02-19drm/xe/wa: Steer RMW of MCR registers while building default LRCMatt Roper
When generating the default LRC, if a register is not masked, we apply any save-restore programming necessary via a read-modify-write sequence that will ensure we only update the relevant bits/fields without clobbering the rest of the register. However some of the registers that need to be updated might be MCR registers which require steering to a non-terminated instance to ensure we can read back a valid, non-zero value. The steering of reads originating from a command streamer is controlled by register CS_MMIO_GROUP_INSTANCE_SELECT. Emit additional MI_LRI commands to update the steering before any RMW of an MCR register to ensure the reads are performed properly. Note that needing to perform a RMW of an MCR register while building the default LRC is pretty rare. Most of the MCR registers that are part of an engine's LRCs are also masked registers, so no MCR is necessary. Fixes: f2f90989ccff ("drm/xe: Avoid reading RMW registers in emit_wa_job") Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com> Link: https://patch.msgid.link/20260206223058.387014-2-matthew.d.roper@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
2026-02-19drm/i915/dp_mst: Fix ww mutex lock failure in for_each_joiner_candidate() loopImre Deak
Handle modeset WW mutex lock failures due to contention properly. Return -EDEADLK to the caller instead of attempting to lock the same mutex again in a subsequent joiner candidate iteration, where the WW mutex is already in a contended state. This fixes the following warning: WARNING: drivers/gpu/drm/drm_modeset_lock.c:298 at modeset_lock+0x1c0/0x210 triggered by ctx->contended. Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Fixes: b506a8e18c972 ("drm/i915/dp_mst: Rework pipe joiner logic in compute_config") Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260218105708.845161-2-imre.deak@intel.com
2026-02-19drm/i915/dp: Fix ww mutex lock failure in for_each_joiner_candidate() loopImre Deak
Handle modeset WW mutex lock failures due to contention properly. Return -EDEADLK to the caller instead of attempting to lock the same mutex again in a subsequent joiner candidate iteration, where the WW mutex is already in a contended state. This fixes the following warning: WARNING: drivers/gpu/drm/drm_modeset_lock.c:298 at modeset_lock+0x1c0/0x210 triggered by ctx->contended. Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Fixes: 1f1e3e5c65f6d ("drm/i915/dp: Rework pipe joiner logic in compute_config") Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260218105708.845161-1-imre.deak@intel.com
2026-02-18Merge tag 'mm-stable-2026-02-18-19-48' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Pull more MM updates from Andrew Morton: - "mm/vmscan: fix demotion targets checks in reclaim/demotion" fixes a couple of issues in the demotion code - pages were failed demotion and were finding themselves demoted into disallowed nodes (Bing Jiao) - "Remove XA_ZERO from error recovery of dup_mmap()" fixes a rare mapledtree race and performs a number of cleanups (Liam Howlett) - "mm: add bitmap VMA flag helpers and convert all mmap_prepare to use them" implements a lot of cleanups following on from the conversion of the VMA flags into a bitmap (Lorenzo Stoakes) - "support batch checking of references and unmapping for large folios" implements batching to greatly improve the performance of reclaiming clean file-backed large folios (Baolin Wang) - "selftests/mm: add memory failure selftests" does as claimed (Miaohe Lin) * tag 'mm-stable-2026-02-18-19-48' of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm: (36 commits) mm/page_alloc: clear page->private in free_pages_prepare() selftests/mm: add memory failure dirty pagecache test selftests/mm: add memory failure clean pagecache test selftests/mm: add memory failure anonymous page test mm: rmap: support batched unmapping for file large folios arm64: mm: implement the architecture-specific clear_flush_young_ptes() arm64: mm: support batch clearing of the young flag for large folios arm64: mm: factor out the address and ptep alignment into a new helper mm: rmap: support batched checks of the references for large folios tools/testing/vma: add VMA userland tests for VMA flag functions tools/testing/vma: separate out vma_internal.h into logical headers tools/testing/vma: separate VMA userland tests into separate files mm: make vm_area_desc utilise vma_flags_t only mm: update all remaining mmap_prepare users to use vma_flags_t mm: update shmem_[kernel]_file_*() functions to use vma_flags_t mm: update secretmem to use VMA flags on mmap_prepare mm: update hugetlbfs to use VMA flags on mmap_prepare mm: add basic VMA flag operation helper functions tools: bitmap: add missing bitmap_[subset(), andnot()] mm: add mk_vma_flags() bitmap flag macro helper ...
2026-02-18drm/amd/display: Add static keyword for sharpness tablesSamson Tam
[Why & How] Sharpness tables are only accessed in dc_spl_isharp_filters source file. Reviewed-by: Joshua Aberback <joshua.aberback@amd.com> Reviewed-by: Jun Lei <jun.lei@amd.com> Signed-off-by: Samson Tam <samson.tam@amd.com> Signed-off-by: Tom Chung <chiahsuan.chung@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-02-18drm/amd/display: Only use analog stream encoder with analog engineTimur Kristóf
Some GPUs have analog connectors that work with a DP bridge chip and don't actually have an internal DAC: Those should not use the analog stream encoders. Fixes: 5834c33fd3f6 ("drm/amd/display: Add concept of analog encoders (v2)") Signed-off-by: Timur Kristóf <timur.kristof@gmail.com> Reviewed-by: Alex Hung <alex.hung@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-02-18drm/amd/display: Only use analog link encoder with analog engineTimur Kristóf
Some GPUs have analog connectors that work with a DP bridge chip and don't actually have an internal DAC: Those should not use the analog link encoder code path. Fixes: 0fbe321a93ce ("drm/amd/display: Implement DCE analog link encoders (v2)") Signed-off-by: Timur Kristóf <timur.kristof@gmail.com> Reviewed-by: Alex Hung <alex.hung@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-02-18drm/amd/display: Use DCE 6 link encoder for DCE 6 analog connectorsTimur Kristóf
DCE 6 should use the DCE 6 specific link encoder. This was a copy paste mistake. Fixes: 0fbe321a93ce ("drm/amd/display: Implement DCE analog link encoders (v2)") Signed-off-by: Timur Kristóf <timur.kristof@gmail.com> Reviewed-by: Alex Hung <alex.hung@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-02-18Merge tag 'amd-drm-next-6.20-2026-02-13' of ↵Dave Airlie
https://gitlab.freedesktop.org/agd5f/linux into drm-next amd-drm-next-6.20-2026-02-13: amdgpu: - SMU 13.x fixes - DC resume lag fix - MPO fixes - DCN 3.6 fix - VSDB fixes - HWSS clean up - Replay fixes - DCE cursor fixes - DCN 3.5 SR DDR5 latency fixes - HPD fixes - Error path unwind fixes - SMU13/14 mode1 reset fixes - PSP 15 updates - SMU 15 updates - RAS fixes - Sync fix in amdgpu_dma_buf_move_notify() - HAINAN fix - PSP 13.x fix - GPUVM locking fix amdkfd: - APU GTT as VRAM fix radeon: - HAINAN fix Signed-off-by: Dave Airlie <airlied@redhat.com> From: Alex Deucher <alexander.deucher@amd.com> Link: https://patch.msgid.link/20260213220825.1454189-1-alexander.deucher@amd.com
2026-02-18Merge tag 'drm-intel-next-fixes-2026-02-13' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/i915/kernel into drm-next - Regresion fix for HDR 4k displays (#15503) - Fixup for Dell XPS 13 7390 eDP rate limit - Memory leak fix on ACPI _DSM handling Signed-off-by: Dave Airlie <airlied@redhat.com> From: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patch.msgid.link/aY8CtbhijtetQ6P3@jlahtine-mobl
2026-02-17drm/xe: Convert GT stats to per-cpu countersMatthew Brost
Current GT statistics use atomic64_t counters. Atomic operations incur a global coherency penalty. Transition to dynamic per-cpu counters using alloc_percpu(). This allows stats to be incremented via this_cpu_add(), which compiles to a single non-locking instruction. This approach keeps the hot-path updates local to the CPU, avoiding expensive cross-core cache invalidation traffic. Use for_each_possible_cpu() during aggregation and clear operations to ensure data consistency across CPU hotplug events. Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Stuart Summers <stuart.summers@intel.com> Link: https://patch.msgid.link/20260217200552.596718-1-matthew.brost@intel.com
2026-02-17drm/xe: Prevent VFs from exposing the CCS mode sysfs fileNareshkumar Gollakoti
Skip creating CCS sysfs files in VF mode to ensure VFs do not try to change CCS mode, as it is predefined and immutable in the SR-IOV mode. Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by: Nareshkumar Gollakoti <naresh.kumar.g@intel.com> Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Link: https://patch.msgid.link/20260202170810.1393147-5-naresh.kumar.g@intel.com (cherry picked from commit 4e8f602ac3574cf1ebc7acfb6624d06e04b30c91) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2026-02-17drm/xe/hwmon: Prevent unintended VRAM channel creationKarthik Poosa
Remove the unnecessary VRAM channel entry introduced in xe_hwmon_channel. Without this, adding any new hwmon channel causes extra VRAM channel to appear. This remained unnoticed earlier because VRAM was the final xe hwmon channel. v2: Use MAX_VRAM_CHANNELS with in_range() instead of CHANNEL_VRAM_N_MAX. (Raag) Fixes: 49a498338417 ("drm/xe/hwmon: Expose individual VRAM channel temperature") Signed-off-by: Karthik Poosa <karthik.poosa@intel.com> Reviewed-by: Raag Jadav <raag.jadav@intel.com> Link: https://patch.msgid.link/20260206081655.2115439-1-karthik.poosa@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> (cherry picked from commit 48eb073c7d95883eca2789447f94e1e8cafbabe5) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2026-02-17drm/pagemap: pass pagemap_addr by referenceArnd Bergmann
Passing a structure by value into a function is sometimes problematic, for a number of reasons. Of of these is a warning from the 32-bit arm compiler: drivers/gpu/drm/drm_gpusvm.c: In function '__drm_gpusvm_unmap_pages': drivers/gpu/drm/drm_gpusvm.c:1152:33: note: parameter passing for argument of type 'struct drm_pagemap_addr' changed in GCC 9.1 1152 | dpagemap->ops->device_unmap(dpagemap, | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1153 | dev, *addr); | ~~~~~~~~~~~ This particular problem is harmless since we are not mixing compiler versions inside of the compiler. However, passing this by reference avoids the warning along with providing slightly better calling conventions as it avoids an extra copy on the stack. Fixes: 75af93b3f5d0 ("drm/pagemap, drm/xe: Support destination migration over interconnect") Fixes: 2df55d9e66a2 ("drm/xe: Support pcie p2p dma as a fast interconnect") 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://patch.msgid.link/20260216134644.1025365-1-arnd@kernel.org Acked-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> (cherry picked from commit 95162db0208aee122d10ac1342fe97a1721cd258) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2026-02-17drm/xe/bo: Redirect faults to dummy page for wedged deviceRaag Jadav
As per uapi documentation[1], the prerequisite for wedged device is to redirected page faults to a dummy page. Follow it. [1] Documentation/gpu/drm-uapi.rst v2: Add uapi reference and fixes tag (Matthew Brost) Fixes: 7bc00751f877 ("drm/xe: Use device wedged event") Signed-off-by: Raag Jadav <raag.jadav@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20260212055622.2054991-1-raag.jadav@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com> (cherry picked from commit c020fff70d757612933711dd3cc3751d7d782d3c) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2026-02-17drm/xe: Make xe_modparam.force_vram_bar_size signedShuicheng Lin
vram_bar_size is registered as an int module parameter and is documented to accept negative values to disable BAR resizing. Store it as an int in xe_modparam as well, so negative values work as intended and the module_param type matches. Fixes: 80742a1aa26e ("drm/xe: Allow to drop vram resizing") Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by: Shuicheng Lin <shuicheng.lin@intel.com> Link: https://patch.msgid.link/20260202181853.1095736-2-shuicheng.lin@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com> (cherry picked from commit 25c9aa4dcb5ef2ad9f354d19f8f1eeb690d1c161) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2026-02-17drm/xe/vf: Avoid reading media version when media GT is disabledPiotr Piórkowski
When the media GT is not allowed, a VF must not attempt to read the media version from the GuC. The GuC may not be loaded, and any attempt to communicate with it would result in a timeout and a VF probe failure: (...) [ 1912.406046] xe 0000:01:00.1: [drm] *ERROR* Tile0: GT1: GuC mmio request 0x5507: no reply 0x5507 [ 1912.407277] xe 0000:01:00.1: [drm] *ERROR* Tile0: GT1: [GUC COMMUNICATION] MMIO send failed (-ETIMEDOUT) [ 1912.408689] xe 0000:01:00.1: [drm] *ERROR* VF: Tile0: GT1: Failed to reset GuC state (-ETIMEDOUT) [ 1912.413986] xe 0000:01:00.1: probe with driver xe failed with error -110 Let's skip reading the media version for VFs when the media GT is not allowed. v2: move the condition directly to the VF path Fixes: 7abd69278bb5 ("drm/xe/configfs: Add attribute to disable GT types") Signed-off-by: Piotr Piórkowski <piotr.piorkowski@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Shuicheng Lin <shuicheng.lin@intel.com> Reviewed-by: Shuicheng Lin <shuicheng.lin@intel.com> Link: https://patch.msgid.link/20260202115041.2863357-1-piotr.piorkowski@intel.com Signed-off-by: Michał Winiarski <michal.winiarski@intel.com> (cherry picked from commit 0bcacf56dc0b265f9c47056c6a4f0c1394a8a3f0) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2026-02-17drm/xe/xe2_hpg: Fix handling of Wa_14019988906 & Wa_14019877138Matt Roper
The PSS_CHICKEN register has been part of the RCS engine's LRC since it was first introduced in Xe_LP. That means that any workarounds that adjust its value (such as Wa_14019988906 and Wa_14019877138) need to be implemented in the lrc_was[] table so that they become part of the default LRC from which all subsequent LRCs are copied. Although these workarounds were implemented correctly on most platforms, they were incorrectly placed on the engine_was[] table for Xe2_HPG. Move the workarounds to the proper lrc_was[] table and switch the 'xe_rtp_match_first_render_or_compute' rule to specifically match the RCS since that's the engine whose LRC manages the register. Bspec: 65182 Fixes: 7f3ee7d88058 ("drm/xe/xe2hpg: Add initial GT workarounds") Reviewed-by: Shekhar Chauhan <shekhar.chauhan@intel.com> Link: https://patch.msgid.link/20260205220508.51905-2-matthew.d.roper@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com> (cherry picked from commit e04c609eedf4d6748ac0bcada4de1275b034fed6) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2026-02-17drm/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> (cherry picked from commit a30f999681126b128a43137793ac84b6a5b7443f) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
generated by cgit v1.2.3 (git 2.39.1) at 2026-08-10 22:33:06 +0000