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: <e22cqybvhlfv6mvmbr6tlaz4zousxcyo475g67yjerxw6xks64@6zzg6tj33kxa>
Date: Mon, 8 Dec 2025 16:16:31 +0200
From: Abel Vesa <abel.vesa@....qualcomm.com>
To: Dmitry Baryshkov <dmitry.baryshkov@....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 25-12-05 22:26:35, Dmitry Baryshkov wrote:
> 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?
> 

Sure, I could check what are the values for the rest of the regs for platforms
with v4 and v5.

> > +	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?
> 

So after double checking the documentation again, it seems
the proper values here are:

   1.62 -> 0
   2.7  -> 0
   5.4  -> 2
   8.1  -> 1

And did some testing on the CRD and it seems to be working fine.

So will update and respin.

Thanks for reviewing,
Abel

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ