[PATCH v2] clk: qcom: mmcc-sdm660: enable the parents of the pixel clock sources

[PATCH v2] clk: qcom: mmcc-sdm660: enable the parents of the pixel clock sources

[Fabricio Akio via B4 Relay]

From: Fabricio Akio <fabricioakio@gmail.com>

pclk0_clk_src and pclk1_clk_src are fed by the DSI PHY PLLs, which
dsi_pll_14nm_vco_set_rate() resets and only clk_prepare() restarts. The
DSI host sets the link rates before it prepares the PLL, so the RCG is
updated against a stopped source, and if it is enabled at that point
the update times out:

  pclk0_clk_src: rcg didn't update its configuration.

Seen on a board whose simple-framebuffer node lists the pixel clock:
the RCG then reads enabled at msm's first modeset.

Set CLK_OPS_PARENT_ENABLE on both so the core prepares the PLL around
the rate change, as dispcc-sm8250 does for its pixel clock sources since
commit acf7a91d0b0e ("clk: qcom: dispcc-sm8250: Enable parents for pixel
clocks").

Fixes: 5db3ae8b33de ("clk: qcom: Add SDM660 Multimedia Clock Controller (MMCC) driver")
Signed-off-by: Fabricio Akio <fabricioakio@gmail.com>
---
Tested on the Motorola Moto X4 (SDM630, payton) with the sdm660-mainline
7.2.y tree, sdm660_defconfig, DRM_MSM=m: without the flag the
pclk0_clk_src warning fires in most boots, with it never. At the stall
the RCG reads root-on and the PLL stopped. pclk1_clk_src is not
exercised here, nothing on this board drives DSI1. With the display
built in, clk_disable_unused() also prepares the PLL under this flag,
and some boots then log "DSI PLL lock failed".
---
Changes in v2:
- Set the flag on pclk1_clk_src as well, as Dmitry asked. v1 left it
  out because this board has nothing on DSI1 to test it with.
- Link to v1: https://patch.msgid.link/20261002-sdm660-pclk0-parent-enable-v1-1-d6ff889144e4@gmail.com
---
 drivers/clk/qcom/mmcc-sdm660.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/clk/qcom/mmcc-sdm660.c b/drivers/clk/qcom/mmcc-sdm660.c
index 9f8b8e29fa0f..827741229dd7 100644
--- a/drivers/clk/qcom/mmcc-sdm660.c
+++ b/drivers/clk/qcom/mmcc-sdm660.c
@@ -984,7 +984,8 @@ static struct clk_rcg2 pclk0_clk_src = {
 		.parent_data = mmcc_xo_dsi0pll_dsi1pll,
 		.num_parents = ARRAY_SIZE(mmcc_xo_dsi0pll_dsi1pll),
 		.ops = &clk_pixel_ops,
-		.flags = CLK_SET_RATE_PARENT | CLK_GET_RATE_NOCACHE,
+		.flags = CLK_SET_RATE_PARENT | CLK_GET_RATE_NOCACHE |
+			 CLK_OPS_PARENT_ENABLE,
 	},
 };
 
@@ -998,7 +999,8 @@ static struct clk_rcg2 pclk1_clk_src = {
 		.parent_data = mmcc_xo_dsi0pll_dsi1pll,
 		.num_parents = ARRAY_SIZE(mmcc_xo_dsi0pll_dsi1pll),
 		.ops = &clk_pixel_ops,
-		.flags = CLK_SET_RATE_PARENT | CLK_GET_RATE_NOCACHE,
+		.flags = CLK_SET_RATE_PARENT | CLK_GET_RATE_NOCACHE |
+			 CLK_OPS_PARENT_ENABLE,
 	},
 };
 

---
base-commit: 9f24d789f03b22941b905ded43cb5ff8eea9ce62
change-id: 20261002-sdm660-pclk0-parent-enable-8123c9ac71d8

Best regards,
--  
Fabricio Akio <fabricioakio@gmail.com>

Re: [PATCH v2] clk: qcom: mmcc-sdm660: enable the parents of the pixel clock sources

[Dmitry Baryshkov]

On Fri, Oct 02, 2026 at 01:46:24PM -0300, Fabricio Akio via B4 Relay wrote:
> From: Fabricio Akio <fabricioakio@gmail.com>
> 
> pclk0_clk_src and pclk1_clk_src are fed by the DSI PHY PLLs, which
> dsi_pll_14nm_vco_set_rate() resets and only clk_prepare() restarts. The
> DSI host sets the link rates before it prepares the PLL, so the RCG is
> updated against a stopped source, and if it is enabled at that point
> the update times out:
> 
>   pclk0_clk_src: rcg didn't update its configuration.
> 
> Seen on a board whose simple-framebuffer node lists the pixel clock:
> the RCG then reads enabled at msm's first modeset.
> 
> Set CLK_OPS_PARENT_ENABLE on both so the core prepares the PLL around
> the rate change, as dispcc-sm8250 does for its pixel clock sources since
> commit acf7a91d0b0e ("clk: qcom: dispcc-sm8250: Enable parents for pixel
> clocks").
> 
> Fixes: 5db3ae8b33de ("clk: qcom: Add SDM660 Multimedia Clock Controller (MMCC) driver")
> Signed-off-by: Fabricio Akio <fabricioakio@gmail.com>

Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>


-- 
With best wishes
Dmitry

Re: [PATCH v2] clk: qcom: mmcc-sdm660: enable the parents of the pixel clock sources

[Taniya Das]

On 10/2/2026 10:16 PM, Fabricio Akio via B4 Relay wrote:
> From: Fabricio Akio <fabricioakio@gmail.com>
> 
> pclk0_clk_src and pclk1_clk_src are fed by the DSI PHY PLLs, which
> dsi_pll_14nm_vco_set_rate() resets and only clk_prepare() restarts. The
> DSI host sets the link rates before it prepares the PLL, so the RCG is
> updated against a stopped source, and if it is enabled at that point
> the update times out:
> 
>   pclk0_clk_src: rcg didn't update its configuration.
> 
> Seen on a board whose simple-framebuffer node lists the pixel clock:
> the RCG then reads enabled at msm's first modeset.
> 
> Set CLK_OPS_PARENT_ENABLE on both so the core prepares the PLL around
> the rate change, as dispcc-sm8250 does for its pixel clock sources since
> commit acf7a91d0b0e ("clk: qcom: dispcc-sm8250: Enable parents for pixel
> clocks").
> 
> Fixes: 5db3ae8b33de ("clk: qcom: Add SDM660 Multimedia Clock Controller (MMCC) driver")
> Signed-off-by: Fabricio Akio <fabricioakio@gmail.com>

Reviewed-by: Taniya Das <taniya.das@oss.qualcomm.com>

-- 
Thanks,
Taniya Das

Re: [PATCH v2] clk: qcom: mmcc-sdm660: enable the parents of the pixel clock sources

[Alexey Minnekhanov]

On 02.10.2026 19:46, Fabricio Akio via B4 Relay wrote:
> From: Fabricio Akio <fabricioakio@gmail.com>
> 
> pclk0_clk_src and pclk1_clk_src are fed by the DSI PHY PLLs, which
> dsi_pll_14nm_vco_set_rate() resets and only clk_prepare() restarts. The
> DSI host sets the link rates before it prepares the PLL, so the RCG is
> updated against a stopped source, and if it is enabled at that point
> the update times out:
> 
>    pclk0_clk_src: rcg didn't update its configuration.
> 
> Seen on a board whose simple-framebuffer node lists the pixel clock:
> the RCG then reads enabled at msm's first modeset.
> 
> Set CLK_OPS_PARENT_ENABLE on both so the core prepares the PLL around
> the rate change, as dispcc-sm8250 does for its pixel clock sources since
> commit acf7a91d0b0e ("clk: qcom: dispcc-sm8250: Enable parents for pixel
> clocks").
> 
> Fixes: 5db3ae8b33de ("clk: qcom: Add SDM660 Multimedia Clock Controller (MMCC) driver")
> Signed-off-by: Fabricio Akio <fabricioakio@gmail.com>
> ---
> Changes in v2:
> - Set the flag on pclk1_clk_src as well, as Dmitry asked. v1 left it
>    out because this board has nothing on DSI1 to test it with.
> - Link to v1: https://patch.msgid.link/20261002-sdm660-pclk0-parent-enable-v1-1-d6ff889144e4@gmail.com
> ---
>   drivers/clk/qcom/mmcc-sdm660.c | 6 ++++--
>   1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/clk/qcom/mmcc-sdm660.c b/drivers/clk/qcom/mmcc-sdm660.c
> index 9f8b8e29fa0f..827741229dd7 100644
> --- a/drivers/clk/qcom/mmcc-sdm660.c
> +++ b/drivers/clk/qcom/mmcc-sdm660.c
> @@ -984,7 +984,8 @@ static struct clk_rcg2 pclk0_clk_src = {
>   		.parent_data = mmcc_xo_dsi0pll_dsi1pll,
>   		.num_parents = ARRAY_SIZE(mmcc_xo_dsi0pll_dsi1pll),
>   		.ops = &clk_pixel_ops,
> -		.flags = CLK_SET_RATE_PARENT | CLK_GET_RATE_NOCACHE,
> +		.flags = CLK_SET_RATE_PARENT | CLK_GET_RATE_NOCACHE |
> +			 CLK_OPS_PARENT_ENABLE,
>   	},
>   };
>   
> @@ -998,7 +999,8 @@ static struct clk_rcg2 pclk1_clk_src = {
>   		.parent_data = mmcc_xo_dsi0pll_dsi1pll,
>   		.num_parents = ARRAY_SIZE(mmcc_xo_dsi0pll_dsi1pll),
>   		.ops = &clk_pixel_ops,
> -		.flags = CLK_SET_RATE_PARENT | CLK_GET_RATE_NOCACHE,
> +		.flags = CLK_SET_RATE_PARENT | CLK_GET_RATE_NOCACHE |
> +			 CLK_OPS_PARENT_ENABLE,
>   	},
>   };
>   
> 
> ---
> 
> Best regards,
> 
> Fabricio Akio <fabricioakio@gmail.com>

I've verified that it at least doesn't break booting on 3 different
devices based on 3 different related SoCs:

  * sdm630-sony-pioneer (Xperia XA2)
  * sdm636-xiaomi-whyred (Redmi Note 5/Pro)
  * sdm660-xiaomi-lavender (Redmi Note 7)

I've also never seen before the warning about pclk0_clk_src not
updating its configuration. MMCC seemed to always work fine, but
given some recent fixes to clock drivers I'd be not surprised if
something was missed in initial porting..

Tested-by: Alexey Minnekhanov <alexeymin@minlexx.ru>

--
Regards,
Alexey Minnekhanov