* Re: [PATCH v4 4/5] phy: qcom: edp: Fix AUX_CFG8 programming for DP mode
From: Dmitry Baryshkov @ 2026-04-22 16:31 UTC (permalink / raw)
To: Yongxing Mou
Cc: Vinod Koul, Neil Armstrong, Stephen Boyd, Bjorn Andersson,
linux-arm-msm, linux-phy, linux-kernel, Konrad Dybcio
In-Reply-To: <20260422-edp_phy-v4-4-c38bef2d027b@oss.qualcomm.com>
On Wed, Apr 22, 2026 at 02:01:54PM +0800, Yongxing Mou wrote:
> AUX_CFG8 depends on whether the PHY is operating in eDP or DP mode, not
> the selected swing/pre-emphasis table. All supported platforms already
> have the proper tables, so remove the unnecessary check.
>
> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
> Signed-off-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com>
> ---
> drivers/phy/qualcomm/phy-qcom-edp.c | 7 +------
> 1 file changed, 1 insertion(+), 6 deletions(-)
>
Fixes?
With the tag in place,
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v4 2/5] phy: qcom: edp: Add eDP/DP mode switch support
From: Dmitry Baryshkov @ 2026-04-22 16:14 UTC (permalink / raw)
To: Yongxing Mou
Cc: Vinod Koul, Neil Armstrong, Stephen Boyd, Bjorn Andersson,
linux-arm-msm, linux-phy, linux-kernel, stable, Konrad Dybcio
In-Reply-To: <20260422-edp_phy-v4-2-c38bef2d027b@oss.qualcomm.com>
On Wed, Apr 22, 2026 at 02:01:52PM +0800, Yongxing Mou wrote:
> The eDP PHY supports both eDP/DP modes, each requires a different table.
> The current driver doesn't support both modes and use either the eDP or
> DP table when enable the platform.
This is not quite true. The driver supports both modes, but it uses a
fixed static table for eDP programming.
Other than the commit message, LGTM.
> Add a separate set of tables for eDP
> and DP modes, and select the appropriate table based on the current mode.
>
> Glymur's DP mode table differs from the other platforms, add a dedicated
> table for it.
>
> Since both modes are supported, so also fixes the table mismatch for
> X1E80100(eDP) and SA8775P(DP).
>
> Cc: stable@vger.kernel.org
> Fixes: 3f12bf16213c ("phy: qcom: edp: Add support for eDP PHY on SA8775P")
> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
> Signed-off-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com>
> ---
> drivers/phy/qualcomm/phy-qcom-edp.c | 46 +++++++++++++++++++++++++++----------
> 1 file changed, 34 insertions(+), 12 deletions(-)
>
--
With best wishes
Dmitry
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v4 1/5] phy: qcom: edp: Unify generic DP/eDP swing and pre-emphasis tables
From: Dmitry Baryshkov @ 2026-04-22 16:10 UTC (permalink / raw)
To: Yongxing Mou
Cc: Vinod Koul, Neil Armstrong, Stephen Boyd, Bjorn Andersson,
linux-arm-msm, linux-phy, linux-kernel, stable, Konrad Dybcio
In-Reply-To: <20260422-edp_phy-v4-1-c38bef2d027b@oss.qualcomm.com>
On Wed, Apr 22, 2026 at 02:01:51PM +0800, Yongxing Mou wrote:
> The current eDP and DP swing/pre-emphasis tables do not match the HPG
> requirements for the supported platforms, correct the table accordingly.
>
> The generic tables which can be shared as follows:
>
> DP mode：
> -sa8775p/sc7280/sc8280xp/x1e80100
> -glymur
> -sc8180x
> eDP mode(low vdiff):
> -glymur/sa8775p/sc8280xp/x1e80100
> -sc7280
> -sc8180x
>
> The proper tables for SC8180X and SC7280 will be added in a later patch,
> since they need separate table.
>
> Cc: stable@vger.kernel.org
> Fixes: f199223cb490 ("phy: qcom: Introduce new eDP PHY driver")
> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
> Signed-off-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com>
> ---
> drivers/phy/qualcomm/phy-qcom-edp.c | 41 +++++++++----------------------------
> 1 file changed, 10 insertions(+), 31 deletions(-)
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH] phy: qualcomm: qmp-combo: update DP PHY PLL programming on Glymur
From: Dmitry Baryshkov @ 2026-04-22 15:40 UTC (permalink / raw)
To: Konrad Dybcio
Cc: Mahadevan P, Vinod Koul, Neil Armstrong, Wesley Cheng, Abel Vesa,
Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-msm, linux-phy, linux-kernel, devicetree,
Ritesh Kumar
In-Reply-To: <b21b1f73-881a-40bd-aef6-5c34aed0e266@oss.qualcomm.com>
On Wed, Apr 22, 2026 at 11:54:30AM +0200, Konrad Dybcio wrote:
> On 4/20/26 4:18 PM, Mahadevan P wrote:
> >
> >
> > On 4/19/2026 6:48 PM, Dmitry Baryshkov wrote:
> >> On Sun, 19 Apr 2026 at 13:16, Mahadevan P <mahadevan.p@oss.qualcomm.com> wrote:
> >>>
> >>> The existing DP PHY PLL and AUX configuration for the Glymur platform
> >>> does not fully follow the Hardware Programming Guide requirements for
> >>> DP over Type-C, which results in DP link bring-up failures.
> >>>
> >>> Update the DP PHY programming sequence and PLL-related register
> >>> settings to align with the latest HPG recommendations. With this
> >>> change, DP link training completes successfully on Glymur-based
> >>> platforms.
> >>>
> >>> Fixes: d10736db98d2 ("phy: qualcomm: qmp-combo: Add DP offsets and settings for Glymur platforms")
> >>> Signed-off-by: Ritesh Kumar <ritesh.kumar@oss.qualcomm.com>
> >>> Signed-off-by: Mahadevan P <mahadevan.p@oss.qualcomm.com>
> >>> ---
>
> [...]
>
> >>> + writel(val, qmp->dp_dp_phy + QSERDES_DP_PHY_PD_CTL);
> >>> +
> >>> + writel(0x5c, qmp->dp_dp_phy + QSERDES_DP_PHY_MODE);
> >>
> >> Are you saying that we don't need to write 0x4c here in case of the
> >> reverse mode? Was that changed and why?
> > Yes for glymur it is changed
> > DP2_PHY_DP_PHY_PD_CTL
> > Normal Orientation: 0x7D for 4lane; 0x75 for 1Lane or 2Lanne
> > Flip Orientation: 0x7D for 4Lane; 0x6D for 1Lane or 2Lane
>
>
> Dmitry asked about the other register - DP_PHY_MODE.
>
> I checked the reg description, and at least for Glymur, BIT(5)
> (the difference between 0x4c and 0x5c) says "take bit 4 into
> consideration, otherwise let the HW decide". I wonder if we need
> to set it at all, for any target.
I think it depends on the orientation GPIO being correctly wired from
PMIC to the device. I don't remember why, but it's easier to use the
software switch instead.
>
> Konrad
--
With best wishes
Dmitry
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v4 3/5] phy: qcom: edp: Add SC7280/SC8180X swing/pre-emphasis tables
From: Konrad Dybcio @ 2026-04-22 10:42 UTC (permalink / raw)
To: Yongxing Mou, Vinod Koul, Neil Armstrong, Stephen Boyd,
Bjorn Andersson
Cc: linux-arm-msm, linux-phy, linux-kernel
In-Reply-To: <20260422-edp_phy-v4-3-c38bef2d027b@oss.qualcomm.com>
On 4/22/26 8:01 AM, Yongxing Mou wrote:
> SC7280 and SC8180X previously shared the same cfg because they did not use
> swing/pre-emphasis tables. Add the corresponding tables for these
> platforms. Since they have different PHY sub-versions, their eDP/DP mode
> tables also differ, so move SC8180X to its own cfg instead of reusing the
> SC7280 one.
>
> Signed-off-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com>
> ---
> +static const struct qcom_edp_swing_pre_emph_cfg edp_phy_swing_pre_emph_cfg_v2 = {
> + .swing_hbr_rbr = &edp_swing_hbr_rbr,
For eDP / low-Vdiff:
I believe the RBR swing settings for 8180 should
instead be:
0x07 0x0f 0x17 0x1f (matches)
(the rest differs)
0x0d 0x16 0x1e
0x11 0x1b
0x16
The preem RBR almost matches, one byte is off
(arr[0][1] = 0x12 on poipu, 0x11 on kodiak)
The swing and preem settings for HBR3 look OK
For DP / low-Vdiff:
.swing_hbr3_hbr2 OK
.swing_hbr_rbr - I don't know. The docs are unclear whether the same
settings should be used for RBR and HBR3, but maybe? There's a
separate table for mini-DP but I doubt there's any poipu boards with
such a connector (maybe some obscure ones)
.pre_emphasis_hbr3_hbr2 OK
.pre_emphasis_hbr_rbr same as above
Konrad
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH] phy: qualcomm: qmp-combo: update DP PHY PLL programming on Glymur
From: Konrad Dybcio @ 2026-04-22 10:06 UTC (permalink / raw)
To: Mahadevan P, Vinod Koul, Neil Armstrong, Wesley Cheng, Abel Vesa,
Dmitry Baryshkov, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-msm, linux-phy, linux-kernel, devicetree, Ritesh Kumar
In-Reply-To: <20260419-glymur_dp-v1-1-ad1067a8e8ae@oss.qualcomm.com>
On 4/19/26 12:15 PM, Mahadevan P wrote:
> The existing DP PHY PLL and AUX configuration for the Glymur platform
> does not fully follow the Hardware Programming Guide requirements for
> DP over Type-C, which results in DP link bring-up failures.
[...]
> @@ -283,8 +283,8 @@ static const unsigned int qmp_v8_n3_usb43dpphy_regs_layout[QPHY_LAYOUT_SIZE] = {
> [QPHY_DP_AON_TOGGLE_ENABLE] = QPHY_V8_PCS_AON_DP_AON_TOGGLE_ENABLE,
>
> [QPHY_COM_RESETSM_CNTRL] = QSERDES_V8_COM_RESETSM_CNTRL,
> - [QPHY_COM_C_READY_STATUS] = QSERDES_V8_COM_C_READY_STATUS,
> - [QPHY_COM_CMN_STATUS] = QSERDES_V8_COM_CMN_STATUS,
> + [QPHY_COM_C_READY_STATUS] = QSERDES_V8_COM_C_READY_STATUS_N3,
This register is in the DP_QSERDES region, not in COM.
The updates to the reg addreses themselves seem to match the hw description.
[...]
> +static bool qmp_v8_combo_configure_dp_mode(struct qmp_combo *qmp)
> +{
> + bool reverse = (qmp->orientation == TYPEC_ORIENTATION_REVERSE);
> + const struct phy_configure_opts_dp *dp_opts = &qmp->dp_opts;
> + u32 val;
> +
> + val = DP_PHY_PD_CTL_PWRDN | DP_PHY_PD_CTL_AUX_PWRDN |
> + DP_PHY_PD_CTL_LANE_0_1_PWRDN | DP_PHY_PD_CTL_LANE_2_3_PWRDN |
> + DP_PHY_PD_CTL_PLL_PWRDN | DP_PHY_PD_CTL_DP_CLAMP_EN;
The Hamoa (v6) HSR suggests we can use this broader value there too.
And same for e.g. Makena (v4), but not sdm845 (v3) (perhaps we could
use do it either way?).
With my response to Dmitry's comment in mind, the diff in this function
against qmp_combo_configure_dp_mode() should either be broadened to
other platforms, or the function should just be the same for all targets
[...]
>
> +static int qmp_v8_helper_configure_dp_phy(struct qmp_combo *qmp)
This function would then be the same (except your v8 impl returns earlier
than the existing one, skipping a 0x19 write to QSERDES_DP_PHY_CFG and
QPHY_DP_PHY_STATUS reads)
Konrad
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH] phy: qualcomm: qmp-combo: update DP PHY PLL programming on Glymur
From: Konrad Dybcio @ 2026-04-22 9:54 UTC (permalink / raw)
To: Mahadevan P, Dmitry Baryshkov
Cc: Vinod Koul, Neil Armstrong, Wesley Cheng, Abel Vesa,
Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-msm, linux-phy, linux-kernel, devicetree,
Ritesh Kumar
In-Reply-To: <a967d7ec-66f7-4eaa-91e3-0a96e5a8ec7f@oss.qualcomm.com>
On 4/20/26 4:18 PM, Mahadevan P wrote:
>
>
> On 4/19/2026 6:48 PM, Dmitry Baryshkov wrote:
>> On Sun, 19 Apr 2026 at 13:16, Mahadevan P <mahadevan.p@oss.qualcomm.com> wrote:
>>>
>>> The existing DP PHY PLL and AUX configuration for the Glymur platform
>>> does not fully follow the Hardware Programming Guide requirements for
>>> DP over Type-C, which results in DP link bring-up failures.
>>>
>>> Update the DP PHY programming sequence and PLL-related register
>>> settings to align with the latest HPG recommendations. With this
>>> change, DP link training completes successfully on Glymur-based
>>> platforms.
>>>
>>> Fixes: d10736db98d2 ("phy: qualcomm: qmp-combo: Add DP offsets and settings for Glymur platforms")
>>> Signed-off-by: Ritesh Kumar <ritesh.kumar@oss.qualcomm.com>
>>> Signed-off-by: Mahadevan P <mahadevan.p@oss.qualcomm.com>
>>> ---
[...]
>>> + writel(val, qmp->dp_dp_phy + QSERDES_DP_PHY_PD_CTL);
>>> +
>>> + writel(0x5c, qmp->dp_dp_phy + QSERDES_DP_PHY_MODE);
>>
>> Are you saying that we don't need to write 0x4c here in case of the
>> reverse mode? Was that changed and why?
> Yes for glymur it is changed
> DP2_PHY_DP_PHY_PD_CTL
> Normal Orientation: 0x7D for 4lane; 0x75 for 1Lane or 2Lanne
> Flip Orientation: 0x7D for 4Lane; 0x6D for 1Lane or 2Lane
Dmitry asked about the other register - DP_PHY_MODE.
I checked the reg description, and at least for Glymur, BIT(5)
(the difference between 0x4c and 0x5c) says "take bit 4 into
consideration, otherwise let the HW decide". I wonder if we need
to set it at all, for any target.
Konrad
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH] phy: qualcomm: qmp-combo: update DP PHY PLL programming on Glymur
From: Konrad Dybcio @ 2026-04-22 9:36 UTC (permalink / raw)
To: Mahadevan P, Vinod Koul, Neil Armstrong, Wesley Cheng, Abel Vesa,
Dmitry Baryshkov, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-msm, linux-phy, linux-kernel, devicetree, Ritesh Kumar
In-Reply-To: <20260419-glymur_dp-v1-1-ad1067a8e8ae@oss.qualcomm.com>
On 4/19/26 12:15 PM, Mahadevan P wrote:
> The existing DP PHY PLL and AUX configuration for the Glymur platform
> does not fully follow the Hardware Programming Guide requirements for
> DP over Type-C, which results in DP link bring-up failures.
>
> Update the DP PHY programming sequence and PLL-related register
> settings to align with the latest HPG recommendations. With this
> change, DP link training completes successfully on Glymur-based
> platforms.
>
> Fixes: d10736db98d2 ("phy: qualcomm: qmp-combo: Add DP offsets and settings for Glymur platforms")
> Signed-off-by: Ritesh Kumar <ritesh.kumar@oss.qualcomm.com>
> Signed-off-by: Mahadevan P <mahadevan.p@oss.qualcomm.com>
The tag chain is invalid as-is.
Should this patch have "Author: Ritesh Kumar"?
Konrad
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v3 1/5] dt-bindings: phy: qcom,sc8280xp-qmp-pcie-phy: Add support for glymur Gen5 x8 bifurcation mode
From: Krzysztof Kozlowski @ 2026-04-22 6:27 UTC (permalink / raw)
To: Qiang Yu
Cc: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Bjorn Andersson, Konrad Dybcio,
linux-arm-msm, linux-phy, devicetree, linux-kernel
In-Reply-To: <aeXUZ1uSEJ9InUtw@hu-qianyu-lv.qualcomm.com>
On 20/04/2026 09:23, Qiang Yu wrote:
>>> It is not the same as the 5x4 PHY. In DT, we model three PHY nodes:
>>> phy_3a (1x4), phy_3b (1x4), and a separate phy_1x8 node for x8 mode.
>>
>> OK, that's what I wanted to hear. And that's what should not be done,
>>
>> You should not have a separate node for the same hardware. First, DTC
>> will give you a W=1 warning, although warning itself should be moved to
>> W=2.
>>
>> Second, the warning tells important story - same hardware is described
>> twice.
>>
>> You only need phy_3a and phy_3b, so only two in total.
>
> We can keep only phy_3a and phy_3b, but still add new compatible
> qcom,glymur-qmp-gen5x8-pcie-phy in binding, right?
No, you cannot. You cannot create fake device nodes.
Best regards,
Krzysztof
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v3 1/5] dt-bindings: phy: qcom,sc8280xp-qmp-pcie-phy: Add support for glymur Gen5 x8 bifurcation mode
From: Krzysztof Kozlowski @ 2026-04-22 6:27 UTC (permalink / raw)
To: Qiang Yu
Cc: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Bjorn Andersson, Konrad Dybcio,
linux-arm-msm, linux-phy, devicetree, linux-kernel
In-Reply-To: <aeBQRStG3imY0cOe@hu-qianyu-lv.qualcomm.com>
On 16/04/2026 04:58, Qiang Yu wrote:
>>> reset-names:
>>> minItems: 1
>>> items:
>>> - const: phy
>>> - const: phy_nocsr
>>> + - const: phy_b
>>> + - const: phy_b_nocsr
>>
>> And now I doubt that all the changes here are for duplicated node.
>>
>
> All the changes here are for 1x8 PHY node.
>
>> Maybe just the commit msg is confusing and instead of describing some
>> node which combines two other phys just say what device is here being
>> described.
>>
>
> Okay, I will focus on describing the required resources. Is the
> description below clearer?
>
> Glymur has two physical Gen5x4 PCIe PHY blocks: pcie3a phy and pcie3b phy.
I just proven you that it is not true.
Best regards,
Krzysztof
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v3 1/5] dt-bindings: phy: qcom,sc8280xp-qmp-pcie-phy: Add support for glymur Gen5 x8 bifurcation mode
From: Qiang Yu @ 2026-04-22 6:19 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Bjorn Andersson, Konrad Dybcio,
linux-arm-msm, linux-phy, devicetree, linux-kernel
In-Reply-To: <20260420-optimistic-unnatural-stingray-80da35@quoll>
On Mon, Apr 20, 2026 at 03:23:43PM +0200, Krzysztof Kozlowski wrote:
> On Mon, Apr 20, 2026 at 12:23:19AM -0700, Qiang Yu wrote:
> > On Fri, Apr 17, 2026 at 11:18:08AM +0200, Krzysztof Kozlowski wrote:
> > > On Wed, Apr 15, 2026 at 07:58:13PM -0700, Qiang Yu wrote:
> > > > On Wed, Apr 15, 2026 at 09:50:28AM +0200, Krzysztof Kozlowski wrote:
> > > > > On Sun, Apr 12, 2026 at 11:25:56PM -0700, Qiang Yu wrote:
> > > > > > The Glymur SoC has pcie3a and pcie3b PHYs that can operate in two modes:
> > > > > >
> > > > > > 1. Independent 4-lane mode: Each PHY operates as a separate PCIe Gen5
> > > > > > 4-lane interface, compatible with qcom,glymur-qmp-gen5x4-pcie-phy
> > > > > > 2. Bifurcation mode (8-lane): pcie3a phy acts as leader and pcie3b phy as
> > > > > > follower to form a single 8-lane PCIe Gen5 interface
> > > > > >
> > > > > > In bifurcation mode, the hardware design requires controlling additional
> > > > > > resources beyond the standard pcie3a PHY configuration:
> > > > > >
> > > > > > - pcie3b's aux_clk (phy_b_aux)
> > > > > > - pcie3b's phy_gdsc power domain
> > > > > > - pcie3b's bcr/nocsr reset
> > > > > >
> > > > > > Add qcom,glymur-qmp-gen5x8-pcie-phy compatible string to document this
> > > > > > 8-lane bifurcation configuration.
> > > > >
> > > > > Do you describe PCI3A or PCI3B or something combined PCI3?
> > > >
> > > > I describe a single x8 PHY with resources from both the pcie3a and pcie3b
> > > > PHY blocks for x8 operation.
> > > >
> > > > >
> > > > > >
> > > > > > The phy_b_aux clock is used as the 6th clock instead of pipediv2,
> > > > > > requiring the clock-names enum to be extended to support both
> > > > > > [phy_b_aux, pipediv2] options at index 5. This follows the existing
> > > > > > pattern used for [rchng, refgen] clocks at index 3.
> > > > > >
> > > > > > Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
> > > > > > ---
> > > > > > .../bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml | 53 ++++++++++++++++++----
> > > > > > 1 file changed, 45 insertions(+), 8 deletions(-)
> > > > > >
> > > > > > diff --git a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml
> > > > > > index 3a35120a77ec0ceb814a1cdcacff32fef32b4f7b..14eba5d705b1956c1bb00cc8c95171ed6488299b 100644
> > > > > > --- a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml
> > > > > > +++ b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml
> > > > > > @@ -18,6 +18,7 @@ properties:
> > > > > > enum:
> > > > > > - qcom,glymur-qmp-gen4x2-pcie-phy
> > > > > > - qcom,glymur-qmp-gen5x4-pcie-phy
> > > > > > + - qcom,glymur-qmp-gen5x8-pcie-phy
> > > > >
> > > > > That's the same device as 5x4, no? One device, one compatible and this
> > > > > suggests you will have three PCI phys in the DT - two 5x4 and one 5x8?
> > > > >
> > > >
> > > > It is not the same as the 5x4 PHY. In DT, we model three PHY nodes:
> > > > phy_3a (1x4), phy_3b (1x4), and a separate phy_1x8 node for x8 mode.
> > >
> > > OK, that's what I wanted to hear. And that's what should not be done,
> > >
> > > You should not have a separate node for the same hardware. First, DTC
> > > will give you a W=1 warning, although warning itself should be moved to
> > > W=2.
> > >
> > > Second, the warning tells important story - same hardware is described
> > > twice.
> > >
> > > You only need phy_3a and phy_3b, so only two in total.
> >
> > We can keep only phy_3a and phy_3b, but still add new compatible
> > qcom,glymur-qmp-gen5x8-pcie-phy in binding, right?
> >
> > For boards that support pcie3a(1x4) + pcie3b(1x4), DTS would be:
> >
> > pcie3a_phy { compatible = "qcom,glymur-qmp-gen5x4-pcie-phy"; };
> > pcie3b_phy { compatible = "qcom,glymur-qmp-gen5x4-pcie-phy"; };
> >
> > For boards that support 1x8, we would override pcie3a_phy with:
> >
> > pcie3a_phy { compatible = "qcom,glymur-qmp-gen5x8-pcie-phy"; /* additional resources */ };
> > pcie3b_phy { compatible = "qcom,glymur-qmp-gen5x4-pcie-phy"; };
> >
> > This still uses only two PHY nodes and DTC will not report warning.
>
> IMO, you do not need another compatible. Device is exactly the same. If
> wiring on the board differs, e.g. you have 8x instead of 4x, you:
> 1. disable unused 3B phy.
> 2. Add to 3A missing resources or the phandle to companion node.
>
> At least that is what I tought till now, when I opened the HPG/manual
> for Glymur phy. Someone skipped important information when PCIe PHY was
> upstreamed first and glymur.dtsi already got PHY 3B described.
>
> Reminder: writing bindings asks you explicitly to post COMPLETE
> bindings.
>
> If you posted COMPLETE bindings we would question all this and you would
> have to check in user manual that this is actually ONE device.
>
> There is no 5x4 phy 3A and 3B, at least HPG is pretty clear here.
PHY_A and PHY_B are two sub PHYs that can act independently. I thought we
can describe them. And for previous target eg Hamoa, we also descibed like
this.
>
> And you should start with that.
>
> But you posted first incomplete binding, hiding the rest and now you
> have 5x4 merged into DTSI.
>
> So let's rephrase based on manual:
> You have only one PCIE phy3. Not 3A + 3B. That one phy3 can be
> configured by consumers (board) differently, e.g. by requesting 8-lane
> or twice 4-lane phys.
>
> Let me send correction note for glymur.dtsi.
>
So we can have only one compatible "qcom,glymur-qmp-gen5x8-pcie-phy" and
one phy dts node?
- Qiang Yu
> Best regards,
> Krzysztof
>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* [PATCH v4 5/5] phy: qcom: edp: Add PHY-specific LDO config for eDP low vdiff
From: Yongxing Mou @ 2026-04-22 6:01 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Stephen Boyd, Bjorn Andersson
Cc: linux-arm-msm, linux-phy, linux-kernel, Yongxing Mou, stable,
Dmitry Baryshkov, Konrad Dybcio
In-Reply-To: <20260422-edp_phy-v4-0-c38bef2d027b@oss.qualcomm.com>
For eDP low vdiff, the LDO setting depends on the PHY version rather
than being a simple 0x0 or 0x1 value. Introduce a PHY callback to program
the correct LDO setting according to the HPG.
Since SC7280/SC8180X uses different LDO settings from SA8775P/SC8280XP,
introduce qcom_edp_phy_ops_v3 to keep the LDO setting correct.
Cc: stable@vger.kernel.org
Fixes: f199223cb490 ("phy: qcom: Introduce new eDP PHY driver")
Signed-off-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Tested-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> # SC8280XP X13s
---
drivers/phy/qualcomm/phy-qcom-edp.c | 88 ++++++++++++++++++++++++++++++++-----
1 file changed, 77 insertions(+), 11 deletions(-)
diff --git a/drivers/phy/qualcomm/phy-qcom-edp.c b/drivers/phy/qualcomm/phy-qcom-edp.c
index bbd45f709a4b..3a5284522bab 100644
--- a/drivers/phy/qualcomm/phy-qcom-edp.c
+++ b/drivers/phy/qualcomm/phy-qcom-edp.c
@@ -81,6 +81,7 @@ struct phy_ver_ops {
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);
+ int (*com_ldo_config)(const struct qcom_edp *edp);
};
struct qcom_edp_phy_cfg {
@@ -339,7 +340,7 @@ static int qcom_edp_set_voltages(struct qcom_edp *edp, const struct phy_configur
const struct qcom_edp_swing_pre_emph_cfg *cfg;
unsigned int v_level = 0;
unsigned int p_level = 0;
- u8 ldo_config;
+ int ret;
u8 swing;
u8 emph;
int i;
@@ -365,13 +366,13 @@ static int qcom_edp_set_voltages(struct qcom_edp *edp, const struct phy_configur
if (swing == 0xff || emph == 0xff)
return -EINVAL;
- ldo_config = edp->is_edp ? 0x0 : 0x1;
+ ret = edp->cfg->ver_ops->com_ldo_config(edp);
+ if (ret)
+ return ret;
- writel(ldo_config, edp->tx0 + TXn_LDO_CONFIG);
writel(swing, edp->tx0 + TXn_TX_DRV_LVL);
writel(emph, edp->tx0 + TXn_TX_EMP_POST1_LVL);
- writel(ldo_config, edp->tx1 + TXn_LDO_CONFIG);
writel(swing, edp->tx1 + TXn_TX_DRV_LVL);
writel(emph, edp->tx1 + TXn_TX_EMP_POST1_LVL);
@@ -595,6 +596,52 @@ static int qcom_edp_com_configure_pll_v4(const struct qcom_edp *edp)
return 0;
}
+static int qcom_edp_ldo_config_v3(const struct qcom_edp *edp)
+{
+ const struct phy_configure_opts_dp *dp_opts = &edp->dp_opts;
+ u32 ldo_config;
+
+ if (!edp->is_edp)
+ ldo_config = 0x0;
+ else if (dp_opts->link_rate <= 2700)
+ ldo_config = 0x81;
+ else
+ ldo_config = 0x41;
+
+ writel(ldo_config, edp->tx0 + TXn_LDO_CONFIG);
+ writel(dp_opts->lanes > 2 ? ldo_config : 0x00, edp->tx1 + TXn_LDO_CONFIG);
+
+ return 0;
+}
+
+static int qcom_edp_ldo_config_v4(const struct qcom_edp *edp)
+{
+ const struct phy_configure_opts_dp *dp_opts = &edp->dp_opts;
+ u32 ldo_config;
+
+ if (!edp->is_edp)
+ ldo_config = 0x0;
+ else if (dp_opts->link_rate <= 2700)
+ ldo_config = 0xc1;
+ else
+ ldo_config = 0x81;
+
+ writel(ldo_config, edp->tx0 + TXn_LDO_CONFIG);
+ writel(dp_opts->lanes > 2 ? ldo_config : 0x00, edp->tx1 + TXn_LDO_CONFIG);
+
+ return 0;
+}
+
+static const struct phy_ver_ops qcom_edp_phy_ops_v3 = {
+ .com_power_on = qcom_edp_phy_power_on_v4,
+ .com_resetsm_cntrl = qcom_edp_phy_com_resetsm_cntrl_v4,
+ .com_bias_en_clkbuflr = qcom_edp_com_bias_en_clkbuflr_v4,
+ .com_clk_fwd_cfg = qcom_edp_com_clk_fwd_cfg_v4,
+ .com_configure_pll = qcom_edp_com_configure_pll_v4,
+ .com_configure_ssc = qcom_edp_com_configure_ssc_v4,
+ .com_ldo_config = qcom_edp_ldo_config_v3,
+};
+
static const struct phy_ver_ops qcom_edp_phy_ops_v4 = {
.com_power_on = qcom_edp_phy_power_on_v4,
.com_resetsm_cntrl = qcom_edp_phy_com_resetsm_cntrl_v4,
@@ -602,6 +649,7 @@ static const struct phy_ver_ops qcom_edp_phy_ops_v4 = {
.com_clk_fwd_cfg = qcom_edp_com_clk_fwd_cfg_v4,
.com_configure_pll = qcom_edp_com_configure_pll_v4,
.com_configure_ssc = qcom_edp_com_configure_ssc_v4,
+ .com_ldo_config = qcom_edp_ldo_config_v4,
};
static const struct qcom_edp_phy_cfg sa8775p_dp_phy_cfg = {
@@ -618,7 +666,7 @@ static const struct qcom_edp_phy_cfg sc7280_dp_phy_cfg = {
.vco_div_cfg = edp_phy_vco_div_cfg_v4,
.dp_swing_pre_emph_cfg = &dp_phy_swing_pre_emph_cfg,
.edp_swing_pre_emph_cfg = &edp_phy_swing_pre_emph_cfg_v3,
- .ver_ops = &qcom_edp_phy_ops_v4,
+ .ver_ops = &qcom_edp_phy_ops_v3,
};
static const struct qcom_edp_phy_cfg sc8180x_dp_phy_cfg = {
@@ -626,7 +674,7 @@ static const struct qcom_edp_phy_cfg sc8180x_dp_phy_cfg = {
.vco_div_cfg = edp_phy_vco_div_cfg_v4,
.dp_swing_pre_emph_cfg = &dp_phy_swing_pre_emph_cfg_v2,
.edp_swing_pre_emph_cfg = &edp_phy_swing_pre_emph_cfg_v2,
- .ver_ops = &qcom_edp_phy_ops_v4,
+ .ver_ops = &qcom_edp_phy_ops_v3,
};
static const struct qcom_edp_phy_cfg sc8280xp_dp_phy_cfg = {
@@ -811,6 +859,24 @@ static int qcom_edp_com_configure_pll_v6(const struct qcom_edp *edp)
return 0;
}
+static int qcom_edp_ldo_config_v6(const struct qcom_edp *edp)
+{
+ const struct phy_configure_opts_dp *dp_opts = &edp->dp_opts;
+ u32 ldo_config;
+
+ if (!edp->is_edp)
+ ldo_config = 0x0;
+ else if (dp_opts->link_rate <= 2700)
+ ldo_config = 0x51;
+ else
+ ldo_config = 0x91;
+
+ writel(ldo_config, edp->tx0 + TXn_LDO_CONFIG);
+ writel(dp_opts->lanes > 2 ? ldo_config : 0x00, edp->tx1 + TXn_LDO_CONFIG);
+
+ return 0;
+}
+
static const struct phy_ver_ops qcom_edp_phy_ops_v6 = {
.com_power_on = qcom_edp_phy_power_on_v6,
.com_resetsm_cntrl = qcom_edp_phy_com_resetsm_cntrl_v6,
@@ -818,6 +884,7 @@ static const struct phy_ver_ops qcom_edp_phy_ops_v6 = {
.com_clk_fwd_cfg = qcom_edp_com_clk_fwd_cfg_v4,
.com_configure_pll = qcom_edp_com_configure_pll_v6,
.com_configure_ssc = qcom_edp_com_configure_ssc_v6,
+ .com_ldo_config = qcom_edp_ldo_config_v6,
};
static struct qcom_edp_phy_cfg x1e80100_phy_cfg = {
@@ -998,6 +1065,7 @@ static const struct phy_ver_ops qcom_edp_phy_ops_v8 = {
.com_clk_fwd_cfg = qcom_edp_com_clk_fwd_cfg_v8,
.com_configure_pll = qcom_edp_com_configure_pll_v8,
.com_configure_ssc = qcom_edp_com_configure_ssc_v8,
+ .com_ldo_config = qcom_edp_ldo_config_v6,
};
static struct qcom_edp_phy_cfg glymur_phy_cfg = {
@@ -1013,7 +1081,6 @@ static int qcom_edp_phy_power_on(struct phy *phy)
const struct qcom_edp *edp = phy_get_drvdata(phy);
u32 bias0_en, drvr0_en, bias1_en, drvr1_en;
unsigned long pixel_freq;
- u8 ldo_config = 0x0;
int ret;
u32 val;
u8 cfg1;
@@ -1022,11 +1089,10 @@ static int qcom_edp_phy_power_on(struct phy *phy)
if (ret)
return ret;
- if (edp->cfg->edp_swing_pre_emph_cfg && !edp->is_edp)
- ldo_config = 0x1;
+ ret = edp->cfg->ver_ops->com_ldo_config(edp);
+ if (ret)
+ return ret;
- writel(ldo_config, edp->tx0 + TXn_LDO_CONFIG);
- writel(ldo_config, edp->tx1 + TXn_LDO_CONFIG);
writel(0x00, edp->tx0 + TXn_LANE_MODE_1);
writel(0x00, edp->tx1 + TXn_LANE_MODE_1);
--
2.43.0
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH v4 4/5] phy: qcom: edp: Fix AUX_CFG8 programming for DP mode
From: Yongxing Mou @ 2026-04-22 6:01 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Stephen Boyd, Bjorn Andersson
Cc: linux-arm-msm, linux-phy, linux-kernel, Yongxing Mou,
Konrad Dybcio
In-Reply-To: <20260422-edp_phy-v4-0-c38bef2d027b@oss.qualcomm.com>
AUX_CFG8 depends on whether the PHY is operating in eDP or DP mode, not
the selected swing/pre-emphasis table. All supported platforms already
have the proper tables, so remove the unnecessary check.
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com>
---
drivers/phy/qualcomm/phy-qcom-edp.c | 7 +------
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/drivers/phy/qualcomm/phy-qcom-edp.c b/drivers/phy/qualcomm/phy-qcom-edp.c
index 7ac2f502c7a0..bbd45f709a4b 100644
--- a/drivers/phy/qualcomm/phy-qcom-edp.c
+++ b/drivers/phy/qualcomm/phy-qcom-edp.c
@@ -312,12 +312,7 @@ static int qcom_edp_phy_init(struct phy *phy)
DP_PHY_PD_CTL_PLL_PWRDN | DP_PHY_PD_CTL_DP_CLAMP_EN,
edp->edp + DP_PHY_PD_CTL);
- /*
- * TODO: Re-work the conditions around setting the cfg8 value
- * when more information becomes available about why this is
- * even needed.
- */
- if (edp->cfg->dp_swing_pre_emph_cfg && !edp->is_edp)
+ if (!edp->is_edp)
aux_cfg[8] = 0xb7;
writel(0xfc, edp->edp + DP_PHY_MODE);
--
2.43.0
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH v4 3/5] phy: qcom: edp: Add SC7280/SC8180X swing/pre-emphasis tables
From: Yongxing Mou @ 2026-04-22 6:01 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Stephen Boyd, Bjorn Andersson
Cc: linux-arm-msm, linux-phy, linux-kernel, Yongxing Mou
In-Reply-To: <20260422-edp_phy-v4-0-c38bef2d027b@oss.qualcomm.com>
SC7280 and SC8180X previously shared the same cfg because they did not use
swing/pre-emphasis tables. Add the corresponding tables for these
platforms. Since they have different PHY sub-versions, their eDP/DP mode
tables also differ, so move SC8180X to its own cfg instead of reusing the
SC7280 one.
Signed-off-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com>
---
drivers/phy/qualcomm/phy-qcom-edp.c | 71 ++++++++++++++++++++++++++++++++++---
1 file changed, 67 insertions(+), 4 deletions(-)
diff --git a/drivers/phy/qualcomm/phy-qcom-edp.c b/drivers/phy/qualcomm/phy-qcom-edp.c
index 3266026cfe37..7ac2f502c7a0 100644
--- a/drivers/phy/qualcomm/phy-qcom-edp.c
+++ b/drivers/phy/qualcomm/phy-qcom-edp.c
@@ -165,6 +165,27 @@ static const struct qcom_edp_swing_pre_emph_cfg dp_phy_swing_pre_emph_cfg_v8 = {
.pre_emphasis_hbr3_hbr2 = &dp_pre_emp_hbr2_hbr3,
};
+static const u8 dp_swing_hbr2_hbr3_v2[4][4] = {
+ { 0x27, 0x2f, 0x36, 0xff },
+ { 0x31, 0x3e, 0x3f, 0xff },
+ { 0x3a, 0x3f, 0xff, 0xff },
+ { 0xff, 0xff, 0xff, 0xff }
+};
+
+static const u8 dp_pre_emp_hbr2_hbr3_v2[4][4] = {
+ { 0x20, 0x2e, 0x35, 0xff },
+ { 0x20, 0x2e, 0x35, 0xff },
+ { 0x20, 0x2e, 0xff, 0xff },
+ { 0xff, 0xff, 0xff, 0xff }
+};
+
+static const struct qcom_edp_swing_pre_emph_cfg dp_phy_swing_pre_emph_cfg_v2 = {
+ .swing_hbr_rbr = &dp_swing_hbr_rbr,
+ .swing_hbr3_hbr2 = &dp_swing_hbr2_hbr3_v2,
+ .pre_emphasis_hbr_rbr = &dp_pre_emp_hbr_rbr,
+ .pre_emphasis_hbr3_hbr2 = &dp_pre_emp_hbr2_hbr3_v2,
+};
+
static const u8 edp_swing_hbr_rbr[4][4] = {
{ 0x07, 0x0f, 0x16, 0x1f },
{ 0x0d, 0x16, 0x1e, 0xff },
@@ -208,6 +229,41 @@ static const u8 edp_phy_vco_div_cfg_v4[4] = {
0x01, 0x01, 0x02, 0x00,
};
+static const u8 edp_pre_emp_hbr2_hbr3_v2[4][4] = {
+ { 0x0c, 0x15, 0x19, 0x1e },
+ { 0x08, 0x15, 0x19, 0xff },
+ { 0x0e, 0x14, 0xff, 0xff },
+ { 0x0d, 0xff, 0xff, 0xff }
+};
+
+static const struct qcom_edp_swing_pre_emph_cfg edp_phy_swing_pre_emph_cfg_v2 = {
+ .swing_hbr_rbr = &edp_swing_hbr_rbr,
+ .swing_hbr3_hbr2 = &edp_swing_hbr2_hbr3,
+ .pre_emphasis_hbr_rbr = &edp_pre_emp_hbr_rbr,
+ .pre_emphasis_hbr3_hbr2 = &edp_pre_emp_hbr2_hbr3_v2,
+};
+
+static const u8 edp_swing_hbr2_hbr3_v3[4][4] = {
+ { 0x06, 0x11, 0x16, 0x1b },
+ { 0x0b, 0x19, 0x1f, 0xff },
+ { 0x18, 0x1f, 0xff, 0xff },
+ { 0x1f, 0xff, 0xff, 0xff }
+};
+
+static const u8 edp_pre_emp_hbr2_hbr3_v3[4][4] = {
+ { 0x0c, 0x15, 0x19, 0x1e },
+ { 0x09, 0x14, 0x19, 0xff },
+ { 0x0f, 0x14, 0xff, 0xff },
+ { 0x0d, 0xff, 0xff, 0xff }
+};
+
+static const struct qcom_edp_swing_pre_emph_cfg edp_phy_swing_pre_emph_cfg_v3 = {
+ .swing_hbr_rbr = &edp_swing_hbr_rbr,
+ .swing_hbr3_hbr2 = &edp_swing_hbr2_hbr3_v3,
+ .pre_emphasis_hbr_rbr = &edp_pre_emp_hbr_rbr,
+ .pre_emphasis_hbr3_hbr2 = &edp_pre_emp_hbr2_hbr3_v3,
+};
+
static const u8 edp_phy_aux_cfg_v5[DP_AUX_CFG_SIZE] = {
0x00, 0x13, 0xa4, 0x00, 0x0a, 0x26, 0x0a, 0x03, 0x37, 0x03, 0x02, 0x02, 0x00,
};
@@ -298,9 +354,6 @@ static int qcom_edp_set_voltages(struct qcom_edp *edp, const struct phy_configur
else
cfg = edp->cfg->dp_swing_pre_emph_cfg;
- if (!cfg)
- return 0;
-
for (i = 0; i < dp_opts->lanes; i++) {
v_level = max(v_level, dp_opts->voltage[i]);
p_level = max(p_level, dp_opts->pre[i]);
@@ -568,6 +621,16 @@ static const struct qcom_edp_phy_cfg sa8775p_dp_phy_cfg = {
static const struct qcom_edp_phy_cfg sc7280_dp_phy_cfg = {
.aux_cfg = edp_phy_aux_cfg_v4,
.vco_div_cfg = edp_phy_vco_div_cfg_v4,
+ .dp_swing_pre_emph_cfg = &dp_phy_swing_pre_emph_cfg,
+ .edp_swing_pre_emph_cfg = &edp_phy_swing_pre_emph_cfg_v3,
+ .ver_ops = &qcom_edp_phy_ops_v4,
+};
+
+static const struct qcom_edp_phy_cfg sc8180x_dp_phy_cfg = {
+ .aux_cfg = edp_phy_aux_cfg_v4,
+ .vco_div_cfg = edp_phy_vco_div_cfg_v4,
+ .dp_swing_pre_emph_cfg = &dp_phy_swing_pre_emph_cfg_v2,
+ .edp_swing_pre_emph_cfg = &edp_phy_swing_pre_emph_cfg_v2,
.ver_ops = &qcom_edp_phy_ops_v4,
};
@@ -1348,7 +1411,7 @@ static const struct of_device_id qcom_edp_phy_match_table[] = {
{ .compatible = "qcom,glymur-dp-phy", .data = &glymur_phy_cfg, },
{ .compatible = "qcom,sa8775p-edp-phy", .data = &sa8775p_dp_phy_cfg, },
{ .compatible = "qcom,sc7280-edp-phy", .data = &sc7280_dp_phy_cfg, },
- { .compatible = "qcom,sc8180x-edp-phy", .data = &sc7280_dp_phy_cfg, },
+ { .compatible = "qcom,sc8180x-edp-phy", .data = &sc8180x_dp_phy_cfg, },
{ .compatible = "qcom,sc8280xp-dp-phy", .data = &sc8280xp_dp_phy_cfg, },
{ .compatible = "qcom,sc8280xp-edp-phy", .data = &sc8280xp_edp_phy_cfg, },
{ .compatible = "qcom,x1e80100-dp-phy", .data = &x1e80100_phy_cfg, },
--
2.43.0
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH v4 2/5] phy: qcom: edp: Add eDP/DP mode switch support
From: Yongxing Mou @ 2026-04-22 6:01 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Stephen Boyd, Bjorn Andersson
Cc: linux-arm-msm, linux-phy, linux-kernel, Yongxing Mou, stable,
Konrad Dybcio
In-Reply-To: <20260422-edp_phy-v4-0-c38bef2d027b@oss.qualcomm.com>
The eDP PHY supports both eDP/DP modes, each requires a different table.
The current driver doesn't support both modes and use either the eDP or
DP table when enable the platform. Add a separate set of tables for eDP
and DP modes, and select the appropriate table based on the current mode.
Glymur's DP mode table differs from the other platforms, add a dedicated
table for it.
Since both modes are supported, so also fixes the table mismatch for
X1E80100(eDP) and SA8775P(DP).
Cc: stable@vger.kernel.org
Fixes: 3f12bf16213c ("phy: qcom: edp: Add support for eDP PHY on SA8775P")
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com>
---
drivers/phy/qualcomm/phy-qcom-edp.c | 46 +++++++++++++++++++++++++++----------
1 file changed, 34 insertions(+), 12 deletions(-)
diff --git a/drivers/phy/qualcomm/phy-qcom-edp.c b/drivers/phy/qualcomm/phy-qcom-edp.c
index 2af3fd63832f..3266026cfe37 100644
--- a/drivers/phy/qualcomm/phy-qcom-edp.c
+++ b/drivers/phy/qualcomm/phy-qcom-edp.c
@@ -87,7 +87,8 @@ struct qcom_edp_phy_cfg {
bool is_edp;
const u8 *aux_cfg;
const u8 *vco_div_cfg;
- const struct qcom_edp_swing_pre_emph_cfg *swing_pre_emph_cfg;
+ const struct qcom_edp_swing_pre_emph_cfg *dp_swing_pre_emph_cfg;
+ const struct qcom_edp_swing_pre_emph_cfg *edp_swing_pre_emph_cfg;
const struct phy_ver_ops *ver_ops;
};
@@ -150,6 +151,20 @@ static const struct qcom_edp_swing_pre_emph_cfg dp_phy_swing_pre_emph_cfg = {
.pre_emphasis_hbr3_hbr2 = &dp_pre_emp_hbr2_hbr3,
};
+static const u8 dp_pre_emp_hbr_rbr_v8[4][4] = {
+ { 0x00, 0x0e, 0x15, 0x1a },
+ { 0x00, 0x0e, 0x15, 0xff },
+ { 0x00, 0x0e, 0xff, 0xff },
+ { 0x00, 0xff, 0xff, 0xff }
+};
+
+static const struct qcom_edp_swing_pre_emph_cfg dp_phy_swing_pre_emph_cfg_v8 = {
+ .swing_hbr_rbr = &dp_swing_hbr_rbr,
+ .swing_hbr3_hbr2 = &dp_swing_hbr2_hbr3,
+ .pre_emphasis_hbr_rbr = &dp_pre_emp_hbr_rbr_v8,
+ .pre_emphasis_hbr3_hbr2 = &dp_pre_emp_hbr2_hbr3,
+};
+
static const u8 edp_swing_hbr_rbr[4][4] = {
{ 0x07, 0x0f, 0x16, 0x1f },
{ 0x0d, 0x16, 0x1e, 0xff },
@@ -246,7 +261,7 @@ static int qcom_edp_phy_init(struct phy *phy)
* when more information becomes available about why this is
* even needed.
*/
- if (edp->cfg->swing_pre_emph_cfg && !edp->is_edp)
+ if (edp->cfg->dp_swing_pre_emph_cfg && !edp->is_edp)
aux_cfg[8] = 0xb7;
writel(0xfc, edp->edp + DP_PHY_MODE);
@@ -270,7 +285,7 @@ static int qcom_edp_phy_init(struct phy *phy)
static int qcom_edp_set_voltages(struct qcom_edp *edp, const struct phy_configure_opts_dp *dp_opts)
{
- const struct qcom_edp_swing_pre_emph_cfg *cfg = edp->cfg->swing_pre_emph_cfg;
+ const struct qcom_edp_swing_pre_emph_cfg *cfg;
unsigned int v_level = 0;
unsigned int p_level = 0;
u8 ldo_config;
@@ -278,12 +293,14 @@ static int qcom_edp_set_voltages(struct qcom_edp *edp, const struct phy_configur
u8 emph;
int i;
+ if (edp->is_edp)
+ cfg = edp->cfg->edp_swing_pre_emph_cfg;
+ else
+ cfg = edp->cfg->dp_swing_pre_emph_cfg;
+
if (!cfg)
return 0;
- if (edp->is_edp)
- cfg = &edp_phy_swing_pre_emph_cfg;
-
for (i = 0; i < dp_opts->lanes; i++) {
v_level = max(v_level, dp_opts->voltage[i]);
p_level = max(p_level, dp_opts->pre[i]);
@@ -543,7 +560,8 @@ static const struct qcom_edp_phy_cfg sa8775p_dp_phy_cfg = {
.is_edp = false,
.aux_cfg = edp_phy_aux_cfg_v5,
.vco_div_cfg = edp_phy_vco_div_cfg_v4,
- .swing_pre_emph_cfg = &edp_phy_swing_pre_emph_cfg,
+ .dp_swing_pre_emph_cfg = &dp_phy_swing_pre_emph_cfg,
+ .edp_swing_pre_emph_cfg = &edp_phy_swing_pre_emph_cfg,
.ver_ops = &qcom_edp_phy_ops_v4,
};
@@ -556,7 +574,8 @@ static const struct qcom_edp_phy_cfg sc7280_dp_phy_cfg = {
static const struct qcom_edp_phy_cfg sc8280xp_dp_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,
+ .dp_swing_pre_emph_cfg = &dp_phy_swing_pre_emph_cfg,
+ .edp_swing_pre_emph_cfg = &edp_phy_swing_pre_emph_cfg,
.ver_ops = &qcom_edp_phy_ops_v4,
};
@@ -564,7 +583,8 @@ static const struct qcom_edp_phy_cfg sc8280xp_edp_phy_cfg = {
.is_edp = true,
.aux_cfg = edp_phy_aux_cfg_v4,
.vco_div_cfg = edp_phy_vco_div_cfg_v4,
- .swing_pre_emph_cfg = &edp_phy_swing_pre_emph_cfg,
+ .dp_swing_pre_emph_cfg = &dp_phy_swing_pre_emph_cfg,
+ .edp_swing_pre_emph_cfg = &edp_phy_swing_pre_emph_cfg,
.ver_ops = &qcom_edp_phy_ops_v4,
};
@@ -745,7 +765,8 @@ static const struct phy_ver_ops qcom_edp_phy_ops_v6 = {
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,
+ .dp_swing_pre_emph_cfg = &dp_phy_swing_pre_emph_cfg,
+ .edp_swing_pre_emph_cfg = &edp_phy_swing_pre_emph_cfg,
.ver_ops = &qcom_edp_phy_ops_v6,
};
@@ -924,7 +945,8 @@ static const struct phy_ver_ops qcom_edp_phy_ops_v8 = {
static struct qcom_edp_phy_cfg glymur_phy_cfg = {
.aux_cfg = edp_phy_aux_cfg_v8,
.vco_div_cfg = edp_phy_vco_div_cfg_v8,
- .swing_pre_emph_cfg = &edp_phy_swing_pre_emph_cfg,
+ .dp_swing_pre_emph_cfg = &dp_phy_swing_pre_emph_cfg_v8,
+ .edp_swing_pre_emph_cfg = &edp_phy_swing_pre_emph_cfg,
.ver_ops = &qcom_edp_phy_ops_v8,
};
@@ -942,7 +964,7 @@ static int qcom_edp_phy_power_on(struct phy *phy)
if (ret)
return ret;
- if (edp->cfg->swing_pre_emph_cfg && !edp->is_edp)
+ if (edp->cfg->edp_swing_pre_emph_cfg && !edp->is_edp)
ldo_config = 0x1;
writel(ldo_config, edp->tx0 + TXn_LDO_CONFIG);
--
2.43.0
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH v4 1/5] phy: qcom: edp: Unify generic DP/eDP swing and pre-emphasis tables
From: Yongxing Mou @ 2026-04-22 6:01 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Stephen Boyd, Bjorn Andersson
Cc: linux-arm-msm, linux-phy, linux-kernel, Yongxing Mou, stable,
Konrad Dybcio
In-Reply-To: <20260422-edp_phy-v4-0-c38bef2d027b@oss.qualcomm.com>
The current eDP and DP swing/pre-emphasis tables do not match the HPG
requirements for the supported platforms, correct the table accordingly.
The generic tables which can be shared as follows:
DP mode：
-sa8775p/sc7280/sc8280xp/x1e80100
-glymur
-sc8180x
eDP mode(low vdiff):
-glymur/sa8775p/sc8280xp/x1e80100
-sc7280
-sc8180x
The proper tables for SC8180X and SC7280 will be added in a later patch,
since they need separate table.
Cc: stable@vger.kernel.org
Fixes: f199223cb490 ("phy: qcom: Introduce new eDP PHY driver")
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com>
---
drivers/phy/qualcomm/phy-qcom-edp.c | 41 +++++++++----------------------------
1 file changed, 10 insertions(+), 31 deletions(-)
diff --git a/drivers/phy/qualcomm/phy-qcom-edp.c b/drivers/phy/qualcomm/phy-qcom-edp.c
index 7372de05a0b8..2af3fd63832f 100644
--- a/drivers/phy/qualcomm/phy-qcom-edp.c
+++ b/drivers/phy/qualcomm/phy-qcom-edp.c
@@ -116,17 +116,17 @@ struct qcom_edp {
};
static const u8 dp_swing_hbr_rbr[4][4] = {
- { 0x08, 0x0f, 0x16, 0x1f },
+ { 0x07, 0x0f, 0x16, 0x1f },
{ 0x11, 0x1e, 0x1f, 0xff },
{ 0x16, 0x1f, 0xff, 0xff },
{ 0x1f, 0xff, 0xff, 0xff }
};
static const u8 dp_pre_emp_hbr_rbr[4][4] = {
- { 0x00, 0x0d, 0x14, 0x1a },
+ { 0x00, 0x0e, 0x15, 0x1a },
{ 0x00, 0x0e, 0x15, 0xff },
{ 0x00, 0x0e, 0xff, 0xff },
- { 0x03, 0xff, 0xff, 0xff }
+ { 0x04, 0xff, 0xff, 0xff }
};
static const u8 dp_swing_hbr2_hbr3[4][4] = {
@@ -158,7 +158,7 @@ static const u8 edp_swing_hbr_rbr[4][4] = {
};
static const u8 edp_pre_emp_hbr_rbr[4][4] = {
- { 0x05, 0x12, 0x17, 0x1d },
+ { 0x05, 0x11, 0x17, 0x1d },
{ 0x05, 0x11, 0x18, 0xff },
{ 0x06, 0x11, 0xff, 0xff },
{ 0x00, 0xff, 0xff, 0xff }
@@ -172,10 +172,10 @@ static const u8 edp_swing_hbr2_hbr3[4][4] = {
};
static const u8 edp_pre_emp_hbr2_hbr3[4][4] = {
- { 0x08, 0x11, 0x17, 0x1b },
- { 0x00, 0x0c, 0x13, 0xff },
- { 0x05, 0x10, 0xff, 0xff },
- { 0x00, 0xff, 0xff, 0xff }
+ { 0x0c, 0x15, 0x19, 0x1e },
+ { 0x0b, 0x15, 0x19, 0xff },
+ { 0x0e, 0x14, 0xff, 0xff },
+ { 0x0d, 0xff, 0xff, 0xff }
};
static const struct qcom_edp_swing_pre_emph_cfg edp_phy_swing_pre_emph_cfg = {
@@ -193,27 +193,6 @@ static const u8 edp_phy_vco_div_cfg_v4[4] = {
0x01, 0x01, 0x02, 0x00,
};
-static const u8 edp_pre_emp_hbr_rbr_v5[4][4] = {
- { 0x05, 0x11, 0x17, 0x1d },
- { 0x05, 0x11, 0x18, 0xff },
- { 0x06, 0x11, 0xff, 0xff },
- { 0x00, 0xff, 0xff, 0xff }
-};
-
-static const u8 edp_pre_emp_hbr2_hbr3_v5[4][4] = {
- { 0x0c, 0x15, 0x19, 0x1e },
- { 0x0b, 0x15, 0x19, 0xff },
- { 0x0e, 0x14, 0xff, 0xff },
- { 0x0d, 0xff, 0xff, 0xff }
-};
-
-static const struct qcom_edp_swing_pre_emph_cfg edp_phy_swing_pre_emph_cfg_v5 = {
- .swing_hbr_rbr = &edp_swing_hbr_rbr,
- .swing_hbr3_hbr2 = &edp_swing_hbr2_hbr3,
- .pre_emphasis_hbr_rbr = &edp_pre_emp_hbr_rbr_v5,
- .pre_emphasis_hbr3_hbr2 = &edp_pre_emp_hbr2_hbr3_v5,
-};
-
static const u8 edp_phy_aux_cfg_v5[DP_AUX_CFG_SIZE] = {
0x00, 0x13, 0xa4, 0x00, 0x0a, 0x26, 0x0a, 0x03, 0x37, 0x03, 0x02, 0x02, 0x00,
};
@@ -564,7 +543,7 @@ static const struct qcom_edp_phy_cfg sa8775p_dp_phy_cfg = {
.is_edp = false,
.aux_cfg = edp_phy_aux_cfg_v5,
.vco_div_cfg = edp_phy_vco_div_cfg_v4,
- .swing_pre_emph_cfg = &edp_phy_swing_pre_emph_cfg_v5,
+ .swing_pre_emph_cfg = &edp_phy_swing_pre_emph_cfg,
.ver_ops = &qcom_edp_phy_ops_v4,
};
@@ -945,7 +924,7 @@ static const struct phy_ver_ops qcom_edp_phy_ops_v8 = {
static struct qcom_edp_phy_cfg glymur_phy_cfg = {
.aux_cfg = edp_phy_aux_cfg_v8,
.vco_div_cfg = edp_phy_vco_div_cfg_v8,
- .swing_pre_emph_cfg = &edp_phy_swing_pre_emph_cfg_v5,
+ .swing_pre_emph_cfg = &edp_phy_swing_pre_emph_cfg,
.ver_ops = &qcom_edp_phy_ops_v8,
};
--
2.43.0
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH v4 0/5] phy: qcom: edp: Add DP/eDP switch for phys
From: Yongxing Mou @ 2026-04-22 6:01 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Stephen Boyd, Bjorn Andersson
Cc: linux-arm-msm, linux-phy, linux-kernel, Yongxing Mou, stable,
Konrad Dybcio, Dmitry Baryshkov
Currently the PHY selects the DP/eDP configuration tables in a fixed way,
choosing the table when enable. This driver has known issues:
1. The selected table does not match the actual platform mode.
2. It cannot support both modes at the same time.
As discussed here[1], this series:
1. Cleans up duplicated and incorrect tables based on the HPG.
2. Fixes the LDO programming error in eDP mode.
3. Adds DP/eDP mode switching support.
Note: x1e80100/sa8775p/sc7280/SC8280XP have been tested, while
glymur/sc8180x have not been tested.
[1] https://lore.kernel.org/all/20260119-klm_dpphy-v2-1-52252190940b@oss.qualcomm.com/
Signed-off-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com>
---
Changes in v4:
- Splite changes.[Dmitry]
- Add sc8180x tables in a single chagne.[Dmitry][Konrad]
- Link to v3: https://lore.kernel.org/r/20260302-edp_phy-v3-0-ca8888d793b0@oss.qualcomm.com
Changes in v3:
- Rebase to next-20260224.[Dmitry]
- Only enable TX1 LDO when lane counts > 2.[Konrad]
- Link to v2: https://lore.kernel.org/all/20260213-edp_phy-v2-0-43c40976435e@oss.qualcomm.com/
Changes in v2:
- Combine the third patch with the first one.[Dmitry]
- Fix code formatting issues.[Konrad][Dmitry]
- Update the commit message description.[Dmitry][Konrad]
- Fix kodiak swing/pre_emp table values.[Konrad]
---
Yongxing Mou (5):
phy: qcom: edp: Unify generic DP/eDP swing and pre-emphasis tables
phy: qcom: edp: Add eDP/DP mode switch support
phy: qcom: edp: Add SC7280/SC8180X swing/pre-emphasis tables
phy: qcom: edp: Fix AUX_CFG8 programming for DP mode
phy: qcom: edp: Add PHY-specific LDO config for eDP low vdiff
drivers/phy/qualcomm/phy-qcom-edp.c | 221 ++++++++++++++++++++++++++++--------
1 file changed, 173 insertions(+), 48 deletions(-)
---
base-commit: bee6ea30c48788e18348309f891ed8afbf7702ac
change-id: 20260205-edp_phy-1eca3ed074c0
Best regards,
--
Yongxing Mou <yongxing.mou@oss.qualcomm.com>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v3 1/2] phy: qcom: edp: Add eDP/DP mode switch support
From: Dmitry Baryshkov @ 2026-04-21 15:43 UTC (permalink / raw)
To: Yongxing Mou
Cc: Vinod Koul, Neil Armstrong, Stephen Boyd, Bjorn Andersson,
linux-arm-msm, linux-phy, linux-kernel, stable
In-Reply-To: <f27b39fc-a6c5-4450-93bc-babb7d6dd9a5@oss.qualcomm.com>
On Tue, Apr 21, 2026 at 10:32:49AM +0800, Yongxing Mou wrote:
>
>
> On 4/21/2026 2:32 AM, Dmitry Baryshkov wrote:
> > On Mon, Apr 20, 2026 at 08:47:09PM +0800, Yongxing Mou wrote:
> > >
> > >
> > > On 3/20/2026 2:36 PM, Dmitry Baryshkov wrote:
> > > > On Mon, Mar 02, 2026 at 04:28:29PM +0800, Yongxing Mou wrote:
> > > > > The eDP PHY supports both eDP&DP modes, each requires a different table.
> > > > > The current driver doesn't fully support every combo PHY mode and use
> > > > > either the eDP or DP table when enable the platform. In addition, some
> > > > > platforms mismatch between the mode and the table where DP mode uses
> > > > > the eDP table or eDP mode use the DP table.
> > > > >
> > > > > Clean up and correct the tables for currently supported platforms based on
> > > > > the HPG specification.
> > > > >
> > > > > Here lists the tables can be reused across current platforms.
> > > > > DP mode：
> > > > > -sa8775p/sc7280/sc8280xp/x1e80100
> > > > > -glymur
> > > > > eDP mode(low vdiff):
> > > >
> > > > Separate question: should we extend phy_configure_dp_opts with the
> > > > low/high vdiff? Is there a point in providing the ability to toggle
> > > > between low vdiff and high vdiff?
> > > >
> > > Emm ,i haven't found any platform using high vdiff so far, and I'm not clear
> > > in which cases switching between low and high vdiff would be needed.
> >
> > From my (maybe incorrect) understanding of eDP B.3, the high vs low
> > vdiff selection should be based on the cable length.
> >
> Thanks for the explanation. Maybe we can add this when we really need it.
> > >
> > > > > -glymur/sa8775p/sc8280xp/x1e80100
> > > > > -sc7280
> > > >
> > > > I understand your wish to perform all the changes in a single patch, but
> > > > there is one problem with that. Consider this patch regresses one of the
> > > > platforms (I'm looking at Kodiak and SC8180X as they get the biggest set
> > > > of changes). It would be almost impossible to separate, which particular
> > > > change caused the regression. I'd suggest splitting this patch into a
> > > > set of more atomic changes. E.g. the AUX_CFG8 is definitely a separate
> > > > change. Writing swing / pre_emph tables on Kodiak and SC8180X is a
> > > > separate change (or two). Switching each of the platforms to the
> > > > corrected set of tables ideally also should come as a separate change,
> > > > so that in case of a regression the issue would be easier to identify.
> > > >
> > > Thank for point this, will separate the change.
> > > I mostly overlooked SC8180X here, since I assumed it shares the same PHY as
> > > SC7280. However, they are using different PHY sub‑versions. Will add proper
> > > support for it in the next version.
> >
> > Thanks!
> >
> Emm, one more question.. Based on Konard's comments, should I split this
> patch, and send a new revision, or post a new SC8180X patch on top of these
> two existing patches?
Please split this commit into logical chunks, as I wrote before. SC8180X
would be one of those patches.
> > > > >
> > > > > Cc: stable@vger.kernel.org
> > > > > Fixes: f199223cb490 ("phy: qcom: Introduce new eDP PHY driver")
> > > > > Signed-off-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com>
> > > > > ---
> > > > > drivers/phy/qualcomm/phy-qcom-edp.c | 90 ++++++++++++++++++++++---------------
> > > > > 1 file changed, 53 insertions(+), 37 deletions(-)
--
With best wishes
Dmitry
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v5 0/6] phy: realtek: usb2: support for RTL9607C USB2 PHY
From: Rustam Adilov @ 2026-04-21 14:17 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Stanley Chang, linux-phy, devicetree, linux-kernel
In-Reply-To: <20260421-courageous-rigorous-angelfish-97a51f@quoll>
On 2026-04-21 07:09, Krzysztof Kozlowski wrote:
> On Tue, Apr 21, 2026 at 12:19:35AM +0500, Rustam Adilov wrote:
>> This patch series for Realtek USB2 PHY driver adds support for RTL9607C
>> USB2 PHY.
>>
>> RTL9607C is a big endian MIPS CPU which is quite far from RTD series SoCs
>> supported by realtek usb2 phy driver, but the phy initilization is found
>> to be very indentical in most areas.
>>
>> Most of the code was based on the Realtek's usb driver from the GPL tarball
>> in [1] and adjusted to fit into the realtek usb2 phy driver code format.
>>
>> The patch series was split into smaller patches that add/change something
>> in the driver that are not exactly related to RTL9607C and that also
>> helps for easier review. That also means, patch 5 depends on all the prior
>> patches that come before it.
>>
>> USB2 PHY on RTL9607C is primarly used for its internal OHCI/EHCI controllers.
>>
>> [1] - https://github.com/jameywine/GPL-for-GP3000/blob/main/linux-5.10.x/arch/mips/rtl9607c/usb.c
>>
>> ---
>> Changelog in v5:
>> Mostly addressing LLM review
>> - Patch 1
>> - changed int to u32 type for new_reg_req and vstatus_busy data fields.
>> - changed comments in rtk_phy_read/write from PHY_NEW_REG_REQ to phy_reg->new_reg_req.
>> - Patch 2
>> - explained readl/writel native endianess issue in more detail.
>> - explained why vstatus register doesn't need byte swapping.
>> - Patch 4
>> - moved reset_control_deassert to rtk_phy_init function to keep it outside of for loop.
>> - changed msleep(5) to usleep_range(5000, 6000).
>> - explained why reset_control_assert is not needed.
>> - Patch 5
>> - explained readl/writel native endianess issue here as well.
>> - explained why FORCE_DISCONNECT_REG doesn't need byte swapping.
>> - Link to v4: https://lore.kernel.org/linux-phy/20260406181228.25892-1-adilov@disroot.org/
>>
>> Changelog in v4:
>> - Patch 2
>> - moved the le variations of read/write functions to Patch 5 where it is actually used because
>> otherwise, it results in unused errors when only Patch 2 is applied.
>> - updated the commit message to to point the reason for le32 wrappers around readl/writel.
>> - Patch 3
>> - added "Reviewed by Krzysztof Kozlowski"
>
> Where?
Oi, it must have been lost in transmission because i added the tag manually to .patch after
format-patch command instead of adding it to commit message. So it disappeared in v5.
Sorry about that. Unintentional blunder on my part.
> Best regards,
> Krzysztof
Thanks,
Rustam
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH] dt-bindings: phy: qcom,sc8280xp-qmp-ufs-phy: Document Nord QMP UFS PHY
From: Shawn Guo @ 2026-04-21 13:30 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Vinod Koul, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Konrad Dybcio, Dmitry Baryshkov, Bartosz Golaszewski,
Deepti Jaggi, linux-phy, devicetree, linux-arm-msm, linux-kernel
In-Reply-To: <faa58e87-fb6f-4598-bfc4-b48b93bd0400@kernel.org>
On Mon, Apr 20, 2026 at 10:21:39AM +0200, Krzysztof Kozlowski wrote:
> On 20/04/2026 09:49, Shawn Guo wrote:
> > Add compatible for QMP UFS PHY on Qualcomm Nord SoC with a fallback
> > on qcom,sm8650-qmp-ufs-phy.
> >
> > Signed-off-by: Shawn Guo <shengchao.guo@oss.qualcomm.com>
> > ---
> > .../devicetree/bindings/phy/qcom,sc8280xp-qmp-ufs-phy.yaml | 4 ++++
> > 1 file changed, 4 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-ufs-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-ufs-phy.yaml
> > index 9616c736b6d4..cc3457d6aa3b 100644
> > --- a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-ufs-phy.yaml
> > +++ b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-ufs-phy.yaml
> > @@ -36,6 +36,10 @@ properties:
> > - enum:
> > - qcom,kaanapali-qmp-ufs-phy
> > - const: qcom,sm8750-qmp-ufs-phy
> > + - items:
> > + - enum:
> > + - qcom,nord-qmp-ufs-phy
> > + - const: qcom,sm8650-qmp-ufs-phy
>
> You do not need new entry, especially placed in incorrect order. Sort it
> and then you will see that you just duplicated it.
Indeed! I missed that. Thanks Krzysztof!
Shawn
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v3 1/2] phy: qcom: edp: Add eDP/DP mode switch support
From: Konrad Dybcio @ 2026-04-21 13:00 UTC (permalink / raw)
To: Yongxing Mou, Vinod Koul, Neil Armstrong, Stephen Boyd,
Bjorn Andersson
Cc: linux-arm-msm, linux-phy, linux-kernel, stable
In-Reply-To: <aad6a3a4-5050-467d-8ece-e83648d219d6@oss.qualcomm.com>
On 4/21/26 5:54 AM, Yongxing Mou wrote:
>
>
> On 4/20/2026 8:49 PM, Konrad Dybcio wrote:
>> On 4/20/26 2:48 PM, Yongxing Mou wrote:
>>>
>>>
>>> On 4/16/2026 5:34 PM, Konrad Dybcio wrote:
>>>> On 3/2/26 9:28 AM, Yongxing Mou wrote:
>>>>> The eDP PHY supports both eDP&DP modes, each requires a different table.
>>>>> The current driver doesn't fully support every combo PHY mode and use
>>>>> either the eDP or DP table when enable the platform. In addition, some
>>>>> platforms mismatch between the mode and the table where DP mode uses
>>>>> the eDP table or eDP mode use the DP table.
>>>>>
>>>>> Clean up and correct the tables for currently supported platforms based on
>>>>> the HPG specification.
>>>>>
>>>>> Here lists the tables can be reused across current platforms.
>>>>> DP mode：
>>>>> -sa8775p/sc7280/sc8280xp/x1e80100
>>>>> -glymur
>>>>> eDP mode(low vdiff):
>>>>> -glymur/sa8775p/sc8280xp/x1e80100
>>>>> -sc7280
>>>>>
>>>>> Cc: stable@vger.kernel.org
>>>>> Fixes: f199223cb490 ("phy: qcom: Introduce new eDP PHY driver")
>>>>> Signed-off-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com>
>>>>> ---
>>>>
>>>> I went through everything and all the sequences are OK.
>>>>
>>>> SC8180X will need changes, but it's already incorrect so this
>>>> doesn't necessarily affect it
>>>>
>>>> Thanks!
>>>>
>>>> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
>>>>
>>>> Konrad
>>> Thanks here.. I didn’t notice before that SC8180X is different from SC7280, and will correct it in the next version.
>>
>> Please make it another patch on top of these two, so that we don't have
>> to re-validate the existing diff
>>
>> Konrad
> Thanks very much for the validating this patch. Could you sync with Dmitry how i post next patch?... He suggest me to splite this patch...
Eh I guess he's right.. I think the following approach should be fine:
- take your current change
- split it up into smaller pieces (so that the resulting diff is the same)
- add a 8180 fixup on top
Konrad
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v5 3/6] dt-bindings: phy: realtek,usb2phy.yaml: extend for resets and RTL9607C support
From: Krzysztof Kozlowski @ 2026-04-21 7:10 UTC (permalink / raw)
To: Rustam Adilov
Cc: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Stanley Chang, linux-phy, devicetree, linux-kernel
In-Reply-To: <20260420191941.81834-4-adilov@disroot.org>
On Tue, Apr 21, 2026 at 12:19:38AM +0500, Rustam Adilov wrote:
> Add the "realtek,rtl9607-usb2phy" compatible for USB2 PHY on the RTL9607C
> SoC series.
>
> Add a resets property to properties to describe the usb2phy reset line.
>
> In RTL9607C, USB2 PHY reset line is from "IP Enable controller" which is
> multipurpose and handle activating various SoC peripherals.
>
> It is unclear whether RTD SoCs have something similar to that so set
> the resets to false for these devices.
>
> RTL9607C requires the "resets" to be specified so add the corresponding
> if check for the "realtek,rtl9607-usb2phy" compatible.
<form letter>
This is a friendly reminder during the review process.
It looks like you received a tag and forgot to add it.
If you do not know the process, here is a short explanation:
Please add Acked-by/Reviewed-by/Tested-by tags when posting new
versions of patchset, under or above your Signed-off-by tag, unless
patch changed significantly (e.g. new properties added to the DT
bindings). Tag is "received", when provided in a message replied to you
on the mailing list. Tools like b4 can help here. However, there's no
need to repost patches *only* to add the tags. The upstream maintainer
will do that for tags received on the version they apply.
Please read:
https://elixir.bootlin.com/linux/v6.12-rc3/source/Documentation/process/submitting-patches.rst#L577
If a tag was not added on purpose, please state in the patch changelog
or cover letter why and what changed.
</form letter>
Pay attention to the last part. Intentional dropping tag is the same as
"not adding".
Best regards,
Krzysztof
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v5 0/6] phy: realtek: usb2: support for RTL9607C USB2 PHY
From: Krzysztof Kozlowski @ 2026-04-21 7:09 UTC (permalink / raw)
To: Rustam Adilov
Cc: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Stanley Chang, linux-phy, devicetree, linux-kernel
In-Reply-To: <20260420191941.81834-1-adilov@disroot.org>
On Tue, Apr 21, 2026 at 12:19:35AM +0500, Rustam Adilov wrote:
> This patch series for Realtek USB2 PHY driver adds support for RTL9607C
> USB2 PHY.
>
> RTL9607C is a big endian MIPS CPU which is quite far from RTD series SoCs
> supported by realtek usb2 phy driver, but the phy initilization is found
> to be very indentical in most areas.
>
> Most of the code was based on the Realtek's usb driver from the GPL tarball
> in [1] and adjusted to fit into the realtek usb2 phy driver code format.
>
> The patch series was split into smaller patches that add/change something
> in the driver that are not exactly related to RTL9607C and that also
> helps for easier review. That also means, patch 5 depends on all the prior
> patches that come before it.
>
> USB2 PHY on RTL9607C is primarly used for its internal OHCI/EHCI controllers.
>
> [1] - https://github.com/jameywine/GPL-for-GP3000/blob/main/linux-5.10.x/arch/mips/rtl9607c/usb.c
>
> ---
> Changelog in v5:
> Mostly addressing LLM review
> - Patch 1
> - changed int to u32 type for new_reg_req and vstatus_busy data fields.
> - changed comments in rtk_phy_read/write from PHY_NEW_REG_REQ to phy_reg->new_reg_req.
> - Patch 2
> - explained readl/writel native endianess issue in more detail.
> - explained why vstatus register doesn't need byte swapping.
> - Patch 4
> - moved reset_control_deassert to rtk_phy_init function to keep it outside of for loop.
> - changed msleep(5) to usleep_range(5000, 6000).
> - explained why reset_control_assert is not needed.
> - Patch 5
> - explained readl/writel native endianess issue here as well.
> - explained why FORCE_DISCONNECT_REG doesn't need byte swapping.
> - Link to v4: https://lore.kernel.org/linux-phy/20260406181228.25892-1-adilov@disroot.org/
>
> Changelog in v4:
> - Patch 2
> - moved the le variations of read/write functions to Patch 5 where it is actually used because
> otherwise, it results in unused errors when only Patch 2 is applied.
> - updated the commit message to to point the reason for le32 wrappers around readl/writel.
> - Patch 3
> - added "Reviewed by Krzysztof Kozlowski"
Where?
Best regards,
Krzysztof
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v3 1/2] phy: qcom: edp: Add eDP/DP mode switch support
From: Yongxing Mou @ 2026-04-21 3:54 UTC (permalink / raw)
To: Konrad Dybcio, Vinod Koul, Neil Armstrong, Stephen Boyd,
Bjorn Andersson
Cc: linux-arm-msm, linux-phy, linux-kernel, stable
In-Reply-To: <e956b609-3e37-4c3c-9168-a50793722061@oss.qualcomm.com>
On 4/20/2026 8:49 PM, Konrad Dybcio wrote:
> On 4/20/26 2:48 PM, Yongxing Mou wrote:
>>
>>
>> On 4/16/2026 5:34 PM, Konrad Dybcio wrote:
>>> On 3/2/26 9:28 AM, Yongxing Mou wrote:
>>>> The eDP PHY supports both eDP&DP modes, each requires a different table.
>>>> The current driver doesn't fully support every combo PHY mode and use
>>>> either the eDP or DP table when enable the platform. In addition, some
>>>> platforms mismatch between the mode and the table where DP mode uses
>>>> the eDP table or eDP mode use the DP table.
>>>>
>>>> Clean up and correct the tables for currently supported platforms based on
>>>> the HPG specification.
>>>>
>>>> Here lists the tables can be reused across current platforms.
>>>> DP mode：
>>>> -sa8775p/sc7280/sc8280xp/x1e80100
>>>> -glymur
>>>> eDP mode(low vdiff):
>>>> -glymur/sa8775p/sc8280xp/x1e80100
>>>> -sc7280
>>>>
>>>> Cc: stable@vger.kernel.org
>>>> Fixes: f199223cb490 ("phy: qcom: Introduce new eDP PHY driver")
>>>> Signed-off-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com>
>>>> ---
>>>
>>> I went through everything and all the sequences are OK.
>>>
>>> SC8180X will need changes, but it's already incorrect so this
>>> doesn't necessarily affect it
>>>
>>> Thanks!
>>>
>>> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
>>>
>>> Konrad
>> Thanks here.. I didn’t notice before that SC8180X is different from SC7280, and will correct it in the next version.
>
> Please make it another patch on top of these two, so that we don't have
> to re-validate the existing diff
>
> Konrad
Thanks very much for the validating this patch. Could you sync with
Dmitry how i post next patch?... He suggest me to splite this patch...
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v3 1/2] phy: qcom: edp: Add eDP/DP mode switch support
From: Yongxing Mou @ 2026-04-21 2:32 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Vinod Koul, Neil Armstrong, Stephen Boyd, Bjorn Andersson,
linux-arm-msm, linux-phy, linux-kernel, stable
In-Reply-To: <vywmtt6p3itkrbnucahzvsh6hpwqbno7al5h5zrqdcf3cejyto@pr4of7o3zdeo>
On 4/21/2026 2:32 AM, Dmitry Baryshkov wrote:
> On Mon, Apr 20, 2026 at 08:47:09PM +0800, Yongxing Mou wrote:
>>
>>
>> On 3/20/2026 2:36 PM, Dmitry Baryshkov wrote:
>>> On Mon, Mar 02, 2026 at 04:28:29PM +0800, Yongxing Mou wrote:
>>>> The eDP PHY supports both eDP&DP modes, each requires a different table.
>>>> The current driver doesn't fully support every combo PHY mode and use
>>>> either the eDP or DP table when enable the platform. In addition, some
>>>> platforms mismatch between the mode and the table where DP mode uses
>>>> the eDP table or eDP mode use the DP table.
>>>>
>>>> Clean up and correct the tables for currently supported platforms based on
>>>> the HPG specification.
>>>>
>>>> Here lists the tables can be reused across current platforms.
>>>> DP mode：
>>>> -sa8775p/sc7280/sc8280xp/x1e80100
>>>> -glymur
>>>> eDP mode(low vdiff):
>>>
>>> Separate question: should we extend phy_configure_dp_opts with the
>>> low/high vdiff? Is there a point in providing the ability to toggle
>>> between low vdiff and high vdiff?
>>>
>> Emm ,i haven't found any platform using high vdiff so far, and I'm not clear
>> in which cases switching between low and high vdiff would be needed.
>
> From my (maybe incorrect) understanding of eDP B.3, the high vs low
> vdiff selection should be based on the cable length.
>
Thanks for the explanation. Maybe we can add this when we really need it.
>>
>>>> -glymur/sa8775p/sc8280xp/x1e80100
>>>> -sc7280
>>>
>>> I understand your wish to perform all the changes in a single patch, but
>>> there is one problem with that. Consider this patch regresses one of the
>>> platforms (I'm looking at Kodiak and SC8180X as they get the biggest set
>>> of changes). It would be almost impossible to separate, which particular
>>> change caused the regression. I'd suggest splitting this patch into a
>>> set of more atomic changes. E.g. the AUX_CFG8 is definitely a separate
>>> change. Writing swing / pre_emph tables on Kodiak and SC8180X is a
>>> separate change (or two). Switching each of the platforms to the
>>> corrected set of tables ideally also should come as a separate change,
>>> so that in case of a regression the issue would be easier to identify.
>>>
>> Thank for point this, will separate the change.
>> I mostly overlooked SC8180X here, since I assumed it shares the same PHY as
>> SC7280. However, they are using different PHY sub‑versions. Will add proper
>> support for it in the next version.
>
> Thanks!
>
Emm, one more question.. Based on Konard's comments, should I split this
patch, and send a new revision, or post a new SC8180X patch on top of
these two existing patches?
>>>>
>>>> Cc: stable@vger.kernel.org
>>>> Fixes: f199223cb490 ("phy: qcom: Introduce new eDP PHY driver")
>>>> Signed-off-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com>
>>>> ---
>>>> drivers/phy/qualcomm/phy-qcom-edp.c | 90 ++++++++++++++++++++++---------------
>>>> 1 file changed, 53 insertions(+), 37 deletions(-)
>>>>
>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox