* [PATCH v6 04/23] phy: rockchip: usbdp: Fix devm_clk_bulk_get_all check
From: Sebastian Reichel @ 2026-06-19 15:28 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Heiko Stuebner, Frank Wang,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: Andy Yan, Dmitry Baryshkov, Yubing Zhang, Alexey Charkov,
linux-phy, linux-arm-kernel, linux-rockchip, linux-kernel, kernel,
devicetree, Sebastian Reichel, Sashiko
In-Reply-To: <20260619-rockchip-usbdp-cleanup-v6-0-3bb1f54b3f35@collabora.com>
If devm_clk_bulk_get_all() returns -EPROBE_DEFER, it is replaced with
-ENODEV, permanently failing the driver probe instead of allowing it to
defer. Avoid masking the error code to fix the issue.
This effectively drops returning -ENODEV in case no clocks are being
described in DT. This special case will now be handled by the follow-up
check searching for "refclk" and exit with -EINVAL.
None of this will be hit in practice, since the driver is only used by
RK3588 and RK3576 - on these platforms the DT is validated to contain
the clocks and the clock driver is force probed early. Thus there is
no need to backport this.
Fixes: 2f70bbddeb45 ("phy: rockchip: add usbdp combo phy driver")
Reported-by: Sashiko <sashiko-bot@kernel.org>
Closes: https://lore.kernel.org/linux-phy/20260612164107.C7DB21F000E9@smtp.kernel.org/
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
---
drivers/phy/rockchip/phy-rockchip-usbdp.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/phy/rockchip/phy-rockchip-usbdp.c b/drivers/phy/rockchip/phy-rockchip-usbdp.c
index 12dfdd470a78..2845a012eafc 100644
--- a/drivers/phy/rockchip/phy-rockchip-usbdp.c
+++ b/drivers/phy/rockchip/phy-rockchip-usbdp.c
@@ -427,8 +427,8 @@ static int rk_udphy_clk_init(struct rk_udphy *udphy, struct device *dev)
int i;
udphy->num_clks = devm_clk_bulk_get_all(dev, &udphy->clks);
- if (udphy->num_clks < 1)
- return -ENODEV;
+ if (udphy->num_clks < 0)
+ return udphy->num_clks;
/* used for configure phy reference clock frequency */
for (i = 0; i < udphy->num_clks; i++) {
--
2.53.0
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH v6 03/23] phy: rockchip: usbdp: Do not lose USB3 PHY status
From: Sebastian Reichel @ 2026-06-19 15:28 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Heiko Stuebner, Frank Wang,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: Andy Yan, Dmitry Baryshkov, Yubing Zhang, Alexey Charkov,
linux-phy, linux-arm-kernel, linux-rockchip, linux-kernel, kernel,
devicetree, Sebastian Reichel
In-Reply-To: <20260619-rockchip-usbdp-cleanup-v6-0-3bb1f54b3f35@collabora.com>
By default (i.e. without manually enabling runtime PM) DWC3 requests the
USB3 PHY once and keeps it enabled all the time. When DisplayPort is
being requested later on, a mode change is needed. This re-initializes
the PHY. During re-initialization the status variable has incorrectly
been cleared, which means the tracking information for USB3 is lost.
This is not an immediate problem, since the DP side keeps the PHY
enabled. But once DP is toggled off, the whole PHY will be disabled.
This is a problem, because the USB side still needs it powered.
Fix things by not clearing the status flags.
Fixes: 2f70bbddeb45 ("phy: rockchip: add usbdp combo phy driver")
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
---
drivers/phy/rockchip/phy-rockchip-usbdp.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/phy/rockchip/phy-rockchip-usbdp.c b/drivers/phy/rockchip/phy-rockchip-usbdp.c
index a5ffdf7a6e76..12dfdd470a78 100644
--- a/drivers/phy/rockchip/phy-rockchip-usbdp.c
+++ b/drivers/phy/rockchip/phy-rockchip-usbdp.c
@@ -1008,7 +1008,6 @@ static int rk_udphy_power_on(struct rk_udphy *udphy, u8 mode)
rk_udphy_u3_port_disable(udphy, false);
udphy->mode_change = false;
} else if (udphy->mode_change) {
- udphy->status = UDPHY_MODE_NONE;
if (udphy->mode == UDPHY_MODE_DP)
rk_udphy_u3_port_disable(udphy, true);
--
2.53.0
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH v6 01/23] dt-bindings: phy: rockchip-usbdp: add improved ports scheme
From: Sebastian Reichel @ 2026-06-19 15:28 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Heiko Stuebner, Frank Wang,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: Andy Yan, Dmitry Baryshkov, Yubing Zhang, Alexey Charkov,
linux-phy, linux-arm-kernel, linux-rockchip, linux-kernel, kernel,
devicetree, Sebastian Reichel
In-Reply-To: <20260619-rockchip-usbdp-cleanup-v6-0-3bb1f54b3f35@collabora.com>
Currently the Rockchip USBDP PHY is missing a documented port scheme.
Meanwhile upstream RK3588 DTS files are a bit messy and use different
port schemes. The upstream USBDP PHY Linux kernel driver does not yet
parse the ports at all and thus does not create any implicit ABI either.
But with the current mess it is not possible to properly support USB-C
DP AltMode. Thus this introduces a proper port scheme following roughly
the ports design of the Qualcomm QMP USB4-USB3-DP PHY controller binding
with a slight difference that there is an additional port for the
USB-C SBU port as the Rockchip USB-DP PHY also contains the SBU mux.
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
---
.../bindings/phy/phy-rockchip-usbdp.yaml | 23 ++++++++++++++++++++++
1 file changed, 23 insertions(+)
diff --git a/Documentation/devicetree/bindings/phy/phy-rockchip-usbdp.yaml b/Documentation/devicetree/bindings/phy/phy-rockchip-usbdp.yaml
index 8b7059d5b182..f728acf057e4 100644
--- a/Documentation/devicetree/bindings/phy/phy-rockchip-usbdp.yaml
+++ b/Documentation/devicetree/bindings/phy/phy-rockchip-usbdp.yaml
@@ -114,6 +114,29 @@ properties:
A port node to link the PHY to a TypeC controller for the purpose of
handling orientation switching.
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ Output endpoint of the PHY for USB (or DP when configured into 4 lane
+ mode), which should point to the superspeed port of a USB connector.
+
+ port@1:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: Incoming endpoint from the USB controller
+
+ port@2:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: Incoming endpoint from the DisplayPort controller
+
+ port@3:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ Output endpoint of the PHY for DP, which should either point to the
+ SBU port of a USB-C connector or a DisplayPort connector input port.
+
required:
- compatible
- reg
--
2.53.0
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* Re: [PATCH v2 2/4] dt-bindings: phy: qcom,msm8998-qmp-usb3-phy: Add support for Shikra
From: Konrad Dybcio @ 2026-06-19 15:12 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Krishna Kurapati, Krzysztof Kozlowski, Neil Armstrong, Vinod Koul,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Xiangxu Yin, Johan Hovold, Loic Poulain, Kathiravan Thirumoorthy,
linux-arm-msm, linux-phy, devicetree, linux-kernel
In-Reply-To: <5vfu3h66pelbhzyfqnagxg2j6r5mn7jupx3nmewt2zsggfa6sj@ttqr775cybxa>
On 6/12/26 10:00 AM, Dmitry Baryshkov wrote:
> On Wed, Jun 10, 2026 at 03:36:20PM +0200, Konrad Dybcio wrote:
>> On 5/17/26 9:16 PM, Dmitry Baryshkov wrote:
>>> On Fri, May 15, 2026 at 09:06:21PM +0530, Krishna Kurapati wrote:
>>>>
>>>>
>>>> On 5/14/2026 8:07 PM, Krzysztof Kozlowski wrote:
>>>>> On 14/05/2026 08:22, Krishna Kurapati wrote:
>>>>>>
>>>>>>
>>>>>> On 5/14/2026 12:26 AM, Krzysztof Kozlowski wrote:
>>>>>>> On 07/05/2026 13:37, Krishna Kurapati wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> On 5/5/2026 7:30 PM, Krzysztof Kozlowski wrote:
>>>>>>>>> On 05/05/2026 15:57, Krishna Kurapati wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 5/5/2026 6:59 PM, Krzysztof Kozlowski wrote:
>>>>>>>>>>> On 05/05/2026 15:27, Krishna Kurapati wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On 5/5/2026 4:22 PM, Krzysztof Kozlowski wrote:
>>>>>>>>>>>>> On 05/05/2026 12:49, Krzysztof Kozlowski wrote:
>>>>>>>>>>>>>> On Mon, May 04, 2026 at 10:36:57PM +0530, Krishna Kurapati wrote:
>>>>>>>>>>>>>>> Declare the USB-C QMP PHY present on the Qualcomm Shikra platform.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Signed-off-by: Krishna Kurapati <krishna.kurapati@oss.qualcomm.com>
>>>>>>>>>>>>>>> ---
>>>>>>>>>>>>>>> .../devicetree/bindings/phy/qcom,msm8998-qmp-usb3-phy.yaml | 2 ++
>>>>>>>>>>>>>>> 1 file changed, 2 insertions(+)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
>>>>>>>>>>>>>
>>>>>>>>>>>>> ... and then I looked at the driver. So un-reviewed. Devices are clearly
>>>>>>>>>>>>> compatible. If not, explain what is not compatible.
>>>>>>>>>>>>>
>>>>>>>>>>>> Talos uses GCC_USB3_PRIM_PHY_AUX_CLK.
>>>>>>>>>>>>
>>>>>>>>>>>> In Shikra, we are using GCC_USB3_PRIM_PHY_COM_AUX_CLK. We don't have
>>>>>>>>>>>> GCC_USB3_PRIM_PHY_AUX_CLK.
>>>>>>>>>>>>
>>>>>>>>>>>> Hence, I didn't use a fallback compatible.
>>>>>>>>>>>
>>>>>>>>>>> This still explains nothing. How different clock makes interface for SW
>>>>>>>>>>> incompatible exactly?
>>>>>>>>>>>
>>>>>>>>>> So I went by the naming. AUX vs COM_AUX.
>>>>>>>>>
>>>>>>>>> The naming does not matter. If the clock is called
>>>>>>>>> "no_one_expects_spanish_inquisition", does that make software
>>>>>>>>> incompatible? Why would the name itself matter?
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Can I use a fallback compatible and in DT vote for "COM_AUX" clock with
>>>>>>>>>> clock-names mentioning "aux" ?
>>>>>>>>>
>>>>>>>>> I don't know, I asked what is different in software interface.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Hi Krzysztof,
>>>>>>>>
>>>>>>>> I checked with the hw team here and found out two things.
>>>>>>>>
>>>>>>>> 1. Shikra is a spinoff of Agatti and its sw interface (clocks used and
>>>>>>>> regulators used) is the same as agatti.
>>>>>>>>
>>>>>>>> 2. I thought we could use qcm2290 as a fallback since the phy register
>>>>>>>> init sequence is the same for Talos/Shikra/Agatti. The difference
>>>>>>>> between Talos and agatti when checked in the driver was the init load
>>>>>>>> settings. I checked with the hw team and they suggested using the init
>>>>>>>> load settings which talos was using.
>>>>>>>>
>>>>>>>> Hence both these compatibles (qcm2290 and qcs615) cannot be used as
>>>>>>>> fallback for Shikra.
>>>>>>>
>>>>>>> Then I do not understand why you are using qcs615_usb3phy_cfg for
>>>>>>> Shikra. You say that the initialization is different, but you use
>>>>>>> exactly the same initialization. So in a meaning of compatibility
>>>>>>> between hardware for Devicetree they are compatible.
>>>>>>>
>>>>>> Hi Krzysztof,
>>>>>>
>>>>>> There are 3 things:
>>>>>>
>>>>>> 1. Clocks used:
>>>>>> -> Talos supports AUX Clock since it supports DP over USB.
>>>>>> -> Agatti and Shikra use COM_AUX clock since they dont support DP over USB.
>>>>>>
>>>>>> 2. Phy register Init sequence - same for all 3 targets
>>>>>>
>>>>>> 3. Regulator init load:
>>>>>> -> Different for both Talos and Agatti
>>>>>> -> Recommendation is to use Talos regulator load values.
>>>>>>
>>>>>> SW interface wise, shikra is comaptible with agatti. If we use agatti as
>>>>>> fallback, we would end up using the platform data of Agatti where the
>>>>>> regulator init load is not suitable for Shikra. Hence not using Agatti
>>>>>> as fallback.
>>>>>>
>>>>>> Coming to driver changes, I used qcs615_cfg because it has required phy
>>>>>> register sequence and regulator init load as needed by shikra.
>>>>>
>>>>> So is it compatible with QCS615? If not, then something is incomplete or
>>>>> confusing. The driver uses the same software interface.
>>>>>
>>>> Sorry for the confusion. The Talos compatible represents the USB/DP PHY with
>>>> aux clock input, while Shikra is a USB-only PHY with com_aux input clock, so
>>>> the two PHYs are not compatible with each other.
>>>
>>> According to the memory map, there is an (unused) DP registers part
>>> right after the QMP USB3 PHY. So, sofware-wise it is compatible to
>>> Talos. Having the different clock input means different integration of
>>> the block rather than the differences in the hardware block.
>>>
>>> So, the block should be compatible to qcom,qcs615-qmp-usb3-dp-phy
>>
>> It should still carry its own compatible though, to let the driver
>> disallow powering up the DP part
>
> Why? The DP part is there, in the PHY, pretty much like it's present on
> most of USBC platforms. I assume it can be powered on. There is no
> point in it though as there is no DP controller (nor DP pins).
I wouldn't bet too much on that sub-block being fully silicon-validated
given its of no use as there isn't a DPTX onboard..
Konrad
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v8 1/2] dt-bindings: phy: qcom: Add CSI2 C-PHY/DPHY schema
From: Konrad Dybcio @ 2026-06-19 12:37 UTC (permalink / raw)
To: Dmitry Baryshkov, Vijay Kumar Tumati
Cc: Bryan O'Donoghue, Vladimir Zapolskiy, Bryan O'Donoghue,
Vinod Koul, Kishon Vijay Abraham I, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Neil Armstrong, linux-arm-msm,
linux-phy, linux-media, devicetree, linux-kernel
In-Reply-To: <qt2d2anvwlubaicwhw3rur7u47v4swqbctapcw5qek54f2yzdu@ljd46avkfgy4>
On 6/10/26 12:30 AM, Dmitry Baryshkov wrote:
> On Tue, Jun 09, 2026 at 12:20:56PM -0700, Vijay Kumar Tumati wrote:
>>
>>
>> On 6/9/2026 6:56 AM, Konrad Dybcio wrote:
>>> On 6/4/26 11:06 AM, Bryan O'Donoghue wrote:
>>>> On 04/06/2026 09:46, Vladimir Zapolskiy wrote:
>>>>> On 6/4/26 03:30, Bryan O'Donoghue wrote:
>>>>>> On 04/06/2026 01:07, Vladimir Zapolskiy wrote:
>>>>>>> On 6/4/26 00:18, Bryan O'Donoghue wrote:
>>>>>>>> On 03/06/2026 21:51, Vladimir Zapolskiy wrote:
>>>>>>>>>> Actually, one more thing, Why isn't TITAN TOP GDSC here?>>>> +
>>>>>>>>> If CSIPHYs are true subdevices under the umbrella CAMSS device and well
>>>>>>>>> described as subnodes, then likely none of power domains are needed
>>> [...]
>>>
>>>>> CCI is not described as a child of CAMSS, here the situation is different.
>>>> CCI probably_should_ be a child of CAMSS given the design we are going for here.
>>> Yes
>> As of now CCI is an independently usable device to configure any I2C slave
>> that is connected to it. If it is to become a child of camss, it should be
>> self contained, as it is now, and camss may have to become a simple-mfd to
>> make the CCI independently probe-able? In which case, we may want to follow
>> the same protocol for all other sub devices like PHY. However, if we do not
>> have any requirement to use CCI independently (who can confirm this?),
>
> Uno-Q uses CCI as a semi-independent i2c controller. There can be other
> similar designs.
CCI still physically lies within the camera subsystem and needs both the
TOP_GDSC and the AHB/CPAS clocks to be on.
devm_of_platform_populate() will ensure that subdevices will be probed.
simple-mfd is essentially a hack/shortcut to call that function for nodes
which aren't bound to drivers (e.g. because they represent something
without a top-level software interface, which is rarely true and why it
seems to be discouraged)
Konrad
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v2 3/3] phy: rockchip: phy-rockchip-inno-csidphy: add clock lane phase tuning
From: sashiko-bot @ 2026-06-19 9:26 UTC (permalink / raw)
To: Gerald Loacker
Cc: neil.armstrong, vkoul, robh, devicetree, olteanv, linux-phy,
conor+dt
In-Reply-To: <20260619-feature-mipi-csi-dphy-4k60-v2-3-323356c2cc2e@wolfvision.net>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] The macro `CSIDPHY_CLK_PHASE_DEFAULT` is defined but never used.
--
commit 47571c2082c0165537db96312865f3a9805e768d
Author: Gerald Loacker <gerald.loacker@wolfvision.net>
phy: rockchip: phy-rockchip-inno-csidphy: add clock lane phase tuning
This commit adds support for parsing the 'rockchip,clk-lane-phase' device
tree property to adjust the clock lane sampling phase. It enables
board-specific tuning to optimize link stability at high data rates, falling
back to hardware defaults if the property is absent.
> diff --git a/drivers/phy/rockchip/phy-rockchip-inno-csidphy.c b/drivers/phy/rockchip/phy-rockchip-inno-csidphy.c
> index 5281f8dea0ad3..3a15840e86cad 100644
> --- a/drivers/phy/rockchip/phy-rockchip-inno-csidphy.c
> +++ b/drivers/phy/rockchip/phy-rockchip-inno-csidphy.c
> @@ -69,6 +69,10 @@
> #define RK1808_CSIDPHY_CLK_CALIB_EN 0x168
> #define RK3568_CSIDPHY_CLK_CALIB_EN 0x168
>
> +#define CSIDPHY_LANE_CLK_3_PHASE 0x38
> +#define CSIDPHY_CLK_PHASE_MASK GENMASK(6, 4)
> +#define CSIDPHY_CLK_PHASE_DEFAULT 3
[Severity: Low]
Is this macro intended to be used somewhere?
It appears to be defined but never used, since the driver falls back to the
hardware default by initializing priv->clk_phase to -1 in
rockchip_inno_csidphy_probe() and conditionally skipping the register write in
rockchip_inno_csidphy_power_on():
if (priv->clk_phase >= 0) {
val = readl(priv->phy_base + CSIDPHY_LANE_CLK_3_PHASE);
...
}
Can CSIDPHY_CLK_PHASE_DEFAULT be safely removed?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260619-feature-mipi-csi-dphy-4k60-v2-0-323356c2cc2e@wolfvision.net?part=3
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v2 1/3] phy: rockchip: phy-rockchip-inno-csidphy: fix rk1808 hsfreq table
From: sashiko-bot @ 2026-06-19 9:23 UTC (permalink / raw)
To: Gerald Loacker
Cc: olteanv, vkoul, conor+dt, linux-phy, robh, devicetree,
neil.armstrong
In-Reply-To: <20260619-feature-mipi-csi-dphy-4k60-v2-1-323356c2cc2e@wolfvision.net>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] Valid lowest frequency ranges are incorrectly rejected because `hsfreq == 0x00` is treated as an error by the `if (!hsfreq)` check.
--
commit d7a2518a95d2ab7b8f2baea0da9f35646ffb6136
Author: Gerald Loacker <gerald.loacker@wolfvision.net>
phy: rockchip: phy-rockchip-inno-csidphy: fix rk1808 hsfreq table
The rk1808 hsfreq table previously capped at 2499 Mbps, preventing a data rate
of exactly 2500 Mbps. This commit extends the final entry to 2500 Mbps to
fully support this rate, which is also essential for RK3588 as it reuses
this array.
> diff --git a/drivers/phy/rockchip/phy-rockchip-inno-csidphy.c b/drivers/phy/rockchip/phy-rockchip-inno-csidphy.c
> index c79fb53d8ee5c..5281f8dea0ad3 100644
> --- a/drivers/phy/rockchip/phy-rockchip-inno-csidphy.c
> +++ b/drivers/phy/rockchip/phy-rockchip-inno-csidphy.c
> @@ -170,7 +170,7 @@ static const struct hsfreq_range rk1808_mipidphy_hsfreq_ranges[] = {
> { 299, 0x06}, { 399, 0x08}, { 499, 0x0b}, { 599, 0x0e},
> { 699, 0x10}, { 799, 0x12}, { 999, 0x16}, {1199, 0x1e},
> {1399, 0x23}, {1599, 0x2d}, {1799, 0x32}, {1999, 0x37},
> - {2199, 0x3c}, {2399, 0x41}, {2499, 0x46}
> + {2199, 0x3c}, {2399, 0x41}, {2500, 0x46}
> };
>
> static const struct hsfreq_range rk3326_mipidphy_hsfreq_ranges[] = {
[Severity: High]
This isn't a bug introduced by this patch, but does the configuration logic
reject valid low frequency ranges?
Looking at rk3326_mipidphy_hsfreq_ranges[], the first entry configures low
data rates using 0x00:
{ 109, 0x00 }, ...
In rockchip_inno_csidphy_configure(), hsfreq is initialized to 0 and validated
with:
for (i = 0; i < drv_data->num_hsfreq_ranges; i++) {
if (drv_data->hsfreq_ranges[i].range_h >= data_rate_mbps) {
hsfreq = drv_data->hsfreq_ranges[i].cfg_bit;
break;
}
}
if (!hsfreq)
return -EINVAL;
When a low data rate is requested (e.g., <= 109 Mbps for rk3326), the loop
correctly assigns hsfreq = 0x00. However, the subsequent if (!hsfreq) check
treats this valid configuration as an error state and returns -EINVAL.
This same pattern appears in drivers/phy/rockchip/phy-rockchip-dphy-rx0.c
during rk_dphy_configure() where low-speed configurations are similarly
rejected.
Could the validation check be updated to differentiate between an uninitialized
value and a valid 0x00 configuration?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260619-feature-mipi-csi-dphy-4k60-v2-0-323356c2cc2e@wolfvision.net?part=1
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* [PATCH v2 3/3] phy: rockchip: phy-rockchip-inno-csidphy: add clock lane phase tuning
From: Gerald Loacker @ 2026-06-19 9:13 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Heiko Stuebner, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: linux-phy, linux-arm-kernel, linux-rockchip, linux-kernel,
devicetree, Gerald Loacker
In-Reply-To: <20260619-feature-mipi-csi-dphy-4k60-v2-0-323356c2cc2e@wolfvision.net>
At high data rates like 4K60 (2500 Mbps), such as when using an
LT6911GXD bridge chip on an RK3588 board, fixed default timing parameters
can cause signal integrity issues and clock-data recovery failures.
The driver currently lacks a mechanism to adjust the clock lane sampling
phase to compensate for board-specific trace variations.
Resolve this by parsing and applying the optional 'rockchip,clk-lane-phase'
device tree property. This enables board-specific tuning of the clock
lane sampling phase in ~40 ps steps (range 0-7) to optimize link
stability. If the property is absent, the driver falls back to the
hardware default.
Signed-off-by: Gerald Loacker <gerald.loacker@wolfvision.net>
---
drivers/phy/rockchip/phy-rockchip-inno-csidphy.c | 25 ++++++++++++++++++++++++
1 file changed, 25 insertions(+)
diff --git a/drivers/phy/rockchip/phy-rockchip-inno-csidphy.c b/drivers/phy/rockchip/phy-rockchip-inno-csidphy.c
index 5281f8dea0ad3..3a15840e86cad 100644
--- a/drivers/phy/rockchip/phy-rockchip-inno-csidphy.c
+++ b/drivers/phy/rockchip/phy-rockchip-inno-csidphy.c
@@ -69,6 +69,10 @@
#define RK1808_CSIDPHY_CLK_CALIB_EN 0x168
#define RK3568_CSIDPHY_CLK_CALIB_EN 0x168
+#define CSIDPHY_LANE_CLK_3_PHASE 0x38
+#define CSIDPHY_CLK_PHASE_MASK GENMASK(6, 4)
+#define CSIDPHY_CLK_PHASE_DEFAULT 3
+
#define RESETS_MAX 2
/*
@@ -151,6 +155,7 @@ struct rockchip_inno_csidphy {
const struct dphy_drv_data *drv_data;
struct phy_configure_opts_mipi_dphy config;
u8 hsfreq;
+ int clk_phase;
};
static inline void write_grf_reg(struct rockchip_inno_csidphy *priv,
@@ -304,6 +309,13 @@ static int rockchip_inno_csidphy_power_on(struct phy *phy)
rockchip_inno_csidphy_ths_settle(priv, priv->hsfreq,
CSIDPHY_LANE_THS_SETTLE(i));
+ if (priv->clk_phase >= 0) {
+ val = readl(priv->phy_base + CSIDPHY_LANE_CLK_3_PHASE);
+ val &= ~CSIDPHY_CLK_PHASE_MASK;
+ val |= FIELD_PREP(CSIDPHY_CLK_PHASE_MASK, priv->clk_phase);
+ writel(val, priv->phy_base + CSIDPHY_LANE_CLK_3_PHASE);
+ }
+
write_grf_reg(priv, GRF_DPHY_CSIPHY_CLKLANE_EN, 0x1);
write_grf_reg(priv, GRF_DPHY_CSIPHY_DATALANE_EN,
GENMASK(priv->config.lanes - 1, 0));
@@ -449,6 +461,7 @@ static int rockchip_inno_csidphy_probe(struct platform_device *pdev)
struct device *dev = &pdev->dev;
struct phy_provider *phy_provider;
struct phy *phy;
+ u32 phase;
int ret;
priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
@@ -464,6 +477,18 @@ static int rockchip_inno_csidphy_probe(struct platform_device *pdev)
return -ENODEV;
}
+ priv->clk_phase = -1;
+ if (device_property_read_u32(dev, "rockchip,clk-lane-phase",
+ &phase) == 0) {
+ if (phase >= BIT(3)) {
+ dev_err(dev,
+ "rockchip,clk-lane-phase %u out of range [0,7]\n",
+ phase);
+ return -EINVAL;
+ }
+ priv->clk_phase = phase;
+ }
+
priv->grf = syscon_regmap_lookup_by_phandle(dev->of_node,
"rockchip,grf");
if (IS_ERR(priv->grf)) {
--
2.34.1
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH v2 2/3] dt-bindings: phy: rockchip-inno-csi-dphy: add rockchip,clk-lane-phase property
From: Gerald Loacker @ 2026-06-19 9:13 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Heiko Stuebner, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: linux-phy, linux-arm-kernel, linux-rockchip, linux-kernel,
devicetree, Gerald Loacker
In-Reply-To: <20260619-feature-mipi-csi-dphy-4k60-v2-0-323356c2cc2e@wolfvision.net>
Add support for the optional rockchip,clk-lane-phase device tree property
to allow board-specific tuning of the clock lane sampling phase for
improved signal integrity across supported data rates.
Signed-off-by: Gerald Loacker <gerald.loacker@wolfvision.net>
---
.../devicetree/bindings/phy/rockchip-inno-csi-dphy.yaml | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/Documentation/devicetree/bindings/phy/rockchip-inno-csi-dphy.yaml b/Documentation/devicetree/bindings/phy/rockchip-inno-csi-dphy.yaml
index 03950b3cad08c..010950a8a8856 100644
--- a/Documentation/devicetree/bindings/phy/rockchip-inno-csi-dphy.yaml
+++ b/Documentation/devicetree/bindings/phy/rockchip-inno-csi-dphy.yaml
@@ -56,6 +56,15 @@ properties:
description:
Some additional phy settings are access through GRF regs.
+ rockchip,clk-lane-phase:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 7
+ description:
+ Clock lane sampling phase selection (hardware tap index 0–7). Each step
+ corresponds to an approximately 40 ps delay as described in the hardware
+ specification.
+
required:
- compatible
- reg
--
2.34.1
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH v2 1/3] phy: rockchip: phy-rockchip-inno-csidphy: fix rk1808 hsfreq table
From: Gerald Loacker @ 2026-06-19 9:13 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Heiko Stuebner, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: linux-phy, linux-arm-kernel, linux-rockchip, linux-kernel,
devicetree, Gerald Loacker
In-Reply-To: <20260619-feature-mipi-csi-dphy-4k60-v2-0-323356c2cc2e@wolfvision.net>
The rk1808 hsfreq table capped at 2499 Mbps, preventing a data rate of
exactly 2500 Mbps. Extend the final entry to 2500 Mbps to support this
rate.
This is essential for RK3588 reusing this array and fully supporting
rates up to 2500 Mbps.
Fixes: bd1f775d6027 ("phy/rockchip: add Innosilicon-based CSI dphy")
Signed-off-by: Gerald Loacker <gerald.loacker@wolfvision.net>
---
drivers/phy/rockchip/phy-rockchip-inno-csidphy.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/phy/rockchip/phy-rockchip-inno-csidphy.c b/drivers/phy/rockchip/phy-rockchip-inno-csidphy.c
index c79fb53d8ee5c..5281f8dea0ad3 100644
--- a/drivers/phy/rockchip/phy-rockchip-inno-csidphy.c
+++ b/drivers/phy/rockchip/phy-rockchip-inno-csidphy.c
@@ -170,7 +170,7 @@ static const struct hsfreq_range rk1808_mipidphy_hsfreq_ranges[] = {
{ 299, 0x06}, { 399, 0x08}, { 499, 0x0b}, { 599, 0x0e},
{ 699, 0x10}, { 799, 0x12}, { 999, 0x16}, {1199, 0x1e},
{1399, 0x23}, {1599, 0x2d}, {1799, 0x32}, {1999, 0x37},
- {2199, 0x3c}, {2399, 0x41}, {2499, 0x46}
+ {2199, 0x3c}, {2399, 0x41}, {2500, 0x46}
};
static const struct hsfreq_range rk3326_mipidphy_hsfreq_ranges[] = {
--
2.34.1
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH v2 0/3] phy: rockchip: inno-csidphy: fix 2500 Mbps support and add clock lane phase tuning
From: Gerald Loacker @ 2026-06-19 9:13 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Heiko Stuebner, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: linux-phy, linux-arm-kernel, linux-rockchip, linux-kernel,
devicetree, Gerald Loacker
This series fixes and extends the Rockchip Innosilicon CSI D-PHY driver
to support data rates up to 2500 Mbps and adds optional board-specific
clock lane phase tuning for signal integrity.
Patch 1 fixes an off-by-one error in the rk1808 hsfreq range table:
the final entry was capped at 2499 Mbps, causing a rejection of the
maximum supported rate of 2500 Mbps.
Patches 2 and 3 add an optional rockchip,clk-lane-phase device tree
property that allows tuning the clock lane sampling phase in ~40 ps
steps to compensate for board-level signal integrity variations.
---
Changes in v2:
- dt-bindings: improve rockchip,clk-lane-phase description wording
(Conor Dooley)
- Link to v1: https://patch.msgid.link/20260617-feature-mipi-csi-dphy-4k60-v1-0-4611ff00b0ff@wolfvision.net
To: Vinod Koul <vkoul@kernel.org>
To: Neil Armstrong <neil.armstrong@linaro.org>
To: Heiko Stuebner <heiko@sntech.de>
To: Rob Herring <robh@kernel.org>
To: Krzysztof Kozlowski <krzk+dt@kernel.org>
To: Conor Dooley <conor+dt@kernel.org>
Cc: linux-phy@lists.infradead.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-rockchip@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Cc: devicetree@vger.kernel.org
---
Gerald Loacker (3):
phy: rockchip: phy-rockchip-inno-csidphy: fix rk1808 hsfreq table
dt-bindings: phy: rockchip-inno-csi-dphy: add rockchip,clk-lane-phase property
phy: rockchip: phy-rockchip-inno-csidphy: add clock lane phase tuning
.../bindings/phy/rockchip-inno-csi-dphy.yaml | 9 ++++++++
drivers/phy/rockchip/phy-rockchip-inno-csidphy.c | 27 +++++++++++++++++++++-
2 files changed, 35 insertions(+), 1 deletion(-)
---
base-commit: 8cd9520d35a6c38db6567e97dd93b1f11f185dc6
change-id: 20260617-feature-mipi-csi-dphy-4k60-9879c3d1fe4f
Best regards,
--
Gerald Loacker <gerald.loacker@wolfvision.net>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v2 3/4] PCI: qcom: Add link retention support
From: Krishna Chaitanya Chundru @ 2026-06-19 5:00 UTC (permalink / raw)
To: Konrad Dybcio, Vinod Koul, Neil Armstrong, Philipp Zabel,
Jingoo Han, Manivannan Sadhasivam, Lorenzo Pieralisi,
Krzysztof Wilczyński, Rob Herring, Bjorn Helgaas
Cc: linux-arm-msm, linux-phy, linux-kernel, linux-pci, Qiang Yu
In-Reply-To: <8bb365dc-25b4-4fe3-8ad9-1f110bad2417@oss.qualcomm.com>
On 6/16/2026 5:38 PM, Konrad Dybcio wrote:
> On 5/21/26 2:56 PM, Krishna Chaitanya Chundru wrote:
>> Some platforms keep the PCIe link active across bootloader and kernel
>> handoff. Reinitializing the controller and toggling PERST# in such cases is
>> unnecessary when the driver does not need to retrain the link.
>>
>> Introduce link_retain in both qcom_pcie_cfg and qcom_pcie to indicate when
>> link retention is supported. During initialization, check the LTSSM state;
>> if the link is already in L0 or L1 idle and LTSSM is enabled, set
>> link_retain and skip controller reset, PERST# toggling, and other post-
>> init steps.
>>
>> If the current link speed or lane width does not satisfy the constraints
>> specified by max-link-speed or num-lanes in the device tree, fall back to
>> normal initialization and retrain the link instead of retaining it.
>>
>> Configure the DBI and ATU base addresses in the retention path, since the
>> bootloader may use different base addresses than those provided by the
>> device tree.
>>
>> Also fix the -EPROBE_DEFER error handling path to return 0 instead of
>> propagating the error, avoiding unnecessary cleanup when probe deferral is
>> requested.
>>
>> Tested-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
>> Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
>> ---
>> drivers/pci/controller/dwc/pcie-designware.h | 1 +
>> drivers/pci/controller/dwc/pcie-qcom.c | 62 +++++++++++++++++++++++++---
>> 2 files changed, 58 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/pci/controller/dwc/pcie-designware.h b/drivers/pci/controller/dwc/pcie-designware.h
>> index 3e69ef60165b..be6c4abf31e8 100644
>> --- a/drivers/pci/controller/dwc/pcie-designware.h
>> +++ b/drivers/pci/controller/dwc/pcie-designware.h
>> @@ -450,6 +450,7 @@ struct dw_pcie_rp {
>> bool ecam_enabled;
>> bool native_ecam;
>> bool skip_l23_ready;
>> + bool link_retain;
>> };
>>
>> struct dw_pcie_ep_ops {
>> diff --git a/drivers/pci/controller/dwc/pcie-qcom.c b/drivers/pci/controller/dwc/pcie-qcom.c
>> index bfe873cbf44f..b061eaa227b3 100644
>> --- a/drivers/pci/controller/dwc/pcie-qcom.c
>> +++ b/drivers/pci/controller/dwc/pcie-qcom.c
>> @@ -253,12 +253,14 @@ struct qcom_pcie_ops {
>> * @override_no_snoop: Override NO_SNOOP attribute in TLP to enable cache
>> * snooping
>> * @firmware_managed: Set if the Root Complex is firmware managed
>> + * @link_retain: Set if controller supports retaining link from bootloader
>> */
>> struct qcom_pcie_cfg {
>> const struct qcom_pcie_ops *ops;
>> bool override_no_snoop;
>> bool firmware_managed;
>> bool no_l0s;
>> + bool link_retain;
>> };
>>
>> struct qcom_pcie_perst {
>> @@ -960,6 +962,42 @@ static int qcom_pcie_get_resources_2_7_0(struct qcom_pcie *pcie)
>> return 0;
>> }
>>
>> +/*
>> + * Determine whether the link established by the bootloader can be reused.
>> + *
>> + * Reuse the existing link only if its current speed and lane count match
>> + * the max-link-speed and num-lanes specified in Device Tree; otherwise,
>> + * retrain the link.
>> + */
>> +static bool qcom_pcie_check_link_retain(struct qcom_pcie *pcie)
>> +{
>> + u32 cap, speed, val, ltssm, width;
>> + struct dw_pcie *pci = pcie->pci;
>> + u8 offset;
>> +
>> + val = readl(pcie->parf + PARF_LTSSM);
>> + ltssm = val & 0x1f;
>> + if ((val & LTSSM_EN) &&
>> + (ltssm == DW_PCIE_LTSSM_L0 || ltssm == DW_PCIE_LTSSM_L1_IDLE)) {
>> + qcom_pcie_configure_dbi_atu_base(pcie);
>> +
>> + offset = dw_pcie_find_capability(pci, PCI_CAP_ID_EXP);
>> + cap = dw_pcie_readl_dbi(pci, offset + PCI_EXP_LNKCAP);
>> + speed = FIELD_GET(PCI_EXP_LNKCAP_SLS, cap);
>> + width = dw_pcie_link_get_max_link_width(pci);
>> +
>> + if (pci->max_link_speed > 0 && speed > pci->max_link_speed)
> I think I raised this concern already, but this goes against what
> max-link-speed is supposed to do, i.e. this will not retrain the link if
> the bootloader had initialized the link to a speed faster than what the
> DT requested
sorry for the miss, it should be speed < pci->max_link_speed same for width
check also it should be width < pci->num_lanes I will correct it next version.
- Krishna Chaitanya.
>> + return false;
>> +
>> + if (pci->num_lanes > 0 && width > pci->num_lanes)
>> + return false;
> Similarly, this should be ==
>
> Konrad
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v6 3/4] phy: ti-pipe3: Fix EPROBE_DEFER handling for clock resources
From: sashiko-bot @ 2026-06-19 3:12 UTC (permalink / raw)
To: Hongling Zeng; +Cc: neil.armstrong, olteanv, linux-phy, vkoul
In-Reply-To: <20260619030214.1779043-4-zenghongling@kylinos.cn>
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
New issues:
- [Medium] Missing `dev_err_probe()` when propagating `-EPROBE_DEFER` causes kernel log spam.
Pre-existing issues:
- [High] Clock refcount leak on power-down timeout in `ti_pipe3_exit()`.
- [High] Unreliable jiffies polling loop in DPLL wait lock logic may falsely fail due to preemption.
--
commit 89eeca270e66e8da376c4a66e5ffebb70d29ee84
Author: Hongling Zeng <zenghongling@kylinos.cn>
phy: ti-pipe3: Fix EPROBE_DEFER handling for clock resources
This commit updates the clock retrieval logic in ti_pipe3_get_clk() to
properly propagate -EPROBE_DEFER and other error codes. It fixes an issue
where devm_clk_get() failures for sysclk were masked as -EINVAL, and updates
SATA refclk to use devm_clk_get_optional() so that deferrals are not ignored.
> diff --git a/drivers/phy/ti/phy-ti-pipe3.c b/drivers/phy/ti/phy-ti-pipe3.c
> --- a/drivers/phy/ti/phy-ti-pipe3.c
> +++ b/drivers/phy/ti/phy-ti-pipe3.c
[ ... ]
> @@ -608,14 +608,20 @@ static int ti_pipe3_get_clk(struct ti_pipe3 *phy)
> /*
> * refclk is optional for SATA PHY to support older DTBs, but
> * required for other modes. Use devm_clk_get_optional() for SATA
> * which returns NULL for -ENOENT, allowing us to propagate all
> * other errors including -EPROBE_DEFER.
> */
> if (phy->mode == PIPE3_MODE_SATA)
> phy->refclk = devm_clk_get_optional(dev, "refclk");
> else
> phy->refclk = devm_clk_get(dev, "refclk");
> +
> if (IS_ERR(phy->refclk)) {
> dev_err(dev, "unable to get refclk\n");
> - /* older DTBs have missing refclk in SATA PHY
> - * so don't bail out in case of SATA PHY.
> - */
> - if (phy->mode != PIPE3_MODE_SATA)
> - return PTR_ERR(phy->refclk);
> + return PTR_ERR(phy->refclk);
> }
[Severity: Medium]
Since PTR_ERR() can now return -EPROBE_DEFER, will this dev_err() call spam
the kernel log on every probe deferral?
Should this be updated to use dev_err_probe() instead, which gracefully
handles the deferral and suppresses the spam?
[ ... ]
> @@ -632,7 +638,7 @@ static int ti_pipe3_get_clk(struct ti_pipe3 *phy)
> phy->sys_clk = devm_clk_get(dev, "sysclk");
> if (IS_ERR(phy->sys_clk)) {
> dev_err(dev, "unable to get sysclk\n");
> - return -EINVAL;
> + return PTR_ERR(phy->sys_clk);
> }
> }
[Severity: Medium]
Similarly, does this dev_err() need to be replaced with dev_err_probe() to
prevent log spam when sysclk defers?
While reviewing this driver, I also noticed a couple of related items:
drivers/phy/ti/phy-ti-pipe3.c:ti_pipe3_exit() {
...
if (!(val & PLL_TICOPWDN) || !(val & PLL_LDOPWDN)) {
dev_err(phy->dev, "Failed to power down: PLL_STATUS 0x%x\n",
val);
return -EBUSY;
}
...
}
[Severity: High]
This is a pre-existing issue, but does this early return bypass the final
ti_pipe3_disable_clocks(phy) cleanup?
If the PLL LDO and Oscillator fail to power down within the timeout, it
appears the reference counts for wkupclk, refclk, and div_clk will leak.
If initialization is later retried, would the refcount increase
indefinitely, leaving the clocks permanently enabled?
drivers/phy/ti/phy-ti-pipe3.c:ti_pipe3_dpll_wait_lock() {
...
do {
cpu_relax();
val = ti_pipe3_readl(phy->pll_ctrl_base, PLL_STATUS);
if (val & PLL_LOCK)
return 0;
} while (!time_after(jiffies, timeout));
dev_err(phy->dev, "DPLL failed to lock\n");
return -EBUSY;
}
[Severity: High]
This is also a pre-existing issue, but can this polling loop falsely fail
due to preemption?
If the thread is preempted or interrupted after reading PLL_STATUS but
before evaluating time_after() for a duration exceeding the timeout, it
looks like it will terminate and return -EBUSY even if the hardware
successfully locked during the preemption interval.
Could this be fixed by converting it to use readl_poll_timeout(), which
ensures a final check is made after the timeout condition?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260619030214.1779043-1-zenghongling@kylinos.cn?part=3
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* [PATCH v6 2/4] phy: ti: pipe3: Fix clock resource leak on probe errors
From: Hongling Zeng @ 2026-06-19 3:02 UTC (permalink / raw)
To: vkoul, neil.armstrong, johan, kishon, rogerq
Cc: linux-phy, linux-kernel, zhongling0719, Hongling Zeng
In-Reply-To: <20260619030214.1779043-1-zenghongling@kylinos.cn>
When devm_phy_create() or devm_of_phy_provider_register() fails,
the refclk that was enabled earlier is not disabled, causing a
resource leak.
Fix this by adding an error handling path to disable the clock
when these functions fail.
Fixes: 234738ea3390 ("phy: ti-pipe3: move clk initialization to a separate function")
Signed-off-by: Hongling Zeng <zenghongling@kylinos.cn>
---
Change in v2:
-Add pm_runtime_disable() in error path (reported by Sashiko AI).
---
change in v3:
-Fix unbalanced clock disable by checking clk_prepare_enable()return value and
setting sata_refclk_enabledonly on success.
-Fix error path teardown order to match ti_pipe3_remove()(disable clock before
disabling runtime PM).
---
change in v4:
-Fix the patch version
---
Change in v5:
-Add Fix ignored clock enable return value in init patch
---
Change in v6:
-Fix all clock leak paths comprehensively:
-PCIe syscon update failure path
-SATA DPLL lock check path (also fix incorrect return logic)
-SATA errata path in ti_pipe3_exit()
---
drivers/phy/ti/phy-ti-pipe3.c | 26 ++++++++++++++++++++++----
1 file changed, 22 insertions(+), 4 deletions(-)
diff --git a/drivers/phy/ti/phy-ti-pipe3.c b/drivers/phy/ti/phy-ti-pipe3.c
index b8c055893742..2d36fe4c4218 100644
--- a/drivers/phy/ti/phy-ti-pipe3.c
+++ b/drivers/phy/ti/phy-ti-pipe3.c
@@ -834,21 +834,39 @@ static int ti_pipe3_probe(struct platform_device *pdev)
*/
if (phy->mode == PIPE3_MODE_SATA) {
if (!IS_ERR(phy->refclk)) {
- clk_prepare_enable(phy->refclk);
+ ret = clk_prepare_enable(phy->refclk);
+ if (ret) {
+ dev_err(dev, "Failed to enable refclk %d\n", ret);
+ goto err_pm_disable;
+ }
phy->sata_refclk_enabled = true;
}
}
generic_phy = devm_phy_create(dev, NULL, &ops);
- if (IS_ERR(generic_phy))
- return PTR_ERR(generic_phy);
+ if (IS_ERR(generic_phy)) {
+ ret = PTR_ERR(generic_phy);
+ goto err_clk_disable;
+ }
phy_set_drvdata(generic_phy, phy);
ti_pipe3_power_off(generic_phy);
phy_provider = devm_of_phy_provider_register(dev, of_phy_simple_xlate);
- return PTR_ERR_OR_ZERO(phy_provider);
+ if (IS_ERR(phy_provider)) {
+ ret = PTR_ERR(phy_provider);
+ goto err_clk_disable;
+ }
+
+ return 0;
+
+err_clk_disable:
+ if (phy->sata_refclk_enabled && !IS_ERR(phy->refclk))
+ clk_disable_unprepare(phy->refclk);
+err_pm_disable:
+ pm_runtime_disable(dev);
+ return ret;
}
static void ti_pipe3_remove(struct platform_device *pdev)
--
2.25.1
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH v6 1/4] phy: ti-pipe3: Fix ignored clock enable return value in init
From: Hongling Zeng @ 2026-06-19 3:02 UTC (permalink / raw)
To: vkoul, neil.armstrong, johan, kishon, rogerq
Cc: linux-phy, linux-kernel, zhongling0719, Hongling Zeng, Sashiko AI
In-Reply-To: <20260619030214.1779043-1-zenghongling@kylinos.cn>
ti_pipe3_init() ignores the return value of ti_pipe3_enable_clocks(),
which can lead to:
1. Unclocked hardware access if clock enable fails
2. Unbalanced clock disables in error paths
ti_pipe3_enable_clocks() returns an error code when clock enable fails
and rolls back any partially enabled clocks. If we ignore this error
and continue, we access hardware without proper clocking, which can
cause bus errors.
Additionally, if we reach error paths later in the function and call
ti_pipe3_disable_clocks(), we'll be disabling already-disabled clocks,
causing unbalanced disable warnings.
Fix this by checking the return value of ti_pipe3_enable_clocks()
and returning early if it fails.
Fixes: 234738ea3390 ("phy: ti-pipe3: move clk initialization to a separate function")
Reported-by: Sashiko AI <sashiko@kernel.org>
Signed-off-by: Hongling Zeng <zenghongling@kylinos.cn>
---
Change in v5:
-Add Fix ignored clock enable return value in init patch
---
Change in v6:
-Fix all clock leak paths comprehensively
-PCIe syscon update failure path
-SATA DPLL lock check path (also fix incorrect return logic)
-SATA errata path in ti_pipe3_exit()
---
drivers/phy/ti/phy-ti-pipe3.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/phy/ti/phy-ti-pipe3.c b/drivers/phy/ti/phy-ti-pipe3.c
index b5543b5c674c..b8c055893742 100644
--- a/drivers/phy/ti/phy-ti-pipe3.c
+++ b/drivers/phy/ti/phy-ti-pipe3.c
@@ -500,7 +500,10 @@ static int ti_pipe3_init(struct phy *x)
u32 val;
int ret = 0;
- ti_pipe3_enable_clocks(phy);
+ ret = ti_pipe3_enable_clocks(phy);
+ if (ret)
+ return ret;
+
/*
* Set pcie_pcs register to 0x96 for proper functioning of phy
* as recommended in AM572x TRM SPRUHZ6, section 18.5.2.2, table
--
2.25.1
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH v6 4/4] phy: ti-pipe3: Fix clock leak in init error path
From: Hongling Zeng @ 2026-06-19 3:02 UTC (permalink / raw)
To: vkoul, neil.armstrong, johan, kishon, rogerq
Cc: linux-phy, linux-kernel, zhongling0719, Hongling Zeng, Sashiko AI,
stable
In-Reply-To: <20260619030214.1779043-1-zenghongling@kylinos.cn>
When regmap_update_bits() fails in ti_pipe3_init() for PCIe mode,
the function returns the error without calling ti_pipe3_disable_clocks().
This leaves the clocks permanently enabled since the PHY framework won't
invoke the .exit callback on init failure.
Fix this by adding proper clock cleanup in the PCIe error path, consistent
with how the DPLL program error path handles cleanup.
Fixes: 234738ea3390 ("phy: ti-pipe3: move clk initialization to a separate function")
Reported-by: Sashiko AI <sashiko@kernel.org>
Closes: https://lore.kernel.org/all/20260518023657.41852C2BCB0@smtp.kernel.org/
Signed-off-by: Hongling Zeng <zenghongling@kylinos.cn>
Cc: stable@vger.kernel.org
---
Change in v5:
-Add Fix ignored clock enable return value in init patch
---
Change in v6:
-Fix all clock leak paths comprehensively:
-PCIe syscon update failure path
-SATA DPLL lock check path
-SATA errata path in ti_pipe3_exit()
---
drivers/phy/ti/phy-ti-pipe3.c | 11 ++++++++---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/phy/ti/phy-ti-pipe3.c b/drivers/phy/ti/phy-ti-pipe3.c
index 9ec228c2a940..860058f31594 100644
--- a/drivers/phy/ti/phy-ti-pipe3.c
+++ b/drivers/phy/ti/phy-ti-pipe3.c
@@ -518,6 +518,8 @@ static int ti_pipe3_init(struct phy *x)
val = 0x96 << OMAP_CTRL_PCIE_PCS_DELAY_COUNT_SHIFT;
ret = regmap_update_bits(phy->pcs_syscon, phy->pcie_pcs_reg,
PCIE_PCS_MASK, val);
+ if (ret)
+ ti_pipe3_disable_clocks(phy);
return ret;
}
@@ -531,8 +533,9 @@ static int ti_pipe3_init(struct phy *x)
/* SATA has issues if re-programmed when locked */
val = ti_pipe3_readl(phy->pll_ctrl_base, PLL_STATUS);
- if ((val & PLL_LOCK) && phy->mode == PIPE3_MODE_SATA)
- return ret;
+ if ((val & PLL_LOCK) && phy->mode == PIPE3_MODE_SATA) {
+ return 0;
+ }
/* Program the DPLL */
ret = ti_pipe3_dpll_program(phy);
@@ -555,8 +558,10 @@ static int ti_pipe3_exit(struct phy *x)
/* If dpll_reset_syscon is not present we wont power down SATA DPLL
* due to Errata i783
*/
- if (phy->mode == PIPE3_MODE_SATA && !phy->dpll_reset_syscon)
+ if (phy->mode == PIPE3_MODE_SATA && !phy->dpll_reset_syscon) {
+ ti_pipe3_disable_clocks(phy);
return 0;
+ }
/* PCIe doesn't have internal DPLL */
if (phy->mode != PIPE3_MODE_PCIE) {
--
2.25.1
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH v6 3/4] phy: ti-pipe3: Fix EPROBE_DEFER handling for clock resources
From: Hongling Zeng @ 2026-06-19 3:02 UTC (permalink / raw)
To: vkoul, neil.armstrong, johan, kishon, rogerq
Cc: linux-phy, linux-kernel, zhongling0719, Hongling Zeng
In-Reply-To: <20260619030214.1779043-1-zenghongling@kylinos.cn>
ti_pipe3_get_clk() has two issues with -EPROBE_DEFER error handling:
1. When devm_clk_get() for sysclk fails, the function returns -EINVAL
instead of propagating the actual error code. This masks -EPROBE_DEFER
to -EINVAL, breaking the probe deferral mechanism and causing permanent
driver initialization failure on systems with non-deterministic probe
ordering.
2. For SATA PHY refclk, the function ignores all errors to support older
DTBs missing the refclk property. However, this incorrectly ignores
-EPROBE_DEFER as well, causing the driver to proceed without waiting
for the clock provider to become available.
Fix both issues:
- Return PTR_ERR(phy->sys_clk) instead of -EINVAL to propagate all
error codes including -EPROBE_DEFER
- Use devm_clk_get_optional() for SATA refclk to handle optional
clocks while propagating -EPROBE_DEFER and other errors
Fixes: a70143bbef6b ("drivers: phy: usb3/pipe3: Adapt pipe3 driver to Generic PHY Framework")
Fixes: 7f33912d2978 ("phy: ti-pipe3: Fix SATA across suspend/resume")
Signed-off-by: Hongling Zeng <zenghongling@kylinos.cn>
---
Change in v4:
-Merge refclk leak fix and EPROBE_DEFER fix into a single patch
-Use devm_clk_get_optional() for SATA refclk
-Drop manual -ENOENT handling
-Ensure error paths are fully symmetric
---
Change in v5:
-Add Fix ignored clock enable return value in init patch
---
Change in v6:
-Fix all clock leak paths comprehensively:
-PCIe syscon update failure path
-SATA DPLL lock check path (also fix incorrect return logic)
-SATA errata path in ti_pipe3_exit()
---
drivers/phy/ti/phy-ti-pipe3.c | 20 +++++++++++++-------
1 file changed, 13 insertions(+), 7 deletions(-)
diff --git a/drivers/phy/ti/phy-ti-pipe3.c b/drivers/phy/ti/phy-ti-pipe3.c
index 2d36fe4c4218..9ec228c2a940 100644
--- a/drivers/phy/ti/phy-ti-pipe3.c
+++ b/drivers/phy/ti/phy-ti-pipe3.c
@@ -608,14 +608,20 @@ static int ti_pipe3_get_clk(struct ti_pipe3 *phy)
struct clk *clk;
struct device *dev = phy->dev;
- phy->refclk = devm_clk_get(dev, "refclk");
+ /*
+ * refclk is optional for SATA PHY to support older DTBs, but
+ * required for other modes. Use devm_clk_get_optional() for SATA
+ * which returns NULL for -ENOENT, allowing us to propagate all
+ * other errors including -EPROBE_DEFER.
+ */
+ if (phy->mode == PIPE3_MODE_SATA)
+ phy->refclk = devm_clk_get_optional(dev, "refclk");
+ else
+ phy->refclk = devm_clk_get(dev, "refclk");
+
if (IS_ERR(phy->refclk)) {
dev_err(dev, "unable to get refclk\n");
- /* older DTBs have missing refclk in SATA PHY
- * so don't bail out in case of SATA PHY.
- */
- if (phy->mode != PIPE3_MODE_SATA)
- return PTR_ERR(phy->refclk);
+ return PTR_ERR(phy->refclk);
}
if (phy->mode != PIPE3_MODE_SATA) {
@@ -632,7 +638,7 @@ static int ti_pipe3_get_clk(struct ti_pipe3 *phy)
phy->sys_clk = devm_clk_get(dev, "sysclk");
if (IS_ERR(phy->sys_clk)) {
dev_err(dev, "unable to get sysclk\n");
- return -EINVAL;
+ return PTR_ERR(phy->sys_clk);
}
}
--
2.25.1
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH v6 0/4] phy: ti-pipe3: Fix clock resource handling issues
From: Hongling Zeng @ 2026-06-19 3:02 UTC (permalink / raw)
To: vkoul, neil.armstrong, johan, kishon, rogerq
Cc: linux-phy, linux-kernel, zhongling0719, Hongling Zeng
This patch series fixes multiple clock resource handling issues in the
ti-pipe3 PHY driver.
Patch 1 fixes a critical issue where ti_pipe3_init() was ignoring the
return value of ti_pipe3_enable_clocks(), which could lead to unclocked
hardware access and unbalanced clock disables.
Patch 2 fixes a clock resource leak when probe fails after enabling
the SATA refclk. The error path now properly disables the clock and
cleans up runtime PM resources.
Patch 3 fixes EPROBE_DEFER handling to prevent masking probe deferral
errors. It uses devm_clk_get_optional() for SATA refclk to properly
handle optional clocks while still propagating -EPROBE_DEFER and other
error codes.
Patch 4 fixes a clock leak in the init error path when regmap_update_bits()
fails in PCIe mode, adding proper clock cleanup consistent with other
error paths.
These fixes ensure proper resource cleanup on probe and init failures,
and prevent permanent driver initialization failures due to incorrect
error handling.
Change in v6:
- Fix all clock leak paths comprehensively
Changes in v5:
- Add patch to fix ignored clock enable return value in ti_pipe3_init()
- Improve error handling consistency across all paths
Changes in v4:
- Use devm_clk_get_optional() for SATA refclk
- Drop manual -ENOENT handling
Hongling Zeng (4):
phy: ti-pipe3: Fix ignored clock enable return value in init
phy: ti: pipe3: Fix clock resource leak on probe errors
phy: ti-pipe3: Fix EPROBE_DEFER handling for clock resources
phy: ti-pipe3: Fix clock leak in init error path
drivers/phy/ti/phy-ti-pipe3.c | 58 ++++++++++++++++++++++++++++--------
1 file changed, 46 insertions(+), 12 deletions(-)
--
2.25.1
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* [PATCH v3 4/4] phy: qcom: qmp-pcie: Add QMP PCIe PHY support for Hawi
From: Matthew Leung @ 2026-06-18 21:54 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, linux-phy, devicetree, linux-kernel, Matthew Leung
In-Reply-To: <20260618-hawi-phy-pcie-v3-0-3fa42ca45ea4@oss.qualcomm.com>
Add the QMP PCIe PHY support for the Gen3 x2 and Gen4 x1 PHY found on
the Hawi platform.
Signed-off-by: Matthew Leung <matthew.leung@oss.qualcomm.com>
---
drivers/phy/qualcomm/phy-qcom-qmp-pcie.c | 373 +++++++++++++++++++++++++++++++
1 file changed, 373 insertions(+)
diff --git a/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c b/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c
index fb66e2a97ce0..ca3a5d974422 100644
--- a/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c
+++ b/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c
@@ -118,6 +118,20 @@ static const unsigned int pciephy_v8_50_regs_layout[QPHY_LAYOUT_SIZE] = {
[QPHY_PCS_POWER_DOWN_CONTROL] = QPHY_V8_50_PCS_POWER_DOWN_CONTROL,
};
+static const unsigned int pciephy_v10_regs_layout[QPHY_LAYOUT_SIZE] = {
+ [QPHY_SW_RESET] = QPHY_V10_PCS_SW_RESET,
+ [QPHY_START_CTRL] = QPHY_V10_PCS_START_CONTROL,
+ [QPHY_PCS_STATUS] = QPHY_V10_PCS_PCS_STATUS1,
+ [QPHY_PCS_POWER_DOWN_CONTROL] = QPHY_V10_PCS_POWER_DOWN_CONTROL,
+};
+
+static const unsigned int pciephy_v10_60_regs_layout[QPHY_LAYOUT_SIZE] = {
+ [QPHY_SW_RESET] = QPHY_V10_60_PCS_SW_RESET,
+ [QPHY_START_CTRL] = QPHY_V10_60_PCS_START_CONTROL,
+ [QPHY_PCS_STATUS] = QPHY_V10_60_PCS_PCS_STATUS1,
+ [QPHY_PCS_POWER_DOWN_CONTROL] = QPHY_V10_60_PCS_POWER_DOWN_CONTROL,
+};
+
static const struct qmp_phy_init_tbl msm8998_pcie_serdes_tbl[] = {
QMP_PHY_INIT_CFG(QSERDES_V3_COM_BIAS_EN_CLKBUFLR_EN, 0x14),
QMP_PHY_INIT_CFG(QSERDES_V3_COM_CLK_SELECT, 0x30),
@@ -3222,6 +3236,287 @@ static const struct qmp_phy_init_tbl kaanapali_qmp_gen3x2_pcie_pcs_misc_tbl[] =
QMP_PHY_INIT_CFG(QPHY_PCIE_V8_PCS_POWER_STATE_CONFIG6, 0x1f),
};
+static const struct qmp_phy_init_tbl hawi_qmp_gen3x2_pcie_serdes_tbl[] = {
+ QMP_PHY_INIT_CFG(QSERDES_V10_COM_SSC_EN_CENTER, 0x01),
+ QMP_PHY_INIT_CFG(QSERDES_V10_COM_SSC_PER1, 0x62),
+ QMP_PHY_INIT_CFG(QSERDES_V10_COM_SSC_PER2, 0x02),
+ QMP_PHY_INIT_CFG(QSERDES_V10_COM_SSC_STEP_SIZE1_MODE0, 0xf8),
+ QMP_PHY_INIT_CFG(QSERDES_V10_COM_SSC_STEP_SIZE2_MODE0, 0x01),
+ QMP_PHY_INIT_CFG(QSERDES_V10_COM_SSC_STEP_SIZE1_MODE1, 0x93),
+ QMP_PHY_INIT_CFG(QSERDES_V10_COM_SSC_STEP_SIZE2_MODE1, 0x01),
+ QMP_PHY_INIT_CFG(QSERDES_V10_COM_CLK_ENABLE1, 0x90),
+ QMP_PHY_INIT_CFG(QSERDES_V10_COM_SYS_CLK_CTRL, 0x82),
+ QMP_PHY_INIT_CFG(QSERDES_V10_COM_PLL_IVCO, 0x07),
+ QMP_PHY_INIT_CFG(QSERDES_V10_COM_CP_CTRL_MODE0, 0x02),
+ QMP_PHY_INIT_CFG(QSERDES_V10_COM_CP_CTRL_MODE1, 0x02),
+ QMP_PHY_INIT_CFG(QSERDES_V10_COM_PLL_RCTRL_MODE0, 0x16),
+ QMP_PHY_INIT_CFG(QSERDES_V10_COM_PLL_RCTRL_MODE1, 0x16),
+ QMP_PHY_INIT_CFG(QSERDES_V10_COM_PLL_CCTRL_MODE0, 0x36),
+ QMP_PHY_INIT_CFG(QSERDES_V10_COM_PLL_CCTRL_MODE1, 0x36),
+ QMP_PHY_INIT_CFG(QSERDES_V10_COM_SYSCLK_EN_SEL, 0x08),
+ QMP_PHY_INIT_CFG(QSERDES_V10_COM_BG_TIMER, 0x0a),
+ QMP_PHY_INIT_CFG(QSERDES_V10_COM_LOCK_CMP_EN, 0x42),
+ QMP_PHY_INIT_CFG(QSERDES_V10_COM_LOCK_CMP1_MODE0, 0x04),
+ QMP_PHY_INIT_CFG(QSERDES_V10_COM_LOCK_CMP2_MODE0, 0x0d),
+ QMP_PHY_INIT_CFG(QSERDES_V10_COM_LOCK_CMP1_MODE1, 0x0a),
+ QMP_PHY_INIT_CFG(QSERDES_V10_COM_LOCK_CMP2_MODE1, 0x1a),
+ QMP_PHY_INIT_CFG(QSERDES_V10_COM_DEC_START_MODE0, 0x41),
+ QMP_PHY_INIT_CFG(QSERDES_V10_COM_DEC_START_MODE1, 0x34),
+ QMP_PHY_INIT_CFG(QSERDES_V10_COM_DIV_FRAC_START1_MODE0, 0xab),
+ QMP_PHY_INIT_CFG(QSERDES_V10_COM_DIV_FRAC_START2_MODE0, 0xaa),
+ QMP_PHY_INIT_CFG(QSERDES_V10_COM_DIV_FRAC_START3_MODE0, 0x01),
+ QMP_PHY_INIT_CFG(QSERDES_V10_COM_DIV_FRAC_START1_MODE1, 0x55),
+ QMP_PHY_INIT_CFG(QSERDES_V10_COM_DIV_FRAC_START2_MODE1, 0x55),
+ QMP_PHY_INIT_CFG(QSERDES_V10_COM_DIV_FRAC_START3_MODE1, 0x01),
+ QMP_PHY_INIT_CFG(QSERDES_V10_COM_VCO_TUNE_MAP, 0x14),
+ QMP_PHY_INIT_CFG(QSERDES_V10_COM_CLK_SELECT, 0x34),
+ QMP_PHY_INIT_CFG(QSERDES_V10_COM_HSCLK_SEL_1, 0x01),
+ QMP_PHY_INIT_CFG(QSERDES_V10_COM_CORECLK_DIV_MODE1, 0x04),
+ QMP_PHY_INIT_CFG(QSERDES_V10_COM_CMN_CONFIG_1, 0x16),
+ QMP_PHY_INIT_CFG(QSERDES_V10_COM_ADDITIONAL_MISC_3, 0x0f),
+ QMP_PHY_INIT_CFG(QSERDES_V10_COM_CORE_CLK_EN, 0xa0),
+};
+
+static const struct qmp_phy_init_tbl hawi_qmp_gen3x2_pcie_rx_tbl[] = {
+ QMP_PHY_INIT_CFG(QSERDES_V10_RX_DFE_CTLE_POST_CAL_OFFSET, 0x38),
+ QMP_PHY_INIT_CFG(QSERDES_V10_RX_GM_CAL, 0x11),
+ QMP_PHY_INIT_CFG(QSERDES_V10_RX_RX_MODE_00_HIGH, 0xbf),
+ QMP_PHY_INIT_CFG(QSERDES_V10_RX_RX_MODE_00_HIGH2, 0xbf),
+ QMP_PHY_INIT_CFG(QSERDES_V10_RX_RX_MODE_00_HIGH3, 0xb7),
+ QMP_PHY_INIT_CFG(QSERDES_V10_RX_RX_MODE_00_HIGH4, 0xec),
+ QMP_PHY_INIT_CFG(QSERDES_V10_RX_RX_MODE_00_LOW, 0x3f),
+ QMP_PHY_INIT_CFG(QSERDES_V10_RX_RX_MODE_01_HIGH, 0x09),
+ QMP_PHY_INIT_CFG(QSERDES_V10_RX_RX_MODE_01_HIGH2, 0x49),
+ QMP_PHY_INIT_CFG(QSERDES_V10_RX_RX_MODE_01_HIGH3, 0x1b),
+ QMP_PHY_INIT_CFG(QSERDES_V10_RX_RX_MODE_01_HIGH4, 0x9c),
+ QMP_PHY_INIT_CFG(QSERDES_V10_RX_RX_MODE_01_LOW, 0xd1),
+ QMP_PHY_INIT_CFG(QSERDES_V10_RX_RX_MODE_10_HIGH, 0x09),
+ QMP_PHY_INIT_CFG(QSERDES_V10_RX_RX_MODE_10_HIGH2, 0x49),
+ QMP_PHY_INIT_CFG(QSERDES_V10_RX_RX_MODE_10_HIGH3, 0x1b),
+ QMP_PHY_INIT_CFG(QSERDES_V10_RX_RX_MODE_10_HIGH4, 0x9c),
+ QMP_PHY_INIT_CFG(QSERDES_V10_RX_RX_MODE_10_LOW, 0xd1),
+ QMP_PHY_INIT_CFG(QSERDES_V10_RX_TX_ADAPT_PRE_THRESH1, 0x3e),
+ QMP_PHY_INIT_CFG(QSERDES_V10_RX_TX_ADAPT_PRE_THRESH2, 0x1e),
+ QMP_PHY_INIT_CFG(QSERDES_V10_RX_TX_ADAPT_POST_THRESH, 0xd2),
+ QMP_PHY_INIT_CFG(QSERDES_V10_RX_UCDR_FO_GAIN, 0x09),
+ QMP_PHY_INIT_CFG(QSERDES_V10_RX_UCDR_SO_GAIN, 0x05),
+ QMP_PHY_INIT_CFG(QSERDES_V10_RX_UCDR_SB2_THRESH1, 0x08),
+ QMP_PHY_INIT_CFG(QSERDES_V10_RX_UCDR_SB2_THRESH2, 0x08),
+ QMP_PHY_INIT_CFG(QSERDES_V10_RX_VGA_CAL_CNTRL2, 0x09),
+ QMP_PHY_INIT_CFG(QSERDES_V10_RX_SIGDET_ENABLES, 0x1c),
+ QMP_PHY_INIT_CFG(QSERDES_V10_RX_SIGDET_CNTRL, 0x60),
+ QMP_PHY_INIT_CFG(QSERDES_V10_RX_RX_IDAC_TSETTLE_LOW, 0x07),
+ QMP_PHY_INIT_CFG(QSERDES_V10_RX_SIGDET_CAL_TRIM, 0x08),
+};
+
+static const struct qmp_phy_init_tbl hawi_qmp_gen3x2_pcie_tx_tbl[] = {
+ QMP_PHY_INIT_CFG(QSERDES_V10_TX_LANE_MODE_1, 0x25),
+ QMP_PHY_INIT_CFG(QSERDES_V10_TX_LANE_MODE_3, 0x10),
+ QMP_PHY_INIT_CFG(QSERDES_V10_TX_LANE_MODE_4, 0x31),
+ QMP_PHY_INIT_CFG(QSERDES_V10_TX_LANE_MODE_5, 0x7d),
+ QMP_PHY_INIT_CFG(QSERDES_V10_TX_PI_QEC_CTRL, 0x02),
+ QMP_PHY_INIT_CFG(QSERDES_V10_TX_RES_CODE_LANE_OFFSET_RX, 0x09),
+ QMP_PHY_INIT_CFG(QSERDES_V10_TX_RES_CODE_LANE_OFFSET_TX, 0x14),
+};
+
+static const struct qmp_phy_init_tbl hawi_qmp_gen3x2_pcie_pcs_tbl[] = {
+ QMP_PHY_INIT_CFG(QPHY_V10_PCS_REFGEN_REQ_CONFIG1, 0x05),
+ QMP_PHY_INIT_CFG(QPHY_V10_PCS_RX_SIGDET_LVL, 0x77),
+ QMP_PHY_INIT_CFG(QPHY_V10_PCS_RATE_SLEW_CNTRL1, 0x0b),
+ QMP_PHY_INIT_CFG(QPHY_V10_PCS_EQ_CONFIG2, 0x0f),
+ QMP_PHY_INIT_CFG(QPHY_V10_PCS_PCS_TX_RX_CONFIG, 0x8c),
+ QMP_PHY_INIT_CFG(QPHY_V10_PCS_G12S1_TXDEEMPH_M6DB, 0x17),
+ QMP_PHY_INIT_CFG(QPHY_V10_PCS_G3S2_PRE_GAIN, 0x2e),
+};
+
+static const struct qmp_phy_init_tbl hawi_qmp_gen3x2_pcie_pcs_misc_tbl[] = {
+ QMP_PHY_INIT_CFG(QPHY_PCIE_V10_PCS_EQ_CONFIG1, 0x1e),
+ QMP_PHY_INIT_CFG(QPHY_PCIE_V10_PCS_RXEQEVAL_TIME, 0x27),
+ QMP_PHY_INIT_CFG(QPHY_PCIE_V10_PCS_POWER_STATE_CONFIG2, 0x1d),
+ QMP_PHY_INIT_CFG(QPHY_PCIE_V10_PCS_POWER_STATE_CONFIG4, 0x07),
+ QMP_PHY_INIT_CFG(QPHY_PCIE_V10_PCS_POWER_STATE_CONFIG6, 0x1f),
+ QMP_PHY_INIT_CFG(QPHY_PCIE_V10_PCS_ENDPOINT_REFCLK_DRIVE, 0xc1),
+ QMP_PHY_INIT_CFG(QPHY_PCIE_V10_PCS_OSC_DTCT_ACTIONS, 0x00),
+};
+
+static const struct qmp_phy_init_tbl hawi_qmp_gen4x1_pcie_serdes_tbl[] = {
+ QMP_PHY_INIT_CFG(QSERDES_V10_60_COM_SSC_STEP_SIZE1_MODE1, 0x93),
+ QMP_PHY_INIT_CFG(QSERDES_V10_60_COM_SSC_STEP_SIZE2_MODE1, 0x01),
+ QMP_PHY_INIT_CFG(QSERDES_V10_60_COM_CP_CTRL_MODE1, 0x06),
+ QMP_PHY_INIT_CFG(QSERDES_V10_60_COM_PLL_RCTRL_MODE1, 0x16),
+ QMP_PHY_INIT_CFG(QSERDES_V10_60_COM_PLL_CCTRL_MODE1, 0x36),
+ QMP_PHY_INIT_CFG(QSERDES_V10_60_COM_CORECLK_DIV_MODE1, 0x04),
+ QMP_PHY_INIT_CFG(QSERDES_V10_60_COM_LOCK_CMP1_MODE1, 0x0a),
+ QMP_PHY_INIT_CFG(QSERDES_V10_60_COM_LOCK_CMP2_MODE1, 0x1a),
+ QMP_PHY_INIT_CFG(QSERDES_V10_60_COM_DEC_START_MODE1, 0x34),
+ QMP_PHY_INIT_CFG(QSERDES_V10_60_COM_DIV_FRAC_START1_MODE1, 0x55),
+ QMP_PHY_INIT_CFG(QSERDES_V10_60_COM_DIV_FRAC_START2_MODE1, 0x55),
+ QMP_PHY_INIT_CFG(QSERDES_V10_60_COM_DIV_FRAC_START3_MODE1, 0x01),
+ QMP_PHY_INIT_CFG(QSERDES_V10_60_COM_HSCLK_SEL_1, 0x01),
+ QMP_PHY_INIT_CFG(QSERDES_V10_60_COM_SSC_STEP_SIZE1_MODE0, 0xf8),
+ QMP_PHY_INIT_CFG(QSERDES_V10_60_COM_SSC_STEP_SIZE2_MODE0, 0x01),
+ QMP_PHY_INIT_CFG(QSERDES_V10_60_COM_CP_CTRL_MODE0, 0x06),
+ QMP_PHY_INIT_CFG(QSERDES_V10_60_COM_PLL_RCTRL_MODE0, 0x16),
+ QMP_PHY_INIT_CFG(QSERDES_V10_60_COM_PLL_CCTRL_MODE0, 0x36),
+ QMP_PHY_INIT_CFG(QSERDES_V10_60_COM_CORECLK_DIV_MODE0, 0x0a),
+ QMP_PHY_INIT_CFG(QSERDES_V10_60_COM_LOCK_CMP1_MODE0, 0x04),
+ QMP_PHY_INIT_CFG(QSERDES_V10_60_COM_LOCK_CMP2_MODE0, 0x0d),
+ QMP_PHY_INIT_CFG(QSERDES_V10_60_COM_DEC_START_MODE0, 0x41),
+ QMP_PHY_INIT_CFG(QSERDES_V10_60_COM_DIV_FRAC_START1_MODE0, 0xab),
+ QMP_PHY_INIT_CFG(QSERDES_V10_60_COM_DIV_FRAC_START2_MODE0, 0xaa),
+ QMP_PHY_INIT_CFG(QSERDES_V10_60_COM_DIV_FRAC_START3_MODE0, 0x01),
+ QMP_PHY_INIT_CFG(QSERDES_V10_60_COM_HSCLK_HS_SWITCH_SEL_1, 0x00),
+ QMP_PHY_INIT_CFG(QSERDES_V10_60_COM_BG_TIMER, 0x0a),
+ QMP_PHY_INIT_CFG(QSERDES_V10_60_COM_SSC_PER1, 0x62),
+ QMP_PHY_INIT_CFG(QSERDES_V10_60_COM_SSC_PER2, 0x02),
+ QMP_PHY_INIT_CFG(QSERDES_V10_60_COM_BIAS_EN_CLKBUFLR_EN, 0x14),
+ QMP_PHY_INIT_CFG(QSERDES_V10_60_COM_CLK_ENABLE1, 0x90),
+ QMP_PHY_INIT_CFG(QSERDES_V10_60_COM_SYS_CLK_CTRL, 0x82),
+ QMP_PHY_INIT_CFG(QSERDES_V10_60_COM_PLL_IVCO, 0x0f),
+ QMP_PHY_INIT_CFG(QSERDES_V10_60_COM_SYSCLK_EN_SEL, 0x08),
+ QMP_PHY_INIT_CFG(QSERDES_V10_60_COM_LOCK_CMP_EN, 0x46),
+ QMP_PHY_INIT_CFG(QSERDES_V10_60_COM_LOCK_CMP_CFG, 0x04),
+ QMP_PHY_INIT_CFG(QSERDES_V10_60_COM_VCO_TUNE_MAP, 0x14),
+ QMP_PHY_INIT_CFG(QSERDES_V10_60_COM_CLK_SELECT, 0x34),
+ QMP_PHY_INIT_CFG(QSERDES_V10_60_COM_CORE_CLK_EN, 0xa0),
+ QMP_PHY_INIT_CFG(QSERDES_V10_60_COM_CMN_CONFIG_1, 0x16),
+ QMP_PHY_INIT_CFG(QSERDES_V10_60_COM_CMN_MISC1, 0x88),
+ QMP_PHY_INIT_CFG(QSERDES_V10_60_COM_CMN_MODE, 0x14),
+ QMP_PHY_INIT_CFG(QSERDES_V10_60_COM_VCO_DC_LEVEL_CTRL, 0x0f),
+ QMP_PHY_INIT_CFG(QSERDES_V10_60_COM_PLL_SPARE_FOR_ECO, 0x02),
+};
+
+static const struct qmp_phy_init_tbl hawi_qmp_gen4x1_pcie_tx_tbl[] = {
+ QMP_PHY_INIT_CFG(QSERDES_V10_60_TXRX_RES_CODE_LANE_OFFSET_TX, 0x1a),
+ QMP_PHY_INIT_CFG(QSERDES_V10_60_TXRX_RES_CODE_LANE_OFFSET_RX, 0x12),
+ QMP_PHY_INIT_CFG(QSERDES_V10_60_TXRX_SIGDET_CAL_CTRL1, 0x00),
+ QMP_PHY_INIT_CFG(QSERDES_V10_60_TXRX_SIGDET_CAL_CTRL2, 0x00),
+ QMP_PHY_INIT_CFG(QSERDES_V10_60_TXRX_SIGDET_CAL_TRIM, 0x66),
+ QMP_PHY_INIT_CFG(QSERDES_V10_60_TXRX_TX_BAND0, 0x05),
+ QMP_PHY_INIT_CFG(QSERDES_V10_60_TXRX_TX_BAND1, 0x00),
+ QMP_PHY_INIT_CFG(QSERDES_V10_60_TXRX_SEL_10B_8B, 0x07),
+ QMP_PHY_INIT_CFG(QSERDES_V10_60_TXRX_SEL_20B_10B, 0x1f),
+ QMP_PHY_INIT_CFG(QSERDES_V10_60_TXRX_EQ_RCF_CTRL_RATE3, 0x22),
+ QMP_PHY_INIT_CFG(QSERDES_V10_60_TXRX_EQ_RCF_CTRL_RATE4, 0x22),
+ QMP_PHY_INIT_CFG(QSERDES_V10_60_TXRX_PHPRE_CTRL, 0x20),
+ QMP_PHY_INIT_CFG(QSERDES_V10_60_TXRX_UCDR_FASTLOCK_FO_GAIN_RATE1, 0x14),
+ QMP_PHY_INIT_CFG(QSERDES_V10_60_TXRX_UCDR_FASTLOCK_FO_GAIN_RATE2, 0x14),
+ QMP_PHY_INIT_CFG(QSERDES_V10_60_TXRX_UCDR_FASTLOCK_FO_GAIN_RATE3, 0x14),
+ QMP_PHY_INIT_CFG(QSERDES_V10_60_TXRX_UCDR_FASTLOCK_FO_GAIN_RATE4, 0x14),
+ QMP_PHY_INIT_CFG(QSERDES_V10_60_TXRX_UCDR_FASTLOCK_SO_GAIN_RATE1, 0x04),
+ QMP_PHY_INIT_CFG(QSERDES_V10_60_TXRX_UCDR_FASTLOCK_SO_GAIN_RATE2, 0x04),
+ QMP_PHY_INIT_CFG(QSERDES_V10_60_TXRX_UCDR_FASTLOCK_SO_GAIN_RATE3, 0x04),
+ QMP_PHY_INIT_CFG(QSERDES_V10_60_TXRX_UCDR_FASTLOCK_SO_GAIN_RATE4, 0x04),
+ QMP_PHY_INIT_CFG(QSERDES_V10_60_TXRX_UCDR_PI_CTRL1, 0x40),
+ QMP_PHY_INIT_CFG(QSERDES_V10_60_TXRX_UCDR_PI_CTRL2, 0x02),
+ QMP_PHY_INIT_CFG(QSERDES_V10_60_TXRX_UCDR_PI_CTRL3, 0x00),
+ QMP_PHY_INIT_CFG(QSERDES_V10_60_TXRX_UCDR_PI_CTRL4, 0x00),
+ QMP_PHY_INIT_CFG(QSERDES_V10_60_TXRX_SVS_MODE_CTRL, 0x00),
+ QMP_PHY_INIT_CFG(QSERDES_V10_60_TXRX_RXCLK_DIV2_CTRL, 0x01),
+ QMP_PHY_INIT_CFG(QSERDES_V10_60_TXRX_RX_BAND_CTRL0, 0x05),
+ QMP_PHY_INIT_CFG(QSERDES_V10_60_TXRX_RX_TERM_BW_CTRL0, 0x00),
+ QMP_PHY_INIT_CFG(QSERDES_V10_60_TXRX_RX_TERM_BW_CTRL1, 0x00),
+ QMP_PHY_INIT_CFG(QSERDES_V10_60_TXRX_UCDR_FO_GAIN_RATE1, 0x0a),
+ QMP_PHY_INIT_CFG(QSERDES_V10_60_TXRX_UCDR_FO_GAIN_RATE2, 0x0a),
+ QMP_PHY_INIT_CFG(QSERDES_V10_60_TXRX_UCDR_FO_GAIN_RATE3, 0x06),
+ QMP_PHY_INIT_CFG(QSERDES_V10_60_TXRX_UCDR_FO_GAIN_RATE4, 0x06),
+ QMP_PHY_INIT_CFG(QSERDES_V10_60_TXRX_UCDR_SO_GAIN_RATE1, 0x04),
+ QMP_PHY_INIT_CFG(QSERDES_V10_60_TXRX_UCDR_SO_GAIN_RATE2, 0x06),
+ QMP_PHY_INIT_CFG(QSERDES_V10_60_TXRX_UCDR_SO_GAIN_RATE3, 0x04),
+ QMP_PHY_INIT_CFG(QSERDES_V10_60_TXRX_UCDR_SO_GAIN_RATE4, 0x04),
+ QMP_PHY_INIT_CFG(QSERDES_V10_60_TXRX_UCDR_PI_CONTROLS, 0x07),
+ QMP_PHY_INIT_CFG(QSERDES_V10_60_TXRX_AUXDATA_BIN_RATE3, 0x03),
+ QMP_PHY_INIT_CFG(QSERDES_V10_60_TXRX_AUXDATA_BIN_RATE4, 0x03),
+ QMP_PHY_INIT_CFG(QSERDES_V10_60_TXRX_EOM_MAX_ERR_LIMIT_LSB, 0xff),
+ QMP_PHY_INIT_CFG(QSERDES_V10_60_TXRX_EOM_MAX_ERR_LIMIT_MSB, 0xff),
+ QMP_PHY_INIT_CFG(QSERDES_V10_60_TXRX_VGA_CAL_CNTRL1, 0x04),
+ QMP_PHY_INIT_CFG(QSERDES_V10_60_TXRX_VGA_CAL_MAN_VAL, 0x8e),
+ QMP_PHY_INIT_CFG(QSERDES_V10_60_TXRX_GM_CAL, 0x00),
+ QMP_PHY_INIT_CFG(QSERDES_V10_60_TXRX_RX_EQU_ADAPTOR_CNTRL6, 0xca),
+ QMP_PHY_INIT_CFG(QSERDES_V10_60_TXRX_SIGDET_ENABLES, 0x1c),
+ QMP_PHY_INIT_CFG(QSERDES_V10_60_TXRX_SIGDET_CNTRL, 0x6f),
+ QMP_PHY_INIT_CFG(QSERDES_V10_60_TXRX_SIGDET_LVL, 0x84),
+ QMP_PHY_INIT_CFG(QSERDES_V10_60_TXRX_SIGDET_DEGLITCH_CNTRL, 0x06),
+ QMP_PHY_INIT_CFG(QSERDES_V10_60_TXRX_Q_PI_INTRINSIC_BIAS_RATE32, 0x11),
+ QMP_PHY_INIT_CFG(QSERDES_V10_60_TXRX_Q_PI_INTRINSIC_BIAS_RATE45, 0x10),
+ QMP_PHY_INIT_CFG(QSERDES_V10_60_TXRX_RX_MODE_RATE_0_1_B0, 0xc2),
+ QMP_PHY_INIT_CFG(QSERDES_V10_60_TXRX_RX_MODE_RATE_0_1_B1, 0xc2),
+ QMP_PHY_INIT_CFG(QSERDES_V10_60_TXRX_RX_MODE_RATE_0_1_B2, 0xd8),
+ QMP_PHY_INIT_CFG(QSERDES_V10_60_TXRX_RX_MODE_RATE_0_1_B3, 0x05),
+ QMP_PHY_INIT_CFG(QSERDES_V10_60_TXRX_RX_MODE_RATE_0_1_B4, 0x98),
+ QMP_PHY_INIT_CFG(QSERDES_V10_60_TXRX_RX_MODE_RATE_0_1_B5, 0x36),
+ QMP_PHY_INIT_CFG(QSERDES_V10_60_TXRX_RX_MODE_RATE_0_1_B6, 0x14),
+ QMP_PHY_INIT_CFG(QSERDES_V10_60_TXRX_RX_MODE_RATE_0_1_B7, 0x06),
+ QMP_PHY_INIT_CFG(QSERDES_V10_60_TXRX_RX_MODE_RATE_0_1_B8, 0xc0),
+ QMP_PHY_INIT_CFG(QSERDES_V10_60_TXRX_RX_MODE_RATE_0_1_B9, 0x07),
+ QMP_PHY_INIT_CFG(QSERDES_V10_60_TXRX_RX_MODE_RATE_0_1_B10, 0x00),
+ QMP_PHY_INIT_CFG(QSERDES_V10_60_TXRX_RX_MODE_RATE2_B0, 0x0a),
+ QMP_PHY_INIT_CFG(QSERDES_V10_60_TXRX_RX_MODE_RATE2_B1, 0x0a),
+ QMP_PHY_INIT_CFG(QSERDES_V10_60_TXRX_RX_MODE_RATE2_B2, 0xd8),
+ QMP_PHY_INIT_CFG(QSERDES_V10_60_TXRX_RX_MODE_RATE2_B3, 0x1a),
+ QMP_PHY_INIT_CFG(QSERDES_V10_60_TXRX_RX_MODE_RATE2_B4, 0x98),
+ QMP_PHY_INIT_CFG(QSERDES_V10_60_TXRX_RX_MODE_RATE2_B5, 0x36),
+ QMP_PHY_INIT_CFG(QSERDES_V10_60_TXRX_RX_MODE_RATE2_B6, 0x14),
+ QMP_PHY_INIT_CFG(QSERDES_V10_60_TXRX_RX_MODE_RATE2_B7, 0x06),
+ QMP_PHY_INIT_CFG(QSERDES_V10_60_TXRX_RX_MODE_RATE2_B8, 0xc0),
+ QMP_PHY_INIT_CFG(QSERDES_V10_60_TXRX_RX_MODE_RATE2_B9, 0x07),
+ QMP_PHY_INIT_CFG(QSERDES_V10_60_TXRX_RX_MODE_RATE2_B10, 0x00),
+ QMP_PHY_INIT_CFG(QSERDES_V10_60_TXRX_RX_MODE_RATE3_B0, 0x13),
+ QMP_PHY_INIT_CFG(QSERDES_V10_60_TXRX_RX_MODE_RATE3_B1, 0xd3),
+ QMP_PHY_INIT_CFG(QSERDES_V10_60_TXRX_RX_MODE_RATE3_B2, 0xc0),
+ QMP_PHY_INIT_CFG(QSERDES_V10_60_TXRX_RX_MODE_RATE3_B3, 0x13),
+ QMP_PHY_INIT_CFG(QSERDES_V10_60_TXRX_RX_MODE_RATE3_B4, 0x13),
+ QMP_PHY_INIT_CFG(QSERDES_V10_60_TXRX_RX_MODE_RATE3_B5, 0x36),
+ QMP_PHY_INIT_CFG(QSERDES_V10_60_TXRX_RX_MODE_RATE3_B6, 0x4c),
+ QMP_PHY_INIT_CFG(QSERDES_V10_60_TXRX_RX_MODE_RATE3_B7, 0x06),
+ QMP_PHY_INIT_CFG(QSERDES_V10_60_TXRX_RX_MODE_RATE3_B8, 0xc0),
+ QMP_PHY_INIT_CFG(QSERDES_V10_60_TXRX_RX_MODE_RATE3_B9, 0x07),
+ QMP_PHY_INIT_CFG(QSERDES_V10_60_TXRX_RX_MODE_RATE3_B10, 0x00),
+ QMP_PHY_INIT_CFG(QSERDES_V10_60_TXRX_RX_MODE_RATE4_SA_B0, 0x24),
+ QMP_PHY_INIT_CFG(QSERDES_V10_60_TXRX_RX_MODE_RATE4_SA_B1, 0x24),
+ QMP_PHY_INIT_CFG(QSERDES_V10_60_TXRX_RX_MODE_RATE4_SA_B2, 0xc0),
+ QMP_PHY_INIT_CFG(QSERDES_V10_60_TXRX_RX_MODE_RATE4_SA_B3, 0x0b),
+ QMP_PHY_INIT_CFG(QSERDES_V10_60_TXRX_RX_MODE_RATE4_SA_B4, 0x1a),
+ QMP_PHY_INIT_CFG(QSERDES_V10_60_TXRX_RX_MODE_RATE4_SA_B5, 0x24),
+ QMP_PHY_INIT_CFG(QSERDES_V10_60_TXRX_RX_MODE_RATE4_SA_B6, 0x2c),
+ QMP_PHY_INIT_CFG(QSERDES_V10_60_TXRX_RX_MODE_RATE4_SA_B7, 0x86),
+ QMP_PHY_INIT_CFG(QSERDES_V10_60_TXRX_RX_MODE_RATE4_SA_B8, 0x83),
+ QMP_PHY_INIT_CFG(QSERDES_V10_60_TXRX_RX_MODE_RATE4_SA_B9, 0x1f),
+ QMP_PHY_INIT_CFG(QSERDES_V10_60_TXRX_RX_MODE_RATE4_SA_B10, 0x00),
+ QMP_PHY_INIT_CFG(QSERDES_V10_60_TXRX_LANE_MODE_1, 0x0c),
+ QMP_PHY_INIT_CFG(QSERDES_V10_60_TXRX_LANE_MODE_2, 0xc0),
+ QMP_PHY_INIT_CFG(QSERDES_V10_60_TXRX_LANE_MODE_3, 0x00),
+};
+
+static const struct qmp_phy_init_tbl hawi_qmp_gen4x1_pcie_pcs_tbl[] = {
+ QMP_PHY_INIT_CFG(QPHY_V10_60_PCS_G12S1_TXDEEMPH_M6DB, 0x17),
+ QMP_PHY_INIT_CFG(QPHY_V10_60_PCS_G3S2_PRE_GAIN, 0x2e),
+ QMP_PHY_INIT_CFG(QPHY_V10_60_PCS_RX_SIGDET_LVL, 0xcc),
+ QMP_PHY_INIT_CFG(QPHY_V10_60_PCS_ELECIDLE_DLY_SEL, 0x40),
+ QMP_PHY_INIT_CFG(QPHY_V10_60_PCS_PCS_TX_RX_CONFIG1, 0x04),
+ QMP_PHY_INIT_CFG(QPHY_V10_60_PCS_PCS_TX_RX_CONFIG2, 0x02),
+ QMP_PHY_INIT_CFG(QPHY_V10_60_PCS_EQ_CONFIG4, 0x00),
+ QMP_PHY_INIT_CFG(QPHY_V10_60_PCS_EQ_CONFIG5, 0x22),
+};
+
+static const struct qmp_phy_init_tbl hawi_qmp_gen4x1_pcie_pcs_misc_tbl[] = {
+ QMP_PHY_INIT_CFG(QPHY_PCIE_V10_60_PCS_POWER_STATE_CONFIG2, 0x1d),
+ QMP_PHY_INIT_CFG(QPHY_PCIE_V10_60_PCS_TX_RX_CONFIG, 0xc0),
+ QMP_PHY_INIT_CFG(QPHY_PCIE_V10_60_PCS_ENDPOINT_REFCLK_DRIVE, 0xc1),
+ QMP_PHY_INIT_CFG(QPHY_PCIE_V10_60_PCS_OSC_DTCT_ACTIONS, 0x00),
+ QMP_PHY_INIT_CFG(QPHY_PCIE_V10_60_PCS_EQ_CONFIG1, 0x16),
+ QMP_PHY_INIT_CFG(QPHY_PCIE_V10_60_PCS_G3_RXEQEVAL_TIME, 0x27),
+ QMP_PHY_INIT_CFG(QPHY_PCIE_V10_60_PCS_G4_RXEQEVAL_TIME, 0x27),
+ QMP_PHY_INIT_CFG(QPHY_PCIE_V10_60_PCS_G4_EQ_CONFIG5, 0x02),
+ QMP_PHY_INIT_CFG(QPHY_PCIE_V10_60_PCS_G4_PRE_GAIN, 0x2e),
+ QMP_PHY_INIT_CFG(QPHY_PCIE_V10_60_PCS_RX_MARGINING_CONFIG1, 0x03),
+ QMP_PHY_INIT_CFG(QPHY_PCIE_V10_60_PCS_RX_MARGINING_CONFIG3, 0x28),
+ QMP_PHY_INIT_CFG(QPHY_PCIE_V10_60_PCS_RX_MARGINING_CONFIG5, 0x0f),
+ QMP_PHY_INIT_CFG(QPHY_PCIE_V10_60_PCS_G3_FOM_EQ_CONFIG5, 0xf2),
+ QMP_PHY_INIT_CFG(QPHY_PCIE_V10_60_PCS_G4_FOM_EQ_CONFIG5, 0xf2),
+ QMP_PHY_INIT_CFG(QPHY_PCIE_V10_60_PCS_POWER_STATE_CONFIG6, 0x1f),
+};
+
struct qmp_pcie_offsets {
u16 serdes;
u16 pcs;
@@ -3534,6 +3829,24 @@ static const struct qmp_pcie_offsets qmp_pcie_offsets_v8_50 = {
.txrxz = 0xd000,
};
+static const struct qmp_pcie_offsets qmp_pcie_offsets_v10_0 = {
+ .serdes = 0x0000,
+ .pcs = 0x0400,
+ .pcs_misc = 0x0800,
+ .tx = 0x1000,
+ .rx = 0x1200,
+ .tx2 = 0x1800,
+ .rx2 = 0x1a00,
+};
+
+static const struct qmp_pcie_offsets qmp_pcie_offsets_v10_60 = {
+ .tx = 0x0000,
+ /* no .rx; tx and rx share the same register block */
+ .serdes = 0x1000,
+ .pcs = 0x1400,
+ .pcs_misc = 0x1800,
+};
+
static const struct qmp_phy_cfg ipq8074_pciephy_cfg = {
.lanes = 1,
@@ -4650,6 +4963,60 @@ static const struct qmp_phy_cfg glymur_qmp_gen4x2_pciephy_cfg = {
.phy_status = PHYSTATUS_4_20,
};
+static const struct qmp_phy_cfg hawi_qmp_gen3x2_pciephy_cfg = {
+ .lanes = 2,
+
+ .offsets = &qmp_pcie_offsets_v10_0,
+
+ .tbls = {
+ .serdes = hawi_qmp_gen3x2_pcie_serdes_tbl,
+ .serdes_num = ARRAY_SIZE(hawi_qmp_gen3x2_pcie_serdes_tbl),
+ .tx = hawi_qmp_gen3x2_pcie_tx_tbl,
+ .tx_num = ARRAY_SIZE(hawi_qmp_gen3x2_pcie_tx_tbl),
+ .rx = hawi_qmp_gen3x2_pcie_rx_tbl,
+ .rx_num = ARRAY_SIZE(hawi_qmp_gen3x2_pcie_rx_tbl),
+ .pcs = hawi_qmp_gen3x2_pcie_pcs_tbl,
+ .pcs_num = ARRAY_SIZE(hawi_qmp_gen3x2_pcie_pcs_tbl),
+ .pcs_misc = hawi_qmp_gen3x2_pcie_pcs_misc_tbl,
+ .pcs_misc_num = ARRAY_SIZE(hawi_qmp_gen3x2_pcie_pcs_misc_tbl),
+ },
+
+ .reset_list = sdm845_pciephy_reset_l,
+ .num_resets = ARRAY_SIZE(sdm845_pciephy_reset_l),
+ .vreg_list = qmp_phy_vreg_l,
+ .num_vregs = ARRAY_SIZE(qmp_phy_vreg_l),
+ .regs = pciephy_v10_regs_layout,
+
+ .pwrdn_ctrl = SW_PWRDN | REFCLK_DRV_DSBL,
+ .phy_status = PHYSTATUS,
+};
+
+static const struct qmp_phy_cfg hawi_qmp_gen4x1_pciephy_cfg = {
+ .lanes = 1,
+
+ .offsets = &qmp_pcie_offsets_v10_60,
+
+ .tbls = {
+ .serdes = hawi_qmp_gen4x1_pcie_serdes_tbl,
+ .serdes_num = ARRAY_SIZE(hawi_qmp_gen4x1_pcie_serdes_tbl),
+ .tx = hawi_qmp_gen4x1_pcie_tx_tbl,
+ .tx_num = ARRAY_SIZE(hawi_qmp_gen4x1_pcie_tx_tbl),
+ .pcs = hawi_qmp_gen4x1_pcie_pcs_tbl,
+ .pcs_num = ARRAY_SIZE(hawi_qmp_gen4x1_pcie_pcs_tbl),
+ .pcs_misc = hawi_qmp_gen4x1_pcie_pcs_misc_tbl,
+ .pcs_misc_num = ARRAY_SIZE(hawi_qmp_gen4x1_pcie_pcs_misc_tbl),
+ },
+
+ .reset_list = sdm845_pciephy_reset_l,
+ .num_resets = ARRAY_SIZE(sdm845_pciephy_reset_l),
+ .vreg_list = qmp_phy_vreg_l,
+ .num_vregs = ARRAY_SIZE(qmp_phy_vreg_l),
+ .regs = pciephy_v10_60_regs_layout,
+
+ .pwrdn_ctrl = SW_PWRDN | REFCLK_DRV_DSBL,
+ .phy_status = PHYSTATUS_4_20,
+};
+
static void qmp_pcie_init_port_b(struct qmp_pcie *qmp, const struct qmp_phy_cfg_tbls *tbls)
{
const struct qmp_phy_cfg *cfg = qmp->cfg;
@@ -5406,6 +5773,12 @@ static const struct of_device_id qmp_pcie_of_match_table[] = {
}, {
.compatible = "qcom,glymur-qmp-gen5x4-pcie-phy",
.data = &glymur_qmp_gen5x4_pciephy_cfg,
+ }, {
+ .compatible = "qcom,hawi-qmp-gen3x2-pcie-phy",
+ .data = &hawi_qmp_gen3x2_pciephy_cfg,
+ }, {
+ .compatible = "qcom,hawi-qmp-gen4x1-pcie-phy",
+ .data = &hawi_qmp_gen4x1_pciephy_cfg,
}, {
.compatible = "qcom,ipq6018-qmp-pcie-phy",
.data = &ipq6018_pciephy_cfg,
--
2.34.1
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH v3 3/4] phy: qcom-qmp: Add v10.60 register offsets
From: Matthew Leung @ 2026-06-18 21:54 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, linux-phy, devicetree, linux-kernel, Matthew Leung
In-Reply-To: <20260618-hawi-phy-pcie-v3-0-3fa42ca45ea4@oss.qualcomm.com>
Hawi SoC uses v10.60 register definitions for PCIe Gen4 x1. Add the new
register offset headers for all four sub-blocks:
- QSERDES-COM offsets
- QSERDES TX/RX offsets
- PCS offsets
- PCS PCIe-specific offsets
Signed-off-by: Matthew Leung <matthew.leung@oss.qualcomm.com>
---
drivers/phy/qualcomm/phy-qcom-qmp-pcie.c | 1 +
.../phy/qualcomm/phy-qcom-qmp-pcs-pcie-v10_60.h | 26 +++++
drivers/phy/qualcomm/phy-qcom-qmp-pcs-v10_60.h | 23 +++++
.../phy/qualcomm/phy-qcom-qmp-qserdes-com-v10_60.h | 55 +++++++++++
.../qualcomm/phy-qcom-qmp-qserdes-txrx-v10_60.h | 109 +++++++++++++++++++++
drivers/phy/qualcomm/phy-qcom-qmp.h | 5 +
6 files changed, 219 insertions(+)
diff --git a/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c b/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c
index ba17e53d000f..fb66e2a97ce0 100644
--- a/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c
+++ b/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c
@@ -41,6 +41,7 @@
#include "phy-qcom-qmp-pcs-pcie-v8.h"
#include "phy-qcom-qmp-qserdes-txrx-pcie-v8.h"
#include "phy-qcom-qmp-pcs-pcie-v10.h"
+#include "phy-qcom-qmp-pcs-pcie-v10_60.h"
#define PHY_INIT_COMPLETE_TIMEOUT 10000
diff --git a/drivers/phy/qualcomm/phy-qcom-qmp-pcs-pcie-v10_60.h b/drivers/phy/qualcomm/phy-qcom-qmp-pcs-pcie-v10_60.h
new file mode 100644
index 000000000000..2df5a45010a4
--- /dev/null
+++ b/drivers/phy/qualcomm/phy-qcom-qmp-pcs-pcie-v10_60.h
@@ -0,0 +1,26 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
+ */
+
+#ifndef QCOM_PHY_QMP_PCS_PCIE_V10_60_H_
+#define QCOM_PHY_QMP_PCS_PCIE_V10_60_H_
+
+/* Only for QMP V10_60 PHY - PCIE PCS registers */
+#define QPHY_PCIE_V10_60_PCS_POWER_STATE_CONFIG2 0x00c
+#define QPHY_PCIE_V10_60_PCS_TX_RX_CONFIG 0x018
+#define QPHY_PCIE_V10_60_PCS_ENDPOINT_REFCLK_DRIVE 0x01c
+#define QPHY_PCIE_V10_60_PCS_OSC_DTCT_ACTIONS 0x090
+#define QPHY_PCIE_V10_60_PCS_EQ_CONFIG1 0x0a0
+#define QPHY_PCIE_V10_60_PCS_G3_RXEQEVAL_TIME 0x0f0
+#define QPHY_PCIE_V10_60_PCS_G4_RXEQEVAL_TIME 0x0f4
+#define QPHY_PCIE_V10_60_PCS_G4_EQ_CONFIG5 0x108
+#define QPHY_PCIE_V10_60_PCS_G4_PRE_GAIN 0x15c
+#define QPHY_PCIE_V10_60_PCS_RX_MARGINING_CONFIG1 0x17c
+#define QPHY_PCIE_V10_60_PCS_RX_MARGINING_CONFIG3 0x184
+#define QPHY_PCIE_V10_60_PCS_RX_MARGINING_CONFIG5 0x18c
+#define QPHY_PCIE_V10_60_PCS_G3_FOM_EQ_CONFIG5 0x1ac
+#define QPHY_PCIE_V10_60_PCS_G4_FOM_EQ_CONFIG5 0x1c0
+#define QPHY_PCIE_V10_60_PCS_POWER_STATE_CONFIG6 0x1d0
+
+#endif
diff --git a/drivers/phy/qualcomm/phy-qcom-qmp-pcs-v10_60.h b/drivers/phy/qualcomm/phy-qcom-qmp-pcs-v10_60.h
new file mode 100644
index 000000000000..e4558b69489d
--- /dev/null
+++ b/drivers/phy/qualcomm/phy-qcom-qmp-pcs-v10_60.h
@@ -0,0 +1,23 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
+ */
+
+#ifndef QCOM_PHY_QMP_PCS_V10_60_H_
+#define QCOM_PHY_QMP_PCS_V10_60_H_
+
+/* Only for QMP V10_60 PHY - PCIe PCS registers */
+#define QPHY_V10_60_PCS_SW_RESET 0x000
+#define QPHY_V10_60_PCS_PCS_STATUS1 0x014
+#define QPHY_V10_60_PCS_POWER_DOWN_CONTROL 0x040
+#define QPHY_V10_60_PCS_START_CONTROL 0x044
+#define QPHY_V10_60_PCS_G12S1_TXDEEMPH_M6DB 0x170
+#define QPHY_V10_60_PCS_G3S2_PRE_GAIN 0x178
+#define QPHY_V10_60_PCS_RX_SIGDET_LVL 0x190
+#define QPHY_V10_60_PCS_ELECIDLE_DLY_SEL 0x1b8
+#define QPHY_V10_60_PCS_PCS_TX_RX_CONFIG1 0x1dc
+#define QPHY_V10_60_PCS_PCS_TX_RX_CONFIG2 0x1e0
+#define QPHY_V10_60_PCS_EQ_CONFIG4 0x1f8
+#define QPHY_V10_60_PCS_EQ_CONFIG5 0x1fc
+
+#endif
diff --git a/drivers/phy/qualcomm/phy-qcom-qmp-qserdes-com-v10_60.h b/drivers/phy/qualcomm/phy-qcom-qmp-qserdes-com-v10_60.h
new file mode 100644
index 000000000000..39351bef8b63
--- /dev/null
+++ b/drivers/phy/qualcomm/phy-qcom-qmp-qserdes-com-v10_60.h
@@ -0,0 +1,55 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
+ */
+
+#ifndef QCOM_PHY_QMP_QSERDES_COM_V10_60_H_
+#define QCOM_PHY_QMP_QSERDES_COM_V10_60_H_
+
+/* Only for QMP V10_60 PHY - QSERDES COM registers */
+#define QSERDES_V10_60_COM_SSC_STEP_SIZE1_MODE1 0x00
+#define QSERDES_V10_60_COM_SSC_STEP_SIZE2_MODE1 0x04
+#define QSERDES_V10_60_COM_CP_CTRL_MODE1 0x10
+#define QSERDES_V10_60_COM_PLL_RCTRL_MODE1 0x14
+#define QSERDES_V10_60_COM_PLL_CCTRL_MODE1 0x18
+#define QSERDES_V10_60_COM_CORECLK_DIV_MODE1 0x1c
+#define QSERDES_V10_60_COM_LOCK_CMP1_MODE1 0x20
+#define QSERDES_V10_60_COM_LOCK_CMP2_MODE1 0x24
+#define QSERDES_V10_60_COM_DEC_START_MODE1 0x28
+#define QSERDES_V10_60_COM_DIV_FRAC_START1_MODE1 0x30
+#define QSERDES_V10_60_COM_DIV_FRAC_START2_MODE1 0x34
+#define QSERDES_V10_60_COM_DIV_FRAC_START3_MODE1 0x38
+#define QSERDES_V10_60_COM_HSCLK_SEL_1 0x3c
+#define QSERDES_V10_60_COM_SSC_STEP_SIZE1_MODE0 0x60
+#define QSERDES_V10_60_COM_SSC_STEP_SIZE2_MODE0 0x64
+#define QSERDES_V10_60_COM_CP_CTRL_MODE0 0x70
+#define QSERDES_V10_60_COM_PLL_RCTRL_MODE0 0x74
+#define QSERDES_V10_60_COM_PLL_CCTRL_MODE0 0x78
+#define QSERDES_V10_60_COM_CORECLK_DIV_MODE0 0x7c
+#define QSERDES_V10_60_COM_LOCK_CMP1_MODE0 0x80
+#define QSERDES_V10_60_COM_LOCK_CMP2_MODE0 0x84
+#define QSERDES_V10_60_COM_DEC_START_MODE0 0x88
+#define QSERDES_V10_60_COM_DIV_FRAC_START1_MODE0 0x90
+#define QSERDES_V10_60_COM_DIV_FRAC_START2_MODE0 0x94
+#define QSERDES_V10_60_COM_DIV_FRAC_START3_MODE0 0x98
+#define QSERDES_V10_60_COM_HSCLK_HS_SWITCH_SEL_1 0x9c
+#define QSERDES_V10_60_COM_BG_TIMER 0xbc
+#define QSERDES_V10_60_COM_SSC_PER1 0xcc
+#define QSERDES_V10_60_COM_SSC_PER2 0xd0
+#define QSERDES_V10_60_COM_BIAS_EN_CLKBUFLR_EN 0xdc
+#define QSERDES_V10_60_COM_CLK_ENABLE1 0xe0
+#define QSERDES_V10_60_COM_SYS_CLK_CTRL 0xe4
+#define QSERDES_V10_60_COM_PLL_IVCO 0xf4
+#define QSERDES_V10_60_COM_SYSCLK_EN_SEL 0x110
+#define QSERDES_V10_60_COM_LOCK_CMP_EN 0x120
+#define QSERDES_V10_60_COM_LOCK_CMP_CFG 0x124
+#define QSERDES_V10_60_COM_VCO_TUNE_MAP 0x140
+#define QSERDES_V10_60_COM_CLK_SELECT 0x164
+#define QSERDES_V10_60_COM_CORE_CLK_EN 0x170
+#define QSERDES_V10_60_COM_CMN_CONFIG_1 0x174
+#define QSERDES_V10_60_COM_CMN_MISC1 0x184
+#define QSERDES_V10_60_COM_CMN_MODE 0x188
+#define QSERDES_V10_60_COM_VCO_DC_LEVEL_CTRL 0x198
+#define QSERDES_V10_60_COM_PLL_SPARE_FOR_ECO 0x2b4
+
+#endif
diff --git a/drivers/phy/qualcomm/phy-qcom-qmp-qserdes-txrx-v10_60.h b/drivers/phy/qualcomm/phy-qcom-qmp-qserdes-txrx-v10_60.h
new file mode 100644
index 000000000000..3150a494685e
--- /dev/null
+++ b/drivers/phy/qualcomm/phy-qcom-qmp-qserdes-txrx-v10_60.h
@@ -0,0 +1,109 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
+ */
+
+#ifndef QCOM_PHY_QMP_QSERDES_TXRX_V10_60_H_
+#define QCOM_PHY_QMP_QSERDES_TXRX_V10_60_H_
+
+#define QSERDES_V10_60_TXRX_RES_CODE_LANE_OFFSET_TX 0x034
+#define QSERDES_V10_60_TXRX_RES_CODE_LANE_OFFSET_RX 0x038
+#define QSERDES_V10_60_TXRX_LANE_MODE_1 0x080
+#define QSERDES_V10_60_TXRX_LANE_MODE_2 0x084
+#define QSERDES_V10_60_TXRX_LANE_MODE_3 0x088
+#define QSERDES_V10_60_TXRX_UCDR_FASTLOCK_FO_GAIN_RATE1 0x0c8
+#define QSERDES_V10_60_TXRX_UCDR_FASTLOCK_FO_GAIN_RATE2 0x0cc
+#define QSERDES_V10_60_TXRX_UCDR_FASTLOCK_FO_GAIN_RATE3 0x0d0
+#define QSERDES_V10_60_TXRX_UCDR_FASTLOCK_FO_GAIN_RATE4 0x0d4
+#define QSERDES_V10_60_TXRX_UCDR_FASTLOCK_SO_GAIN_RATE1 0x0e0
+#define QSERDES_V10_60_TXRX_UCDR_FASTLOCK_SO_GAIN_RATE2 0x0e4
+#define QSERDES_V10_60_TXRX_UCDR_FASTLOCK_SO_GAIN_RATE3 0x0e8
+#define QSERDES_V10_60_TXRX_UCDR_FASTLOCK_SO_GAIN_RATE4 0x0ec
+#define QSERDES_V10_60_TXRX_UCDR_PI_CTRL1 0x12c
+#define QSERDES_V10_60_TXRX_UCDR_PI_CTRL2 0x130
+#define QSERDES_V10_60_TXRX_UCDR_PI_CTRL3 0x134
+#define QSERDES_V10_60_TXRX_UCDR_PI_CTRL4 0x138
+#define QSERDES_V10_60_TXRX_SVS_MODE_CTRL 0x19c
+#define QSERDES_V10_60_TXRX_RXCLK_DIV2_CTRL 0x1a0
+#define QSERDES_V10_60_TXRX_RX_BAND_CTRL0 0x1a4
+#define QSERDES_V10_60_TXRX_RX_TERM_BW_CTRL0 0x1ac
+#define QSERDES_V10_60_TXRX_RX_TERM_BW_CTRL1 0x1b0
+#define QSERDES_V10_60_TXRX_UCDR_FO_GAIN_RATE1 0x1b8
+#define QSERDES_V10_60_TXRX_UCDR_FO_GAIN_RATE2 0x1bc
+#define QSERDES_V10_60_TXRX_UCDR_FO_GAIN_RATE3 0x1c0
+#define QSERDES_V10_60_TXRX_UCDR_FO_GAIN_RATE4 0x1c4
+#define QSERDES_V10_60_TXRX_UCDR_SO_GAIN_RATE1 0x1d0
+#define QSERDES_V10_60_TXRX_UCDR_SO_GAIN_RATE2 0x1d4
+#define QSERDES_V10_60_TXRX_UCDR_SO_GAIN_RATE3 0x1d8
+#define QSERDES_V10_60_TXRX_UCDR_SO_GAIN_RATE4 0x1dc
+#define QSERDES_V10_60_TXRX_UCDR_PI_CONTROLS 0x1e4
+#define QSERDES_V10_60_TXRX_AUXDATA_BIN_RATE3 0x200
+#define QSERDES_V10_60_TXRX_AUXDATA_BIN_RATE4 0x204
+#define QSERDES_V10_60_TXRX_EOM_MAX_ERR_LIMIT_LSB 0x218
+#define QSERDES_V10_60_TXRX_EOM_MAX_ERR_LIMIT_MSB 0x21c
+#define QSERDES_V10_60_TXRX_VGA_CAL_CNTRL1 0x280
+#define QSERDES_V10_60_TXRX_VGA_CAL_MAN_VAL 0x288
+#define QSERDES_V10_60_TXRX_GM_CAL 0x29c
+#define QSERDES_V10_60_TXRX_RX_EQU_ADAPTOR_CNTRL6 0x2b8
+#define QSERDES_V10_60_TXRX_SIGDET_ENABLES 0x2d4
+#define QSERDES_V10_60_TXRX_SIGDET_CNTRL 0x2d8
+#define QSERDES_V10_60_TXRX_SIGDET_LVL 0x2dc
+#define QSERDES_V10_60_TXRX_SIGDET_DEGLITCH_CNTRL 0x2e0
+#define QSERDES_V10_60_TXRX_RX_MODE_RATE_0_1_B0 0x314
+#define QSERDES_V10_60_TXRX_RX_MODE_RATE_0_1_B1 0x318
+#define QSERDES_V10_60_TXRX_RX_MODE_RATE_0_1_B2 0x31c
+#define QSERDES_V10_60_TXRX_RX_MODE_RATE_0_1_B3 0x320
+#define QSERDES_V10_60_TXRX_RX_MODE_RATE_0_1_B4 0x324
+#define QSERDES_V10_60_TXRX_RX_MODE_RATE_0_1_B5 0x328
+#define QSERDES_V10_60_TXRX_RX_MODE_RATE_0_1_B6 0x32c
+#define QSERDES_V10_60_TXRX_RX_MODE_RATE_0_1_B7 0x330
+#define QSERDES_V10_60_TXRX_RX_MODE_RATE_0_1_B8 0x334
+#define QSERDES_V10_60_TXRX_RX_MODE_RATE_0_1_B9 0x338
+#define QSERDES_V10_60_TXRX_RX_MODE_RATE_0_1_B10 0x33c
+#define QSERDES_V10_60_TXRX_RX_MODE_RATE2_B0 0x340
+#define QSERDES_V10_60_TXRX_RX_MODE_RATE2_B1 0x344
+#define QSERDES_V10_60_TXRX_RX_MODE_RATE2_B2 0x348
+#define QSERDES_V10_60_TXRX_RX_MODE_RATE2_B3 0x34c
+#define QSERDES_V10_60_TXRX_RX_MODE_RATE2_B4 0x350
+#define QSERDES_V10_60_TXRX_RX_MODE_RATE2_B5 0x354
+#define QSERDES_V10_60_TXRX_RX_MODE_RATE2_B6 0x358
+#define QSERDES_V10_60_TXRX_RX_MODE_RATE2_B7 0x35c
+#define QSERDES_V10_60_TXRX_RX_MODE_RATE2_B8 0x360
+#define QSERDES_V10_60_TXRX_RX_MODE_RATE2_B9 0x364
+#define QSERDES_V10_60_TXRX_RX_MODE_RATE2_B10 0x368
+#define QSERDES_V10_60_TXRX_RX_MODE_RATE3_B0 0x36c
+#define QSERDES_V10_60_TXRX_RX_MODE_RATE3_B1 0x370
+#define QSERDES_V10_60_TXRX_RX_MODE_RATE3_B2 0x374
+#define QSERDES_V10_60_TXRX_RX_MODE_RATE3_B3 0x378
+#define QSERDES_V10_60_TXRX_RX_MODE_RATE3_B4 0x37c
+#define QSERDES_V10_60_TXRX_RX_MODE_RATE3_B5 0x380
+#define QSERDES_V10_60_TXRX_RX_MODE_RATE3_B6 0x384
+#define QSERDES_V10_60_TXRX_RX_MODE_RATE3_B7 0x388
+#define QSERDES_V10_60_TXRX_RX_MODE_RATE3_B8 0x38c
+#define QSERDES_V10_60_TXRX_RX_MODE_RATE3_B9 0x390
+#define QSERDES_V10_60_TXRX_RX_MODE_RATE3_B10 0x394
+#define QSERDES_V10_60_TXRX_RX_MODE_RATE4_SA_B0 0x398
+#define QSERDES_V10_60_TXRX_RX_MODE_RATE4_SA_B1 0x39c
+#define QSERDES_V10_60_TXRX_RX_MODE_RATE4_SA_B2 0x3a0
+#define QSERDES_V10_60_TXRX_RX_MODE_RATE4_SA_B3 0x3a4
+#define QSERDES_V10_60_TXRX_RX_MODE_RATE4_SA_B4 0x3a8
+#define QSERDES_V10_60_TXRX_RX_MODE_RATE4_SA_B5 0x3ac
+#define QSERDES_V10_60_TXRX_RX_MODE_RATE4_SA_B6 0x3b0
+#define QSERDES_V10_60_TXRX_RX_MODE_RATE4_SA_B7 0x3b4
+#define QSERDES_V10_60_TXRX_RX_MODE_RATE4_SA_B8 0x3b8
+#define QSERDES_V10_60_TXRX_RX_MODE_RATE4_SA_B9 0x3bc
+#define QSERDES_V10_60_TXRX_RX_MODE_RATE4_SA_B10 0x3c0
+#define QSERDES_V10_60_TXRX_Q_PI_INTRINSIC_BIAS_RATE32 0x478
+#define QSERDES_V10_60_TXRX_Q_PI_INTRINSIC_BIAS_RATE45 0x47c
+#define QSERDES_V10_60_TXRX_SIGDET_CAL_CTRL1 0x4c8
+#define QSERDES_V10_60_TXRX_SIGDET_CAL_CTRL2 0x4cc
+#define QSERDES_V10_60_TXRX_SIGDET_CAL_TRIM 0x4d0
+#define QSERDES_V10_60_TXRX_TX_BAND0 0x4e8
+#define QSERDES_V10_60_TXRX_TX_BAND1 0x4ec
+#define QSERDES_V10_60_TXRX_SEL_10B_8B 0x4f4
+#define QSERDES_V10_60_TXRX_SEL_20B_10B 0x4f8
+#define QSERDES_V10_60_TXRX_EQ_RCF_CTRL_RATE3 0x53c
+#define QSERDES_V10_60_TXRX_EQ_RCF_CTRL_RATE4 0x540
+#define QSERDES_V10_60_TXRX_PHPRE_CTRL 0x5e8
+
+#endif
diff --git a/drivers/phy/qualcomm/phy-qcom-qmp.h b/drivers/phy/qualcomm/phy-qcom-qmp.h
index 7af77572970e..3a4a0a9a9e4d 100644
--- a/drivers/phy/qualcomm/phy-qcom-qmp.h
+++ b/drivers/phy/qualcomm/phy-qcom-qmp.h
@@ -42,6 +42,9 @@
#include "phy-qcom-qmp-qserdes-com-v10.h"
#include "phy-qcom-qmp-qserdes-txrx-v10.h"
+#include "phy-qcom-qmp-qserdes-com-v10_60.h"
+#include "phy-qcom-qmp-qserdes-txrx-v10_60.h"
+
#include "phy-qcom-qmp-qserdes-pll.h"
#include "phy-qcom-qmp-pcs-v2.h"
@@ -70,6 +73,8 @@
#include "phy-qcom-qmp-pcs-v10.h"
+#include "phy-qcom-qmp-pcs-v10_60.h"
+
/* QPHY_SW_RESET bit */
#define SW_RESET BIT(0)
/* QPHY_POWER_DOWN_CONTROL */
--
2.34.1
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH v3 2/4] phy: qcom-qmp: Add v10 register offsets
From: Matthew Leung @ 2026-06-18 21:54 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, linux-phy, devicetree, linux-kernel, Matthew Leung
In-Reply-To: <20260618-hawi-phy-pcie-v3-0-3fa42ca45ea4@oss.qualcomm.com>
Hawi SoC uses v10 register definitions for PCIe Gen3 x2. Add the new
register offset headers for all four sub-blocks:
- QSERDES-COM offsets
- QSERDES TX/RX offsets
- PCS offsets
- PCS PCIe-specific offsets
Signed-off-by: Matthew Leung <matthew.leung@oss.qualcomm.com>
---
drivers/phy/qualcomm/phy-qcom-qmp-pcie.c | 1 +
drivers/phy/qualcomm/phy-qcom-qmp-pcs-pcie-v10.h | 18 ++++++++
drivers/phy/qualcomm/phy-qcom-qmp-pcs-v10.h | 22 ++++++++++
.../phy/qualcomm/phy-qcom-qmp-qserdes-com-v10.h | 49 ++++++++++++++++++++++
.../phy/qualcomm/phy-qcom-qmp-qserdes-txrx-v10.h | 47 +++++++++++++++++++++
drivers/phy/qualcomm/phy-qcom-qmp.h | 5 +++
6 files changed, 142 insertions(+)
diff --git a/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c b/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c
index fed2fc9bb311..ba17e53d000f 100644
--- a/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c
+++ b/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c
@@ -40,6 +40,7 @@
#include "phy-qcom-qmp-qserdes-com-v8.h"
#include "phy-qcom-qmp-pcs-pcie-v8.h"
#include "phy-qcom-qmp-qserdes-txrx-pcie-v8.h"
+#include "phy-qcom-qmp-pcs-pcie-v10.h"
#define PHY_INIT_COMPLETE_TIMEOUT 10000
diff --git a/drivers/phy/qualcomm/phy-qcom-qmp-pcs-pcie-v10.h b/drivers/phy/qualcomm/phy-qcom-qmp-pcs-pcie-v10.h
new file mode 100644
index 000000000000..2cdcc211bd93
--- /dev/null
+++ b/drivers/phy/qualcomm/phy-qcom-qmp-pcs-pcie-v10.h
@@ -0,0 +1,18 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
+ */
+
+#ifndef QCOM_PHY_QMP_PCS_PCIE_V10_H_
+#define QCOM_PHY_QMP_PCS_PCIE_V10_H_
+
+/* Only for QMP V10 PHY - PCIE PCS registers */
+#define QPHY_PCIE_V10_PCS_POWER_STATE_CONFIG2 0x00c
+#define QPHY_PCIE_V10_PCS_POWER_STATE_CONFIG4 0x014
+#define QPHY_PCIE_V10_PCS_ENDPOINT_REFCLK_DRIVE 0x020
+#define QPHY_PCIE_V10_PCS_OSC_DTCT_ACTIONS 0x094
+#define QPHY_PCIE_V10_PCS_EQ_CONFIG1 0x0a4
+#define QPHY_PCIE_V10_PCS_RXEQEVAL_TIME 0x0f4
+#define QPHY_PCIE_V10_PCS_POWER_STATE_CONFIG6 0x0f8
+
+#endif
diff --git a/drivers/phy/qualcomm/phy-qcom-qmp-pcs-v10.h b/drivers/phy/qualcomm/phy-qcom-qmp-pcs-v10.h
new file mode 100644
index 000000000000..165ce8a28f61
--- /dev/null
+++ b/drivers/phy/qualcomm/phy-qcom-qmp-pcs-v10.h
@@ -0,0 +1,22 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
+ */
+
+#ifndef QCOM_PHY_QMP_PCS_V10_H_
+#define QCOM_PHY_QMP_PCS_V10_H_
+
+/* Only for QMP V10 PHY - PCIe PCS registers */
+#define QPHY_V10_PCS_SW_RESET 0x000
+#define QPHY_V10_PCS_PCS_STATUS1 0x014
+#define QPHY_V10_PCS_POWER_DOWN_CONTROL 0x040
+#define QPHY_V10_PCS_START_CONTROL 0x044
+#define QPHY_V10_PCS_REFGEN_REQ_CONFIG1 0x0dc
+#define QPHY_V10_PCS_G12S1_TXDEEMPH_M6DB 0x168
+#define QPHY_V10_PCS_G3S2_PRE_GAIN 0x170
+#define QPHY_V10_PCS_RX_SIGDET_LVL 0x188
+#define QPHY_V10_PCS_RATE_SLEW_CNTRL1 0x198
+#define QPHY_V10_PCS_PCS_TX_RX_CONFIG 0x1d0
+#define QPHY_V10_PCS_EQ_CONFIG2 0x1e4
+
+#endif
diff --git a/drivers/phy/qualcomm/phy-qcom-qmp-qserdes-com-v10.h b/drivers/phy/qualcomm/phy-qcom-qmp-qserdes-com-v10.h
new file mode 100644
index 000000000000..09199e7b4aac
--- /dev/null
+++ b/drivers/phy/qualcomm/phy-qcom-qmp-qserdes-com-v10.h
@@ -0,0 +1,49 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
+ */
+
+#ifndef QCOM_PHY_QMP_QSERDES_COM_V10_H_
+#define QCOM_PHY_QMP_QSERDES_COM_V10_H_
+
+/* Only for QMP V10 PHY - QSERDES COM registers */
+#define QSERDES_V10_COM_SSC_STEP_SIZE1_MODE1 0x00
+#define QSERDES_V10_COM_SSC_STEP_SIZE2_MODE1 0x04
+#define QSERDES_V10_COM_CP_CTRL_MODE1 0x10
+#define QSERDES_V10_COM_PLL_RCTRL_MODE1 0x14
+#define QSERDES_V10_COM_PLL_CCTRL_MODE1 0x18
+#define QSERDES_V10_COM_CORECLK_DIV_MODE1 0x1c
+#define QSERDES_V10_COM_LOCK_CMP1_MODE1 0x20
+#define QSERDES_V10_COM_LOCK_CMP2_MODE1 0x24
+#define QSERDES_V10_COM_DEC_START_MODE1 0x28
+#define QSERDES_V10_COM_DIV_FRAC_START1_MODE1 0x30
+#define QSERDES_V10_COM_DIV_FRAC_START2_MODE1 0x34
+#define QSERDES_V10_COM_DIV_FRAC_START3_MODE1 0x38
+#define QSERDES_V10_COM_HSCLK_SEL_1 0x3c
+#define QSERDES_V10_COM_SSC_STEP_SIZE1_MODE0 0x60
+#define QSERDES_V10_COM_SSC_STEP_SIZE2_MODE0 0x64
+#define QSERDES_V10_COM_CP_CTRL_MODE0 0x70
+#define QSERDES_V10_COM_PLL_RCTRL_MODE0 0x74
+#define QSERDES_V10_COM_PLL_CCTRL_MODE0 0x78
+#define QSERDES_V10_COM_LOCK_CMP1_MODE0 0x80
+#define QSERDES_V10_COM_LOCK_CMP2_MODE0 0x84
+#define QSERDES_V10_COM_DEC_START_MODE0 0x88
+#define QSERDES_V10_COM_DIV_FRAC_START1_MODE0 0x90
+#define QSERDES_V10_COM_DIV_FRAC_START2_MODE0 0x94
+#define QSERDES_V10_COM_DIV_FRAC_START3_MODE0 0x98
+#define QSERDES_V10_COM_BG_TIMER 0xbc
+#define QSERDES_V10_COM_SSC_EN_CENTER 0xc0
+#define QSERDES_V10_COM_SSC_PER1 0xcc
+#define QSERDES_V10_COM_SSC_PER2 0xd0
+#define QSERDES_V10_COM_CLK_ENABLE1 0xe0
+#define QSERDES_V10_COM_SYS_CLK_CTRL 0xe4
+#define QSERDES_V10_COM_PLL_IVCO 0xf4
+#define QSERDES_V10_COM_SYSCLK_EN_SEL 0x110
+#define QSERDES_V10_COM_LOCK_CMP_EN 0x120
+#define QSERDES_V10_COM_VCO_TUNE_MAP 0x140
+#define QSERDES_V10_COM_CLK_SELECT 0x164
+#define QSERDES_V10_COM_CORE_CLK_EN 0x170
+#define QSERDES_V10_COM_CMN_CONFIG_1 0x174
+#define QSERDES_V10_COM_ADDITIONAL_MISC_3 0x1bc
+
+#endif
diff --git a/drivers/phy/qualcomm/phy-qcom-qmp-qserdes-txrx-v10.h b/drivers/phy/qualcomm/phy-qcom-qmp-qserdes-txrx-v10.h
new file mode 100644
index 000000000000..d81ebdde0063
--- /dev/null
+++ b/drivers/phy/qualcomm/phy-qcom-qmp-qserdes-txrx-v10.h
@@ -0,0 +1,47 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
+ */
+
+#ifndef QCOM_PHY_QMP_QSERDES_TXRX_V10_H_
+#define QCOM_PHY_QMP_QSERDES_TXRX_V10_H_
+
+#define QSERDES_V10_TX_RES_CODE_LANE_OFFSET_TX 0x03c
+#define QSERDES_V10_TX_RES_CODE_LANE_OFFSET_RX 0x040
+#define QSERDES_V10_TX_LANE_MODE_1 0x084
+#define QSERDES_V10_TX_LANE_MODE_3 0x08c
+#define QSERDES_V10_TX_LANE_MODE_4 0x090
+#define QSERDES_V10_TX_LANE_MODE_5 0x094
+#define QSERDES_V10_TX_PI_QEC_CTRL 0x0e4
+
+#define QSERDES_V10_RX_UCDR_FO_GAIN 0x008
+#define QSERDES_V10_RX_UCDR_SO_GAIN 0x014
+#define QSERDES_V10_RX_UCDR_SB2_THRESH1 0x04c
+#define QSERDES_V10_RX_UCDR_SB2_THRESH2 0x050
+#define QSERDES_V10_RX_TX_ADAPT_PRE_THRESH1 0x0c4
+#define QSERDES_V10_RX_TX_ADAPT_PRE_THRESH2 0x0c8
+#define QSERDES_V10_RX_TX_ADAPT_POST_THRESH 0x0cc
+#define QSERDES_V10_RX_VGA_CAL_CNTRL2 0x0d8
+#define QSERDES_V10_RX_GM_CAL 0x0dc
+#define QSERDES_V10_RX_RX_IDAC_TSETTLE_LOW 0x0f8
+#define QSERDES_V10_RX_SIGDET_ENABLES 0x118
+#define QSERDES_V10_RX_SIGDET_CNTRL 0x11c
+#define QSERDES_V10_RX_RX_MODE_00_LOW 0x15c
+#define QSERDES_V10_RX_RX_MODE_00_HIGH 0x160
+#define QSERDES_V10_RX_RX_MODE_00_HIGH2 0x164
+#define QSERDES_V10_RX_RX_MODE_00_HIGH3 0x168
+#define QSERDES_V10_RX_RX_MODE_00_HIGH4 0x16c
+#define QSERDES_V10_RX_RX_MODE_01_LOW 0x170
+#define QSERDES_V10_RX_RX_MODE_01_HIGH 0x174
+#define QSERDES_V10_RX_RX_MODE_01_HIGH2 0x178
+#define QSERDES_V10_RX_RX_MODE_01_HIGH3 0x17c
+#define QSERDES_V10_RX_RX_MODE_01_HIGH4 0x180
+#define QSERDES_V10_RX_RX_MODE_10_LOW 0x184
+#define QSERDES_V10_RX_RX_MODE_10_HIGH 0x188
+#define QSERDES_V10_RX_RX_MODE_10_HIGH2 0x18c
+#define QSERDES_V10_RX_RX_MODE_10_HIGH3 0x190
+#define QSERDES_V10_RX_RX_MODE_10_HIGH4 0x194
+#define QSERDES_V10_RX_DFE_CTLE_POST_CAL_OFFSET 0x1a4
+#define QSERDES_V10_RX_SIGDET_CAL_TRIM 0x1f8
+
+#endif
diff --git a/drivers/phy/qualcomm/phy-qcom-qmp.h b/drivers/phy/qualcomm/phy-qcom-qmp.h
index a873bdd7bffe..7af77572970e 100644
--- a/drivers/phy/qualcomm/phy-qcom-qmp.h
+++ b/drivers/phy/qualcomm/phy-qcom-qmp.h
@@ -39,6 +39,9 @@
#include "phy-qcom-qmp-qserdes-txrx-v8.h"
#include "phy-qcom-qmp-qserdes-lalb-v8.h"
+#include "phy-qcom-qmp-qserdes-com-v10.h"
+#include "phy-qcom-qmp-qserdes-txrx-v10.h"
+
#include "phy-qcom-qmp-qserdes-pll.h"
#include "phy-qcom-qmp-pcs-v2.h"
@@ -65,6 +68,8 @@
#include "phy-qcom-qmp-pcs-v8_50.h"
+#include "phy-qcom-qmp-pcs-v10.h"
+
/* QPHY_SW_RESET bit */
#define SW_RESET BIT(0)
/* QPHY_POWER_DOWN_CONTROL */
--
2.34.1
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH v3 1/4] dt-bindings: phy: qcom,sc8280xp-qmp-pcie-phy: Add Hawi compatibles
From: Matthew Leung @ 2026-06-18 21:54 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, linux-phy, devicetree, linux-kernel, Matthew Leung,
Krzysztof Kozlowski
In-Reply-To: <20260618-hawi-phy-pcie-v3-0-3fa42ca45ea4@oss.qualcomm.com>
Document the compatibles for the Gen3 x2 and Gen4 x1 QMP PCIe PHYs found
on the Hawi platform.
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Matthew Leung <matthew.leung@oss.qualcomm.com>
---
.../devicetree/bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml | 6 ++++++
1 file changed, 6 insertions(+)
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 3a35120a77ec..9e9e34a63bef 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,8 @@ properties:
enum:
- qcom,glymur-qmp-gen4x2-pcie-phy
- qcom,glymur-qmp-gen5x4-pcie-phy
+ - qcom,hawi-qmp-gen3x2-pcie-phy
+ - qcom,hawi-qmp-gen4x1-pcie-phy
- qcom,kaanapali-qmp-gen3x2-pcie-phy
- qcom,qcs615-qmp-gen3x1-pcie-phy
- qcom,qcs8300-qmp-gen4x2-pcie-phy
@@ -183,6 +185,8 @@ allOf:
enum:
- qcom,glymur-qmp-gen4x2-pcie-phy
- qcom,glymur-qmp-gen5x4-pcie-phy
+ - qcom,hawi-qmp-gen3x2-pcie-phy
+ - qcom,hawi-qmp-gen4x1-pcie-phy
- qcom,qcs8300-qmp-gen4x2-pcie-phy
- qcom,sa8775p-qmp-gen4x2-pcie-phy
- qcom,sa8775p-qmp-gen4x4-pcie-phy
@@ -208,6 +212,8 @@ allOf:
enum:
- qcom,glymur-qmp-gen4x2-pcie-phy
- qcom,glymur-qmp-gen5x4-pcie-phy
+ - qcom,hawi-qmp-gen3x2-pcie-phy
+ - qcom,hawi-qmp-gen4x1-pcie-phy
- qcom,kaanapali-qmp-gen3x2-pcie-phy
- qcom,sm8550-qmp-gen4x2-pcie-phy
- qcom,sm8650-qmp-gen4x2-pcie-phy
--
2.34.1
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH v3 0/4] phy: qcom: qmp-pcie: Add PCIe PHY support for Hawi
From: Matthew Leung @ 2026-06-18 21:54 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, linux-phy, devicetree, linux-kernel, Matthew Leung,
Krzysztof Kozlowski
This series adds QMP PCIe PHY support for the Qualcomm Hawi SoC. The Hawi
platform features two PCIe PHY configurations: Gen3 x2 and Gen4 x1.
The Gen3 x2 PHY uses v10 register definitions, while the Gen4 x1 PHY uses
v10.60 register definitions.
The series adds:
- device tree bindings
- v10 register offset headers
- v10.60 register offset headers
- driver support with PHY initialization tables for both configurations
Overlap:
The series has overlap with "phy: qcom: Introduce USB support for Hawi"
by Ronak Raheja (see link [1]). Both patch series introduce a subset of
v10 registers (this series for PCIe and Ronak's for USB). I have
coordinated with Ronak regarding the overlap, and we can update the
series to resolve any overlap based on the order of merging.
Link: https://lore.kernel.org/all/20260508213234.4643-1-ronak.raheja@oss.qualcomm.com/ [1]
Signed-off-by: Matthew Leung <matthew.leung@oss.qualcomm.com>
---
Changes in v3:
- Squashed v10 register offsets into a single change
- Squashed v10.60 register offsets into a single change
- Removed USB mentions from header comments; offsets are PCIe-specific
- Reused the tx offset for the v10.60 combined txrx module instead of
introducing a separate txrx offset
- Link to v2: https://patch.msgid.link/20260604-hawi-phy-pcie-v2-0-be908d3560db@oss.qualcomm.com
Changes in v2:
- Rebased onto v7.1-rc6
- Patch 1: no change (Reviewed-by carried forward)
- Patch 9: rename QPHY_PCIE_V10_60_PCS_PCS_TX_RX_CONFIG to
QPHY_PCIE_V10_60_PCS_TX_RX_CONFIG to be consistent with the
naming convention used in previous pcs-pcie headers
- Patch 10: update usage of renamed macro
- Link to v1: https://patch.msgid.link/20260508-hawi-phy-pcie-v1-0-237b894353fc@oss.qualcomm.com
To: Vinod Koul <vkoul@kernel.org>
To: Neil Armstrong <neil.armstrong@linaro.org>
To: Rob Herring <robh@kernel.org>
To: Krzysztof Kozlowski <krzk+dt@kernel.org>
To: Conor Dooley <conor+dt@kernel.org>
Cc: linux-arm-msm@vger.kernel.org
Cc: linux-phy@lists.infradead.org
Cc: devicetree@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
Matthew Leung (4):
dt-bindings: phy: qcom,sc8280xp-qmp-pcie-phy: Add Hawi compatibles
phy: qcom-qmp: Add v10 register offsets
phy: qcom-qmp: Add v10.60 register offsets
phy: qcom: qmp-pcie: Add QMP PCIe PHY support for Hawi
.../bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml | 6 +
drivers/phy/qualcomm/phy-qcom-qmp-pcie.c | 375 +++++++++++++++++++++
drivers/phy/qualcomm/phy-qcom-qmp-pcs-pcie-v10.h | 18 +
.../phy/qualcomm/phy-qcom-qmp-pcs-pcie-v10_60.h | 26 ++
drivers/phy/qualcomm/phy-qcom-qmp-pcs-v10.h | 22 ++
drivers/phy/qualcomm/phy-qcom-qmp-pcs-v10_60.h | 23 ++
.../phy/qualcomm/phy-qcom-qmp-qserdes-com-v10.h | 49 +++
.../phy/qualcomm/phy-qcom-qmp-qserdes-com-v10_60.h | 55 +++
.../phy/qualcomm/phy-qcom-qmp-qserdes-txrx-v10.h | 47 +++
.../qualcomm/phy-qcom-qmp-qserdes-txrx-v10_60.h | 109 ++++++
drivers/phy/qualcomm/phy-qcom-qmp.h | 10 +
11 files changed, 740 insertions(+)
---
base-commit: 8cd9520d35a6c38db6567e97dd93b1f11f185dc6
change-id: 20260506-hawi-phy-pcie-283933b4113e
Best regards,
--
Matthew Leung <matthew.leung@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 2/3] dt-bindings: phy: rockchip-inno-csi-dphy: add rockchip,clk-lane-phase property
From: Conor Dooley @ 2026-06-17 21:17 UTC (permalink / raw)
To: Gerald Loacker
Cc: Vinod Koul, Neil Armstrong, Heiko Stuebner, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-phy, linux-arm-kernel,
linux-rockchip, linux-kernel, devicetree
In-Reply-To: <c34d4167-1a33-4e20-820c-735811b6a966@wolfvision.net>
[-- Attachment #1.1: Type: text/plain, Size: 2405 bytes --]
On Wed, Jun 17, 2026 at 06:20:19PM +0200, Gerald Loacker wrote:
> Hi Conor,
>
> Am 17.06.2026 um 17:51 schrieb Conor Dooley:
> > On Wed, Jun 17, 2026 at 02:23:14PM +0200, Gerald Loacker wrote:
> >> Add support for the optional rockchip,clk-lane-phase device tree property
> >> to allow board-specific tuning of the clock lane sampling phase for
> >> improved signal integrity across supported data rates.
> >>
> >> Signed-off-by: Gerald Loacker <gerald.loacker@wolfvision.net>
> >> ---
> >> Documentation/devicetree/bindings/phy/rockchip-inno-csi-dphy.yaml | 7 +++++++
> >> 1 file changed, 7 insertions(+)
> >>
> >> diff --git a/Documentation/devicetree/bindings/phy/rockchip-inno-csi-dphy.yaml b/Documentation/devicetree/bindings/phy/rockchip-inno-csi-dphy.yaml
> >> index 03950b3cad08c..0d824d1511bc0 100644
> >> --- a/Documentation/devicetree/bindings/phy/rockchip-inno-csi-dphy.yaml
> >> +++ b/Documentation/devicetree/bindings/phy/rockchip-inno-csi-dphy.yaml
> >> @@ -56,6 +56,13 @@ properties:
> >> description:
> >> Some additional phy settings are access through GRF regs.
> >>
> >> + rockchip,clk-lane-phase:
> >> + $ref: /schemas/types.yaml#/definitions/uint32
> >> + minimum: 0
> >> + maximum: 7
> >> + description:
> >> + Clock lane sampling phase in 40 ps steps. The hardware default is 3.
> >
> > Can this instead become rockchip,clk-lane-phase-ps and be listed in the
> > actual unit?
> > With the -ps suffix, you can then drop the $ref.
> > The default should be listed as "default: 3" (or default: 120)
> >
> > pw-bot: changes-requested
> >
>
> Thanks for the suggestion.
>
> The phase setting is a hardware tap index (0–7) selecting a delay line
> position. The datasheet mentions “about 40 ps” per step, but this is not
> a calibrated or guaranteed value and may vary with PVT.
>
> Because of that, I’d prefer to keep the property as an index and
> document the approximate delay in the description:
>
> Clock lane sampling phase selection (hardware tap index 0–7). Each step
> corresponds to an approximately 40 ps delay as described in the hardware
> specification.
>
> This matches the hardware model more closely. Happy to adjust if needed.
>
Sure, I think that's fair.
> >> +
> >> required:
> >> - compatible
> >> - reg
> >>
> >> --
> >> 2.34.1
> >>
>
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
[-- Attachment #2: Type: text/plain, Size: 112 bytes --]
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 2/3] dt-bindings: phy: rockchip-inno-csi-dphy: add rockchip,clk-lane-phase property
From: Gerald Loacker @ 2026-06-17 16:20 UTC (permalink / raw)
To: Conor Dooley
Cc: Vinod Koul, Neil Armstrong, Heiko Stuebner, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-phy, linux-arm-kernel,
linux-rockchip, linux-kernel, devicetree
In-Reply-To: <20260617-deviate-sulk-c57104ef939f@spud>
Hi Conor,
Am 17.06.2026 um 17:51 schrieb Conor Dooley:
> On Wed, Jun 17, 2026 at 02:23:14PM +0200, Gerald Loacker wrote:
>> Add support for the optional rockchip,clk-lane-phase device tree property
>> to allow board-specific tuning of the clock lane sampling phase for
>> improved signal integrity across supported data rates.
>>
>> Signed-off-by: Gerald Loacker <gerald.loacker@wolfvision.net>
>> ---
>> Documentation/devicetree/bindings/phy/rockchip-inno-csi-dphy.yaml | 7 +++++++
>> 1 file changed, 7 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/phy/rockchip-inno-csi-dphy.yaml b/Documentation/devicetree/bindings/phy/rockchip-inno-csi-dphy.yaml
>> index 03950b3cad08c..0d824d1511bc0 100644
>> --- a/Documentation/devicetree/bindings/phy/rockchip-inno-csi-dphy.yaml
>> +++ b/Documentation/devicetree/bindings/phy/rockchip-inno-csi-dphy.yaml
>> @@ -56,6 +56,13 @@ properties:
>> description:
>> Some additional phy settings are access through GRF regs.
>>
>> + rockchip,clk-lane-phase:
>> + $ref: /schemas/types.yaml#/definitions/uint32
>> + minimum: 0
>> + maximum: 7
>> + description:
>> + Clock lane sampling phase in 40 ps steps. The hardware default is 3.
>
> Can this instead become rockchip,clk-lane-phase-ps and be listed in the
> actual unit?
> With the -ps suffix, you can then drop the $ref.
> The default should be listed as "default: 3" (or default: 120)
>
> pw-bot: changes-requested
>
Thanks for the suggestion.
The phase setting is a hardware tap index (0–7) selecting a delay line
position. The datasheet mentions “about 40 ps” per step, but this is not
a calibrated or guaranteed value and may vary with PVT.
Because of that, I’d prefer to keep the property as an index and
document the approximate delay in the description:
Clock lane sampling phase selection (hardware tap index 0–7). Each step
corresponds to an approximately 40 ps delay as described in the hardware
specification.
This matches the hardware model more closely. Happy to adjust if needed.
>> +
>> required:
>> - compatible
>> - reg
>>
>> --
>> 2.34.1
>>
--
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