GPU Fixes for Pakala#1111
Merged
taniyadas20 merged 4 commits intoMay 11, 2026
Merged
Conversation
The GX GDSC is a special power domain that should only be disabled by OS during GMU recovery. In all other scenarios, the GMU firmware is responsible for handling its disable sequence, and OS must not interfere. During the resume_noirq() phase of system resume, the GenPD framework enables all power domains and later disables them in the complete() phase if there are no active votes from OS. This behavior can incorrectly disable the GX GDSC while the GMU firmware is still using it. To prevent this, implement a custom disable callback for GX GDSC that relies on GenPD’s synced_poweroff flag. The GMU driver sets this flag only during recovery, allowing OS to explicitly disable GX GDSC in hardware in that case. In all other situations, the disable callback will avoid touching GX GDSC hardware. Signed-off-by: Jagadeesh Kona <jagadeesh.kona@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260427-gfx-clk-fixes-v2-1-797e54b3d464@oss.qualcomm.com Signed-off-by: Taniya Das <taniya.das@oss.qualcomm.com>
The GX GDSC represents a special GPU power domain that must not be disabled during normal runtime PM flows. As per the GMU architecture, GX GDSC should only be force-disabled during GMU/GPU recovery, where the OS explicitly resets the GX power domain. However, when managed by the generic GDSC runtime PM path, GX GDSC may be disabled during GMU runtime suspend, resulting in warnings such as: gx_clkctl_gx_gdsc status stuck at 'on' and failures in gdsc_toggle_logic() during rpm suspend. Use the newly added custom disable callback for gx_gdsc to ensure the GDSC is toggled only in recovery scenarios, while preventing unintended disable attempts during normal GMU runtime PM operations. Reported-by: Pengyu Luo <mitltlatltl@gmail.com> Closes: https://lore.kernel.org/all/CAH2e8h4Vp9fJYAUUbOmoHSKB25wakPBvmpwa62BTRqgRQbMWuw@mail.gmail.com/ Reported-by: Alexander Koskovich <akoskovich@pm.me> Closes: https://lore.kernel.org/all/gwVAH2mJerU4dBInw8pKmOs5aQK55Q7W6q_UQAlLFCsEgX6eyvSgXAWbNNMqAX4WmPlYCKUSMhfkr5Jry4Ps5EqnxYZqEEDd3Whwv7ZXGlc=@pm.me/ Fixes: 5af11ac ("clk: qcom: Add a driver for SM8750 GPU clocks") Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260427-gfx-clk-fixes-v2-2-797e54b3d464@oss.qualcomm.com Signed-off-by: Taniya Das <taniya.das@oss.qualcomm.com>
…robe When the clock controller is probed with 'use_rpm' enabled, the runtime PM reference is currently released using pm_runtime_put(), which may return before the runtime suspend has completed. When the clock controller device is registered through this function, calling pm_runtime_disable() immediately after pm_runtime_put() prevents the runtime suspend from completing, leaving the clock controller active and the HW rails in the ON state. Use pm_runtime_put_sync() instead to ensure the runtime PM “putV completes synchronously during probe. This does not have any functional impact, but it guarantees that the device is fully runtime-suspended before returning. Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260427-gfx-clk-fixes-v2-3-797e54b3d464@oss.qualcomm.com Signed-off-by: Taniya Das <taniya.das@oss.qualcomm.com>
…h IFPC The GX GDSC control is handled through a dedicated clock controller, and the enable/disable sequencing depends on correct rail voting. The driver votes for the GX/GMxC rails and CX GDSC before toggling the GX GDSC. Currently, during GMU runtime PM resume, rails remain enabled due to upstream votes propagated via RPM-enabled devlinks and explicit pm_runtime votes on GX GDSC. This is not an expected behaviour of IFPC(Inter Frame Power Collapse) requirements of GPU as GMU firmware is expected to control these rails, except during the GPU/GMU recovery via the OS and that is where the GX GDSC should be voting for the rails (GX/GMxC and CX GDSC) before toggling the GX GDSC. Thus, disable runtime PM after successfully registering the clock controller. Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260427-gfx-clk-fixes-v2-4-797e54b3d464@oss.qualcomm.com Signed-off-by: Taniya Das <taniya.das@oss.qualcomm.com>
taniyadas20
merged commit eea3e98
into
qualcomm-linux:tech/bsp/clk
1 of 2 checks passed
qcomlnxci
requested review from
a team and
mdtipton
and removed request for
a team
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.