On Fri, 29 Apr 2022 at 00:49, Stephen Boyd <swboyd@xxxxxxxxxxxx> wrote:
>
> Quoting Dmitry Baryshkov (2022-04-19 09:34:18)
> > On 08/03/2022 23:46, Stephen Boyd wrote:
> > >
> > > Yes that's my concern. The qmp phy driver has a couple clk_set_rate()
> > > calls in the .configure_dp_phy callback. That is called from
> > > phy_power_on() (see qcom_qmp_phy_power_on() and qcom_qmp_phy_dp_ops).
> > > Looking at qcom_qmp_v3_phy_configure_dp_phy() it does
> > >
> > > clk_set_rate(dp_clks->dp_link_hw.clk, dp_opts->link_rate * 100000);
> > > clk_set_rate(dp_clks->dp_pixel_hw.clk, pixel_freq);
> > >
> > > and I believe the child of dp_pixel_hw is find_clock("stream_pixel").
> > > Looks like that is DISP_CC_MDSS_DP_PIXEL_CLK which is
> > > disp_cc_mdss_dp_pixel_clk_src for the rate settable part. That has
> > > clk_dp_ops which is clk_rcg2_dp_set_rate() for the set rate part. That
> > > wants the parent clk frequency to be something non-zero to use in
> > > rational_best_approximation(). If the clk_set_rate("stream_pixel") call
> > > is made before phy_power_on() then the parent_rate in
> > > clk_rcg2_dp_set_rate() won't be valid and the pixel clk frequency will
> > > be wrong.
> >
> >
> > Please excuse me, I didn't have time for this patchset up to now.
>
> No worries. I lost this in my inbox!
>
> >
> > I double checked the previous patch (drm/msm/dp: "inline"
> > dp_ctrl_set_clock_rate("ctrl_link")). Note, that the OPP is set _after_
> > the PHY is powered on and configured.
> >
>
> Ok. If the clk_set_rate("stream_pixel") call is made after the
> phy_power_on() then it should be equivalent.
R-B?
--
With best wishes
Dmitry
