linux-kernel - Re: [PATCH] drm/msm/dp: Correct LeMans/Monaco DP phy Swing/Emphasis setting

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: <ldl7floy6bi5d6svs45xsdgbgkgwxpvj4kuazzg3e6dxzm654l@l5pjud7mvcgu>
Date: Tue, 13 Jan 2026 20:55:37 +0200
From: Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>
To: Yongxing Mou <yongxing.mou@....qualcomm.com>
Cc: Konrad Dybcio <konrad.dybcio@....qualcomm.com>,
        Vinod Koul <vkoul@...nel.org>,
        Neil Armstrong <neil.armstrong@...aro.org>,
        linux-arm-msm@...r.kernel.org, linux-phy@...ts.infradead.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] drm/msm/dp: Correct LeMans/Monaco DP phy Swing/Emphasis
 setting

On Tue, Jan 13, 2026 at 08:04:06PM +0800, Yongxing Mou wrote:
> 
> 
> On 1/9/2026 5:58 PM, Konrad Dybcio wrote:
> > On 1/9/26 9:30 AM, Yongxing Mou wrote:
> > > Currently, the LeMans/Monaco DP PHY operates in DP mode rather than eDP
> > > mode. Per the PHY HPG, the Swing and Emphasis settings have been corrected
> > > to the appropriate DP-mode values.
> > > 
> > > Additionally, the HPG specifies that the LDO value should be set to 0 when
> > > in DP mode. These misconfigurations can lead to link training failures on
> > > certain dongles.
> > > 
> > > Signed-off-by: Yongxing Mou <yongxing.mou@....qualcomm.com>
> > > ---
> > >   drivers/phy/qualcomm/phy-qcom-edp.c | 27 ++++++++++++++++++++++++---
> > >   1 file changed, 24 insertions(+), 3 deletions(-)
> > > 
> > > diff --git a/drivers/phy/qualcomm/phy-qcom-edp.c b/drivers/phy/qualcomm/phy-qcom-edp.c
> > > index 13feab99feec..5b0d774bd715 100644
> > > --- a/drivers/phy/qualcomm/phy-qcom-edp.c
> > > +++ b/drivers/phy/qualcomm/phy-qcom-edp.c
> > > @@ -122,6 +122,13 @@ static const u8 dp_swing_hbr_rbr[4][4] = {
> > >   	{ 0x1f, 0xff, 0xff, 0xff }
> > >   };
> > > +static const u8 dp_swing_hbr_rbr_v1[4][4] = {
> > > +	{ 0x07, 0x0f, 0x16, 0x1f },
> > > +	{ 0x11, 0x1e, 0x1f, 0xff },
> > > +	{ 0x16, 0x1f, 0xff, 0xff },
> > > +	{ 0x1f, 0xff, 0xff, 0xff }
> > > +};
> > 
> > For these platforms, I see 4 tables of settings:
> > 
> > (Low/High) Swing/Pre-em for (Low/High) HBR
> > 
> > None of them exactly match your change
> > 
> Emm, this table is in LeMans eDP HPG, here are 6 tables. 4 of them use for
> eDP mode and reset 2 tables used for DP mode. If my understanding is
> incorrect, please correct me. Thanks ~~~ > [...]
> > 
> > > -	ldo_config = edp->is_edp ? 0x0 : 0x1;
> > > +	ldo_config = !edp->is_edp ? 0x0 : 0x1;
> > 
> > You'll notice that this is further wrong, because for eDP, it should be
> > 0x81 at low-swing-high-HBR and 0xc1 at low-swing-low-HBR, and 0 at both
> > cases of high-swing
> > 
> > Please split the LDO change into a separate commit because it touches
> > more platforms
> > 
> > Konrad
> > 
> 
> Yes, you are right, here seems something not correct. i will separate this
> change into single one.Here are some parts I don't fully understand here.
> Could you please point it? How do we know whether it is in low‑swing or
> high‑swing. I didn’t see any logic in the current code that determines this.
> Also, the value in Hamoa seems not same with LeMans,it is 0x51 and 0x91.
> 
> While going through the Hamoa HPG, I noticed a potential issue.
> 
>  static struct qcom_edp_phy_cfg x1e80100_phy_cfg = {
> 	.aux_cfg = edp_phy_aux_cfg_v4,
> 	.vco_div_cfg = edp_phy_vco_div_cfg_v4,
> 	.swing_pre_emph_cfg = &dp_phy_swing_pre_emph_cfg,...It use
> dp_phy_swing_pre_emph_cfg not edp_phy_swing_pre_emph_cfg, but Hamoa really
> use edp-panel here.. so does this phy cfg correct here?

All PHYs should support eDP and DP modes, so most of the configuration
tables need to be updated/fixed. I tried going through all the tables,
but I never had time to do it in a sane and complete way. As you started
looking into it, would you please review programming for all chipsets
starting from SC8180X?

-- 
With best wishes
Dmitry