Received-SPF: pass (google.com: domain of linux-kernel+bounces-140343-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) client-ip=2604:1380:40f1:3f00::1;
Precedence: bulk
Mime-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
Date: Thu, 11 Apr 2024 13:33:59 +0200
Message-Id: <D0H9F200BT16.2HWU1I45AS1S7@fairphone.com>
Cc: <linux-arm-msm@vger.kernel.org>, <linux-clk@vger.kernel.org>,
 <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 2/4] clk: qcom: dispcc-sm6350: fix DisplayPort clocks
From: "Luca Weiss" <luca.weiss@fairphone.com>
To: "Dmitry Baryshkov" <dmitry.baryshkov@linaro.org>, "Bjorn Andersson"
 <andersson@kernel.org>, "Michael Turquette" <mturquette@baylibre.com>,
 "Stephen Boyd" <sboyd@kernel.org>, "Konrad Dybcio"
 <konrad.dybcio@somainline.org>, "Konrad Dybcio" <konrad.dybcio@linaro.org>,
 "Neil Armstrong" <neil.armstrong@linaro.org>
References: <20240408-dispcc-dp-clocks-v1-0-f9e44902c28d@linaro.org>
 <20240408-dispcc-dp-clocks-v1-2-f9e44902c28d@linaro.org>
In-Reply-To: <20240408-dispcc-dp-clocks-v1-2-f9e44902c28d@linaro.org>

On Mon Apr 8, 2024 at 1:47 PM CEST, Dmitry Baryshkov wrote:
> On SM6350 DisplayPort link clocks use frequency tables inherited from
> the vendor kernel, it is not applicable in the upstream kernel. Drop
> frequency tables and use clk_byte2_ops for those clocks.
>
> Fixes: 837519775f1d ("clk: qcom: Add display clock controller driver for =
SM6350")
> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>

Appears to fix this non-critical error when enabling DisplayPort.

  msm-dp-display ae90000.displayport-controller: _opp_config_clk_single: fa=
iled to set clock rate: -22

And DisplayPort (over USB-C) continues to work as expected, thanks!

Tested-by: Luca Weiss <luca.weiss@fairphone.com>

For completeness, I wrote something about this also on #linux-msm IRC on
March 22nd.

> Hi, I'm trying to get displayport to work on sm6350 but hitting a
> weird issue regarding link clk frequency. For the requested link
> rate=3D540000 in dp_ctrl_enable_mainlink_clocks we call
> dev_pm_opp_set_rate with target_freq=3D540000000 (clk name:
> disp_cc_mdss_dp_link_clk) but the clk_round_rate there makes this into
> freq=3D810000 and subsequently qmp_dp_link_clk_determine_rate fails
> because that's not a valid frequency, only for example 810000000.
> Without any debug statements the visible error in kernel log is:
> "msm-dp-display ae90000.displayport-controller:
> _opp_config_clk_single: failed to set clock rate: -22"
>
> So somewhere there seems to be confusion between how many zeroes
> should be where.. But not sure how this is working on other SoCs, I
> don't see anything much different for my SoC
>
> Kernel base is 6.8.1 fwiw
>
> clk_round_rate behavior feels correct as
> ftbl_disp_cc_mdss_dp_link_clk_src lists the frequencies as
> 162000/270000/540000/810000 so it rounds it to the highest available
> frequency of the clock

Regards
Luca


> ---
>  drivers/clk/qcom/dispcc-sm6350.c | 11 +----------
>  1 file changed, 1 insertion(+), 10 deletions(-)
>
> diff --git a/drivers/clk/qcom/dispcc-sm6350.c b/drivers/clk/qcom/dispcc-s=
m6350.c
> index 839435362010..e4b7464c4d0e 100644
> --- a/drivers/clk/qcom/dispcc-sm6350.c
> +++ b/drivers/clk/qcom/dispcc-sm6350.c
> @@ -221,26 +221,17 @@ static struct clk_rcg2 disp_cc_mdss_dp_crypto_clk_s=
rc =3D {
>  	},
>  };
> =20
> -static const struct freq_tbl ftbl_disp_cc_mdss_dp_link_clk_src[] =3D {
> -	F(162000, P_DP_PHY_PLL_LINK_CLK, 1, 0, 0),
> -	F(270000, P_DP_PHY_PLL_LINK_CLK, 1, 0, 0),
> -	F(540000, P_DP_PHY_PLL_LINK_CLK, 1, 0, 0),
> -	F(810000, P_DP_PHY_PLL_LINK_CLK, 1, 0, 0),
> -	{ }
> -};
> -
>  static struct clk_rcg2 disp_cc_mdss_dp_link_clk_src =3D {
>  	.cmd_rcgr =3D 0x10f8,
>  	.mnd_width =3D 0,
>  	.hid_width =3D 5,
>  	.parent_map =3D disp_cc_parent_map_0,
> -	.freq_tbl =3D ftbl_disp_cc_mdss_dp_link_clk_src,
>  	.clkr.hw.init =3D &(struct clk_init_data){
>  		.name =3D "disp_cc_mdss_dp_link_clk_src",
>  		.parent_data =3D disp_cc_parent_data_0,
>  		.num_parents =3D ARRAY_SIZE(disp_cc_parent_data_0),
>  		.flags =3D CLK_SET_RATE_PARENT | CLK_GET_RATE_NOCACHE,
> -		.ops =3D &clk_rcg2_ops,
> +		.ops =3D &clk_byte2_ops,
>  	},
>  };
> =20