@@ -1182,14 +1182,21 @@ static int clk_rcg2_dp_set_rate_and_parent(struct clk_hw *hw,
static int clk_rcg2_dp_determine_rate(struct clk_hw *hw,
struct clk_rate_request *req)
{
- struct clk_rate_request parent_req = *req;
- int ret;
+ struct clk_rcg2 *rcg = to_clk_rcg2(hw);
+ unsigned long num, den;
+ u64 tmp;
- ret = __clk_determine_rate(clk_hw_get_parent(hw), &parent_req);
- if (ret)
- return ret;
+ /* Parent rate is a fixed phy link rate */
+ rational_best_approximation(req->best_parent_rate, req->rate,
+ GENMASK(rcg->mnd_width - 1, 0),
+ GENMASK(rcg->mnd_width - 1, 0), &den, &num);
+
+ if (!num || !den)
+ return -EINVAL;
- req->best_parent_rate = parent_req.rate;
+ tmp = req->best_parent_rate * num;
+ do_div(tmp, den);
+ req->rate = tmp;
return 0;
}
@@ -202,7 +202,6 @@ static struct clk_rcg2 disp_cc_mdss_dp_crypto_clk_src = {
.name = "disp_cc_mdss_dp_crypto_clk_src",
.parent_data = disp_cc_parent_data_1,
.num_parents = ARRAY_SIZE(disp_cc_parent_data_1),
- .flags = CLK_SET_RATE_PARENT,
.ops = &clk_byte2_ops,
},
};
@@ -216,7 +215,6 @@ static struct clk_rcg2 disp_cc_mdss_dp_link_clk_src = {
.name = "disp_cc_mdss_dp_link_clk_src",
.parent_data = disp_cc_parent_data_1,
.num_parents = ARRAY_SIZE(disp_cc_parent_data_1),
- .flags = CLK_SET_RATE_PARENT,
.ops = &clk_byte2_ops,
},
};
@@ -230,7 +228,6 @@ static struct clk_rcg2 disp_cc_mdss_dp_pixel_clk_src = {
.name = "disp_cc_mdss_dp_pixel_clk_src",
.parent_data = disp_cc_parent_data_1,
.num_parents = ARRAY_SIZE(disp_cc_parent_data_1),
- .flags = CLK_SET_RATE_PARENT,
.ops = &clk_dp_ops,
},
};
The clk_rcg2_dp_determine_rate() function is used for the DP pixel clk. This function should return the rate that can be achieved by the pixel clk in 'struct clk_rate_request::rate' and match the logic similar to what is seen in clk_rcg2_dp_set_rate(). But that isn't the case. Instead the code merely bubbles the rate request up to the parent of the pixel clk and doesn't try to do a rational approximation of the rate that would be achieved by picking some m/n value for the RCG. Let's change this logic so that we can assume the parent clk frequency is fixed (it is because it's the VCO of the DP PLL that is configured based on the link rate) and so that we can calculate what the m/n value will be and adjust the req->rate appropriately. Cc: Jeykumar Sankaran <jsanka@codeaurora.org> Cc: Chandan Uddaraju <chandanu@codeaurora.org> Cc: Vara Reddy <varar@codeaurora.org> Cc: Tanmay Shah <tanmay@codeaurora.org> Cc: Bjorn Andersson <bjorn.andersson@linaro.org> Cc: Manu Gautam <mgautam@codeaurora.org> Cc: Sandeep Maheswaram <sanm@codeaurora.org> Cc: Douglas Anderson <dianders@chromium.org> Cc: Sean Paul <seanpaul@chromium.org> Cc: Stephen Boyd <sboyd@kernel.org> Cc: Jonathan Marek <jonathan@marek.ca> Cc: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Cc: Rob Clark <robdclark@chromium.org> Signed-off-by: Stephen Boyd <swboyd@chromium.org> --- drivers/clk/qcom/clk-rcg2.c | 19 +++++++++++++------ drivers/clk/qcom/dispcc-sc7180.c | 3 --- 2 files changed, 13 insertions(+), 9 deletions(-)