summaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)Author
2026-01-22drm/i915/display: Fix color pipeline enum name leakChaitanya Kumar Borah
intel_color_pipeline_plane_init() allocates enum names for color pipelines, which are copied by drm_property_create_enum(). The temporary strings were not freed, resulting in a memory leak. Allocate enum names only after successful pipeline construction and free them on all exit paths. Fixes: ef105316819d ("drm/i915/color: Create a transfer function color pipeline") 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> Signed-off-by: Maarten Lankhorst <dev@lankhorst.se> Acked-by: Jani Nikula <jani.nikula@intel.com> Link: https://patch.msgid.link/20260113102303.724205-5-chaitanya.kumar.borah@intel.com
2026-01-22drm/vkms: Fix color pipeline enum name leakChaitanya Kumar Borah
vkms_initialize_colorops() allocates enum names for color pipelines, which are copied by drm_property_create_enum(). The temporary strings were not freed, resulting in a memory leak. Allocate enum names only after successful pipeline construction and free them on all exit paths Fixes: c1e578bd08da ("drm/vkms: Add enumerated 1D curve colorop") 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> Signed-off-by: Maarten Lankhorst <dev@lankhorst.se> Link: https://patch.msgid.link/20260113102303.724205-4-chaitanya.kumar.borah@intel.com
2026-01-22drm/amd/display: Fix color pipeline enum name leakChaitanya Kumar Borah
dm_plane_init_colorops() allocates enum names for color pipelines. These are eventually passed to drm_property_create_enum() which create its own copies of the string. Free the strings after initialization is done. Also, allocate color pipeline enum names only after successfully creating color pipeline. Fixes: 9ba25915efba ("drm/amd/display: Add support for sRGB EOTF in DEGAM block") 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> Signed-off-by: Maarten Lankhorst <dev@lankhorst.se> Acked-by: Alex Deucher <alexander.deucher@amd.com> #irc Link: https://patch.msgid.link/20260113102303.724205-3-chaitanya.kumar.borah@intel.com
2026-01-22drm/i915/color: Place 3D LUT after CSC in plane color pipelineChaitanya Kumar Borah
Move the 3D LUT block to its correct position in the plane color pipeline: [Pre-CSC] -> [CSC] -> [3DLUT] -> [Post-CSC] Fixes: 65db7a1f9cf7 ("drm/i915/color: Add 3D LUT to color pipeline") 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> Signed-off-by: Maarten Lankhorst <dev@lankhorst.se> Acked-by: Jani Nikula <jani.nikula@intel.com> Link: https://patch.msgid.link/20260113102303.724205-2-chaitanya.kumar.borah@intel.com
2026-01-22drm/msm/a8xx: Add UBWC v6 supportAkhil P Oommen
Adreno 840 GPU supports UBWC v6. Add support for this. Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/700073/ Link: https://lore.kernel.org/r/20260121-kaana-gpu-support-v5-1-984848af12e4@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2026-01-22drm/ci: ignore Gamma test failures on Qualcomm SC7180Dmitry Baryshkov
It seems, on SC7180 color conversion results are not included into the CRC calculation (unlike SM8350). The fails for SC7180 already lists CTM tests. Add gamma-related tests too. Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Acked-by: Daniel Stone <daniels@collabora.com> Patchwork: https://patchwork.freedesktop.org/patch/699820/ Link: https://lore.kernel.org/r/20260121-dpu-sc7180-ignore-gamma-v1-1-84f2cc2beeb1@oss.qualcomm.com
2026-01-22drm/msm/dpu: Add DSPP GC driver to provide GAMMA_LUT DRM propertyFederico Amedeo Izzo
Add support for DSPP GC block in DPU driver for Qualcomm SoCs. Expose the GAMMA_LUT DRM property, which is needed to enable night light and basic screen color calibration. I used LineageOS downstream kernel as a reference and found the LUT format by trial-and-error on OnePlus 6. Tested on oneplus-enchilada (sdm845-mainline 6.16-dev) and xiaomi-tissot (msm8953-mainline 6.12/main). Tested-by: David Heidelberg <david@ixit.cz> # Pixel 3 (next-20251018) Tested-by: Guido Günther <agx@sigxcpu.org> # on sdm845-shift-axolotl Signed-off-by: Federico Amedeo Izzo <federico@izzo.pro> Tested-by: Steev Klimaszewski <threeway@gmail.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/682102/ Link: https://lore.kernel.org/r/20251019-dpu-add-dspp-gc-driver-v3-1-840491934e56@izzo.pro Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2026-01-21drm/nouveau/disp: Set drm_mode_config_funcs.atomic_(check|commit)Lyude Paul
Apparently we never actually filled these in, despite the fact that we do in fact technically support atomic modesetting. Since not having these filled in causes us to potentially forget to disable fbdev and friends during suspend/resume, let's fix it. Signed-off-by: Lyude Paul <lyude@redhat.com> Cc: stable@vger.kernel.org Reviewed-by: Dave Airlie <airlied@redhat.com> Link: https://patch.msgid.link/20260121191320.210342-1-lyude@redhat.com
2026-01-21drm/nouveau: implement missing DCB connector types; gracefully handle ↵Alex Ramírez
unknown connectors * Implement missing DCB connectors in uconn.c previously defined in conn.h. * Replace kernel WARN_ON macro with printk message to more gracefully signify an unknown connector was encountered. With this patch, unknown connectors are explicitly marked with value 0 (DCB_CONNECTOR_VGA) to match the tested current behavior. Although 0xff (DCB_CONNECTOR_NONE) may be more suitable, I don't want to introduce a breaking change. Fixes: 8b7d92cad953 ("drm/nouveau/kms/nv50-: create connectors based on nvkm info") Link: https://download.nvidia.com/open-gpu-doc/DCB/1/DCB-4.0-Specification.html#_connector_table_entry Signed-off-by: Alex Ramírez <lxrmrz732@rocketmail.com> Reviewed-by: Lyude Paul <lyude@redhat.com> [Lyude: Remove unneeded parenthesis around nvkm_warn()] Signed-off-by: Lyude Paul <lyude@redhat.com> Link: https://patch.msgid.link/20251213005327.9495-3-lxrmrz732@gmail.com
2026-01-21drm/nouveau: add missing DCB connector typesAlex Ramírez
* Add missing DCB connectors in conn.h as per the NVIDIA DCB specification. A lot of connector logic was rewritten for Linux v6.5; some display connector types went unaccounted-for which caused kernel warnings on devices with the now-unsupported DCB connectors. This patch adds all of the DCB connectors as defined by NVIDIA to the dcb_connector_type enum to bring back support for these connectors to the new logic. Fixes: 8b7d92cad953 ("drm/nouveau/kms/nv50-: create connectors based on nvkm info") Link: https://download.nvidia.com/open-gpu-doc/DCB/1/DCB-4.0-Specification.html#_connector_table_entry Signed-off-by: Alex Ramírez <lxrmrz732@rocketmail.com> Reviewed-by: Lyude Paul <lyude@redhat.com> [Lyude: Clarify DCB_CONNECTOR_HDMI_0 weirdness in comments] Signed-off-by: Lyude Paul <lyude@redhat.com> Link: https://patch.msgid.link/20251213005327.9495-2-lxrmrz732@gmail.com
2026-01-21drm/amdgpu: fix type for wptr in ring backupAlex Deucher
Needs to be a u64. Fixes: 77cc0da39c7c ("drm/amdgpu: track ring state associated with a fence") Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 56fff1941abd3ca3b6f394979614ca7972552f7f)
2026-01-21drm/amdgpu: Fix validating flush_gpu_tlb_pasid()Timur Kristóf
When a function holds a lock and we return without unlocking it, it deadlocks the kernel. We should always unlock before returning. This commit fixes suspend/resume on SI. Tested on two Tahiti GPUs: FirePro W9000 and R9 280X. Fixes: f4db9913e4d3 ("drm/amdgpu: validate the flush_gpu_tlb_pasid()") Reported-by: kernel test robot <lkp@intel.com> Reported-by: Dan Carpenter <dan.carpenter@linaro.org> Closes: https://lore.kernel.org/r/202601190121.z9C0uml5-lkp@intel.com/ Signed-off-by: Timur Kristóf <timur.kristof@gmail.com> Signed-off-by: Prike Liang <Prike.Liang@amd.com> Reviewed-by: Prike Liang <Prike.Liang@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit e3a6eff92bbd960b471966d9afccb4d584546d17)
2026-01-21drm/amd/pm: Workaround SI powertune issue on Radeon 430 (v2)Timur Kristóf
Radeon 430 and 520 are OEM GPUs from 2016~2017 They have the same device id: 0x6611 and revision: 0x87 On the Radeon 430, powertune is buggy and throttles the GPU, never allowing it to reach its maximum SCLK. Work around this bug by raising the TDP limits we program to the SMC from 24W (specified by the VBIOS on Radeon 430) to 32W. Disabling powertune entirely is not a viable workaround, because it causes the Radeon 520 to heat up above 100 C, which I prefer to avoid. Additionally, revise the maximum SCLK limit. Considering the above issue, these GPUs never reached a high SCLK on Linux, and the workarounds were added before the GPUs were released, so the workaround likely didn't target these specifically. Use 780 MHz (the maximum SCLK according to the VBIOS on the Radeon 430). Note that the Radeon 520 VBIOS has a higher maximum SCLK: 905 MHz, but in practice it doesn't seem to perform better with the higher clock, only heats up more. v2: Move the workaround to si_populate_smc_tdp_limits. Fixes: 841686df9f7d ("drm/amdgpu: add SI DPM support (v4)") Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Timur Kristóf <timur.kristof@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 966d70f1e160bdfdecaf7ff2b3f22ad088516e9f)
2026-01-21drm/amd/pm: Don't clear SI SMC table when setting power limitTimur Kristóf
There is no reason to clear the SMC table. We also don't need to recalculate the power limit then. Fixes: 841686df9f7d ("drm/amdgpu: add SI DPM support (v4)") Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Timur Kristóf <timur.kristof@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit e214d626253f5b180db10dedab161b7caa41f5e9)
2026-01-21drm/amd/pm: Fix si_dpm mmCG_THERMAL_INT settingTimur Kristóf
Use WREG32 to write mmCG_THERMAL_INT. This is a direct access register. Fixes: 841686df9f7d ("drm/amdgpu: add SI DPM support (v4)") Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Timur Kristóf <timur.kristof@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 2555f4e4a741d31e0496572a8ab4f55941b4e30e)
2026-01-21drm/amdgpu: rename amdgpu_fence_driver_guilty_force_completion()Alex Deucher
The function no longer signals the fence so rename it to better match what it does. Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-01-21drm/amdgpu: fix type for wptr in ring backupAlex Deucher
Needs to be a u64. Fixes: 77cc0da39c7c ("drm/amdgpu: track ring state associated with a fence") Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-01-21drm/amdgpu: mark invalid records with U64_MAXGangliang Xie
set retired_page of invalid ras records to U64_MAX, and skip them when reading ras records Signed-off-by: Gangliang Xie <ganglxie@amd.com> Reviewed-by: Tao Zhou <tao.zhou1@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-01-21drm/amdgpu: Avoid excessive dmesg logLijo Lazar
KIQ access is not guaranteed to work reliably under all reset situations. Avoid flooding dmesg with HDP flush failure messages. Signed-off-by: Lijo Lazar <lijo.lazar@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-01-21drm/amdgpu: Fix validating flush_gpu_tlb_pasid()Timur Kristóf
When a function holds a lock and we return without unlocking it, it deadlocks the kernel. We should always unlock before returning. This commit fixes suspend/resume on SI. Tested on two Tahiti GPUs: FirePro W9000 and R9 280X. Fixes: f4db9913e4d3 ("drm/amdgpu: validate the flush_gpu_tlb_pasid()") Reported-by: kernel test robot <lkp@intel.com> Reported-by: Dan Carpenter <dan.carpenter@linaro.org> Closes: https://lore.kernel.org/r/202601190121.z9C0uml5-lkp@intel.com/ Signed-off-by: Timur Kristóf <timur.kristof@gmail.com> Signed-off-by: Prike Liang <Prike.Liang@amd.com> Reviewed-by: Prike Liang <Prike.Liang@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-01-21drm/amdkfd: simplify svm_range_unmap_from_gpus()Yury Norov
The function calls bitmap_or() followed by for_each_set_bit(). Switch it to the dedicated for_each_or_bit() and drop the temporary bitmap. Signed-off-by: Yury Norov <ynorov@nvidia.com> Signed-off-by: Felix Kuehling <felix.kuehling@amd.com> Reviewed-by: Felix Kuehling <felix.kuehling@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-01-21drm/amdkfd: Do not include VGPR MSBs in saved PC during saveLancelot Six
The current trap handler uses the top bits of ttmp1 to store a copy of sq_wave_mode.*vgpr_msb (except for src2_vgpr_msb). This is so the effective values in sq_wave_mode can be cleared to ensure correct behavior of the trap handler. When saving sq_wave_mode, the trap handler correctly rebuilds the expected value (with *vgpr_msb restored), so the save area is correct. However, the PC itself is copied from ttmp[0:1], which contains the wave's PC as well as the saved MSBs. The debugger reads the PC from the save area and is confused when non-0 values from VGPR_MSBs are present. This patch fixes this by saving the PC in the save area's PC slot, not the composite of the PC and VGPR_MSBs. On restore, the VGPR_MSBs are restored from sq_wave_mode. Signed-off-by: Lancelot Six <lancelot.six@amd.com> Tested-by: Alexey Kondratiev <Alexey.Kondratiev@amd.com> Reviewed-by: Jay Cornwall <jay.cornwall@amd.com> Cc: Vladimir Indic <vladimir.indic@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-01-21drm/amd/pm: Correct comment above power2_cap attributesTimur Kristóf
Previously only Van Gogh supported this, but that is not true anymore since: commit 12c958d1db36 ("drm/amd/pm: Expose ppt1 limit for gc_v9_5_0") Update the comment to reflect that. Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Timur Kristóf <timur.kristof@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-01-21drm/amd/pm: Return -EOPNOTSUPP when can't read power limitTimur Kristóf
So that hwmon_attributes_visible() will see that the power2_cap attributes should not be visible on GPUs that don't support the get_power_limit() function. This fixes an error when running the "sensors" command on SI. Fixes: 12c958d1db36 ("drm/amd/pm: Expose ppt1 limit for gc_v9_5_0") Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Timur Kristóf <timur.kristof@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-01-21drm/amd/pm: Workaround SI powertune issue on Radeon 430 (v2)Timur Kristóf
Radeon 430 and 520 are OEM GPUs from 2016~2017 They have the same device id: 0x6611 and revision: 0x87 On the Radeon 430, powertune is buggy and throttles the GPU, never allowing it to reach its maximum SCLK. Work around this bug by raising the TDP limits we program to the SMC from 24W (specified by the VBIOS on Radeon 430) to 32W. Disabling powertune entirely is not a viable workaround, because it causes the Radeon 520 to heat up above 100 C, which I prefer to avoid. Additionally, revise the maximum SCLK limit. Considering the above issue, these GPUs never reached a high SCLK on Linux, and the workarounds were added before the GPUs were released, so the workaround likely didn't target these specifically. Use 780 MHz (the maximum SCLK according to the VBIOS on the Radeon 430). Note that the Radeon 520 VBIOS has a higher maximum SCLK: 905 MHz, but in practice it doesn't seem to perform better with the higher clock, only heats up more. v2: Move the workaround to si_populate_smc_tdp_limits. Fixes: 841686df9f7d ("drm/amdgpu: add SI DPM support (v4)") Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Timur Kristóf <timur.kristof@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-01-21drm/amd/pm: Don't clear SI SMC table when setting power limitTimur Kristóf
There is no reason to clear the SMC table. We also don't need to recalculate the power limit then. Fixes: 841686df9f7d ("drm/amdgpu: add SI DPM support (v4)") Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Timur Kristóf <timur.kristof@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-01-21drm/amdkfd: gfx12.1 trap handler support for expert scheduling modeJay Cornwall
- Leave DEP_MODE unchanged as it is ignored in the trap handler - Save/restore SCHED_MODE (gfx12.0 saves in ttmp11) Signed-off-by: Jay Cornwall <jay.cornwall@amd.com> Reviewed-by: Lancelot Six <lancelot.six@amd.com> Cc: Vladimir Indic <vladimir.indic@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-01-21drm/amdkfd: gfx12.1 cluster barrier context save workaroundJay Cornwall
Trap cluster barrier may not serialize with user cluster barrier under some circumstances. Add a check for pending user cluster barrier complete. Signed-off-by: Jay Cornwall <jay.cornwall@amd.com> Tested-by: Gang Ba <Gang.Ba@amd.com> Cc: Harish Kasiviswanathan <Harish.Kasiviswanathan@amd.com> Reviewed-by: Lancelot Six <lancelot.six@amd.com> Cc: Vladimir Indic <vladimir.indic@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-01-21drm/amdkfd: Fix scalar load ordering in gfx12.1 trap handlerJay Cornwall
Scalar loads may arrive out-of-order with respect to KMCNT. The affected code expects the two loads to arrive in-order. Signed-off-by: Jay Cornwall <jay.cornwall@amd.com> Reviewed-by: Lancelot Six <lancelot.six@amd.com> Cc: Joseph Greathouse <joseph.greathouse@amd.com> Cc: Vladimir Indic <vladimir.indic@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-01-21drm/amdkfd: Sync trap handler binary with sourceJay Cornwall
Binary and source desynced during branch activity. Source merge also introduced compile error. Signed-off-by: Jay Cornwall <jay.cornwall@amd.com> Reviewed-by: Lancelot Six <lancelot.six@amd.com> Cc: Vladimir Indic <vladimir.indic@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-01-21drm/amdgpu/vcn5.0.1: rework reset handlingJesse.Zhang
Resetting VCN resets the entire tile, including jpeg. When resetting the VCN, we need to ensure that JPEG data blocks are accessible and we also need to handle the JPEG queue. Add a helper function to restore the JPEG queue during the VCN reset. v2: split the jpeg helper in two, in the top helper we can stop the sched workqueues and attempt to wait for any outstanding fences. Then in the bottom helper, we can force completion, re-init the rings, and restart the sched workqueues (Alex) v3: merge patches 4 and 5 into one patch (Alex) Signed-off-by: Jesse Zhang <jesse.zhang@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-01-21drm/amdgpu/vcn4.0.3: rework reset handlingJesse.Zhang
Resetting VCN resets the entire tile, including jpeg. When resetting the VCN, we need to ensure that JPEG data blocks are accessible and we also need to handle the JPEG queue. Add a helper function to restore the JPEG queue during the VCN reset. v2: split the jpeg helper in two, in the top helper we can stop the sched workqueues and attempt to wait for any outstanding fences. Then in the bottom helper, we can force completion, re-init the rings, and restart the sched workqueues (Alex) v3: merge patches 1 and 2 into one patch (Alex) Signed-off-by: Jesse Zhang <jesse.zhang@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-01-21drm/amdgpu/vcn4.0.3: implement DPG pause mode handling for VCN 4.0.3Jesse.Zhang
For MI projects, when Dynamic Power Gating (DPG) is enabled, VCN reset operations should be performed with DPG in pause mode. Otherwise, the hardware may perform undesirable reset operations Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Jesse Zhang <jesse.zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-01-21drm/amd/pm: Fix si_dpm mmCG_THERMAL_INT settingTimur Kristóf
Use WREG32 to write mmCG_THERMAL_INT. This is a direct access register. Fixes: 841686df9f7d ("drm/amdgpu: add SI DPM support (v4)") Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Timur Kristóf <timur.kristof@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-01-21drm/bridge: fix kdoc syntaxLuca Ceresoli
Use the correct kdoc syntax for bullet list. Fixes kdoc error and warning: Documentation/gpu/drm-kms-helpers:197: ./drivers/gpu/drm/drm_bridge.c:1519: ERROR: Unexpected indentation. [docutils] Documentation/gpu/drm-kms-helpers:197: ./drivers/gpu/drm/drm_bridge.c:1521: WARNING: Block quote ends without a blank line; unexpected unindent. [docutils] Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202512302319.1PGGt3CN-lkp@intel.com/ Fixes: 9da0e06abda8 ("drm/bridge: deprecate of_drm_find_bridge()") Reviewed-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com> Link: https://patch.msgid.link/20251231-drm-bridge-alloc-getput-drm_of_find_bridge-kdoc-fix-v1-1-193a03f0609c@bootlin.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2026-01-21drm/xe: Update wedged.mode only after successful reset policy changeLukasz Laguna
Previously, the driver's internal wedged.mode state was updated without verifying whether the corresponding engine reset policy update in GuC succeeded. This could leave the driver reporting a wedged.mode state that doesn't match the actual reset behavior programmed in GuC. With this change, the reset policy is updated first, and the driver's wedged.mode state is modified only if the policy update succeeds on all available GTs. This patch also introduces two functional improvements: - The policy is sent to GuC only when a change is required. An update is needed only when entering or leaving XE_WEDGED_MODE_UPON_ANY_HANG, because only in that case the reset policy changes. For example, switching between XE_WEDGED_MODE_UPON_CRITICAL_ERROR and XE_WEDGED_MODE_NEVER doesn't affect the reset policy, so there is no need to send the same value to GuC. - An inconsistent_reset flag is added to track cases where reset policy update succeeds only on a subset of GTs. If such inconsistency is detected, future wedged mode configuration will force a retry of the reset policy update to restore a consistent state across all GTs. Fixes: 6b8ef44cc0a9 ("drm/xe: Introduce the wedged_mode debugfs") Signed-off-by: Lukasz Laguna <lukasz.laguna@intel.com> Link: https://patch.msgid.link/20260107174741.29163-3-lukasz.laguna@intel.com Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> (cherry picked from commit 0f13dead4e0385859f5c9c3625a19df116b389d3) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
2026-01-21drm/xe/migrate: fix job lock assertMatthew Auld
We are meant to be checking the user vm for the bind queue, but actually we are checking the migrate vm. For various reasons this is not currently firing but this will likely change in the future. Now that we have the user_vm attached to the bind queue, we can fix this by directly checking that here. Fixes: dba89840a920 ("drm/xe: Add GT TLB invalidation jobs") Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Arvind Yadav <arvind.yadav@intel.com> Link: https://patch.msgid.link/20260120110609.77958-4-matthew.auld@intel.com (cherry picked from commit 9dd1048bca4fe2aa67c7a286bafb3947537adedb) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
2026-01-21drm/xe/uapi: disallow bind queue sharingMatthew Auld
Currently this is very broken if someone attempts to create a bind queue and share it across multiple VMs. For example currently we assume it is safe to acquire the user VM lock to protect some of the bind queue state, but if allow sharing the bind queue with multiple VMs then this quickly breaks down. To fix this reject using a bind queue with any VM that is not the same VM that was originally passed when creating the bind queue. This a uAPI change, however this was more of an oversight on kernel side that we didn't reject this, and expectation is that userspace shouldn't be using bind queues in this way, so in theory this change should go unnoticed. Based on a patch from Matt Brost. v2 (Matt B): - Hold the vm lock over queue create, to ensure it can't be closed as we attach the user_vm to the queue. - Make sure we actually check for NULL user_vm in destruction path. v3: - Fix error path handling. Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Reported-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Michal Mrozek <michal.mrozek@intel.com> Cc: Carl Zhang <carl.zhang@intel.com> Cc: <stable@vger.kernel.org> # v6.8+ Acked-by: José Roberto de Souza <jose.souza@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Arvind Yadav <arvind.yadav@intel.com> Acked-by: Michal Mrozek <michal.mrozek@intel.com> Link: https://patch.msgid.link/20260120110609.77958-3-matthew.auld@intel.com (cherry picked from commit 9dd08fdecc0c98d6516c2d2d1fa189c1332f8dab) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
2026-01-21drm: rcar-du: lvds: convert to of_drm_find_and_get_bridge()Luca Ceresoli
of_drm_find_bridge() is deprecated. Move to its replacement of_drm_find_and_get_bridge() which gets a bridge reference, and ensure it is put when done. Since the companion bridge pointer is used by .atomic_enable, putting its reference in the remove function would be dangerous. Use .destroy to put it on final deallocation. Acked-by: Maxime Ripard <mripard@kernel.org> Link: https://patch.msgid.link/20260109-drm-bridge-alloc-getput-drm_of_find_bridge-3-v2-6-8d7a3dbacdf4@bootlin.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2026-01-21drm/exynos: hdmi: convert to of_drm_find_and_get_bridge()Luca Ceresoli
of_drm_find_bridge() is deprecated. Move to its replacement of_drm_find_and_get_bridge() which gets a bridge reference, and ensure it is put when done. Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Acked-by: Maxime Ripard <mripard@kernel.org> Link: https://patch.msgid.link/20260109-drm-bridge-alloc-getput-drm_of_find_bridge-3-v2-5-8d7a3dbacdf4@bootlin.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2026-01-21drm/mediatek: mtk_hdmi*: convert to of_drm_find_and_get_bridge()Luca Ceresoli
of_drm_find_bridge() is deprecated. Move to its replacement of_drm_find_and_get_bridge() which gets a bridge reference, and ensure it is put when done by using the drm_bridge::next_bridge pointer. Acked-by: Maxime Ripard <mripard@kernel.org> Link: https://patch.msgid.link/20260109-drm-bridge-alloc-getput-drm_of_find_bridge-3-v2-4-8d7a3dbacdf4@bootlin.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2026-01-21drm/imx/dw-hdmi: convert to of_drm_find_and_get_bridge()Luca Ceresoli
of_drm_find_bridge() is deprecated. Move to its replacement of_drm_find_and_get_bridge() which gets a bridge reference, and ensure it is put when done. Acked-by: Maxime Ripard <mripard@kernel.org> Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de> Link: https://patch.msgid.link/20260109-drm-bridge-alloc-getput-drm_of_find_bridge-3-v2-3-8d7a3dbacdf4@bootlin.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2026-01-21drm/meson/dw-hdmi: convert to of_drm_find_and_get_bridge()Luca Ceresoli
of_drm_find_bridge() is deprecated. Move to its replacement of_drm_find_and_get_bridge() which gets a bridge reference, and ensure it is put when done. dw_hdmi->bridge is used only in dw_hdmi_top_thread_irq(), so in order to avoid potential use-after-free ensure the irq is freed before putting the dw_hdmi->bridge reference. Acked-by: Maxime Ripard <mripard@kernel.org> Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Acked-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patch.msgid.link/20260109-drm-bridge-alloc-getput-drm_of_find_bridge-3-v2-2-8d7a3dbacdf4@bootlin.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2026-01-21drm/bridge: dw-hdmi: convert to of_drm_find_and_get_bridge()Luca Ceresoli
of_drm_find_bridge() is deprecated. Move to its replacement of_drm_find_and_get_bridge() which gets a bridge reference, and ensure it is put when done by using the drm_bridge::next_bridge pointer. Acked-by: Maxime Ripard <mripard@kernel.org> Link: https://patch.msgid.link/20260109-drm-bridge-alloc-getput-drm_of_find_bridge-3-v2-1-8d7a3dbacdf4@bootlin.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2026-01-21drm/bridge: simple: add the Algoltek AG6311 DP-to-HDMI bridgeVal Packett
The Algoltek AG6311 is a transparent DisplayPort to HDMI bridge. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Val Packett <val@packett.cool> Link: https://patch.msgid.link/20260120234029.419825-8-val@packett.cool Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2026-01-21drm/bridge: anx7625: Fix invalid EDID sizeLoic Poulain
DRM checks EDID block count against allocated size in drm_edid_valid function. We have to allocate the right EDID size instead of the max size to prevent the EDID to be reported as invalid. Cc: stable@kernel.org Fixes: 7c585f9a71aa ("drm/bridge: anx7625: use struct drm_edid more") Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com> Link: https://patch.msgid.link/20251218151307.95491-1-loic.poulain@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2026-01-21drm/tests/drm_buddy: Add tests for allocations exceeding max_orderSanjay Yadav
Add kunit tests that exercise edge cases where allocation requests exceed mm->max_order after rounding. This can happen with non-power-of-two VRAM sizes when the allocator rounds up requests. For example, with 10G VRAM (8G + 2G roots), mm->max_order represents the 8G block. A 9G allocation can round up to 16G in multiple ways: CONTIGUOUS allocation rounds to next power-of-two, or non-CONTIGUOUS with 8G min_block_size rounds to next alignment boundary. The test validates CONTIGUOUS and RANGE flag combinations, ensuring that only CONTIGUOUS-alone allocations use try_harder fallback, while other combinations return -EINVAL when rounded size exceeds memory, preventing BUG_ON assertions. Cc: Christian König <christian.koenig@amd.com> Cc: Arunpravin Paneer Selvam <Arunpravin.PaneerSelvam@amd.com> Suggested-by: Matthew Auld <matthew.auld@intel.com> Signed-off-by: Sanjay Yadav <sanjay.kumar.yadav@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Signed-off-by: Arunpravin Paneer Selvam <Arunpravin.PaneerSelvam@amd.com> Link: https://patch.msgid.link/20260108113227.2101872-6-sanjay.kumar.yadav@intel.com
2026-01-21drm/buddy: Prevent BUG_ON by validating rounded allocationSanjay Yadav
When DRM_BUDDY_CONTIGUOUS_ALLOCATION is set, the requested size is rounded up to the next power-of-two via roundup_pow_of_two(). Similarly, for non-contiguous allocations with large min_block_size, the size is aligned up via round_up(). Both operations can produce a rounded size that exceeds mm->size, which later triggers BUG_ON(order > mm->max_order). Example scenarios: - 9G CONTIGUOUS allocation on 10G VRAM memory: roundup_pow_of_two(9G) = 16G > 10G - 9G allocation with 8G min_block_size on 10G VRAM memory: round_up(9G, 8G) = 16G > 10G Fix this by checking the rounded size against mm->size. For non-contiguous or range allocations where size > mm->size is invalid, return -EINVAL immediately. For contiguous allocations without range restrictions, allow the request to fall through to the existing __alloc_contig_try_harder() fallback. This ensures invalid user input returns an error or uses the fallback path instead of hitting BUG_ON. v2: (Matt A) - Add Fixes, Cc stable, and Closes tags for context Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/6712 Fixes: 0a1844bf0b53 ("drm/buddy: Improve contiguous memory allocation") Cc: <stable@vger.kernel.org> # v6.7+ Cc: Christian König <christian.koenig@amd.com> Cc: Arunpravin Paneer Selvam <Arunpravin.PaneerSelvam@amd.com> Suggested-by: Matthew Auld <matthew.auld@intel.com> Signed-off-by: Sanjay Yadav <sanjay.kumar.yadav@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Reviewed-by: Arunpravin Paneer Selvam <Arunpravin.PaneerSelvam@amd.com> Signed-off-by: Arunpravin Paneer Selvam <Arunpravin.PaneerSelvam@amd.com> Link: https://patch.msgid.link/20260108113227.2101872-5-sanjay.kumar.yadav@intel.com
2026-01-21drm/atmel-hlcdc: don't reject the commit if the src rect has fractional partsLudovic Desroches
Don’t reject the commit when the source rectangle has fractional parts. This can occur due to scaling: drm_atomic_helper_check_plane_state() calls drm_rect_clip_scaled(), which may introduce fractional parts while computing the clipped source rectangle. This does not imply the commit is invalid, so we should accept it instead of discarding it. Signed-off-by: Ludovic Desroches <ludovic.desroches@microchip.com> Reviewed-by: Manikandan Muralidharan <manikandan.m@microchip.com> Link: https://patch.msgid.link/20251120-lcd_scaling_fix-v1-1-5ffc98557923@microchip.com Signed-off-by: Manikandan Muralidharan <manikandan.m@microchip.com>
2026-01-20watchdog: softlockup: panic when lockup duration exceeds N thresholdsLi RongQing
The softlockup_panic sysctl is currently a binary option: panic immediately or never panic on soft lockups. Panicking on any soft lockup, regardless of duration, can be overly aggressive for brief stalls that may be caused by legitimate operations. Conversely, never panicking may allow severe system hangs to persist undetected. Extend softlockup_panic to accept an integer threshold, allowing the kernel to panic only when the normalized lockup duration exceeds N watchdog threshold periods. This provides finer-grained control to distinguish between transient delays and persistent system failures. The accepted values are: - 0: Don't panic (unchanged) - 1: Panic when duration >= 1 * threshold (20s default, original behavior) - N > 1: Panic when duration >= N * threshold (e.g., 2 = 40s, 3 = 60s.) The original behavior is preserved for values 0 and 1, maintaining full backward compatibility while allowing systems to tolerate brief lockups while still catching severe, persistent hangs. [lirongqing@baidu.com: v2] Link: https://lkml.kernel.org/r/20251218074300.4080-1-lirongqing@baidu.com Link: https://lkml.kernel.org/r/20251216074521.2796-1-lirongqing@baidu.com Signed-off-by: Li RongQing <lirongqing@baidu.com> Cc: Eduard Zingerman <eddyz87@gmail.com> Cc: Hao Luo <haoluo@google.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: John Fastabend <john.fastabend@gmail.com> Cc: KP Singh <kpsingh@kernel.org> Cc: Lance Yang <lance.yang@linux.dev> Cc: Martin KaFai Lau <martin.lau@linux.dev> Cc: Nicholas Piggin <npiggin@gmail.com> Cc: Song Liu <song@kernel.org> Cc: Stanislav Fomichev <sdf@fomichev.me> Cc: Yonghong Song <yonghong.song@linux.dev> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
generated by cgit v1.2.3 (git 2.46.0) at 2026-05-09 05:21:58 +0000