summaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)Author
2025-11-19drm/vblank: Switch to use %ptSpAndy Shevchenko
Use %ptSp instead of open coded variants to print content of struct timespec64 in human readable format. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://patch.msgid.link/20251113150217.3030010-8-andriy.shevchenko@linux.intel.com Reviewed-by: Petr Mladek <pmladek@suse.com> Signed-off-by: Petr Mladek <pmladek@suse.com>
2025-11-19drm/i915/cx0: Update C10/C20 state calculationMika Kahola
Update several functions in intel_cx0_phy.c to make PLL state management more explicit. Changes include * add 'const' qualifiers to intel_crtc_state parameter for cx0 state calculation functions * refactor C10/C20 PLL state calculations helpers to take explicit hardware state pointers instead of directly modifying 'crtc_state->dpll_hw_state' Signed-off-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Mika Kahola <mika.kahola@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://lore.kernel.org/r/20251117104602.2363671-18-mika.kahola@intel.com
2025-11-19drm/i915/cx0: Add PLL information for MTL+Mika Kahola
Start bringing MTL+ platforms as part of PLL framework. The work is started by adding PLL information and related function hooks. BSpec: 55726 v2: Revise commit message and add BSpec ID (Suraj) Signed-off-by: Mika Kahola <mika.kahola@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://lore.kernel.org/r/20251117104602.2363671-17-mika.kahola@intel.com
2025-11-19drm/i915/cx0: Remove state verificationMika Kahola
When pll's are moved to dpll framework we no longer need Cx0 specific state verification as we can rely on dpll state verification instead. Signed-off-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Mika Kahola <mika.kahola@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://lore.kernel.org/r/20251117104602.2363671-16-mika.kahola@intel.com
2025-11-19drm/i915/cx0: Print additional Cx0 PLL HW stateImre Deak
Print all the Cx0 PLL state in the PLL state dumper. v2: Use BUILD_BUG_ON() instead of WARN_ON() (Jani) Signed-off-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Mika Kahola <mika.kahola@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://lore.kernel.org/r/20251117104602.2363671-15-mika.kahola@intel.com
2025-11-19drm/i915/cx0: Zero Cx0 PLL state before compute and HW readoutImre Deak
Ensure Cx0 pll state is initialized to zero before any computation or HW readouts, to prevent leaving some parameter in the state uninitialized in the actual compute/HW readout functions later. Signed-off-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Mika Kahola <mika.kahola@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://lore.kernel.org/r/20251117104602.2363671-14-mika.kahola@intel.com
2025-11-19drm/i915/cx0: Determine Cx0 PLL port clock from PLL stateImre Deak
The port clock is tracked in the PLL state, so there is no need to pass it separately to __intel_cx0pll_enable(). Drop the port clock function param accordingly. Signed-off-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Mika Kahola <mika.kahola@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://lore.kernel.org/r/20251117104602.2363671-13-mika.kahola@intel.com
2025-11-19drm/i915/cx0: Determine Cx0 PLL DP mode from PLL stateImre Deak
The Cx0 PLL enable programming needs to know if the PLL is in DP or HDMI mode. The PLL manager framework doesn't pass the CRTC state to the PLL's enable hook, so prepare here for the conversion to use the PLL manager for Cx0 PHY PLLs by determining the DP/HDMI mode from the PLL state. For C10 PHYs use the fact that the HDMI divider value in the PLL registers are set if and only if the PLL is in HDMI mode. For C20 PHYs use the DP mode flag programmed to the VDR SERDES register, which is set if and only if the PLL is in DP mode. Assert that the above PLL/VDR SERDES register values match the DP/HDMI mode being configured already during state computation. This also allows dropping the is_dp param from the __intel_cx0pll_enable() function, since it can retrieve this now from the PLL state. Signed-off-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Mika Kahola <mika.kahola@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://lore.kernel.org/r/20251117104602.2363671-12-mika.kahola@intel.com
2025-11-19drm/i915/cx0: Read out the Cx0 PHY SSC enabled stateImre Deak
Read out the C10, C20 PHY PLLs SSC enabled state, so the PLL HW/SW state verification can check this state as well. C10 PHY PLLs program some PLL registers zeroed out for the non-SSC case, while programming non-zero values to the same registers for the SSC case, so check that these PLL registers being zero or non-zero matches the PLL's overall SSC-enabled state (stored in the intel_c10pll_state::ssc_enabled flag). Signed-off-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Mika Kahola <mika.kahola@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://lore.kernel.org/r/20251117104602.2363671-11-mika.kahola@intel.com
2025-11-19drm/i915/cx0: Sanitize C10 PHY PLL SSC register setupImre Deak
Define the C10 PLL SSC register range via macros, so the HW/SW state of these register can be verified by a follow-up change, reusing these macros. Signed-off-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Mika Kahola <mika.kahola@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://lore.kernel.org/r/20251117104602.2363671-10-mika.kahola@intel.com
2025-11-19drm/i915/cx0: Track the Cx0 PHY enabled lane count in the PLL stateImre Deak
The Cx0 PLL enable programming requires the enabled lane count. The PLL manager framework doesn't pass the CRTC state to the PLL's enable hook, so prepare here for the conversion to use the PLL manager, by tracking the enabled lane count in the PLL state as well. This has the advantage, that the enabled lane count can be verified against the PHY/PLL's enabled TX lanes. This also allows dropping the lane count param from the __intel_cx0pll_enable() function, since it can retrieve this now from the PLL state. Signed-off-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Mika Kahola <mika.kahola@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://lore.kernel.org/r/20251117104602.2363671-9-mika.kahola@intel.com
2025-11-19drm/i915/cx0: Add macro to get DDI port width from a register valueImre Deak
A follow-up change will need to retrieve the DDI port field from the register value, add a macro for this. Make things symmetric with setting the field in the register. Signed-off-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Mika Kahola <mika.kahola@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://lore.kernel.org/r/20251117104602.2363671-8-mika.kahola@intel.com
2025-11-19drm/i915/cx0: Move definition of Cx0 PHY functions earlierImre Deak
Move the definitions of the intel_c10pll_calc_port_clock() intel_c20_get_dp_rate() intel_c20_get_hdmi_rate() is_hdmi_frl() is_dp2() intel_get_c20_custom_width() functions earlier to avoid the forward declarations. Signed-off-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Mika Kahola <mika.kahola@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://lore.kernel.org/r/20251117104602.2363671-7-mika.kahola@intel.com
2025-11-19drm/i915/cx0: Track the C20 PHY VDR state in the PLL stateImre Deak
The Cx0 PLL enable programming needs to know if the PLL is in DP or HDMI mode. The PLL manager framework doesn't pass the CRTC state to the PLL's enable hook, so prepare here for the conversion to use the PLL manager for Cx0 PHY PLLs by tracking the DP/HDMI mode in the PLL state. This change has the advantage, that the VDR HW/SW state can be verified now. A follow up change will convert the PLL enable function to retrieve the DP/HDMI mode parameter from the PLL state. This also allows dropping the is_dp and port clock params from the intel_c20_pll_program() function, since it can retrieve these now from the PLL state. v2: Fix comment to under same multicomment line (Suraj) Signed-off-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Mika Kahola <mika.kahola@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://lore.kernel.org/r/20251117104602.2363671-6-mika.kahola@intel.com
2025-11-19drm/i915/cx0: Sanitize calculating C20 PLL state from tablesImre Deak
A follow up change adds a computation for the C20 PLL VDR state, which is common to both the HDMI algorithmic and DP/HDMI table based method. To prepare for that streamline the code. The C10 counterpart would benefit from the same change, leave that for later adding a TODO comment. Signed-off-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Mika Kahola <mika.kahola@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://lore.kernel.org/r/20251117104602.2363671-5-mika.kahola@intel.com
2025-11-19drm/i915/cx0: Sanitize setting the Cx0 PLL use_c10 flagImre Deak
Sanitize setting the Cx0 PLL use_c10 flag during state computation and HW readout, making sure they happen the same way in the intel_c{10,20}pll_calc_state() and intel_c{10,20}pll_readout_hw_state() functions. Follow-up changes will add more state computation/HW readout, this change prepares for those as well. Signed-off-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Mika Kahola <mika.kahola@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://lore.kernel.org/r/20251117104602.2363671-4-mika.kahola@intel.com
2025-11-19drm/i915/cx0: Factor out C10 msgbus access start/end helpersImre Deak
Factor out functions to begin and complete C10 PHY programming sequences to make the code more concise. v2: Rename msgbus_update_config() to more descriptive msg_bus_access_commit() (Jani) Signed-off-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Mika Kahola <mika.kahola@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://lore.kernel.org/r/20251117104602.2363671-3-mika.kahola@intel.com
2025-11-19drm/i915/cx0: Rename TBT functions to be ICL specificMika Kahola
Rename pll functions to include ICL platform as these are used from ICL onwards. Signed-off-by: Mika Kahola <mika.kahola@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://lore.kernel.org/r/20251117104602.2363671-2-mika.kahola@intel.com
2025-11-19drm/msm: Switch to use %ptSpAndy Shevchenko
Use %ptSp instead of open coded variants to print content of struct timespec64 in human readable format. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://patch.msgid.link/20251113150217.3030010-7-andriy.shevchenko@linux.intel.com Signed-off-by: Petr Mladek <pmladek@suse.com>
2025-11-19drm/amdgpu: Switch to use %ptSpAndy Shevchenko
Use %ptSp instead of open coded variants to print content of struct timespec64 in human readable format. Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://patch.msgid.link/20251113150217.3030010-6-andriy.shevchenko@linux.intel.com Signed-off-by: Petr Mladek <pmladek@suse.com>
2025-11-19drm/i915/fbdev: Hold runtime PM ref during fbdev BO creationDibin Moolakadan Subrahmanian
During fbdev probe, the xe driver allocates and pins a framebuffer BO (via xe_bo_create_pin_map_novm() → xe_ggtt_insert_bo()). Without a runtime PM reference, xe_pm_runtime_get_noresume() warns about missing outer PM protection as below: xe 0000:03:00.0: [drm] Missing outer runtime PM protection Acquire a runtime PM reference before framebuffer allocation to ensure xe_ggtt_insert_bo() executes under active runtime PM context. Changes in v2: - Update commit message to add Fixes tag (Jani Nikula) Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/6350 Fixes: 44e694958b95 ("drm/xe/display: Implement display support") Cc: Jani Nikula <jani.nikula@linux.intel.com> Signed-off-by: Dibin Moolakadan Subrahmanian <dibin.moolakadan.subrahmanian@intel.com> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Link: https://patch.msgid.link/20251111135403.3415947-1-dibin.moolakadan.subrahmanian@intel.com
2025-11-18drm/xe/vf: Shadow buffer management for CCS read/write operationsSatyanarayana K V P
CCS copy command consist of 5-dword sequence. If vCPU halts during save/restore operations while these sequences are being programmed, incomplete writes can cause page faults during IGPU CCS metadata saving. Use shadow buffer management to prevent partial write issues during CCS operations. Signed-off-by: Satyanarayana K V P <satyanarayana.k.v.p@intel.com> Suggested-by: Matthew Brost <matthew.brost@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Matthew Auld <matthew.auld@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20251118120745.3460172-3-satyanarayana.k.v.p@intel.com
2025-11-18drm/xe/sa: Shadow buffer support in the sub-allocator poolSatyanarayana K V P
The existing sub-allocator is limited to managing a single buffer object. This enhancement introduces shadow buffer functionality to support scenarios requiring dual buffer management. The changes include added shadow buffer object creation capability, Management for both primary and shadow buffers, and appropriate locking mechanisms for thread-safe operations. This enables more flexible buffer allocation strategies in scenarios where shadow buffering is required. Signed-off-by: Satyanarayana K V P <satyanarayana.k.v.p@intel.com> Suggested-by: Matthew Brost <matthew.brost@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Matthew Auld <matthew.auld@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20251118120745.3460172-2-satyanarayana.k.v.p@intel.com
2025-11-18drm/xe/irq: Handle msix vector0 interruptVenkata Ramana Nayana
Current gu2host handler registered as MSI-X vector 0 and as per bspec for a msix vector 0 interrupt, the driver must check the legacy registers 190008(TILE_INT_REG), 190060h (GT INTR Identity Reg 0) and other registers mentioned in "Interrupt Service Routine Pseudocode" otherwise it will block the next interrupts. To overcome this issue replacing guc2host handler with legacy xe_irq_handler. Fixes: da889070be7b2 ("drm/xe/irq: Separate MSI and MSI-X flows") Bspec: 62357 Signed-off-by: Venkata Ramana Nayana <venkata.ramana.nayana@intel.com> Reviewed-by: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com> Link: https://patch.msgid.link/20251107083141.2080189-1-venkata.ramana.nayana@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com> (cherry picked from commit c34a14bce7090862ebe5a64abe8d85df75e62737) Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-11-18drm/xe: Remove duplicate DRM_EXEC selection from KconfigShuicheng Lin
There are 2 identical "select DRM_EXEC" lines for DRM_XE. Remove one to clean up the configuration. Fixes: d490ecf57790 ("drm/xe: Rework xe_exec and the VM rebind worker to use the drm_exec helper") Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Shuicheng Lin <shuicheng.lin@intel.com> Reviewed-by: Nitin Gote <nitin.r.gote@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patch.msgid.link/20251110232657.1807998-2-shuicheng.lin@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> (cherry picked from commit b1aa02acd03bfef3ed39c511d33c4a4303d2f9b1) Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-11-18drm/xe/kunit: Fix forcewake assertion in mocs testMatt Roper
The MOCS kunit test calls KUNIT_ASSERT_TRUE_MSG() with a condition of 'true;' this prevents the assertion from ever failing. Replace KUNIT_ASSERT_TRUE_MSG with KUNIT_FAIL_AND_ABORT to get the intended failure behavior in cases where forcewake was not acquired successfully. Fixes: 51c0ee84e4dc ("drm/xe/tests/mocs: Hold XE_FORCEWAKE_ALL for LNCF regs") Cc: Tejas Upadhyay <tejas.upadhyay@intel.com> Cc: Gustavo Sousa <gustavo.sousa@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Link: https://patch.msgid.link/20251113234038.2256106-2-matthew.d.roper@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com> (cherry picked from commit 9be4f0f687048ba77428ceca11994676736507b7) Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-11-18drm/xe: Prevent BIT() overflow when handling invalid prefetch regionShuicheng Lin
If user provides a large value (such as 0x80) for parameter prefetch_mem_region_instance in vm_bind ioctl, it will cause BIT(prefetch_region) overflow as below: " ------------[ cut here ]------------ UBSAN: shift-out-of-bounds in drivers/gpu/drm/xe/xe_vm.c:3414:7 shift exponent 128 is too large for 64-bit type 'long unsigned int' CPU: 8 UID: 0 PID: 53120 Comm: xe_exec_system_ Tainted: G W 6.18.0-rc1-lgci-xe-kernel+ #200 PREEMPT(voluntary) Tainted: [W]=WARN Hardware name: ASUS System Product Name/PRIME Z790-P WIFI, BIOS 0812 02/24/2023 Call Trace: <TASK> dump_stack_lvl+0xa0/0xc0 dump_stack+0x10/0x20 ubsan_epilogue+0x9/0x40 __ubsan_handle_shift_out_of_bounds+0x10e/0x170 ? mutex_unlock+0x12/0x20 xe_vm_bind_ioctl.cold+0x20/0x3c [xe] ... " Fix it by validating prefetch_region before the BIT() usage. v2: Add Closes and Cc stable kernels. (Matt) Reported-by: Koen Koning <koen.koning@intel.com> Reported-by: Peter Senna Tschudin <peter.senna@linux.intel.com> Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/6478 Cc: <stable@vger.kernel.org> # v6.8+ Reviewed-by: Matthew Auld <matthew.auld@intel.com> Signed-off-by: Shuicheng Lin <shuicheng.lin@intel.com> Signed-off-by: Matthew Auld <matthew.auld@intel.com> Link: https://patch.msgid.link/20251112181005.2120521-2-shuicheng.lin@intel.com (cherry picked from commit 8f565bdd14eec5611cc041dba4650e42ccdf71d9) Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-11-18drm/radeon: delete radeon_fence_process in is_signaled, no deadlockRobert McClinton
Delete the attempt to progress the queue when checking if fence is signaled. This avoids deadlock. dma-fence_ops::signaled can be called with the fence lock in unknown state. For radeon, the fence lock is also the wait queue lock. This can cause a self deadlock when signaled() tries to make forward progress on the wait queue. But advancing the queue is unneeded because incorrectly returning false from signaled() is perfectly acceptable. Link: https://github.com/brave/brave-browser/issues/49182 Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4641 Cc: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Robert McClinton <rbmccav@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 527ba26e50ec2ca2be9c7c82f3ad42998a75d0db) Cc: stable@vger.kernel.org
2025-11-18drm/amd/display: Fix pbn to kbps ConversionFangzhi Zuo
[Why] Existing routine has two conversion sequence, pbn_to_kbps and kbps_to_pbn with margin. Non of those has without-margin calculation. kbps_to_pbn with margin conversion includes fec overhead which has already been included in pbn_div calculation with 0.994 factor considered. It is a double counted fec overhead factor that causes potential bw loss. [How] Add without-margin calculation. Fix fec overhead double counted issue. Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3735 Reviewed-by: Aurabindo Pillai <aurabindo.pillai@amd.com> Signed-off-by: Fangzhi Zuo <Jerry.Zuo@amd.com> Signed-off-by: Ivan Lipski <ivan.lipski@amd.com> Tested-by: Dan Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit e0dec00f3d05e8c0eceaaebfdca217f8d10d380c) Cc: stable@vger.kernel.org
2025-11-18drm/amd/display: Clear the CUR_ENABLE register on DCN20 on DPP5Ivan Lipski
[Why] On DCN20 & DCN30, the 6th DPP's & HUBP's are powered on permanently and cannot be power gated. Thus, when dpp_reset() is invoked for the DPP5, while it's still powered on, the cached cursor_state (dpp_base->pos.cur0_ctl.bits.cur0_enable) and the actual state (CUR0_ENABLE) bit are unsycned. This can cause a double cursor in full screen with non-native scaling. [How] Force disable cursor on DPP5 on plane powerdown for ASICs w/ 6 DPPs/HUBPs. Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4673 Reviewed-by: Aric Cyr <aric.cyr@amd.com> Signed-off-by: Ivan Lipski <ivan.lipski@amd.com> Tested-by: Dan Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 79b3c037f972dcb13e325a8eabfb8da835764e15) Cc: stable@vger.kernel.org
2025-11-18drm/amd/display: Add an HPD filter for HDMIIvan Lipski
[Why] Some monitors perform rapid “autoscan” HPD re‑assertions right after a disconnect or powersaving mode enablement. These appear as a quick disconnect→reconnect with an identical EDID. Since Linux has no HDMI hotplug detection (HPD) filter, these quick reconnects are seen as hotplug events, which can unintentionally wake a system with DPMS off. An example: https://gitlab.freedesktop.org/drm/amd/-/issues/2876 Such 'fake reconnects' are considered when the interval between a disconnect and a connect is within 1500ms (experimentally chosen using several monitors), and the two connections have the same EDID. [How] Implement a time-based debounce mechanism: 1. On HDMI disconnect detection, instead of immediately processing the HPD event, save the current sink and schedule delayed work (default 1500ms) 2. If another HDMI disconnect HPD event arrives during the debounce period, it reschedules the pending work, ensuring only the final state is processed. 3. When the debounce timer expires, re-detect the display and compare the new sink with the cached one using EDID comparison. 4. If sinks match (same EDID), this was a spontaneous HPD toggle: - Update connector state internally - Skip hotplug event to prevent desktop rearrangement If sinks differ, this was a real display change: - Process normally with the hotplug event The debounce delay is configurable via module parameter 'hdmi_hpd_debounce_delay_ms'. Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/2876 Reviewed-by: Sun peng (Leo) Li <sunpeng.li@amd.com> Signed-off-by: Ivan Lipski <ivan.lipski@amd.com> Tested-by: Dan Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit c918e75e1ed95be76f8e3156a411188f650fe03f)
2025-11-18drm/amd/display: Increase DPCD read retriesMario Limonciello (AMD)
[Why] Empirical measurement of some monitors that fail to read EDID while booting shows that the number of retries with a 30ms delay between tries is as high as 16. [How] Increase number of retries to 20. Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4672 Reviewed-by: Alex Hung <alex.hung@amd.com> Signed-off-by: Mario Limonciello (AMD) <superm1@kernel.org> Signed-off-by: Ivan Lipski <ivan.lipski@amd.com> Tested-by: Dan Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit ad1c59ad7cf74ec06e32fe2c330ac1e957222288) Cc: stable@vger.kernel.org
2025-11-18drm/msm/a8xx: Add support for Adreno X2-85 GPUAkhil P Oommen
Adreno X2-85 GPU is found in the next generation of Qualcomm's compute series chipset called Snapdragon X2 Elite (a.k.a Glymur). It is based on the new A8x slice architecture and features up to 4 slices. Due to the wider 12 channel DDR support, there is higher DDR bandwidth available than previous generation to improve performance. Add a new entry in the catalog along with the necessary register configurations to enable support for it. Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/689026/ Message-ID: <20251118-kaana-gpu-support-v4-18-86eeb8e93fb6@oss.qualcomm.com> Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
2025-11-18drm/msm/adreno: Do CX GBIF config before GMU startAkhil P Oommen
GMU lies on the CX domain and accesses CX GBIF. So do CX GBIF configurations before GMU wakes up. This was not a problem so far, but A840 GPU is very sensitive to this requirement. Also, move these registers to the catalog. Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/689024/ Message-ID: <20251118-kaana-gpu-support-v4-17-86eeb8e93fb6@oss.qualcomm.com> Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
2025-11-18drm/msm/a8xx: Add support for Adreno 840 GPUAkhil P Oommen
Adreno 840 present in Kaanapali SoC is the second generation GPU in A8x family. It comes in 2 variants with either 2 or 3 Slices. This is in addition to the SKUs supported based on the GPU FMAX. Add the necessary register configurations to the catalog and enable support for it. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/689022/ Message-ID: <20251118-kaana-gpu-support-v4-16-86eeb8e93fb6@oss.qualcomm.com> Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
2025-11-18drm/msm/adreno: Support AQE engineAkhil P Oommen
AQE (Applicaton Qrisc Engine) is a dedicated core inside CP which aides in Raytracing related workloads. Add support for loading the AQE firmware and initialize the necessary registers. 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/689020/ Message-ID: <20251118-kaana-gpu-support-v4-15-86eeb8e93fb6@oss.qualcomm.com> Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
2025-11-18drm/msm/adreno: Introduce A8x GPU SupportAkhil P Oommen
A8x is the next generation of Adreno GPUs, featuring a significant hardware design change. A major update to the design is the introduction of Slice architecture. Slices are sort of mini-GPUs within the GPU which are more independent in processing Graphics and compute workloads. Also, in addition to the BV and BR pipe we saw in A7x, CP has more concurrency with additional pipes. From a software interface perspective, these changes have a significant impact on the KMD side. First, the GPU register space has been extensively reorganized. Second, to avoid a register space explosion caused by the new slice architecture and additional pipes, many registers are now virtualized, instead of duplicated as in A7x. KMD must configure an aperture register with the appropriate slice and pipe ID before accessing these virtualized registers. Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/689019/ Message-ID: <20251118-kaana-gpu-support-v4-14-86eeb8e93fb6@oss.qualcomm.com> Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
2025-11-18drm/msm/a6xx: Share dependency vote table with GMUAkhil P Oommen
A8x GMU firmwares expect a separate vote table which describes the relationship between the Gx rail and MxA rail (and possibly Cx rail). Create this new vote table and implement the new HFI message which allows passing vote tables to send this data to GMU. Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/689016/ Message-ID: <20251118-kaana-gpu-support-v4-13-86eeb8e93fb6@oss.qualcomm.com> Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
2025-11-18drm/msm/a6xx: Improve MX rail fallback in RPMH vote initAkhil P Oommen
Current logic assumes that the voltage corners in both MxG and MxA are always same. This is not true for recent targets. So, rework the rpmh init sequence to probe and calculate the votes with the respective rails, ie, GX rails should use MxG as secondary rail and Cx rail should use MxA as the secondary rail. Fixes: d6225e0cd096 ("drm/msm/adreno: Add support for X185 GPU") Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/689014/ Message-ID: <20251118-kaana-gpu-support-v4-12-86eeb8e93fb6@oss.qualcomm.com> Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
2025-11-18drm/msm/a8xx: Add support for A8x GMUAkhil P Oommen
A8x GMU configurations are very similar to A7x. Unfortunately, there are minor shuffling in the register offsets in the GMU CX register region. So, update the driver to use the correct register offsets on A8x hw. Some A8x GPUs have more than 16 powerlevels on GX domain and 4 on CX domain. To accommodate this, increase the arrays' sizes which hold gx and cx power levels. Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/689013/ Message-ID: <20251118-kaana-gpu-support-v4-11-86eeb8e93fb6@oss.qualcomm.com> Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
2025-11-18drm/msm/a6xx: Rebase GMU register offsetsAkhil P Oommen
GMU registers are always at a fixed offset from the GPU base address, a consistency maintained at least within a given architecture generation. In A8x family, the base address of the GMU has changed, but the offsets of the gmu registers remain largely the same. To enable reuse of the gmu code for A8x chipsets, update the gmu register offsets to be relative to the GPU's base address instead of GMU's. Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/689010/ Message-ID: <20251118-kaana-gpu-support-v4-10-86eeb8e93fb6@oss.qualcomm.com> Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
2025-11-18drm/msm/a6xx: Sync latest register definitionsAkhil P Oommen
Sync the latest register definitions from Mesa which includes the updates for A8x family. Co-developed-by: Rob Clark <robin.clark@oss.qualcomm.com> Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com> Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/689009/ Message-ID: <20251118-kaana-gpu-support-v4-9-86eeb8e93fb6@oss.qualcomm.com>
2025-11-18drm/amd/display: Move sleep into each retry for retrieve_link_cap()Mario Limonciello (AMD)
[Why] When a monitor is booting it's possible that it isn't ready to retrieve link caps and this can lead to an EDID read failure: ``` [drm:retrieve_link_cap [amdgpu]] *ERROR* retrieve_link_cap: Read receiver caps dpcd data failed. amdgpu 0000:c5:00.0: [drm] *ERROR* No EDID read. ``` [How] Rather than msleep once and try a few times, msleep each time. Should be no changes for existing working monitors, but should correct reading caps on a monitor that is slow to boot. Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4672 Reviewed-by: Alex Hung <alex.hung@amd.com> Signed-off-by: Mario Limonciello (AMD) <superm1@kernel.org> Signed-off-by: Ivan Lipski <ivan.lipski@amd.com> Tested-by: Dan Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 669dca37b3348a447db04bbdcbb3def94d5997cc) Cc: stable@vger.kernel.org
2025-11-18drm/amd/display: Prevent Gating DTBCLK before It Is Properly LatchedFangzhi Zuo
[why] 1. With allow_0_dtb_clk enabled, the time required to latch DTBCLK to 600 MHz depends on the SMU. If DTBCLK is not latched to 600 MHz before set_mode completes, gating DTBCLK causes the DP2 sink to lose its clock source. 2. The existing DTBCLK gating sequence ungates DTBCLK based on both pix_clk and ref_dtbclk, but gates DTBCLK when either pix_clk or ref_dtbclk is zero. pix_clk can be zero outside the set_mode sequence before DTBCLK is properly latched, which can lead to DTBCLK being gated by mistake. [how] Consider both pixel_clk and ref_dtbclk when determining when it is safe to gate DTBCLK; this is more accurate. Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4701 Fixes: 5949e7c4890c ("drm/amd/display: Enable Dynamic DTBCLK Switch") Reviewed-by: Charlene Liu <charlene.liu@amd.com> Reviewed-by: Aurabindo Pillai <aurabindo.pillai@amd.com> Signed-off-by: Fangzhi Zuo <Jerry.Zuo@amd.com> Signed-off-by: Roman Li <roman.li@amd.com> Tested-by: Dan Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit d04eb0c402780ca037b62a6aecf23b863545ebca) Cc: stable@vger.kernel.org
2025-11-18drm/amd/display: Move analog check to dce110_hwseqTimur Kristóf
Instead of checking that the signal is analog before calling the HWSS disable_audio_stream() function to disable audio, move the check inside the HWSS function. Suggested-by: Ray Wu <Ray.Wu@amd.com> Signed-off-by: Timur Kristóf <timur.kristof@gmail.com> Reviewed-by: Harry Wentland <harry.wentland@amd.com> Link: https://lore.kernel.org/r/20251113163348.137315-5-timur.kristof@gmail.com Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-11-18drm/amd/display: Cleanup early return in construct_phyTimur Kristóf
Match pre-existing patterns in the DC code base. Instead of returning early from the construct_phy() function, add a label at the end and use goto to jump there. Additionally, respect the DC logger and let it log the function even when it returns early. Suggested-by: Ray Wu <Ray.Wu@amd.com> Signed-off-by: Timur Kristóf <timur.kristof@gmail.com> Reviewed-by: Harry Wentland <harry.wentland@amd.com> Link: https://lore.kernel.org/r/20251113163348.137315-4-timur.kristof@gmail.com Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-11-18drm/amd/display: Cleanup uses of the analog flagTimur Kristóf
In the detect_link_and_local_sink() function, do not modify the EDID capabilities of the display based on the connector. Instead, respect the analog flag better and when the analog flag is set, check that the connector indeed supports analog displays. Suggested-by: Ray Wu <Ray.Wu@amd.com> Signed-off-by: Timur Kristóf <timur.kristof@gmail.com> Reviewed-by: Harry Wentland <harry.wentland@amd.com> Link: https://lore.kernel.org/r/20251113163348.137315-3-timur.kristof@gmail.com Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-11-18drm/amd/display: Fix warning for analog stream encodersTimur Kristóf
Fixes the following warning that some users are reporting with some kernel configurations: "positional initialization of field in 'struct' declared with 'designated_init' attribute" Signed-off-by: Timur Kristóf <timur.kristof@gmail.com> Reviewed-by: Harry Wentland <harry.wentland@amd.com> Acked-by: Kees Cook <kees@kernel.org> Link: https://lore.kernel.org/r/20251113163348.137315-2-timur.kristof@gmail.com Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-11-18drm/radeon: delete radeon_fence_process in is_signaled, no deadlockRobert McClinton
Delete the attempt to progress the queue when checking if fence is signaled. This avoids deadlock. dma-fence_ops::signaled can be called with the fence lock in unknown state. For radeon, the fence lock is also the wait queue lock. This can cause a self deadlock when signaled() tries to make forward progress on the wait queue. But advancing the queue is unneeded because incorrectly returning false from signaled() is perfectly acceptable. Link: https://github.com/brave/brave-browser/issues/49182 Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4641 Cc: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Robert McClinton <rbmccav@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-11-18drm/amd/display: dc_hw_sequencer.c: remove kernel-doc commentsRandy Dunlap
Change comments from kernel-doc style "/**" to normal C comments "/*" since the comments are not in kernel-doc format. This fixes around 39 kernel-doc warnings like this one: drivers/gpu/drm/amd/display/dc/core/dc_hw_sequencer.c:1322: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202511062036.Ry8Z2APc-lkp@intel.com/ Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
generated by cgit v1.2.3 (git 2.46.0) at 2026-05-16 21:45:48 +0000