[PATCH] clk: qcom: camcc-sdm845/670: Raise CSIPHY timer clock limit

[PATCH] clk: qcom: camcc-sdm845/670: Raise CSIPHY timer clock limit

[David Heidelberg via B4 Relay]

From: David Heidelberg <david@ixit.cz>

The sdm845 CSIPHY timer clock only listed up to 269.33 MHz, capping the
supported CSI link frequency at roughly 1.07 GHz
(CSIPHY timer = link_freq / 4). The Samsung S5K2X7SP camera runs at a
1.15 GHz link frequency, so camss rejected powering up the
pipeline with 'Pixel clock is too high for CSIPHY'.

Add a 288 MHz entry to the shared camcc CSIPHY timer frequency table
(PLL1 VCO 1152 MHz, well within range) and add a 400 MHz entry to the
sdm845 CSIPHY timer clock_rate tables. The camss min_rate check now
passes and the timer clock rounds to 288 MHz, matching the ~287.5 MHz
required by the 1.15 GHz link.

Assisted-by: tencent:hy3
Signed-off-by: David Heidelberg <david@ixit.cz>
---
Tested on SHIFT 6MQ with next-20260820.
---
 drivers/clk/qcom/camcc-sdm845.c           |  1 +
 drivers/media/platform/qcom/camss/camss.c | 14 +++++++-------
 2 files changed, 8 insertions(+), 7 deletions(-)

diff --git a/drivers/clk/qcom/camcc-sdm845.c b/drivers/clk/qcom/camcc-sdm845.c
index 534dc56fc13ca..77bb783b4ef0a 100644
--- a/drivers/clk/qcom/camcc-sdm845.c
+++ b/drivers/clk/qcom/camcc-sdm845.c
@@ -250,16 +250,17 @@ static struct clk_rcg2 cam_cc_cphy_rx_clk_src = {
 		.ops = &clk_rcg2_ops,
 	},
 };
 
 static const struct freq_tbl ftbl_cam_cc_csi0phytimer_clk_src[] = {
 	F(19200000, P_BI_TCXO, 1, 0, 0),
 	F(240000000, P_CAM_CC_PLL2_OUT_EVEN, 2, 0, 0),
 	F(269333333, P_CAM_CC_PLL1_OUT_EVEN, 3, 0, 0),
+	F(288000000, P_CAM_CC_PLL1_OUT_EVEN, 2, 0, 0),
 	{ }
 };
 
 static struct clk_rcg2 cam_cc_csi0phytimer_clk_src = {
 	.cmd_rcgr = 0x5004,
 	.mnd_width = 0,
 	.hid_width = 5,
 	.parent_map = cam_cc_parent_map_0,
diff --git a/drivers/media/platform/qcom/camss/camss.c b/drivers/media/platform/qcom/camss/camss.c
index 2123f6388e3d7..e1bf828cf7af2 100644
--- a/drivers/media/platform/qcom/camss/camss.c
+++ b/drivers/media/platform/qcom/camss/camss.c
@@ -1070,17 +1070,17 @@ static const struct camss_subdev_resources csiphy_res_670[] = {
 			{ .supply = "vdda-phy", .init_load_uA = 42800 },
 			{ .supply = "vdda-pll", .init_load_uA = 13900 }
 		},
 		.clock = { "soc_ahb", "cpas_ahb",
 			   "csiphy0", "csiphy0_timer" },
 		.clock_rate = { { 0 },
 				{ 0 },
 				{ 0 },
-				{ 19200000, 240000000, 269333333 } },
+				{ 19200000, 240000000, 269333333, 400000000 } },
 		.reg = { "csiphy0" },
 		.interrupt = { "csiphy0" },
 		.csiphy = {
 			.id = 0,
 			.hw_ops = &csiphy_ops_3ph_1_0,
 			.formats = &csiphy_formats_sdm845
 		}
 	},
@@ -1091,17 +1091,17 @@ static const struct camss_subdev_resources csiphy_res_670[] = {
 			{ .supply = "vdda-phy", .init_load_uA = 42800 },
 			{ .supply = "vdda-pll", .init_load_uA = 13900 }
 		},
 		.clock = { "soc_ahb", "cpas_ahb",
 			   "csiphy1", "csiphy1_timer" },
 		.clock_rate = { { 0 },
 				{ 0 },
 				{ 0 },
-				{ 19200000, 240000000, 269333333 } },
+				{ 19200000, 240000000, 269333333, 400000000 } },
 		.reg = { "csiphy1" },
 		.interrupt = { "csiphy1" },
 		.csiphy = {
 			.id = 1,
 			.hw_ops = &csiphy_ops_3ph_1_0,
 			.formats = &csiphy_formats_sdm845
 		}
 	},
@@ -1112,17 +1112,17 @@ static const struct camss_subdev_resources csiphy_res_670[] = {
 			{ .supply = "vdda-phy", .init_load_uA = 42800 },
 			{ .supply = "vdda-pll", .init_load_uA = 13900 }
 		},
 		.clock = { "soc_ahb", "cpas_ahb",
 			   "csiphy2", "csiphy2_timer" },
 		.clock_rate = { { 0 },
 				{ 0 },
 				{ 0 },
-				{ 19200000, 240000000, 269333333 } },
+				{ 19200000, 240000000, 269333333, 400000000 } },
 		.reg = { "csiphy2" },
 		.interrupt = { "csiphy2" },
 		.csiphy = {
 			.id = 2,
 			.hw_ops = &csiphy_ops_3ph_1_0,
 			.formats = &csiphy_formats_sdm845
 		}
 	}
@@ -1263,17 +1263,17 @@ static const struct camss_subdev_resources csiphy_res_845[] = {
 				"csiphy0_timer_src", "csiphy0_timer" },
 		.clock_rate = { { 0 },
 				{ 0 },
 				{ 0 },
 				{ 0 },
 				{ 0 },
 				{ 0 },
 				{ 0 },
-				{ 19200000, 240000000, 269333333 } },
+				{ 19200000, 240000000, 269333333, 400000000 } },
 		.reg = { "csiphy0" },
 		.interrupt = { "csiphy0" },
 		.csiphy = {
 			.id = 0,
 			.hw_ops = &csiphy_ops_3ph_1_0,
 			.formats = &csiphy_formats_sdm845
 		}
 	},
@@ -1286,17 +1286,17 @@ static const struct camss_subdev_resources csiphy_res_845[] = {
 				"csiphy1_timer_src", "csiphy1_timer" },
 		.clock_rate = { { 0 },
 				{ 0 },
 				{ 0 },
 				{ 0 },
 				{ 0 },
 				{ 0 },
 				{ 0 },
-				{ 19200000, 240000000, 269333333 } },
+				{ 19200000, 240000000, 269333333, 400000000 } },
 		.reg = { "csiphy1" },
 		.interrupt = { "csiphy1" },
 		.csiphy = {
 			.id = 1,
 			.hw_ops = &csiphy_ops_3ph_1_0,
 			.formats = &csiphy_formats_sdm845
 		}
 	},
@@ -1309,17 +1309,17 @@ static const struct camss_subdev_resources csiphy_res_845[] = {
 				"csiphy2_timer_src", "csiphy2_timer" },
 		.clock_rate = { { 0 },
 				{ 0 },
 				{ 0 },
 				{ 0 },
 				{ 0 },
 				{ 0 },
 				{ 0 },
-				{ 19200000, 240000000, 269333333 } },
+				{ 19200000, 240000000, 269333333, 400000000 } },
 		.reg = { "csiphy2" },
 		.interrupt = { "csiphy2" },
 		.csiphy = {
 			.id = 2,
 			.hw_ops = &csiphy_ops_3ph_1_0,
 			.formats = &csiphy_formats_sdm845
 		}
 	},
@@ -1332,17 +1332,17 @@ static const struct camss_subdev_resources csiphy_res_845[] = {
 				"csiphy3_timer_src", "csiphy3_timer" },
 		.clock_rate = { { 0 },
 				{ 0 },
 				{ 0 },
 				{ 0 },
 				{ 0 },
 				{ 0 },
 				{ 0 },
-				{ 19200000, 240000000, 269333333 } },
+				{ 19200000, 240000000, 269333333, 400000000 } },
 		.reg = { "csiphy3" },
 		.interrupt = { "csiphy3" },
 		.csiphy = {
 			.id = 3,
 			.hw_ops = &csiphy_ops_3ph_1_0,
 			.formats = &csiphy_formats_sdm845
 		}
 	}

---
base-commit: 7079a12d7506b07fb53b54a664bfad5fa9b16d70
change-id: 20260822-csiphy-sdm845-limits-b1e3dbaf5d38

Best regards,
--  
David Heidelberg <david@ixit.cz>

Re: [PATCH] clk: qcom: camcc-sdm845/670: Raise CSIPHY timer clock limit

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] The newly added 288 MHz CSIPHY timer clock entry erroneously uses a fixed 808 MHz shared PLL with a divider of 2, configuring the hardware for 404 MHz while falsely tracking it as 288 MHz, or otherwise forcing an invalid shared PLL rate.
- [High] Adding a dummy 400 MHz entry to the camss clock_rate tables bypasses the link frequency safety margin validation, allowing unsupported frequencies to be silently clamped.
--

--- Patch [1]: [PATCH] clk: qcom: camcc-sdm845/670: Raise CSIPHY timer clock limit ---
commit 376f8b331f3abeb701471cc1ebbcaaf5bbe8d122
Author: David Heidelberg <david@ixit.cz>

clk: qcom: camcc-sdm845/670: Raise CSIPHY timer clock limit

This commit adds a 288 MHz entry to the shared camcc CSIPHY timer frequency
table and adds a 400 MHz entry to the sdm845 and sdm670 CSIPHY timer
clock_rate tables. This aims to allow the Samsung S5K2X7SP camera to run at a
1.15 GHz link frequency.

> diff --git a/drivers/clk/qcom/camcc-sdm845.c b/drivers/clk/qcom/camcc-sdm845.c
> index 534dc56fc13ca..77bb783b4ef0a 100644
> --- a/drivers/clk/qcom/camcc-sdm845.c
> +++ b/drivers/clk/qcom/camcc-sdm845.c
> @@ -255,6 +255,7 @@ static const struct freq_tbl ftbl_cam_cc_csi0phytimer_clk_src[] = {
>  	F(19200000, P_BI_TCXO, 1, 0, 0),
>  	F(240000000, P_CAM_CC_PLL2_OUT_EVEN, 2, 0, 0),
>  	F(269333333, P_CAM_CC_PLL1_OUT_EVEN, 3, 0, 0),
> +	F(288000000, P_CAM_CC_PLL1_OUT_EVEN, 2, 0, 0),

[Severity: High]
Does this configuration force an invalid rate on the shared PLL1, or
mathematically result in an incorrect output frequency?

When requesting 288 MHz in ftbl_cam_cc_csi0phytimer_clk_src, this table uses
P_CAM_CC_PLL1_OUT_EVEN with a divider of 2. If the parent PLL1 is statically
probed at 808 MHz, a divider of 2 produces 404 MHz instead of 288 MHz, which
could break CSI protocol timing.

Alternatively, since the clock rate request propagates to the parent PLL, does
this cause the framework to request 576 MHz (288 MHz * 2) from PLL1?

Reconfiguring a shared PLL would disrupt other consumers like BPS, IFE, and
IPE that rely on the original parent rate.

>  	{ }
>  };
>  
> diff --git a/drivers/media/platform/qcom/camss/camss.c b/drivers/media/platform/qcom/camss/camss.c
> index 2123f6388e3d7..e1bf828cf7af2 100644
> --- a/drivers/media/platform/qcom/camss/camss.c
> +++ b/drivers/media/platform/qcom/camss/camss.c
> @@ -1075,7 +1075,7 @@ static const struct camss_subdev_resources csiphy_res_670[] = {
>  		.clock_rate = { { 0 },
>  				{ 0 },
>  				{ 0 },
> -				{ 19200000, 240000000, 269333333 } },
> +				{ 19200000, 240000000, 269333333, 400000000 } },

[Severity: High]
Could the addition of this 400 MHz entry bypass the link frequency safety
margin validation in the camss driver?

By adding a dummy 400 MHz entry here in csiphy_res_670 (and similarly in
csiphy_res_845) when the clock controller only provides up to 288 MHz, it
appears any sensor configuration requiring between 288 MHz and 380 MHz will
erroneously pass the margin check.

When the hardware then requests 400 MHz, will clk_round_rate() silently
clamp it down to 288 MHz?

This might cause new sensor configurations requiring a frequency in this gap
to fail at runtime with obscure hardware pipeline failures instead of being
cleanly rejected.

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260822-csiphy-sdm845-limits-v1-1-d360bf7cd38f@ixit.cz?part=1

Re: [PATCH] clk: qcom: camcc-sdm845/670: Raise CSIPHY timer clock limit

[Konrad Dybcio]

On 8/22/26 4:25 AM, David Heidelberg via B4 Relay wrote:
> From: David Heidelberg <david@ixit.cz>
> 
> The sdm845 CSIPHY timer clock only listed up to 269.33 MHz, capping the
> supported CSI link frequency at roughly 1.07 GHz
> (CSIPHY timer = link_freq / 4). The Samsung S5K2X7SP camera runs at a
> 1.15 GHz link frequency, so camss rejected powering up the
> pipeline with 'Pixel clock is too high for CSIPHY'.
> 
> Add a 288 MHz entry to the shared camcc CSIPHY timer frequency table
> (PLL1 VCO 1152 MHz, well within range) and add a 400 MHz entry to the
> sdm845 CSIPHY timer clock_rate tables. The camss min_rate check now
> passes and the timer clock rounds to 288 MHz, matching the ~287.5 MHz
> required by the 1.15 GHz link.
> 
> Assisted-by: tencent:hy3
> Signed-off-by: David Heidelberg <david@ixit.cz>
> ---
> Tested on SHIFT 6MQ with next-20260820.

Is that what happens on downstream for this device too? Is there a
chance the sensor link frequency can be lowered?

Generally the latest clock plan for SDM845 says that 269.333 MHz is
a maximum, with the RPMHPD running at TURBO.. I would assume that
while the PLL rate stays the same, the downstream branches and RCGs
may not have been validated to properly function at these freqs

Konrad