From: Heiko Stuebner heiko@sntech.de
[ Upstream commit 596a977b34a722c00245801a5774aa79cec4e81d ]
The ddrphy is supplied by the dpll, but due to the limited number of PLLs on the rk3036, the dpll also is used for other periperhals, like the GPU.
So it happened, when the Lima driver turned off the gpu clock, this in turn also disabled the dpll and thus the ram.
Signed-off-by: Heiko Stuebner heiko@sntech.de Link: https://lore.kernel.org/r/20250503202532.992033-4-heiko@sntech.de Signed-off-by: Sasha Levin sashal@kernel.org ---
**YES** This commit should absolutely be backported to stable kernel trees. Here's my detailed analysis: ## Critical System Stability Issue The commit fixes a **critical system stability problem** where the DDR PHY clock can be disabled, causing the system to lose access to RAM and crash. This is evidenced by: 1. **Root Cause Analysis**: The commit message clearly explains that "when the Lima driver turned off the gpu clock, this in turn also disabled the dpll and thus the ram" - this is a shared resource conflict that can brick the system. 2. **Hardware Limitation**: The RK3036 has "limited number of PLLs" where the DPLL is shared between the DDR PHY (memory controller) and GPU, creating an inherent conflict when GPU clock management affects memory access. ## Code Change Analysis The fix is **minimal and safe**: ```c static const char *const rk3036_critical_clocks[] __initconst = { "aclk_cpu", "aclk_peri", "hclk_peri", "pclk_peri", "pclk_ddrupctl", + "ddrphy", // <-- Single line addition }; ``` - **Single line change**: Adding "ddrphy" to the critical clocks array - **No functional changes**: Uses existing critical clock infrastructure - **No API modifications**: Compatible with all kernel versions that support Rockchip clocks - **No dependencies**: Self-contained fix within the clock driver ## Backporting Criteria Evaluation ✅ **Fixes important bug**: System crashes when GPU driver disables clocks ✅ **Small and contained**: One line addition to existing array ✅ **Minimal regression risk**: Only prevents clock from being disabled, no new functionality ✅ **Clear side effects**: Explicitly intended to keep DDR PHY always enabled ✅ **Critical subsystem**: Memory controller availability is fundamental to system operation ## Similar Commit Pattern Analysis Looking at the provided similar commits, this follows the **exact same pattern** as Similar Commit #3 (Status: YES) which fixed "unrecoverable freezes and rcu_sched stall warnings" - both address critical system stability issues through clock configuration fixes. Unlike the other commits marked "NO" which were feature additions or exports, this is a **pure bugfix** addressing a **hardware design limitation** that causes system crashes. ## Conclusion This commit prevents **complete system failure** through a **trivial, safe change** that has **zero risk of regression**. The fix addresses a fundamental hardware limitation in the RK3036 where shared PLLs can cause memory controller clock starvation. This is exactly the type of critical stability fix that stable trees are designed to include.
drivers/clk/rockchip/clk-rk3036.c | 1 + 1 file changed, 1 insertion(+)
diff --git a/drivers/clk/rockchip/clk-rk3036.c b/drivers/clk/rockchip/clk-rk3036.c index 6a46f85ad8372..4a8c72d995735 100644 --- a/drivers/clk/rockchip/clk-rk3036.c +++ b/drivers/clk/rockchip/clk-rk3036.c @@ -429,6 +429,7 @@ static const char *const rk3036_critical_clocks[] __initconst = { "hclk_peri", "pclk_peri", "pclk_ddrupctl", + "ddrphy", };
static void __init rk3036_clk_init(struct device_node *np)