drivers/clk/qcom/clk-rcg2.c | 2 ++ 1 file changed, 2 insertions(+)
Recently, when testing 10-bit dsi C-PHY panel, clks are different
from the usual. (dsi0_phy_pll_out_dsiclk's parent is dsi0_pll_bit_clk
now (dsiclk_sel = 0)) And we failed to set dsiclk's children.
dsi_link_clk_set_rate_6g: Set clk rates: pclk=172992000, byteclk=108120000
byteclk was set first to 108120000, so the vco rate was set to
108120000 * 7 * 1 * 1 = 756840000. When we was trying to set
172992000 on mdss_pixel_clk_src later.
Since there was no matched ratio, we failed to set it. And dsiclk
divider ratio was set to 15:1 (wrong cached register value 0xf and
didn't update), we finally got 50455997, apparently wrong.
dsi0vco_clk 1 1 0 756839941
dsi0_pll_out_div_clk 1 1 0 756839941
dsi0_pll_post_out_div_clk 0 0 0 216239983
dsi0_pll_bit_clk 2 2 0 756839941
dsi0_phy_pll_out_dsiclk 2 2 0 50455997
disp_cc_mdss_pclk1_clk_src 1 1 0 50455997
dsi0_pll_by_2_bit_clk 0 0 0 378419970
dsi0_phy_pll_out_byteclk 2 2 0 108119991
disp_cc_mdss_byte1_clk_src 2 2 0 108119991
Downstream clk_summary shows the mdss_pixel_clk_src support the
ratio(35:16)
dsi0_phy_pll_out_dsiclk 2 2 0 378420000
disp_cc_mdss_pclk1_clk_src 1 1 0 172992000
dsi0_phy_pll_out_byteclk 2 2 0 108120000
disp_cc_mdss_byte1_clk_src 2 2 0 108120000
After checking downstream source, 15:4 also seems to be supported,
add them two.
Signed-off-by: Pengyu Luo <mitltlatltl@gmail.com>
---
drivers/clk/qcom/clk-rcg2.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/clk/qcom/clk-rcg2.c b/drivers/clk/qcom/clk-rcg2.c
index fc696b66cc..6064a0e17d 100644
--- a/drivers/clk/qcom/clk-rcg2.c
+++ b/drivers/clk/qcom/clk-rcg2.c
@@ -1117,6 +1117,8 @@ static const struct frac_entry frac_table_pixel[] = {
{ 4, 9 },
{ 1, 1 },
{ 2, 3 },
+ { 16, 35},
+ { 4, 15},
{ }
};
--
2.53.0
On Sat, 21 Mar 2026 17:50:28 +0800, Pengyu Luo wrote:
> Recently, when testing 10-bit dsi C-PHY panel, clks are different
> from the usual. (dsi0_phy_pll_out_dsiclk's parent is dsi0_pll_bit_clk
> now (dsiclk_sel = 0)) And we failed to set dsiclk's children.
>
> dsi_link_clk_set_rate_6g: Set clk rates: pclk=172992000, byteclk=108120000
>
> byteclk was set first to 108120000, so the vco rate was set to
> 108120000 * 7 * 1 * 1 = 756840000. When we was trying to set
> 172992000 on mdss_pixel_clk_src later.
>
> [...]
Applied, thanks!
[1/1] clk: qcom: rcg2: expand frac table for mdss_pixel_clk_src
commit: 0f5c8f03d990f9be9908a08a701c324e113554d2
Best regards,
--
Bjorn Andersson <andersson@kernel.org>
On 3/21/26 10:50 AM, Pengyu Luo wrote: > Recently, when testing 10-bit dsi C-PHY panel, clks are different > from the usual. (dsi0_phy_pll_out_dsiclk's parent is dsi0_pll_bit_clk > now (dsiclk_sel = 0)) And we failed to set dsiclk's children. > > dsi_link_clk_set_rate_6g: Set clk rates: pclk=172992000, byteclk=108120000 > > byteclk was set first to 108120000, so the vco rate was set to > 108120000 * 7 * 1 * 1 = 756840000. When we was trying to set > 172992000 on mdss_pixel_clk_src later. > > Since there was no matched ratio, we failed to set it. And dsiclk > divider ratio was set to 15:1 (wrong cached register value 0xf and > didn't update), we finally got 50455997, apparently wrong. > > dsi0vco_clk 1 1 0 756839941 > dsi0_pll_out_div_clk 1 1 0 756839941 > dsi0_pll_post_out_div_clk 0 0 0 216239983 > dsi0_pll_bit_clk 2 2 0 756839941 > dsi0_phy_pll_out_dsiclk 2 2 0 50455997 > disp_cc_mdss_pclk1_clk_src 1 1 0 50455997 > dsi0_pll_by_2_bit_clk 0 0 0 378419970 > dsi0_phy_pll_out_byteclk 2 2 0 108119991 > disp_cc_mdss_byte1_clk_src 2 2 0 108119991 > > Downstream clk_summary shows the mdss_pixel_clk_src support the > ratio(35:16) > > dsi0_phy_pll_out_dsiclk 2 2 0 378420000 > disp_cc_mdss_pclk1_clk_src 1 1 0 172992000 > dsi0_phy_pll_out_byteclk 2 2 0 108120000 > disp_cc_mdss_byte1_clk_src 2 2 0 108120000 > > After checking downstream source, 15:4 also seems to be supported, > add them two. I don't see that, not even in the newest releases.. Is there even a reason we have to list these divider pairs in the first place? Konrad
On Mon, Mar 23, 2026 at 01:54:29PM +0100, Konrad Dybcio wrote: > On 3/21/26 10:50 AM, Pengyu Luo wrote: > > Recently, when testing 10-bit dsi C-PHY panel, clks are different > > from the usual. (dsi0_phy_pll_out_dsiclk's parent is dsi0_pll_bit_clk > > now (dsiclk_sel = 0)) And we failed to set dsiclk's children. > > > > dsi_link_clk_set_rate_6g: Set clk rates: pclk=172992000, byteclk=108120000 > > > > byteclk was set first to 108120000, so the vco rate was set to > > 108120000 * 7 * 1 * 1 = 756840000. When we was trying to set > > 172992000 on mdss_pixel_clk_src later. > > > > Since there was no matched ratio, we failed to set it. And dsiclk > > divider ratio was set to 15:1 (wrong cached register value 0xf and > > didn't update), we finally got 50455997, apparently wrong. > > > > dsi0vco_clk 1 1 0 756839941 > > dsi0_pll_out_div_clk 1 1 0 756839941 > > dsi0_pll_post_out_div_clk 0 0 0 216239983 > > dsi0_pll_bit_clk 2 2 0 756839941 > > dsi0_phy_pll_out_dsiclk 2 2 0 50455997 > > disp_cc_mdss_pclk1_clk_src 1 1 0 50455997 > > dsi0_pll_by_2_bit_clk 0 0 0 378419970 > > dsi0_phy_pll_out_byteclk 2 2 0 108119991 > > disp_cc_mdss_byte1_clk_src 2 2 0 108119991 > > > > Downstream clk_summary shows the mdss_pixel_clk_src support the > > ratio(35:16) > > > > dsi0_phy_pll_out_dsiclk 2 2 0 378420000 > > disp_cc_mdss_pclk1_clk_src 1 1 0 172992000 > > dsi0_phy_pll_out_byteclk 2 2 0 108120000 > > disp_cc_mdss_byte1_clk_src 2 2 0 108120000 > > > > After checking downstream source, 15:4 also seems to be supported, > > add them two. > > I don't see that, not even in the newest releases.. Is there even a reason > we have to list these divider pairs in the first place? https://git.codelinaro.org/clo/la/kernel/qcom/-/commit/f7aec4359448d25c8a8d21ad8e8733d61f6b69ab We need those dividers to correctly program pclk RCG2 clocks. -- With best wishes Dmitry
On 3/23/26 8:23 PM, Dmitry Baryshkov wrote: > On Mon, Mar 23, 2026 at 01:54:29PM +0100, Konrad Dybcio wrote: >> On 3/21/26 10:50 AM, Pengyu Luo wrote: >>> Recently, when testing 10-bit dsi C-PHY panel, clks are different >>> from the usual. (dsi0_phy_pll_out_dsiclk's parent is dsi0_pll_bit_clk >>> now (dsiclk_sel = 0)) And we failed to set dsiclk's children. >>> >>> dsi_link_clk_set_rate_6g: Set clk rates: pclk=172992000, byteclk=108120000 >>> >>> byteclk was set first to 108120000, so the vco rate was set to >>> 108120000 * 7 * 1 * 1 = 756840000. When we was trying to set >>> 172992000 on mdss_pixel_clk_src later. >>> >>> Since there was no matched ratio, we failed to set it. And dsiclk >>> divider ratio was set to 15:1 (wrong cached register value 0xf and >>> didn't update), we finally got 50455997, apparently wrong. >>> >>> dsi0vco_clk 1 1 0 756839941 >>> dsi0_pll_out_div_clk 1 1 0 756839941 >>> dsi0_pll_post_out_div_clk 0 0 0 216239983 >>> dsi0_pll_bit_clk 2 2 0 756839941 >>> dsi0_phy_pll_out_dsiclk 2 2 0 50455997 >>> disp_cc_mdss_pclk1_clk_src 1 1 0 50455997 >>> dsi0_pll_by_2_bit_clk 0 0 0 378419970 >>> dsi0_phy_pll_out_byteclk 2 2 0 108119991 >>> disp_cc_mdss_byte1_clk_src 2 2 0 108119991 >>> >>> Downstream clk_summary shows the mdss_pixel_clk_src support the >>> ratio(35:16) >>> >>> dsi0_phy_pll_out_dsiclk 2 2 0 378420000 >>> disp_cc_mdss_pclk1_clk_src 1 1 0 172992000 >>> dsi0_phy_pll_out_byteclk 2 2 0 108120000 >>> disp_cc_mdss_byte1_clk_src 2 2 0 108120000 >>> >>> After checking downstream source, 15:4 also seems to be supported, >>> add them two. >> >> I don't see that, not even in the newest releases.. Is there even a reason >> we have to list these divider pairs in the first place? > > https://git.codelinaro.org/clo/la/kernel/qcom/-/commit/f7aec4359448d25c8a8d21ad8e8733d61f6b69ab Ahh branching.. > We need those dividers to correctly program pclk RCG2 clocks. I would assume that's the case, but perhaps the real answer is "because we don't want to try all possible combinations" Konrad
On Tue, Mar 24, 2026 at 5:22 PM Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> wrote: > > On 3/23/26 8:23 PM, Dmitry Baryshkov wrote: > > On Mon, Mar 23, 2026 at 01:54:29PM +0100, Konrad Dybcio wrote: > >> On 3/21/26 10:50 AM, Pengyu Luo wrote: > >>> Recently, when testing 10-bit dsi C-PHY panel, clks are different > >>> from the usual. (dsi0_phy_pll_out_dsiclk's parent is dsi0_pll_bit_clk > >>> now (dsiclk_sel = 0)) And we failed to set dsiclk's children. > >>> > >>> dsi_link_clk_set_rate_6g: Set clk rates: pclk=172992000, byteclk=108120000 > >>> > >>> byteclk was set first to 108120000, so the vco rate was set to > >>> 108120000 * 7 * 1 * 1 = 756840000. When we was trying to set > >>> 172992000 on mdss_pixel_clk_src later. > >>> > >>> Since there was no matched ratio, we failed to set it. And dsiclk > >>> divider ratio was set to 15:1 (wrong cached register value 0xf and > >>> didn't update), we finally got 50455997, apparently wrong. > >>> > >>> dsi0vco_clk 1 1 0 756839941 > >>> dsi0_pll_out_div_clk 1 1 0 756839941 > >>> dsi0_pll_post_out_div_clk 0 0 0 216239983 > >>> dsi0_pll_bit_clk 2 2 0 756839941 > >>> dsi0_phy_pll_out_dsiclk 2 2 0 50455997 > >>> disp_cc_mdss_pclk1_clk_src 1 1 0 50455997 > >>> dsi0_pll_by_2_bit_clk 0 0 0 378419970 > >>> dsi0_phy_pll_out_byteclk 2 2 0 108119991 > >>> disp_cc_mdss_byte1_clk_src 2 2 0 108119991 > >>> > >>> Downstream clk_summary shows the mdss_pixel_clk_src support the > >>> ratio(35:16) > >>> > >>> dsi0_phy_pll_out_dsiclk 2 2 0 378420000 > >>> disp_cc_mdss_pclk1_clk_src 1 1 0 172992000 > >>> dsi0_phy_pll_out_byteclk 2 2 0 108120000 > >>> disp_cc_mdss_byte1_clk_src 2 2 0 108120000 > >>> > >>> After checking downstream source, 15:4 also seems to be supported, > >>> add them two. > >> > >> I don't see that, not even in the newest releases.. Is there even a reason > >> we have to list these divider pairs in the first place? > > > > https://git.codelinaro.org/clo/la/kernel/qcom/-/commit/f7aec4359448d25c8a8d21ad8e8733d61f6b69ab > > Ahh branching.. > > > We need those dividers to correctly program pclk RCG2 clocks. > > I would assume that's the case, but perhaps the real answer is "because we > don't want to try all possible combinations" > So you meant the pixel clk can support any ratio actually, and just common ratio pairs are listed? That is interesting. Best wishes, Pengyu > Konrad
On 3/24/26 1:56 PM, Pengyu Luo wrote: > On Tue, Mar 24, 2026 at 5:22 PM Konrad Dybcio > <konrad.dybcio@oss.qualcomm.com> wrote: >> >> On 3/23/26 8:23 PM, Dmitry Baryshkov wrote: >>> On Mon, Mar 23, 2026 at 01:54:29PM +0100, Konrad Dybcio wrote: >>>> On 3/21/26 10:50 AM, Pengyu Luo wrote: >>>>> Recently, when testing 10-bit dsi C-PHY panel, clks are different >>>>> from the usual. (dsi0_phy_pll_out_dsiclk's parent is dsi0_pll_bit_clk >>>>> now (dsiclk_sel = 0)) And we failed to set dsiclk's children. >>>>> >>>>> dsi_link_clk_set_rate_6g: Set clk rates: pclk=172992000, byteclk=108120000 >>>>> >>>>> byteclk was set first to 108120000, so the vco rate was set to >>>>> 108120000 * 7 * 1 * 1 = 756840000. When we was trying to set >>>>> 172992000 on mdss_pixel_clk_src later. >>>>> >>>>> Since there was no matched ratio, we failed to set it. And dsiclk >>>>> divider ratio was set to 15:1 (wrong cached register value 0xf and >>>>> didn't update), we finally got 50455997, apparently wrong. >>>>> >>>>> dsi0vco_clk 1 1 0 756839941 >>>>> dsi0_pll_out_div_clk 1 1 0 756839941 >>>>> dsi0_pll_post_out_div_clk 0 0 0 216239983 >>>>> dsi0_pll_bit_clk 2 2 0 756839941 >>>>> dsi0_phy_pll_out_dsiclk 2 2 0 50455997 >>>>> disp_cc_mdss_pclk1_clk_src 1 1 0 50455997 >>>>> dsi0_pll_by_2_bit_clk 0 0 0 378419970 >>>>> dsi0_phy_pll_out_byteclk 2 2 0 108119991 >>>>> disp_cc_mdss_byte1_clk_src 2 2 0 108119991 >>>>> >>>>> Downstream clk_summary shows the mdss_pixel_clk_src support the >>>>> ratio(35:16) >>>>> >>>>> dsi0_phy_pll_out_dsiclk 2 2 0 378420000 >>>>> disp_cc_mdss_pclk1_clk_src 1 1 0 172992000 >>>>> dsi0_phy_pll_out_byteclk 2 2 0 108120000 >>>>> disp_cc_mdss_byte1_clk_src 2 2 0 108120000 >>>>> >>>>> After checking downstream source, 15:4 also seems to be supported, >>>>> add them two. >>>> >>>> I don't see that, not even in the newest releases.. Is there even a reason >>>> we have to list these divider pairs in the first place? >>> >>> https://git.codelinaro.org/clo/la/kernel/qcom/-/commit/f7aec4359448d25c8a8d21ad8e8733d61f6b69ab >> >> Ahh branching.. >> >>> We need those dividers to correctly program pclk RCG2 clocks. >> >> I would assume that's the case, but perhaps the real answer is "because we >> don't want to try all possible combinations" >> > > So you meant the pixel clk can support any ratio actually, and just > common ratio pairs are listed? That is interesting. I don't know about pixel specifically, but generally RCG2 clocks can do any rate, only limited by the register width, see: drivers/clk/qcom/clk-rcg2.c : calc_rate() Konrad
On 3/21/2026 3:20 PM, Pengyu Luo wrote:
> Downstream clk_summary shows the mdss_pixel_clk_src support the
> ratio(35:16)
>
> dsi0_phy_pll_out_dsiclk 2 2 0 378420000
> disp_cc_mdss_pclk1_clk_src 1 1 0 172992000
> dsi0_phy_pll_out_byteclk 2 2 0 108120000
> disp_cc_mdss_byte1_clk_src 2 2 0 108120000
>
> After checking downstream source, 15:4 also seems to be supported,
> add them two.
>
> Signed-off-by: Pengyu Luo <mitltlatltl@gmail.com>
> ---
> drivers/clk/qcom/clk-rcg2.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/clk/qcom/clk-rcg2.c b/drivers/clk/qcom/clk-rcg2.c
> index fc696b66cc..6064a0e17d 100644
> --- a/drivers/clk/qcom/clk-rcg2.c
> +++ b/drivers/clk/qcom/clk-rcg2.c
> @@ -1117,6 +1117,8 @@ static const struct frac_entry frac_table_pixel[] = {
> { 4, 9 },
> { 1, 1 },
> { 2, 3 },
> + { 16, 35},
> + { 4, 15},
> { }
> };
>
Reviewed-by: Taniya Das <taniya.das@oss.qualcomm.com>
--
Thanks,
Taniya Das
On 3/21/2026 3:20 PM, Pengyu Luo wrote:
> Downstream clk_summary shows the mdss_pixel_clk_src support the
> ratio(35:16)
>
> dsi0_phy_pll_out_dsiclk 2 2 0 378420000
> disp_cc_mdss_pclk1_clk_src 1 1 0 172992000
> dsi0_phy_pll_out_byteclk 2 2 0 108120000
> disp_cc_mdss_byte1_clk_src 2 2 0 108120000
>
> After checking downstream source, 15:4 also seems to be supported,
> add them two.
>
> Signed-off-by: Pengyu Luo <mitltlatltl@gmail.com>
> ---
> drivers/clk/qcom/clk-rcg2.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/clk/qcom/clk-rcg2.c b/drivers/clk/qcom/clk-rcg2.c
> index fc696b66cc..6064a0e17d 100644
> --- a/drivers/clk/qcom/clk-rcg2.c
> +++ b/drivers/clk/qcom/clk-rcg2.c
> @@ -1117,6 +1117,8 @@ static const struct frac_entry frac_table_pixel[] = {
> { 4, 9 },
> { 1, 1 },
> { 2, 3 },
> + { 16, 35},
> + { 4, 15},
> { }
> };
>
Reviewed-by: Taniya Das <taniya.das@oss.qualcomm.com>
--
Thanks,
Taniya Das
On Sat, Mar 21, 2026 at 05:50:28PM +0800, Pengyu Luo wrote: > Recently, when testing 10-bit dsi C-PHY panel, clks are different > from the usual. (dsi0_phy_pll_out_dsiclk's parent is dsi0_pll_bit_clk > now (dsiclk_sel = 0)) And we failed to set dsiclk's children. > > dsi_link_clk_set_rate_6g: Set clk rates: pclk=172992000, byteclk=108120000 > > byteclk was set first to 108120000, so the vco rate was set to > 108120000 * 7 * 1 * 1 = 756840000. When we was trying to set > 172992000 on mdss_pixel_clk_src later. > > Since there was no matched ratio, we failed to set it. And dsiclk > divider ratio was set to 15:1 (wrong cached register value 0xf and > didn't update), we finally got 50455997, apparently wrong. > > dsi0vco_clk 1 1 0 756839941 > dsi0_pll_out_div_clk 1 1 0 756839941 > dsi0_pll_post_out_div_clk 0 0 0 216239983 > dsi0_pll_bit_clk 2 2 0 756839941 > dsi0_phy_pll_out_dsiclk 2 2 0 50455997 > disp_cc_mdss_pclk1_clk_src 1 1 0 50455997 > dsi0_pll_by_2_bit_clk 0 0 0 378419970 > dsi0_phy_pll_out_byteclk 2 2 0 108119991 > disp_cc_mdss_byte1_clk_src 2 2 0 108119991 > > Downstream clk_summary shows the mdss_pixel_clk_src support the > ratio(35:16) > > dsi0_phy_pll_out_dsiclk 2 2 0 378420000 > disp_cc_mdss_pclk1_clk_src 1 1 0 172992000 > dsi0_phy_pll_out_byteclk 2 2 0 108120000 > disp_cc_mdss_byte1_clk_src 2 2 0 108120000 > > After checking downstream source, 15:4 also seems to be supported, > add them two. > > Signed-off-by: Pengyu Luo <mitltlatltl@gmail.com> > --- > drivers/clk/qcom/clk-rcg2.c | 2 ++ > 1 file changed, 2 insertions(+) > Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> -- With best wishes Dmitry
© 2016 - 2026 Red Hat, Inc.