linux-kernel - Re: [PATCH v5 4/4] phy: qcom: edp: Add Glymur platform support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <q7iguwi6uxkzl3ogk2jidfncc3guuaqzszvemvqita6t3mlnvz@6e2vxnu4li46>
Date: Fri, 5 Dec 2025 22:26:35 +0200
From: Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>
To: Abel Vesa <abel.vesa@....qualcomm.com>
Cc: Vinod Koul <vkoul@...nel.org>, Kishon Vijay Abraham I <kishon@...nel.org>,
        Rob Herring <robh@...nel.org>,
        Krzysztof Kozlowski <krzk+dt@...nel.org>,
        Conor Dooley <conor+dt@...nel.org>,
        Bjorn Andersson <andersson@...nel.org>,
        Dmitry Baryshkov <lumag@...nel.org>,
        Konrad Dybcio <konradybcio@...nel.org>,
        Neil Armstrong <neil.armstrong@...aro.org>,
        linux-arm-msm@...r.kernel.org, linux-phy@...ts.infradead.org,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
        Abel Vesa <abel.vesa@...aro.org>
Subject: Re: [PATCH v5 4/4] phy: qcom: edp: Add Glymur platform support

On Fri, Dec 05, 2025 at 04:23:23PM +0200, Abel Vesa wrote:
> From: Abel Vesa <abel.vesa@...aro.org>
> 
> The Qualcomm Glymur platform has the new v8 version
> of the eDP/DP PHY. So rework the driver to support this
> new version and add the platform specific configuration data.
> 
> Signed-off-by: Abel Vesa <abel.vesa@...aro.org>
> Signed-off-by: Abel Vesa <abel.vesa@....qualcomm.com>
> ---
>  drivers/phy/qualcomm/phy-qcom-edp.c | 230 +++++++++++++++++++++++++++++++++++-
>  1 file changed, 224 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/phy/qualcomm/phy-qcom-edp.c b/drivers/phy/qualcomm/phy-qcom-edp.c
> index f98fe83de42e..052b7782b3d4 100644
> --- a/drivers/phy/qualcomm/phy-qcom-edp.c
> +++ b/drivers/phy/qualcomm/phy-qcom-edp.c
> @@ -26,6 +26,8 @@
>  #include "phy-qcom-qmp-qserdes-com-v4.h"
>  #include "phy-qcom-qmp-qserdes-com-v6.h"
>  
> +#include "phy-qcom-qmp-qserdes-dp-com-v8.h"
> +
>  /* EDP_PHY registers */
>  #define DP_PHY_CFG                              0x0010
>  #define DP_PHY_CFG_1                            0x0014
> @@ -76,6 +78,7 @@ struct phy_ver_ops {
>  	int (*com_power_on)(const struct qcom_edp *edp);
>  	int (*com_resetsm_cntrl)(const struct qcom_edp *edp);
>  	int (*com_bias_en_clkbuflr)(const struct qcom_edp *edp);
> +	int (*com_clk_fwd_cfg)(const struct qcom_edp *edp);
>  	int (*com_configure_pll)(const struct qcom_edp *edp);
>  	int (*com_configure_ssc)(const struct qcom_edp *edp);
>  };
> @@ -83,6 +86,8 @@ struct phy_ver_ops {
>  struct qcom_edp_phy_cfg {
>  	bool is_edp;
>  	const u8 *aux_cfg;
> +	int aux_cfg_size;

Can we always write DP_AUX_CFG_SIZE values?

> +	const u8 *vco_div_cfg;
>  	const struct qcom_edp_swing_pre_emph_cfg *swing_pre_emph_cfg;
>  	const struct phy_ver_ops *ver_ops;
>  };
> @@ -185,6 +190,10 @@ static const u8 edp_phy_aux_cfg_v4[10] = {
>  	0x00, 0x13, 0x24, 0x00, 0x0a, 0x26, 0x0a, 0x03, 0x37, 0x03
>  };
>  
> +static const u8 edp_phy_vco_div_cfg_v4[4] = {
> +	0x1, 0x1, 0x2, 0x0,
> +};
> +
>  static const u8 edp_pre_emp_hbr_rbr_v5[4][4] = {
>  	{ 0x05, 0x11, 0x17, 0x1d },
>  	{ 0x05, 0x11, 0x18, 0xff },
> @@ -210,6 +219,14 @@ static const u8 edp_phy_aux_cfg_v5[10] = {
>  	0x00, 0x13, 0xa4, 0x00, 0x0a, 0x26, 0x0a, 0x03, 0x37, 0x03
>  };
>  
> +static const u8 edp_phy_aux_cfg_v8[13] = {
> +	0x00, 0x00, 0xa0, 0x00, 0x0a, 0x26, 0x0a, 0x03, 0x37, 0x03, 0x02, 0x02, 0x4,
> +};
> +
> +static const u8 edp_phy_vco_div_cfg_v8[4] = {
> +	0x1, 0x1, 0x1, 0x1,
> +};

If it's always 0x01, where do handle the divisor?

> +
>  static int qcom_edp_phy_init(struct phy *phy)
>  {
>  	struct qcom_edp *edp = phy_get_drvdata(phy);

-- 
With best wishes
Dmitry