* [PATCH 1/6] dt-bindings: phy: qcom,qmp-pcie: Add X1P42100 PCIe Gen4x4 PHY
2025-01-25 3:31 [PATCH 0/6] X1P42100 DT and PCIe PHY bits Konrad Dybcio
@ 2025-01-25 3:31 ` Konrad Dybcio
2025-01-27 8:24 ` Krzysztof Kozlowski
2025-01-25 3:31 ` [PATCH 2/6] dt-bindings: phy: qcom,qmp-pcie: Drop reset number constraints Konrad Dybcio
` (5 subsequent siblings)
6 siblings, 1 reply; 22+ messages in thread
From: Konrad Dybcio @ 2025-01-25 3:31 UTC (permalink / raw)
To: Vinod Koul, Kishon Vijay Abraham I, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Konrad Dybcio
Cc: Marijn Suijten, linux-arm-msm, linux-phy, devicetree,
linux-kernel, Konrad Dybcio
From: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
X1P42100 has two Gen4x4 PHYs instead of one Gen4x4 and one Gen4x8.
They are mostly identical to X1E80100's Gen4x4 PHY, but there are some
minor details in the programming sequences.
Introduce a new compatible for this flavor of the PHY.
Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
---
Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml | 4 ++++
1 file changed, 4 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 89391649e0b5cb7e778b51fe61fb445d1f17eaf5..f1ffc3d5cae44b8a9c96cdcd749a6e54533c94f6 100644
--- a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml
@@ -45,6 +45,7 @@ properties:
- qcom,x1e80100-qmp-gen4x2-pcie-phy
- qcom,x1e80100-qmp-gen4x4-pcie-phy
- qcom,x1e80100-qmp-gen4x8-pcie-phy
+ - qcom,x1p42100-qmp-gen4x4-pcie-phy
reg:
minItems: 1
@@ -124,6 +125,7 @@ allOf:
enum:
- qcom,sc8280xp-qmp-gen3x4-pcie-phy
- qcom,x1e80100-qmp-gen4x4-pcie-phy
+ - qcom,x1p42100-qmp-gen4x4-pcie-phy
then:
properties:
reg:
@@ -180,6 +182,7 @@ allOf:
- qcom,x1e80100-qmp-gen4x2-pcie-phy
- qcom,x1e80100-qmp-gen4x4-pcie-phy
- qcom,x1e80100-qmp-gen4x8-pcie-phy
+ - qcom,x1p42100-qmp-gen4x4-pcie-phy
then:
properties:
clocks:
@@ -211,6 +214,7 @@ allOf:
- qcom,x1e80100-qmp-gen4x2-pcie-phy
- qcom,x1e80100-qmp-gen4x4-pcie-phy
- qcom,x1e80100-qmp-gen4x8-pcie-phy
+ - qcom,x1p42100-qmp-gen4x4-pcie-phy
then:
properties:
resets:
--
2.48.1
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related [flat|nested] 22+ messages in thread* Re: [PATCH 1/6] dt-bindings: phy: qcom,qmp-pcie: Add X1P42100 PCIe Gen4x4 PHY
2025-01-25 3:31 ` [PATCH 1/6] dt-bindings: phy: qcom,qmp-pcie: Add X1P42100 PCIe Gen4x4 PHY Konrad Dybcio
@ 2025-01-27 8:24 ` Krzysztof Kozlowski
0 siblings, 0 replies; 22+ messages in thread
From: Krzysztof Kozlowski @ 2025-01-27 8:24 UTC (permalink / raw)
To: Konrad Dybcio
Cc: Vinod Koul, Kishon Vijay Abraham I, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Marijn Suijten, linux-arm-msm, linux-phy, devicetree,
linux-kernel, Konrad Dybcio
On Sat, Jan 25, 2025 at 04:31:17AM +0100, Konrad Dybcio wrote:
> From: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
>
> X1P42100 has two Gen4x4 PHYs instead of one Gen4x4 and one Gen4x8.
>
> They are mostly identical to X1E80100's Gen4x4 PHY, but there are some
> minor details in the programming sequences.
>
> Introduce a new compatible for this flavor of the PHY.
>
> Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
> ---
> Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml | 4 ++++
> 1 file changed, 4 insertions(+)
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Best regards,
Krzysztof
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply [flat|nested] 22+ messages in thread
* [PATCH 2/6] dt-bindings: phy: qcom,qmp-pcie: Drop reset number constraints
2025-01-25 3:31 [PATCH 0/6] X1P42100 DT and PCIe PHY bits Konrad Dybcio
2025-01-25 3:31 ` [PATCH 1/6] dt-bindings: phy: qcom,qmp-pcie: Add X1P42100 PCIe Gen4x4 PHY Konrad Dybcio
@ 2025-01-25 3:31 ` Konrad Dybcio
2025-01-27 8:26 ` Krzysztof Kozlowski
2025-01-25 3:31 ` [PATCH 3/6] phy: qcom: qmp-pcie: Add X1P42100 Gen4x4 PHY Konrad Dybcio
` (4 subsequent siblings)
6 siblings, 1 reply; 22+ messages in thread
From: Konrad Dybcio @ 2025-01-25 3:31 UTC (permalink / raw)
To: Vinod Koul, Kishon Vijay Abraham I, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Konrad Dybcio
Cc: Marijn Suijten, linux-arm-msm, linux-phy, devicetree,
linux-kernel, Konrad Dybcio
From: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
(Almost?) all QMP PHYs come with both a "full reset" ("phy") and a
"retain certain registers" one ("phy_nocsr").
Drop the maxItems=1 constraint for resets and reset_names as we go
ahead and straighten out the DT usage. After that's done (which
will involve modifying some clock drivers etc.), we may set
*min*Items to 2, bar some possible exceptions.
Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
---
.../bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml | 24 ----------------------
1 file changed, 24 deletions(-)
diff --git a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml
index f1ffc3d5cae44b8a9c96cdcd749a6e54533c94f6..c42143bd139e30d1beabc9099d0dde17128413bf 100644
--- a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml
@@ -204,30 +204,6 @@ allOf:
clock-names:
minItems: 7
- - if:
- properties:
- compatible:
- contains:
- enum:
- - qcom,sm8550-qmp-gen4x2-pcie-phy
- - qcom,sm8650-qmp-gen4x2-pcie-phy
- - qcom,x1e80100-qmp-gen4x2-pcie-phy
- - qcom,x1e80100-qmp-gen4x4-pcie-phy
- - qcom,x1e80100-qmp-gen4x8-pcie-phy
- - qcom,x1p42100-qmp-gen4x4-pcie-phy
- then:
- properties:
- resets:
- minItems: 2
- reset-names:
- minItems: 2
- else:
- properties:
- resets:
- maxItems: 1
- reset-names:
- maxItems: 1
-
- if:
properties:
compatible:
--
2.48.1
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related [flat|nested] 22+ messages in thread* Re: [PATCH 2/6] dt-bindings: phy: qcom,qmp-pcie: Drop reset number constraints
2025-01-25 3:31 ` [PATCH 2/6] dt-bindings: phy: qcom,qmp-pcie: Drop reset number constraints Konrad Dybcio
@ 2025-01-27 8:26 ` Krzysztof Kozlowski
2025-02-01 15:56 ` Konrad Dybcio
0 siblings, 1 reply; 22+ messages in thread
From: Krzysztof Kozlowski @ 2025-01-27 8:26 UTC (permalink / raw)
To: Konrad Dybcio
Cc: Vinod Koul, Kishon Vijay Abraham I, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Marijn Suijten, linux-arm-msm, linux-phy, devicetree,
linux-kernel, Konrad Dybcio
On Sat, Jan 25, 2025 at 04:31:18AM +0100, Konrad Dybcio wrote:
> From: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
>
> (Almost?) all QMP PHYs come with both a "full reset" ("phy") and a
> "retain certain registers" one ("phy_nocsr").
>
> Drop the maxItems=1 constraint for resets and reset_names as we go
> ahead and straighten out the DT usage. After that's done (which
> will involve modifying some clock drivers etc.), we may set
> *min*Items to 2, bar some possible exceptions.
You drop minItems now, so that's a bit confusing. If all devices have
two resets, just change in top-level resets the minItems -> 2 now and
mention that it does not affect the ABI, because Linux will support
missing reset and it describes the hardware more accurately.
>
> Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
> ---
> .../bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml | 24 ----------------------
> 1 file changed, 24 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml
> index f1ffc3d5cae44b8a9c96cdcd749a6e54533c94f6..c42143bd139e30d1beabc9099d0dde17128413bf 100644
> --- a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml
> +++ b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml
> @@ -204,30 +204,6 @@ allOf:
> clock-names:
> minItems: 7
>
> - - if:
> - properties:
> - compatible:
> - contains:
> - enum:
> - - qcom,sm8550-qmp-gen4x2-pcie-phy
> - - qcom,sm8650-qmp-gen4x2-pcie-phy
> - - qcom,x1e80100-qmp-gen4x2-pcie-phy
> - - qcom,x1e80100-qmp-gen4x4-pcie-phy
> - - qcom,x1e80100-qmp-gen4x8-pcie-phy
> - - qcom,x1p42100-qmp-gen4x4-pcie-phy
You just added this line, so this patch should be #1.
Best regards,
Krzysztof
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply [flat|nested] 22+ messages in thread* Re: [PATCH 2/6] dt-bindings: phy: qcom,qmp-pcie: Drop reset number constraints
2025-01-27 8:26 ` Krzysztof Kozlowski
@ 2025-02-01 15:56 ` Konrad Dybcio
2025-02-02 14:35 ` Krzysztof Kozlowski
0 siblings, 1 reply; 22+ messages in thread
From: Konrad Dybcio @ 2025-02-01 15:56 UTC (permalink / raw)
To: Krzysztof Kozlowski, Konrad Dybcio
Cc: Vinod Koul, Kishon Vijay Abraham I, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Marijn Suijten, linux-arm-msm, linux-phy, devicetree,
linux-kernel, Konrad Dybcio
On 27.01.2025 9:26 AM, Krzysztof Kozlowski wrote:
> On Sat, Jan 25, 2025 at 04:31:18AM +0100, Konrad Dybcio wrote:
>> From: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
>>
>> (Almost?) all QMP PHYs come with both a "full reset" ("phy") and a
>> "retain certain registers" one ("phy_nocsr").
>>
>> Drop the maxItems=1 constraint for resets and reset_names as we go
>> ahead and straighten out the DT usage. After that's done (which
>> will involve modifying some clock drivers etc.), we may set
>> *min*Items to 2, bar some possible exceptions.
>
> You drop minItems now, so that's a bit confusing. If all devices have
> two resets, just change in top-level resets the minItems -> 2 now and
> mention that it does not affect the ABI, because Linux will support
> missing reset and it describes the hardware more accurately.
This will generate a ton of warnings and resolving them may take an
additional cycle, as I'd need to get things merged through clk too,
so I thought this is a good transitional solution
Konrad
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply [flat|nested] 22+ messages in thread* Re: [PATCH 2/6] dt-bindings: phy: qcom,qmp-pcie: Drop reset number constraints
2025-02-01 15:56 ` Konrad Dybcio
@ 2025-02-02 14:35 ` Krzysztof Kozlowski
2025-02-03 13:03 ` Konrad Dybcio
0 siblings, 1 reply; 22+ messages in thread
From: Krzysztof Kozlowski @ 2025-02-02 14:35 UTC (permalink / raw)
To: Konrad Dybcio, Konrad Dybcio
Cc: Vinod Koul, Kishon Vijay Abraham I, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Marijn Suijten, linux-arm-msm, linux-phy, devicetree,
linux-kernel
On 01/02/2025 16:56, Konrad Dybcio wrote:
> On 27.01.2025 9:26 AM, Krzysztof Kozlowski wrote:
>> On Sat, Jan 25, 2025 at 04:31:18AM +0100, Konrad Dybcio wrote:
>>> From: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
>>>
>>> (Almost?) all QMP PHYs come with both a "full reset" ("phy") and a
>>> "retain certain registers" one ("phy_nocsr").
>>>
>>> Drop the maxItems=1 constraint for resets and reset_names as we go
>>> ahead and straighten out the DT usage. After that's done (which
>>> will involve modifying some clock drivers etc.), we may set
>>> *min*Items to 2, bar some possible exceptions.
>>
>> You drop minItems now, so that's a bit confusing. If all devices have
>> two resets, just change in top-level resets the minItems -> 2 now and
>> mention that it does not affect the ABI, because Linux will support
>> missing reset and it describes the hardware more accurately.
>
> This will generate a ton of warnings and resolving them may take an
> additional cycle, as I'd need to get things merged through clk too,
> so I thought this is a good transitional solution
I still don't understand why existing devices now get 1 reset, while
previously they had minItems:2.
Best regards,
Krzysztof
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply [flat|nested] 22+ messages in thread* Re: [PATCH 2/6] dt-bindings: phy: qcom,qmp-pcie: Drop reset number constraints
2025-02-02 14:35 ` Krzysztof Kozlowski
@ 2025-02-03 13:03 ` Konrad Dybcio
2025-02-03 14:17 ` Krzysztof Kozlowski
0 siblings, 1 reply; 22+ messages in thread
From: Konrad Dybcio @ 2025-02-03 13:03 UTC (permalink / raw)
To: Krzysztof Kozlowski, Konrad Dybcio, Konrad Dybcio
Cc: Vinod Koul, Kishon Vijay Abraham I, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Marijn Suijten, linux-arm-msm, linux-phy, devicetree,
linux-kernel
On 2.02.2025 3:35 PM, Krzysztof Kozlowski wrote:
> On 01/02/2025 16:56, Konrad Dybcio wrote:
>> On 27.01.2025 9:26 AM, Krzysztof Kozlowski wrote:
>>> On Sat, Jan 25, 2025 at 04:31:18AM +0100, Konrad Dybcio wrote:
>>>> From: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
>>>>
>>>> (Almost?) all QMP PHYs come with both a "full reset" ("phy") and a
>>>> "retain certain registers" one ("phy_nocsr").
>>>>
>>>> Drop the maxItems=1 constraint for resets and reset_names as we go
>>>> ahead and straighten out the DT usage. After that's done (which
>>>> will involve modifying some clock drivers etc.), we may set
>>>> *min*Items to 2, bar some possible exceptions.
>>>
>>> You drop minItems now, so that's a bit confusing. If all devices have
>>> two resets, just change in top-level resets the minItems -> 2 now and
>>> mention that it does not affect the ABI, because Linux will support
>>> missing reset and it describes the hardware more accurately.
>>
>> This will generate a ton of warnings and resolving them may take an
>> additional cycle, as I'd need to get things merged through clk too,
>> so I thought this is a good transitional solution
>
> I still don't understand why existing devices now get 1 reset, while
> previously they had minItems:2.
Hm, right..
Would it make sense to just remove the else: branch?
Konrad
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply [flat|nested] 22+ messages in thread* Re: [PATCH 2/6] dt-bindings: phy: qcom,qmp-pcie: Drop reset number constraints
2025-02-03 13:03 ` Konrad Dybcio
@ 2025-02-03 14:17 ` Krzysztof Kozlowski
0 siblings, 0 replies; 22+ messages in thread
From: Krzysztof Kozlowski @ 2025-02-03 14:17 UTC (permalink / raw)
To: Konrad Dybcio, Konrad Dybcio
Cc: Vinod Koul, Kishon Vijay Abraham I, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Marijn Suijten, linux-arm-msm, linux-phy, devicetree,
linux-kernel
On 03/02/2025 14:03, Konrad Dybcio wrote:
> On 2.02.2025 3:35 PM, Krzysztof Kozlowski wrote:
>> On 01/02/2025 16:56, Konrad Dybcio wrote:
>>> On 27.01.2025 9:26 AM, Krzysztof Kozlowski wrote:
>>>> On Sat, Jan 25, 2025 at 04:31:18AM +0100, Konrad Dybcio wrote:
>>>>> From: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
>>>>>
>>>>> (Almost?) all QMP PHYs come with both a "full reset" ("phy") and a
>>>>> "retain certain registers" one ("phy_nocsr").
>>>>>
>>>>> Drop the maxItems=1 constraint for resets and reset_names as we go
>>>>> ahead and straighten out the DT usage. After that's done (which
>>>>> will involve modifying some clock drivers etc.), we may set
>>>>> *min*Items to 2, bar some possible exceptions.
>>>>
>>>> You drop minItems now, so that's a bit confusing. If all devices have
>>>> two resets, just change in top-level resets the minItems -> 2 now and
>>>> mention that it does not affect the ABI, because Linux will support
>>>> missing reset and it describes the hardware more accurately.
>>>
>>> This will generate a ton of warnings and resolving them may take an
>>> additional cycle, as I'd need to get things merged through clk too,
>>> so I thought this is a good transitional solution
>>
>> I still don't understand why existing devices now get 1 reset, while
>> previously they had minItems:2.
>
> Hm, right..
>
> Would it make sense to just remove the else: branch?
Yes, I guess that's what you want to achieve here.
Best regards,
Krzysztof
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply [flat|nested] 22+ messages in thread
* [PATCH 3/6] phy: qcom: qmp-pcie: Add X1P42100 Gen4x4 PHY
2025-01-25 3:31 [PATCH 0/6] X1P42100 DT and PCIe PHY bits Konrad Dybcio
2025-01-25 3:31 ` [PATCH 1/6] dt-bindings: phy: qcom,qmp-pcie: Add X1P42100 PCIe Gen4x4 PHY Konrad Dybcio
2025-01-25 3:31 ` [PATCH 2/6] dt-bindings: phy: qcom,qmp-pcie: Drop reset number constraints Konrad Dybcio
@ 2025-01-25 3:31 ` Konrad Dybcio
2025-01-25 17:30 ` Dmitry Baryshkov
2025-01-25 3:31 ` [PATCH 4/6] arm64: dts: qcom: x1e80100: Wire up PCIe PHY NOCSR resets Konrad Dybcio
` (3 subsequent siblings)
6 siblings, 1 reply; 22+ messages in thread
From: Konrad Dybcio @ 2025-01-25 3:31 UTC (permalink / raw)
To: Vinod Koul, Kishon Vijay Abraham I, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Konrad Dybcio
Cc: Marijn Suijten, linux-arm-msm, linux-phy, devicetree,
linux-kernel, Konrad Dybcio
From: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Add a new, common configuration for Gen4x4 V6 PHYs without an init
sequence.
The bootloader configures the hardware once and the OS retains that
configuration by using the NOCSR reset line (which doesn't drop
register state on assert) in place of the "full reset" one.
Use this new configuration for X1P42100's Gen4x4 PHY.
Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
---
drivers/phy/qualcomm/phy-qcom-qmp-pcie.c | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
diff --git a/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c b/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c
index 58103e87540ad84faca708debf61d79fe9f9ac54..68befe2901944b7f39e5adc12208c4b5578d94b1 100644
--- a/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c
+++ b/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c
@@ -4150,6 +4150,21 @@ static const struct qmp_phy_cfg x1e80100_qmp_gen4x8_pciephy_cfg = {
.phy_status = PHYSTATUS_4_20,
};
+static const struct qmp_phy_cfg qmp_v6_gen4x4_pciephy_cfg = {
+ .lanes = 4,
+
+ .offsets = &qmp_pcie_offsets_v6_20,
+
+ .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_v6_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;
@@ -4981,6 +4996,9 @@ static const struct of_device_id qmp_pcie_of_match_table[] = {
}, {
.compatible = "qcom,x1e80100-qmp-gen4x8-pcie-phy",
.data = &x1e80100_qmp_gen4x8_pciephy_cfg,
+ }, {
+ .compatible = "qcom,x1p42100-qmp-gen4x4-pcie-phy",
+ .data = &qmp_v6_gen4x4_pciephy_cfg,
},
{ },
};
--
2.48.1
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related [flat|nested] 22+ messages in thread* Re: [PATCH 3/6] phy: qcom: qmp-pcie: Add X1P42100 Gen4x4 PHY
2025-01-25 3:31 ` [PATCH 3/6] phy: qcom: qmp-pcie: Add X1P42100 Gen4x4 PHY Konrad Dybcio
@ 2025-01-25 17:30 ` Dmitry Baryshkov
2025-01-26 7:29 ` Manivannan Sadhasivam
0 siblings, 1 reply; 22+ messages in thread
From: Dmitry Baryshkov @ 2025-01-25 17:30 UTC (permalink / raw)
To: Konrad Dybcio
Cc: Vinod Koul, Kishon Vijay Abraham I, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Marijn Suijten, linux-arm-msm, linux-phy, devicetree,
linux-kernel, Konrad Dybcio
On Sat, Jan 25, 2025 at 04:31:19AM +0100, Konrad Dybcio wrote:
> From: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
>
> Add a new, common configuration for Gen4x4 V6 PHYs without an init
> sequence.
>
> The bootloader configures the hardware once and the OS retains that
> configuration by using the NOCSR reset line (which doesn't drop
> register state on assert) in place of the "full reset" one.
I know your opinion, but my 2c would still be for not depending on the
bootloader. I think that was the rule for ages for many possible
reasons.
>
> Use this new configuration for X1P42100's Gen4x4 PHY.
>
> Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
> ---
> drivers/phy/qualcomm/phy-qcom-qmp-pcie.c | 18 ++++++++++++++++++
> 1 file changed, 18 insertions(+)
--
With best wishes
Dmitry
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 3/6] phy: qcom: qmp-pcie: Add X1P42100 Gen4x4 PHY
2025-01-25 17:30 ` Dmitry Baryshkov
@ 2025-01-26 7:29 ` Manivannan Sadhasivam
2025-01-26 11:39 ` Dmitry Baryshkov
0 siblings, 1 reply; 22+ messages in thread
From: Manivannan Sadhasivam @ 2025-01-26 7:29 UTC (permalink / raw)
To: Dmitry Baryshkov, Konrad Dybcio
Cc: Vinod Koul, Kishon Vijay Abraham I, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Marijn Suijten, linux-arm-msm, linux-phy, devicetree,
linux-kernel, Konrad Dybcio
On January 25, 2025 11:00:23 PM GMT+05:30, Dmitry Baryshkov <dmitry.baryshkov@linaro.org> wrote:
>On Sat, Jan 25, 2025 at 04:31:19AM +0100, Konrad Dybcio wrote:
>> From: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
>>
>> Add a new, common configuration for Gen4x4 V6 PHYs without an init
>> sequence.
>>
>> The bootloader configures the hardware once and the OS retains that
>> configuration by using the NOCSR reset line (which doesn't drop
>> register state on assert) in place of the "full reset" one.
>
>I know your opinion, but my 2c would still be for not depending on the
>bootloader. I think that was the rule for ages for many possible
>reasons.
>
But if Linux or other OS can trust the bootloader, then it makes perfect sense to rely on them. Obviously, the question here is that on which platforms this level of trust should be established. And the answer I got was starting from the compute platforms (atleast X1E).
So let's take it on an experimental basis and see how it goes? If at all any problem arises, we can always resort to in kernel sequences.
- Mani
>>
>> Use this new configuration for X1P42100's Gen4x4 PHY.
>>
>> Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
>> ---
>> drivers/phy/qualcomm/phy-qcom-qmp-pcie.c | 18 ++++++++++++++++++
>> 1 file changed, 18 insertions(+)
>
மணிவண்ணன் சதாசிவம்
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 3/6] phy: qcom: qmp-pcie: Add X1P42100 Gen4x4 PHY
2025-01-26 7:29 ` Manivannan Sadhasivam
@ 2025-01-26 11:39 ` Dmitry Baryshkov
2025-01-26 16:32 ` Manivannan Sadhasivam
0 siblings, 1 reply; 22+ messages in thread
From: Dmitry Baryshkov @ 2025-01-26 11:39 UTC (permalink / raw)
To: Manivannan Sadhasivam
Cc: Konrad Dybcio, Vinod Koul, Kishon Vijay Abraham I, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Marijn Suijten, linux-arm-msm, linux-phy, devicetree,
linux-kernel, Konrad Dybcio
On Sun, Jan 26, 2025 at 12:59:52PM +0530, Manivannan Sadhasivam wrote:
>
>
> On January 25, 2025 11:00:23 PM GMT+05:30, Dmitry Baryshkov <dmitry.baryshkov@linaro.org> wrote:
> >On Sat, Jan 25, 2025 at 04:31:19AM +0100, Konrad Dybcio wrote:
> >> From: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
> >>
> >> Add a new, common configuration for Gen4x4 V6 PHYs without an init
> >> sequence.
> >>
> >> The bootloader configures the hardware once and the OS retains that
> >> configuration by using the NOCSR reset line (which doesn't drop
> >> register state on assert) in place of the "full reset" one.
> >
> >I know your opinion, but my 2c would still be for not depending on the
> >bootloader. I think that was the rule for ages for many possible
> >reasons.
> >
>
> But if Linux or other OS can trust the bootloader, then it makes perfect sense to rely on them. Obviously, the question here is that on which platforms this level of trust should be established. And the answer I got was starting from the compute platforms (atleast X1E).
Is there any way how those values can be lost that we still might want
to support ? The GDSC going to the OFF state? Some deep sleep state or a
power collapse? Actual suspend to RAM (instead of current S2Idle)?
>
> So let's take it on an experimental basis and see how it goes? If at all any problem arises, we can always resort to in kernel sequences.
Sounds like a good proposal. Can possibly have a corresponding 'do not
merge' patch with actual init tables?
>
> - Mani
>
> >>
> >> Use this new configuration for X1P42100's Gen4x4 PHY.
> >>
> >> Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
> >> ---
> >> drivers/phy/qualcomm/phy-qcom-qmp-pcie.c | 18 ++++++++++++++++++
> >> 1 file changed, 18 insertions(+)
> >
>
> மணிவண்ணன் சதாசிவம்
--
With best wishes
Dmitry
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 3/6] phy: qcom: qmp-pcie: Add X1P42100 Gen4x4 PHY
2025-01-26 11:39 ` Dmitry Baryshkov
@ 2025-01-26 16:32 ` Manivannan Sadhasivam
2025-01-26 21:43 ` Dmitry Baryshkov
0 siblings, 1 reply; 22+ messages in thread
From: Manivannan Sadhasivam @ 2025-01-26 16:32 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Konrad Dybcio, Vinod Koul, Kishon Vijay Abraham I, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Marijn Suijten, linux-arm-msm, linux-phy, devicetree,
linux-kernel, Konrad Dybcio
On Sun, Jan 26, 2025 at 01:39:05PM +0200, Dmitry Baryshkov wrote:
> On Sun, Jan 26, 2025 at 12:59:52PM +0530, Manivannan Sadhasivam wrote:
> >
> >
> > On January 25, 2025 11:00:23 PM GMT+05:30, Dmitry Baryshkov <dmitry.baryshkov@linaro.org> wrote:
> > >On Sat, Jan 25, 2025 at 04:31:19AM +0100, Konrad Dybcio wrote:
> > >> From: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
> > >>
> > >> Add a new, common configuration for Gen4x4 V6 PHYs without an init
> > >> sequence.
> > >>
> > >> The bootloader configures the hardware once and the OS retains that
> > >> configuration by using the NOCSR reset line (which doesn't drop
> > >> register state on assert) in place of the "full reset" one.
> > >
> > >I know your opinion, but my 2c would still be for not depending on the
> > >bootloader. I think that was the rule for ages for many possible
> > >reasons.
> > >
> >
> > But if Linux or other OS can trust the bootloader, then it makes perfect sense to rely on them. Obviously, the question here is that on which platforms this level of trust should be established. And the answer I got was starting from the compute platforms (atleast X1E).
>
> Is there any way how those values can be lost that we still might want
> to support ? The GDSC going to the OFF state? Some deep sleep state or a
> power collapse? Actual suspend to RAM (instead of current S2Idle)?
>
As per Konrad's reply to my identical question, PHY register state is supposed
to be maintained by MX domain even during CX PC. This seem to be case on X1E
based platforms (compute).
> >
> > So let's take it on an experimental basis and see how it goes? If at all any problem arises, we can always resort to in kernel sequences.
>
> Sounds like a good proposal. Can possibly have a corresponding 'do not
> merge' patch with actual init tables?
>
I don't find it really required. If the init sequences are really needed, we
know where to find them.
- Mani
--
மணிவண்ணன் சதாசிவம்
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 3/6] phy: qcom: qmp-pcie: Add X1P42100 Gen4x4 PHY
2025-01-26 16:32 ` Manivannan Sadhasivam
@ 2025-01-26 21:43 ` Dmitry Baryshkov
2025-01-27 5:34 ` Manivannan Sadhasivam
0 siblings, 1 reply; 22+ messages in thread
From: Dmitry Baryshkov @ 2025-01-26 21:43 UTC (permalink / raw)
To: Manivannan Sadhasivam
Cc: Konrad Dybcio, Vinod Koul, Kishon Vijay Abraham I, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Marijn Suijten, linux-arm-msm, linux-phy, devicetree,
linux-kernel, Konrad Dybcio
On Sun, 26 Jan 2025 at 18:32, Manivannan Sadhasivam
<manivannan.sadhasivam@linaro.org> wrote:
>
> On Sun, Jan 26, 2025 at 01:39:05PM +0200, Dmitry Baryshkov wrote:
> > On Sun, Jan 26, 2025 at 12:59:52PM +0530, Manivannan Sadhasivam wrote:
> > >
> > >
> > > On January 25, 2025 11:00:23 PM GMT+05:30, Dmitry Baryshkov <dmitry.baryshkov@linaro.org> wrote:
> > > >On Sat, Jan 25, 2025 at 04:31:19AM +0100, Konrad Dybcio wrote:
> > > >> From: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
> > > >>
> > > >> Add a new, common configuration for Gen4x4 V6 PHYs without an init
> > > >> sequence.
> > > >>
> > > >> The bootloader configures the hardware once and the OS retains that
> > > >> configuration by using the NOCSR reset line (which doesn't drop
> > > >> register state on assert) in place of the "full reset" one.
> > > >
> > > >I know your opinion, but my 2c would still be for not depending on the
> > > >bootloader. I think that was the rule for ages for many possible
> > > >reasons.
> > > >
> > >
> > > But if Linux or other OS can trust the bootloader, then it makes perfect sense to rely on them. Obviously, the question here is that on which platforms this level of trust should be established. And the answer I got was starting from the compute platforms (atleast X1E).
> >
> > Is there any way how those values can be lost that we still might want
> > to support ? The GDSC going to the OFF state? Some deep sleep state or a
> > power collapse? Actual suspend to RAM (instead of current S2Idle)?
> >
>
> As per Konrad's reply to my identical question, PHY register state is supposed
> to be maintained by MX domain even during CX PC. This seem to be case on X1E
> based platforms (compute).
Is MX on during S2RAM?
>
> > >
> > > So let's take it on an experimental basis and see how it goes? If at all any problem arises, we can always resort to in kernel sequences.
> >
> > Sounds like a good proposal. Can possibly have a corresponding 'do not
> > merge' patch with actual init tables?
> >
>
> I don't find it really required. If the init sequences are really needed, we
> know where to find them.
>
> - Mani
>
> --
> மணிவண்ணன் சதாசிவம்
--
With best wishes
Dmitry
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 3/6] phy: qcom: qmp-pcie: Add X1P42100 Gen4x4 PHY
2025-01-26 21:43 ` Dmitry Baryshkov
@ 2025-01-27 5:34 ` Manivannan Sadhasivam
2025-01-27 14:24 ` Dmitry Baryshkov
0 siblings, 1 reply; 22+ messages in thread
From: Manivannan Sadhasivam @ 2025-01-27 5:34 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Konrad Dybcio, Vinod Koul, Kishon Vijay Abraham I, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Marijn Suijten, linux-arm-msm, linux-phy, devicetree,
linux-kernel, Konrad Dybcio
On Sun, Jan 26, 2025 at 11:43:38PM +0200, Dmitry Baryshkov wrote:
> On Sun, 26 Jan 2025 at 18:32, Manivannan Sadhasivam
> <manivannan.sadhasivam@linaro.org> wrote:
> >
> > On Sun, Jan 26, 2025 at 01:39:05PM +0200, Dmitry Baryshkov wrote:
> > > On Sun, Jan 26, 2025 at 12:59:52PM +0530, Manivannan Sadhasivam wrote:
> > > >
> > > >
> > > > On January 25, 2025 11:00:23 PM GMT+05:30, Dmitry Baryshkov <dmitry.baryshkov@linaro.org> wrote:
> > > > >On Sat, Jan 25, 2025 at 04:31:19AM +0100, Konrad Dybcio wrote:
> > > > >> From: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
> > > > >>
> > > > >> Add a new, common configuration for Gen4x4 V6 PHYs without an init
> > > > >> sequence.
> > > > >>
> > > > >> The bootloader configures the hardware once and the OS retains that
> > > > >> configuration by using the NOCSR reset line (which doesn't drop
> > > > >> register state on assert) in place of the "full reset" one.
> > > > >
> > > > >I know your opinion, but my 2c would still be for not depending on the
> > > > >bootloader. I think that was the rule for ages for many possible
> > > > >reasons.
> > > > >
> > > >
> > > > But if Linux or other OS can trust the bootloader, then it makes perfect sense to rely on them. Obviously, the question here is that on which platforms this level of trust should be established. And the answer I got was starting from the compute platforms (atleast X1E).
> > >
> > > Is there any way how those values can be lost that we still might want
> > > to support ? The GDSC going to the OFF state? Some deep sleep state or a
> > > power collapse? Actual suspend to RAM (instead of current S2Idle)?
> > >
> >
> > As per Konrad's reply to my identical question, PHY register state is supposed
> > to be maintained by MX domain even during CX PC. This seem to be case on X1E
> > based platforms (compute).
>
> Is MX on during S2RAM?
>
Qcom says that their current s2idle implementation is equal to S2RAM (when CX PC
is achieved). In that sense, yes, MX is ON during S2RAM. Do note that, on
majority of the platforms, MX is the AON (Always ON) domain.
- Mani
--
மணிவண்ணன் சதாசிவம்
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 3/6] phy: qcom: qmp-pcie: Add X1P42100 Gen4x4 PHY
2025-01-27 5:34 ` Manivannan Sadhasivam
@ 2025-01-27 14:24 ` Dmitry Baryshkov
0 siblings, 0 replies; 22+ messages in thread
From: Dmitry Baryshkov @ 2025-01-27 14:24 UTC (permalink / raw)
To: Manivannan Sadhasivam
Cc: Konrad Dybcio, Vinod Koul, Kishon Vijay Abraham I, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Marijn Suijten, linux-arm-msm, linux-phy, devicetree,
linux-kernel, Konrad Dybcio
On Mon, Jan 27, 2025 at 11:04:12AM +0530, Manivannan Sadhasivam wrote:
> On Sun, Jan 26, 2025 at 11:43:38PM +0200, Dmitry Baryshkov wrote:
> > On Sun, 26 Jan 2025 at 18:32, Manivannan Sadhasivam
> > <manivannan.sadhasivam@linaro.org> wrote:
> > >
> > > On Sun, Jan 26, 2025 at 01:39:05PM +0200, Dmitry Baryshkov wrote:
> > > > On Sun, Jan 26, 2025 at 12:59:52PM +0530, Manivannan Sadhasivam wrote:
> > > > >
> > > > >
> > > > > On January 25, 2025 11:00:23 PM GMT+05:30, Dmitry Baryshkov <dmitry.baryshkov@linaro.org> wrote:
> > > > > >On Sat, Jan 25, 2025 at 04:31:19AM +0100, Konrad Dybcio wrote:
> > > > > >> From: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
> > > > > >>
> > > > > >> Add a new, common configuration for Gen4x4 V6 PHYs without an init
> > > > > >> sequence.
> > > > > >>
> > > > > >> The bootloader configures the hardware once and the OS retains that
> > > > > >> configuration by using the NOCSR reset line (which doesn't drop
> > > > > >> register state on assert) in place of the "full reset" one.
> > > > > >
> > > > > >I know your opinion, but my 2c would still be for not depending on the
> > > > > >bootloader. I think that was the rule for ages for many possible
> > > > > >reasons.
> > > > > >
> > > > >
> > > > > But if Linux or other OS can trust the bootloader, then it makes perfect sense to rely on them. Obviously, the question here is that on which platforms this level of trust should be established. And the answer I got was starting from the compute platforms (atleast X1E).
> > > >
> > > > Is there any way how those values can be lost that we still might want
> > > > to support ? The GDSC going to the OFF state? Some deep sleep state or a
> > > > power collapse? Actual suspend to RAM (instead of current S2Idle)?
> > > >
> > >
> > > As per Konrad's reply to my identical question, PHY register state is supposed
> > > to be maintained by MX domain even during CX PC. This seem to be case on X1E
> > > based platforms (compute).
> >
> > Is MX on during S2RAM?
> >
>
> Qcom says that their current s2idle implementation is equal to S2RAM (when CX PC
> is achieved). In that sense, yes, MX is ON during S2RAM. Do note that, on
> majority of the platforms, MX is the AON (Always ON) domain.
Acked-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
--
With best wishes
Dmitry
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply [flat|nested] 22+ messages in thread
* [PATCH 4/6] arm64: dts: qcom: x1e80100: Wire up PCIe PHY NOCSR resets
2025-01-25 3:31 [PATCH 0/6] X1P42100 DT and PCIe PHY bits Konrad Dybcio
` (2 preceding siblings ...)
2025-01-25 3:31 ` [PATCH 3/6] phy: qcom: qmp-pcie: Add X1P42100 Gen4x4 PHY Konrad Dybcio
@ 2025-01-25 3:31 ` Konrad Dybcio
2025-01-25 17:32 ` Dmitry Baryshkov
2025-01-25 3:31 ` [PATCH 5/6] arm64: dts: qcom: Commonize X1 CRD DTSI Konrad Dybcio
` (2 subsequent siblings)
6 siblings, 1 reply; 22+ messages in thread
From: Konrad Dybcio @ 2025-01-25 3:31 UTC (permalink / raw)
To: Vinod Koul, Kishon Vijay Abraham I, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Konrad Dybcio
Cc: Marijn Suijten, linux-arm-msm, linux-phy, devicetree,
linux-kernel, Konrad Dybcio
From: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Asserting the NOCSR reset line keeps the PHY registers in tact.
This allows us to avoid programming long tables of magic values in the
operating system.
Wire up these resets to PCIe PHY4 and 5 (it's there on the others).
Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/x1e80100.dtsi | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/x1e80100.dtsi b/arch/arm64/boot/dts/qcom/x1e80100.dtsi
index 9d38436763432892ceef95daf0335d4cf446357c..a244cbb84aecc23ce11414c41f2e5d0905f455ee 100644
--- a/arch/arm64/boot/dts/qcom/x1e80100.dtsi
+++ b/arch/arm64/boot/dts/qcom/x1e80100.dtsi
@@ -3558,8 +3558,10 @@ pcie5_phy: phy@1c06000 {
"pipe",
"pipediv2";
- resets = <&gcc GCC_PCIE_5_PHY_BCR>;
- reset-names = "phy";
+ resets = <&gcc GCC_PCIE_5_PHY_BCR>,
+ <&gcc GCC_PCIE_5_NOCSR_COM_PHY_BCR>;
+ reset-names = "phy",
+ "phy_nocsr";
assigned-clocks = <&gcc GCC_PCIE_5_PHY_RCHNG_CLK>;
assigned-clock-rates = <100000000>;
@@ -3692,8 +3694,10 @@ pcie4_phy: phy@1c0e000 {
"pipe",
"pipediv2";
- resets = <&gcc GCC_PCIE_4_PHY_BCR>;
- reset-names = "phy";
+ resets = <&gcc GCC_PCIE_4_PHY_BCR>,
+ <&gcc GCC_PCIE_4_NOCSR_COM_PHY_BCR>;
+ reset-names = "phy",
+ "phy_nocsr";
assigned-clocks = <&gcc GCC_PCIE_4_PHY_RCHNG_CLK>;
assigned-clock-rates = <100000000>;
--
2.48.1
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related [flat|nested] 22+ messages in thread* Re: [PATCH 4/6] arm64: dts: qcom: x1e80100: Wire up PCIe PHY NOCSR resets
2025-01-25 3:31 ` [PATCH 4/6] arm64: dts: qcom: x1e80100: Wire up PCIe PHY NOCSR resets Konrad Dybcio
@ 2025-01-25 17:32 ` Dmitry Baryshkov
0 siblings, 0 replies; 22+ messages in thread
From: Dmitry Baryshkov @ 2025-01-25 17:32 UTC (permalink / raw)
To: Konrad Dybcio
Cc: Vinod Koul, Kishon Vijay Abraham I, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Marijn Suijten, linux-arm-msm, linux-phy, devicetree,
linux-kernel, Konrad Dybcio
On Sat, Jan 25, 2025 at 04:31:20AM +0100, Konrad Dybcio wrote:
> From: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
>
> Asserting the NOCSR reset line keeps the PHY registers in tact.
> This allows us to avoid programming long tables of magic values in the
> operating system.
>
> Wire up these resets to PCIe PHY4 and 5 (it's there on the others).
>
> Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
> ---
> arch/arm64/boot/dts/qcom/x1e80100.dtsi | 12 ++++++++----
> 1 file changed, 8 insertions(+), 4 deletions(-)
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
--
With best wishes
Dmitry
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply [flat|nested] 22+ messages in thread
* [PATCH 5/6] arm64: dts: qcom: Commonize X1 CRD DTSI
2025-01-25 3:31 [PATCH 0/6] X1P42100 DT and PCIe PHY bits Konrad Dybcio
` (3 preceding siblings ...)
2025-01-25 3:31 ` [PATCH 4/6] arm64: dts: qcom: x1e80100: Wire up PCIe PHY NOCSR resets Konrad Dybcio
@ 2025-01-25 3:31 ` Konrad Dybcio
2025-01-25 3:31 ` [PATCH 6/6] arm64: dts: qcom: Add X1P42100 SoC and CRD Konrad Dybcio
2025-01-29 18:10 ` [PATCH 0/6] X1P42100 DT and PCIe PHY bits Jens Glathe
6 siblings, 0 replies; 22+ messages in thread
From: Konrad Dybcio @ 2025-01-25 3:31 UTC (permalink / raw)
To: Vinod Koul, Kishon Vijay Abraham I, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Konrad Dybcio
Cc: Marijn Suijten, linux-arm-msm, linux-phy, devicetree,
linux-kernel, Konrad Dybcio
From: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Certain X1 SKUs vary very noticeably, but the CRDs based on them don't.
Commonize the existing X1E80100 DTSI to allow reuse.
Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
---
.../dts/qcom/{x1e80100-crd.dts => x1-crd.dtsi} | 7 -
arch/arm64/boot/dts/qcom/x1e80100-crd.dts | 1270 +-------------------
arch/arm64/boot/dts/qcom/x1e80100.dtsi | 2 +-
3 files changed, 4 insertions(+), 1275 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/x1e80100-crd.dts b/arch/arm64/boot/dts/qcom/x1-crd.dtsi
similarity index 99%
copy from arch/arm64/boot/dts/qcom/x1e80100-crd.dts
copy to arch/arm64/boot/dts/qcom/x1-crd.dtsi
index ff5b3472fafd35a2a3754c11ab0b9b9e8ea5a4b4..296b41409ad1797d1da837c2674d6048932ff8ee 100644
--- a/arch/arm64/boot/dts/qcom/x1e80100-crd.dts
+++ b/arch/arm64/boot/dts/qcom/x1-crd.dtsi
@@ -3,15 +3,12 @@
* Copyright (c) 2023 Qualcomm Innovation Center, Inc. All rights reserved.
*/
-/dts-v1/;
-
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/input/gpio-keys.h>
#include <dt-bindings/input/input.h>
#include <dt-bindings/pinctrl/qcom,pmic-gpio.h>
#include <dt-bindings/regulator/qcom,rpmh-regulator.h>
-#include "x1e80100.dtsi"
#include "x1e80100-pmics.dtsi"
/ {
@@ -691,10 +688,6 @@ vreg_l3j_0p8: ldo3 {
&gpu {
status = "okay";
-
- zap-shader {
- firmware-name = "qcom/x1e80100/gen70500_zap.mbn";
- };
};
&i2c0 {
diff --git a/arch/arm64/boot/dts/qcom/x1e80100-crd.dts b/arch/arm64/boot/dts/qcom/x1e80100-crd.dts
index ff5b3472fafd35a2a3754c11ab0b9b9e8ea5a4b4..976b8e44b5763b2d6c0f4786bf5809fee29dcecc 100644
--- a/arch/arm64/boot/dts/qcom/x1e80100-crd.dts
+++ b/arch/arm64/boot/dts/qcom/x1e80100-crd.dts
@@ -5,1278 +5,14 @@
/dts-v1/;
-#include <dt-bindings/gpio/gpio.h>
-#include <dt-bindings/input/gpio-keys.h>
-#include <dt-bindings/input/input.h>
-#include <dt-bindings/pinctrl/qcom,pmic-gpio.h>
-#include <dt-bindings/regulator/qcom,rpmh-regulator.h>
-
#include "x1e80100.dtsi"
-#include "x1e80100-pmics.dtsi"
+#include "x1-crd.dtsi"
/ {
model = "Qualcomm Technologies, Inc. X1E80100 CRD";
compatible = "qcom,x1e80100-crd", "qcom,x1e80100";
-
- aliases {
- serial0 = &uart21;
- };
-
- wcd938x: audio-codec {
- compatible = "qcom,wcd9385-codec";
-
- pinctrl-names = "default";
- pinctrl-0 = <&wcd_default>;
-
- qcom,micbias1-microvolt = <1800000>;
- qcom,micbias2-microvolt = <1800000>;
- qcom,micbias3-microvolt = <1800000>;
- qcom,micbias4-microvolt = <1800000>;
- qcom,mbhc-buttons-vthreshold-microvolt = <75000 150000 237000 500000 500000 500000 500000 500000>;
- qcom,mbhc-headset-vthreshold-microvolt = <1700000>;
- qcom,mbhc-headphone-vthreshold-microvolt = <50000>;
- qcom,rx-device = <&wcd_rx>;
- qcom,tx-device = <&wcd_tx>;
-
- reset-gpios = <&tlmm 191 GPIO_ACTIVE_LOW>;
-
- vdd-buck-supply = <&vreg_l15b_1p8>;
- vdd-rxtx-supply = <&vreg_l15b_1p8>;
- vdd-io-supply = <&vreg_l15b_1p8>;
- vdd-mic-bias-supply = <&vreg_bob1>;
-
- #sound-dai-cells = <1>;
- };
-
- chosen {
- stdout-path = "serial0:115200n8";
- };
-
- gpio-keys {
- compatible = "gpio-keys";
-
- pinctrl-0 = <&hall_int_n_default>;
- pinctrl-names = "default";
-
- switch-lid {
- gpios = <&tlmm 92 GPIO_ACTIVE_LOW>;
- linux,input-type = <EV_SW>;
- linux,code = <SW_LID>;
- wakeup-source;
- wakeup-event-action = <EV_ACT_DEASSERTED>;
- };
- };
-
- pmic-glink {
- compatible = "qcom,x1e80100-pmic-glink",
- "qcom,sm8550-pmic-glink",
- "qcom,pmic-glink";
- #address-cells = <1>;
- #size-cells = <0>;
- orientation-gpios = <&tlmm 121 GPIO_ACTIVE_HIGH>,
- <&tlmm 123 GPIO_ACTIVE_HIGH>,
- <&tlmm 125 GPIO_ACTIVE_HIGH>;
-
- /* Left-side rear port */
- connector@0 {
- compatible = "usb-c-connector";
- reg = <0>;
- power-role = "dual";
- data-role = "dual";
-
- ports {
- #address-cells = <1>;
- #size-cells = <0>;
-
- port@0 {
- reg = <0>;
-
- pmic_glink_ss0_hs_in: endpoint {
- remote-endpoint = <&usb_1_ss0_dwc3_hs>;
- };
- };
-
- port@1 {
- reg = <1>;
-
- pmic_glink_ss0_ss_in: endpoint {
- remote-endpoint = <&usb_1_ss0_qmpphy_out>;
- };
- };
- };
- };
-
- /* Left-side front port */
- connector@1 {
- compatible = "usb-c-connector";
- reg = <1>;
- power-role = "dual";
- data-role = "dual";
-
- ports {
- #address-cells = <1>;
- #size-cells = <0>;
-
- port@0 {
- reg = <0>;
-
- pmic_glink_ss1_hs_in: endpoint {
- remote-endpoint = <&usb_1_ss1_dwc3_hs>;
- };
- };
-
- port@1 {
- reg = <1>;
-
- pmic_glink_ss1_ss_in: endpoint {
- remote-endpoint = <&usb_1_ss1_qmpphy_out>;
- };
- };
- };
- };
-
- /* Right-side port */
- connector@2 {
- compatible = "usb-c-connector";
- reg = <2>;
- power-role = "dual";
- data-role = "dual";
-
- ports {
- #address-cells = <1>;
- #size-cells = <0>;
-
- port@0 {
- reg = <0>;
-
- pmic_glink_ss2_hs_in: endpoint {
- remote-endpoint = <&usb_1_ss2_dwc3_hs>;
- };
- };
-
- port@1 {
- reg = <1>;
-
- pmic_glink_ss2_ss_in: endpoint {
- remote-endpoint = <&usb_1_ss2_qmpphy_out>;
- };
- };
- };
- };
- };
-
- reserved-memory {
- linux,cma {
- compatible = "shared-dma-pool";
- size = <0x0 0x8000000>;
- reusable;
- linux,cma-default;
- };
- };
-
- sound {
- compatible = "qcom,x1e80100-sndcard";
- model = "X1E80100-CRD";
- audio-routing = "WooferLeft IN", "WSA WSA_SPK1 OUT",
- "TweeterLeft IN", "WSA WSA_SPK2 OUT",
- "WooferRight IN", "WSA2 WSA_SPK2 OUT",
- "TweeterRight IN", "WSA2 WSA_SPK2 OUT",
- "IN1_HPHL", "HPHL_OUT",
- "IN2_HPHR", "HPHR_OUT",
- "AMIC2", "MIC BIAS2",
- "VA DMIC0", "MIC BIAS3",
- "VA DMIC1", "MIC BIAS3",
- "VA DMIC2", "MIC BIAS1",
- "VA DMIC3", "MIC BIAS1",
- "VA DMIC0", "VA MIC BIAS3",
- "VA DMIC1", "VA MIC BIAS3",
- "VA DMIC2", "VA MIC BIAS1",
- "VA DMIC3", "VA MIC BIAS1",
- "TX SWR_INPUT1", "ADC2_OUTPUT";
-
- wcd-playback-dai-link {
- link-name = "WCD Playback";
-
- cpu {
- sound-dai = <&q6apmbedai RX_CODEC_DMA_RX_0>;
- };
-
- codec {
- sound-dai = <&wcd938x 0>, <&swr1 0>, <&lpass_rxmacro 0>;
- };
-
- platform {
- sound-dai = <&q6apm>;
- };
- };
-
- wcd-capture-dai-link {
- link-name = "WCD Capture";
-
- cpu {
- sound-dai = <&q6apmbedai TX_CODEC_DMA_TX_3>;
- };
-
- codec {
- sound-dai = <&wcd938x 1>, <&swr2 1>, <&lpass_txmacro 0>;
- };
-
- platform {
- sound-dai = <&q6apm>;
- };
- };
-
- wsa-dai-link {
- link-name = "WSA Playback";
-
- cpu {
- sound-dai = <&q6apmbedai WSA_CODEC_DMA_RX_0>;
- };
-
- codec {
- sound-dai = <&left_woofer>, <&left_tweeter>,
- <&swr0 0>, <&lpass_wsamacro 0>,
- <&right_woofer>, <&right_tweeter>,
- <&swr3 0>, <&lpass_wsa2macro 0>;
- };
-
- platform {
- sound-dai = <&q6apm>;
- };
- };
-
- va-dai-link {
- link-name = "VA Capture";
-
- cpu {
- sound-dai = <&q6apmbedai VA_CODEC_DMA_TX_0>;
- };
-
- codec {
- sound-dai = <&lpass_vamacro 0>;
- };
-
- platform {
- sound-dai = <&q6apm>;
- };
- };
- };
-
- vreg_edp_3p3: regulator-edp-3p3 {
- compatible = "regulator-fixed";
-
- regulator-name = "VREG_EDP_3P3";
- regulator-min-microvolt = <3300000>;
- regulator-max-microvolt = <3300000>;
-
- gpio = <&tlmm 70 GPIO_ACTIVE_HIGH>;
- enable-active-high;
-
- pinctrl-0 = <&edp_reg_en>;
- pinctrl-names = "default";
-
- regulator-boot-on;
- };
-
- vreg_misc_3p3: regulator-misc-3p3 {
- compatible = "regulator-fixed";
-
- regulator-name = "VREG_MISC_3P3";
- regulator-min-microvolt = <3300000>;
- regulator-max-microvolt = <3300000>;
-
- gpio = <&pm8550ve_8_gpios 6 GPIO_ACTIVE_HIGH>;
- enable-active-high;
-
- pinctrl-names = "default";
- pinctrl-0 = <&misc_3p3_reg_en>;
-
- regulator-boot-on;
- regulator-always-on;
- };
-
- vreg_nvme: regulator-nvme {
- compatible = "regulator-fixed";
-
- regulator-name = "VREG_NVME_3P3";
- regulator-min-microvolt = <3300000>;
- regulator-max-microvolt = <3300000>;
-
- gpio = <&tlmm 18 GPIO_ACTIVE_HIGH>;
- enable-active-high;
-
- pinctrl-names = "default";
- pinctrl-0 = <&nvme_reg_en>;
-
- regulator-boot-on;
- };
-
- vph_pwr: regulator-vph-pwr {
- compatible = "regulator-fixed";
-
- regulator-name = "vph_pwr";
- regulator-min-microvolt = <3700000>;
- regulator-max-microvolt = <3700000>;
-
- regulator-always-on;
- regulator-boot-on;
- };
-
- vreg_wwan: regulator-wwan {
- compatible = "regulator-fixed";
-
- regulator-name = "SDX_VPH_PWR";
- regulator-min-microvolt = <3300000>;
- regulator-max-microvolt = <3300000>;
-
- gpio = <&tlmm 221 GPIO_ACTIVE_HIGH>;
- enable-active-high;
-
- pinctrl-0 = <&wwan_sw_en>;
- pinctrl-names = "default";
-
- regulator-boot-on;
- };
};
-&apps_rsc {
- regulators-0 {
- compatible = "qcom,pm8550-rpmh-regulators";
- qcom,pmic-id = "b";
-
- vdd-bob1-supply = <&vph_pwr>;
- vdd-bob2-supply = <&vph_pwr>;
- vdd-l1-l4-l10-supply = <&vreg_s4c_1p8>;
- vdd-l2-l13-l14-supply = <&vreg_bob1>;
- vdd-l5-l16-supply = <&vreg_bob1>;
- vdd-l6-l7-supply = <&vreg_bob2>;
- vdd-l8-l9-supply = <&vreg_bob1>;
- vdd-l12-supply = <&vreg_s5j_1p2>;
- vdd-l15-supply = <&vreg_s4c_1p8>;
- vdd-l17-supply = <&vreg_bob2>;
-
- vreg_bob1: bob1 {
- regulator-name = "vreg_bob1";
- regulator-min-microvolt = <3008000>;
- regulator-max-microvolt = <3960000>;
- regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
- };
-
- vreg_bob2: bob2 {
- regulator-name = "vreg_bob2";
- regulator-min-microvolt = <2504000>;
- regulator-max-microvolt = <3008000>;
- regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
- };
-
- vreg_l1b_1p8: ldo1 {
- regulator-name = "vreg_l1b_1p8";
- regulator-min-microvolt = <1800000>;
- regulator-max-microvolt = <1800000>;
- regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
- };
-
- vreg_l2b_3p0: ldo2 {
- regulator-name = "vreg_l2b_3p0";
- regulator-min-microvolt = <3072000>;
- regulator-max-microvolt = <3100000>;
- regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
- };
-
- vreg_l4b_1p8: ldo4 {
- regulator-name = "vreg_l4b_1p8";
- regulator-min-microvolt = <1800000>;
- regulator-max-microvolt = <1800000>;
- regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
- };
-
- vreg_l5b_3p0: ldo5 {
- regulator-name = "vreg_l5b_3p0";
- regulator-min-microvolt = <3000000>;
- regulator-max-microvolt = <3000000>;
- regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
- };
-
- vreg_l6b_1p8: ldo6 {
- regulator-name = "vreg_l6b_1p8";
- regulator-min-microvolt = <1800000>;
- regulator-max-microvolt = <2960000>;
- regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
- };
-
- vreg_l7b_2p8: ldo7 {
- regulator-name = "vreg_l7b_2p8";
- regulator-min-microvolt = <2800000>;
- regulator-max-microvolt = <2800000>;
- regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
- };
-
- vreg_l8b_3p0: ldo8 {
- regulator-name = "vreg_l8b_3p0";
- regulator-min-microvolt = <3072000>;
- regulator-max-microvolt = <3072000>;
- regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
- };
-
- vreg_l9b_2p9: ldo9 {
- regulator-name = "vreg_l9b_2p9";
- regulator-min-microvolt = <2960000>;
- regulator-max-microvolt = <2960000>;
- regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
- };
-
- vreg_l10b_1p8: ldo10 {
- regulator-name = "vreg_l10b_1p8";
- regulator-min-microvolt = <1800000>;
- regulator-max-microvolt = <1800000>;
- regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
- };
-
- vreg_l12b_1p2: ldo12 {
- regulator-name = "vreg_l12b_1p2";
- regulator-min-microvolt = <1200000>;
- regulator-max-microvolt = <1200000>;
- regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
- };
-
- vreg_l13b_3p0: ldo13 {
- regulator-name = "vreg_l13b_3p0";
- regulator-min-microvolt = <3072000>;
- regulator-max-microvolt = <3100000>;
- regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
- };
-
- vreg_l14b_3p0: ldo14 {
- regulator-name = "vreg_l14b_3p0";
- regulator-min-microvolt = <3072000>;
- regulator-max-microvolt = <3072000>;
- regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
- };
-
- vreg_l15b_1p8: ldo15 {
- regulator-name = "vreg_l15b_1p8";
- regulator-min-microvolt = <1800000>;
- regulator-max-microvolt = <1800000>;
- regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
- };
-
- vreg_l16b_2p9: ldo16 {
- regulator-name = "vreg_l16b_2p9";
- regulator-min-microvolt = <2912000>;
- regulator-max-microvolt = <2912000>;
- regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
- };
-
- vreg_l17b_2p5: ldo17 {
- regulator-name = "vreg_l17b_2p5";
- regulator-min-microvolt = <2504000>;
- regulator-max-microvolt = <2504000>;
- regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
- };
- };
-
- regulators-1 {
- compatible = "qcom,pm8550ve-rpmh-regulators";
- qcom,pmic-id = "c";
-
- vdd-l1-supply = <&vreg_s5j_1p2>;
- vdd-l2-supply = <&vreg_s1f_0p7>;
- vdd-l3-supply = <&vreg_s1f_0p7>;
- vdd-s4-supply = <&vph_pwr>;
-
- vreg_s4c_1p8: smps4 {
- regulator-name = "vreg_s4c_1p8";
- regulator-min-microvolt = <1856000>;
- regulator-max-microvolt = <2000000>;
- regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
- };
-
- vreg_l1c_1p2: ldo1 {
- regulator-name = "vreg_l1c_1p2";
- regulator-min-microvolt = <1200000>;
- regulator-max-microvolt = <1200000>;
- regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
- };
-
- vreg_l2c_0p8: ldo2 {
- regulator-name = "vreg_l2c_0p8";
- regulator-min-microvolt = <880000>;
- regulator-max-microvolt = <920000>;
- regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
- };
-
- vreg_l3c_0p8: ldo3 {
- regulator-name = "vreg_l3c_0p8";
- regulator-min-microvolt = <880000>;
- regulator-max-microvolt = <920000>;
- regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
- };
- };
-
- regulators-2 {
- compatible = "qcom,pmc8380-rpmh-regulators";
- qcom,pmic-id = "d";
-
- vdd-l1-supply = <&vreg_s1f_0p7>;
- vdd-l2-supply = <&vreg_s1f_0p7>;
- vdd-l3-supply = <&vreg_s4c_1p8>;
- vdd-s1-supply = <&vph_pwr>;
-
- vreg_l1d_0p8: ldo1 {
- regulator-name = "vreg_l1d_0p8";
- regulator-min-microvolt = <880000>;
- regulator-max-microvolt = <920000>;
- regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
- };
-
- vreg_l2d_0p9: ldo2 {
- regulator-name = "vreg_l2d_0p9";
- regulator-min-microvolt = <912000>;
- regulator-max-microvolt = <920000>;
- regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
- };
-
- vreg_l3d_1p8: ldo3 {
- regulator-name = "vreg_l3d_1p8";
- regulator-min-microvolt = <1800000>;
- regulator-max-microvolt = <1800000>;
- regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
- };
- };
-
- regulators-3 {
- compatible = "qcom,pmc8380-rpmh-regulators";
- qcom,pmic-id = "e";
-
- vdd-l2-supply = <&vreg_s1f_0p7>;
- vdd-l3-supply = <&vreg_s5j_1p2>;
-
- vreg_l2e_0p8: ldo2 {
- regulator-name = "vreg_l2e_0p8";
- regulator-min-microvolt = <880000>;
- regulator-max-microvolt = <920000>;
- regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
- };
-
- vreg_l3e_1p2: ldo3 {
- regulator-name = "vreg_l3e_1p2";
- regulator-min-microvolt = <1200000>;
- regulator-max-microvolt = <1200000>;
- regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
- };
- };
-
- regulators-4 {
- compatible = "qcom,pmc8380-rpmh-regulators";
- qcom,pmic-id = "f";
-
- vdd-l1-supply = <&vreg_s5j_1p2>;
- vdd-l2-supply = <&vreg_s5j_1p2>;
- vdd-l3-supply = <&vreg_s5j_1p2>;
- vdd-s1-supply = <&vph_pwr>;
-
- vreg_s1f_0p7: smps1 {
- regulator-name = "vreg_s1f_0p7";
- regulator-min-microvolt = <700000>;
- regulator-max-microvolt = <1100000>;
- regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
- };
-
- vreg_l1f_1p0: ldo1 {
- regulator-name = "vreg_l1f_1p0";
- regulator-min-microvolt = <1024000>;
- regulator-max-microvolt = <1024000>;
- regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
- };
-
- vreg_l2f_1p0: ldo2 {
- regulator-name = "vreg_l2f_1p0";
- regulator-min-microvolt = <1024000>;
- regulator-max-microvolt = <1024000>;
- regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
- };
-
- vreg_l3f_1p0: ldo3 {
- regulator-name = "vreg_l3f_1p0";
- regulator-min-microvolt = <1024000>;
- regulator-max-microvolt = <1024000>;
- regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
- };
- };
-
- regulators-6 {
- compatible = "qcom,pm8550ve-rpmh-regulators";
- qcom,pmic-id = "i";
-
- vdd-l1-supply = <&vreg_s4c_1p8>;
- vdd-l2-supply = <&vreg_s5j_1p2>;
- vdd-l3-supply = <&vreg_s1f_0p7>;
- vdd-s1-supply = <&vph_pwr>;
- vdd-s2-supply = <&vph_pwr>;
-
- vreg_s1i_0p9: smps1 {
- regulator-name = "vreg_s1i_0p9";
- regulator-min-microvolt = <900000>;
- regulator-max-microvolt = <920000>;
- regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
- };
-
- vreg_s2i_1p0: smps2 {
- regulator-name = "vreg_s2i_1p0";
- regulator-min-microvolt = <1000000>;
- regulator-max-microvolt = <1100000>;
- regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
- };
-
- vreg_l1i_1p8: ldo1 {
- regulator-name = "vreg_l1i_1p8";
- regulator-min-microvolt = <1800000>;
- regulator-max-microvolt = <1800000>;
- regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
- };
-
- vreg_l2i_1p2: ldo2 {
- regulator-name = "vreg_l2i_1p2";
- regulator-min-microvolt = <1200000>;
- regulator-max-microvolt = <1200000>;
- regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
- };
-
- vreg_l3i_0p8: ldo3 {
- regulator-name = "vreg_l3i_0p8";
- regulator-min-microvolt = <880000>;
- regulator-max-microvolt = <920000>;
- regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
- };
- };
-
- regulators-7 {
- compatible = "qcom,pm8550ve-rpmh-regulators";
- qcom,pmic-id = "j";
-
- vdd-l1-supply = <&vreg_s1f_0p7>;
- vdd-l2-supply = <&vreg_s5j_1p2>;
- vdd-l3-supply = <&vreg_s1f_0p7>;
- vdd-s5-supply = <&vph_pwr>;
-
- vreg_s5j_1p2: smps5 {
- regulator-name = "vreg_s5j_1p2";
- regulator-min-microvolt = <1256000>;
- regulator-max-microvolt = <1304000>;
- regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
- };
-
- vreg_l1j_0p8: ldo1 {
- regulator-name = "vreg_l1j_0p8";
- regulator-min-microvolt = <880000>;
- regulator-max-microvolt = <920000>;
- regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
- };
-
- vreg_l2j_1p2: ldo2 {
- regulator-name = "vreg_l2j_1p2";
- regulator-min-microvolt = <1200000>;
- regulator-max-microvolt = <1200000>;
- regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
- };
-
- vreg_l3j_0p8: ldo3 {
- regulator-name = "vreg_l3j_0p8";
- regulator-min-microvolt = <880000>;
- regulator-max-microvolt = <920000>;
- regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
- };
- };
-};
-
-&gpu {
- status = "okay";
-
- zap-shader {
- firmware-name = "qcom/x1e80100/gen70500_zap.mbn";
- };
-};
-
-&i2c0 {
- clock-frequency = <400000>;
-
- status = "okay";
-
- touchpad@15 {
- compatible = "hid-over-i2c";
- reg = <0x15>;
-
- hid-descr-addr = <0x1>;
- interrupts-extended = <&tlmm 3 IRQ_TYPE_LEVEL_LOW>;
-
- vdd-supply = <&vreg_misc_3p3>;
- vddl-supply = <&vreg_l12b_1p2>;
-
- pinctrl-0 = <&tpad_default>;
- pinctrl-names = "default";
-
- wakeup-source;
- };
-
- keyboard@3a {
- compatible = "hid-over-i2c";
- reg = <0x3a>;
-
- hid-descr-addr = <0x1>;
- interrupts-extended = <&tlmm 67 IRQ_TYPE_LEVEL_LOW>;
-
- vdd-supply = <&vreg_misc_3p3>;
- vddl-supply = <&vreg_l12b_1p2>;
-
- pinctrl-0 = <&kybd_default>;
- pinctrl-names = "default";
-
- wakeup-source;
- };
-};
-
-&i2c8 {
- clock-frequency = <400000>;
-
- status = "okay";
-
- touchscreen@10 {
- compatible = "hid-over-i2c";
- reg = <0x10>;
-
- hid-descr-addr = <0x1>;
- interrupts-extended = <&tlmm 51 IRQ_TYPE_LEVEL_LOW>;
-
- vdd-supply = <&vreg_misc_3p3>;
- vddl-supply = <&vreg_l15b_1p8>;
-
- pinctrl-0 = <&ts0_default>;
- pinctrl-names = "default";
- };
-};
-
-&lpass_tlmm {
- spkr_01_sd_n_active: spkr-01-sd-n-active-state {
- pins = "gpio12";
- function = "gpio";
- drive-strength = <16>;
- bias-disable;
- output-low;
- };
-
- spkr_23_sd_n_active: spkr-23-sd-n-active-state {
- pins = "gpio13";
- function = "gpio";
- drive-strength = <16>;
- bias-disable;
- output-low;
- };
-};
-
-&lpass_vamacro {
- pinctrl-0 = <&dmic01_default>, <&dmic23_default>;
- pinctrl-names = "default";
-
- vdd-micb-supply = <&vreg_l1b_1p8>;
- qcom,dmic-sample-rate = <4800000>;
-};
-
-&mdss {
- status = "okay";
-};
-
-&mdss_dp3 {
- compatible = "qcom,x1e80100-dp";
- /delete-property/ #sound-dai-cells;
-
- status = "okay";
-
- aux-bus {
- panel {
- compatible = "samsung,atna45af01", "samsung,atna33xc20";
- enable-gpios = <&pmc8380_3_gpios 4 GPIO_ACTIVE_HIGH>;
- power-supply = <&vreg_edp_3p3>;
-
- pinctrl-0 = <&edp_bl_en>;
- pinctrl-names = "default";
-
- port {
- edp_panel_in: endpoint {
- remote-endpoint = <&mdss_dp3_out>;
- };
- };
- };
- };
-
- ports {
- port@1 {
- reg = <1>;
- mdss_dp3_out: endpoint {
- data-lanes = <0 1 2 3>;
- link-frequencies = /bits/ 64 <1620000000 2700000000 5400000000 8100000000>;
-
- remote-endpoint = <&edp_panel_in>;
- };
- };
- };
-};
-
-&mdss_dp3_phy {
- vdda-phy-supply = <&vreg_l3j_0p8>;
- vdda-pll-supply = <&vreg_l2j_1p2>;
-
- status = "okay";
-};
-
-&pcie4 {
- perst-gpios = <&tlmm 146 GPIO_ACTIVE_LOW>;
- wake-gpios = <&tlmm 148 GPIO_ACTIVE_LOW>;
-
- pinctrl-0 = <&pcie4_default>;
- pinctrl-names = "default";
-
- status = "okay";
-};
-
-&pcie4_phy {
- vdda-phy-supply = <&vreg_l3i_0p8>;
- vdda-pll-supply = <&vreg_l3e_1p2>;
-
- status = "okay";
-};
-
-&pcie5 {
- perst-gpios = <&tlmm 149 GPIO_ACTIVE_LOW>;
- wake-gpios = <&tlmm 151 GPIO_ACTIVE_LOW>;
-
- vddpe-3v3-supply = <&vreg_wwan>;
-
- pinctrl-0 = <&pcie5_default>;
- pinctrl-names = "default";
-
- status = "okay";
-};
-
-&pcie5_phy {
- vdda-phy-supply = <&vreg_l3i_0p8>;
- vdda-pll-supply = <&vreg_l3e_1p2>;
-
- status = "okay";
-};
-
-&pcie6a {
- perst-gpios = <&tlmm 152 GPIO_ACTIVE_LOW>;
- wake-gpios = <&tlmm 154 GPIO_ACTIVE_LOW>;
-
- vddpe-3v3-supply = <&vreg_nvme>;
-
- pinctrl-names = "default";
- pinctrl-0 = <&pcie6a_default>;
-
- status = "okay";
-};
-
-&pcie6a_phy {
- vdda-phy-supply = <&vreg_l1d_0p8>;
- vdda-pll-supply = <&vreg_l2j_1p2>;
-
- status = "okay";
-};
-
-&pm8550ve_8_gpios {
- misc_3p3_reg_en: misc-3p3-reg-en-state {
- pins = "gpio6";
- function = "normal";
- bias-disable;
- input-disable;
- output-enable;
- drive-push-pull;
- power-source = <1>; /* 1.8 V */
- qcom,drive-strength = <PMIC_GPIO_STRENGTH_LOW>;
- };
-};
-
-&pmc8380_3_gpios {
- edp_bl_en: edp-bl-en-state {
- pins = "gpio4";
- function = "normal";
- power-source = <1>; /* 1.8V */
- input-disable;
- output-enable;
- };
-};
-
-&qupv3_0 {
- status = "okay";
-};
-
-&qupv3_1 {
- status = "okay";
-};
-
-&qupv3_2 {
- status = "okay";
-};
-
-&remoteproc_adsp {
- firmware-name = "qcom/x1e80100/adsp.mbn",
- "qcom/x1e80100/adsp_dtb.mbn";
-
- status = "okay";
-};
-
-&remoteproc_cdsp {
- firmware-name = "qcom/x1e80100/cdsp.mbn",
- "qcom/x1e80100/cdsp_dtb.mbn";
-
- status = "okay";
-};
-
-&smb2360_0 {
- status = "okay";
-};
-
-&smb2360_0_eusb2_repeater {
- vdd18-supply = <&vreg_l3d_1p8>;
- vdd3-supply = <&vreg_l2b_3p0>;
-};
-
-&smb2360_1 {
- status = "okay";
-};
-
-&smb2360_1_eusb2_repeater {
- vdd18-supply = <&vreg_l3d_1p8>;
- vdd3-supply = <&vreg_l14b_3p0>;
-};
-
-&smb2360_2 {
- status = "okay";
-};
-
-&smb2360_2_eusb2_repeater {
- vdd18-supply = <&vreg_l3d_1p8>;
- vdd3-supply = <&vreg_l8b_3p0>;
-};
-
-&swr0 {
- status = "okay";
-
- pinctrl-0 = <&wsa_swr_active>, <&spkr_01_sd_n_active>;
- pinctrl-names = "default";
-
- /* WSA8845, Left Woofer */
- left_woofer: speaker@0,0 {
- compatible = "sdw20217020400";
- reg = <0 0>;
- reset-gpios = <&lpass_tlmm 12 GPIO_ACTIVE_LOW>;
- #sound-dai-cells = <0>;
- sound-name-prefix = "WooferLeft";
- vdd-1p8-supply = <&vreg_l15b_1p8>;
- vdd-io-supply = <&vreg_l12b_1p2>;
- qcom,port-mapping = <1 2 3 7 10 13>;
- };
-
- /* WSA8845, Left Tweeter */
- left_tweeter: speaker@0,1 {
- compatible = "sdw20217020400";
- reg = <0 1>;
- reset-gpios = <&lpass_tlmm 12 GPIO_ACTIVE_LOW>;
- #sound-dai-cells = <0>;
- sound-name-prefix = "TweeterLeft";
- vdd-1p8-supply = <&vreg_l15b_1p8>;
- vdd-io-supply = <&vreg_l12b_1p2>;
- qcom,port-mapping = <4 5 6 7 11 13>;
- };
-};
-
-&swr1 {
- status = "okay";
-
- /* WCD9385 RX */
- wcd_rx: codec@0,4 {
- compatible = "sdw20217010d00";
- reg = <0 4>;
- qcom,rx-port-mapping = <1 2 3 4 5>;
- };
-};
-
-&swr2 {
- status = "okay";
-
- /* WCD9385 TX */
- wcd_tx: codec@0,3 {
- compatible = "sdw20217010d00";
- reg = <0 3>;
- qcom,tx-port-mapping = <2 2 3 4>;
- };
-};
-
-&swr3 {
- status = "okay";
-
- pinctrl-0 = <&wsa2_swr_active>, <&spkr_23_sd_n_active>;
- pinctrl-names = "default";
-
- /* WSA8845, Right Woofer */
- right_woofer: speaker@0,0 {
- compatible = "sdw20217020400";
- reg = <0 0>;
- reset-gpios = <&lpass_tlmm 13 GPIO_ACTIVE_LOW>;
- #sound-dai-cells = <0>;
- sound-name-prefix = "WooferRight";
- vdd-1p8-supply = <&vreg_l15b_1p8>;
- vdd-io-supply = <&vreg_l12b_1p2>;
- qcom,port-mapping = <1 2 3 7 10 13>;
- };
-
- /* WSA8845, Right Tweeter */
- right_tweeter: speaker@0,1 {
- compatible = "sdw20217020400";
- reg = <0 1>;
- reset-gpios = <&lpass_tlmm 13 GPIO_ACTIVE_LOW>;
- #sound-dai-cells = <0>;
- sound-name-prefix = "TweeterRight";
- vdd-1p8-supply = <&vreg_l15b_1p8>;
- vdd-io-supply = <&vreg_l12b_1p2>;
- qcom,port-mapping = <4 5 6 7 11 13>;
- };
-};
-
-&tlmm {
- gpio-reserved-ranges = <34 2>, /* Unused */
- <44 4>, /* SPI (TPM) */
- <238 1>; /* UFS Reset */
-
- edp_reg_en: edp-reg-en-state {
- pins = "gpio70";
- function = "gpio";
- drive-strength = <16>;
- bias-disable;
- };
-
- hall_int_n_default: hall-int-n-state {
- pins = "gpio92";
- function = "gpio";
- bias-disable;
- };
-
- kybd_default: kybd-default-state {
- pins = "gpio67";
- function = "gpio";
- bias-disable;
- };
-
- nvme_reg_en: nvme-reg-en-state {
- pins = "gpio18";
- function = "gpio";
- drive-strength = <2>;
- bias-disable;
- };
-
- pcie4_default: pcie4-default-state {
- clkreq-n-pins {
- pins = "gpio147";
- function = "pcie4_clk";
- drive-strength = <2>;
- bias-pull-up;
- };
-
- perst-n-pins {
- pins = "gpio146";
- function = "gpio";
- drive-strength = <2>;
- bias-disable;
- };
-
- wake-n-pins {
- pins = "gpio148";
- function = "gpio";
- drive-strength = <2>;
- bias-pull-up;
- };
- };
-
- pcie5_default: pcie5-default-state {
- clkreq-n-pins {
- pins = "gpio150";
- function = "pcie5_clk";
- drive-strength = <2>;
- bias-pull-up;
- };
-
- perst-n-pins {
- pins = "gpio149";
- function = "gpio";
- drive-strength = <2>;
- bias-disable;
- };
-
- wake-n-pins {
- pins = "gpio151";
- function = "gpio";
- drive-strength = <2>;
- bias-pull-up;
- };
- };
-
- pcie6a_default: pcie6a-default-state {
- clkreq-n-pins {
- pins = "gpio153";
- function = "pcie6a_clk";
- drive-strength = <2>;
- bias-pull-up;
- };
-
- perst-n-pins {
- pins = "gpio152";
- function = "gpio";
- drive-strength = <2>;
- bias-disable;
- };
-
- wake-n-pins {
- pins = "gpio154";
- function = "gpio";
- drive-strength = <2>;
- bias-pull-up;
- };
- };
-
- tpad_default: tpad-default-state {
- pins = "gpio3";
- function = "gpio";
- bias-disable;
- };
-
- ts0_default: ts0-default-state {
- int-n-pins {
- pins = "gpio51";
- function = "gpio";
- bias-disable;
- };
-
- reset-n-pins {
- pins = "gpio48";
- function = "gpio";
- output-high;
- drive-strength = <16>;
- };
- };
-
- wcd_default: wcd-reset-n-active-state {
- pins = "gpio191";
- function = "gpio";
- drive-strength = <16>;
- bias-disable;
- output-low;
- };
-
- wwan_sw_en: wwan-sw-en-state {
- pins = "gpio221";
- function = "gpio";
- drive-strength = <4>;
- bias-disable;
- };
-};
-
-&uart21 {
- compatible = "qcom,geni-debug-uart";
- status = "okay";
-};
-
-&usb_1_ss0_hsphy {
- vdd-supply = <&vreg_l3j_0p8>;
- vdda12-supply = <&vreg_l2j_1p2>;
-
- phys = <&smb2360_0_eusb2_repeater>;
-
- status = "okay";
-};
-
-&usb_1_ss0_qmpphy {
- vdda-phy-supply = <&vreg_l2j_1p2>;
- vdda-pll-supply = <&vreg_l1j_0p8>;
-
- status = "okay";
-};
-
-&usb_1_ss0 {
- status = "okay";
-};
-
-&usb_1_ss0_dwc3 {
- dr_mode = "host";
-};
-
-&usb_1_ss0_dwc3_hs {
- remote-endpoint = <&pmic_glink_ss0_hs_in>;
-};
-
-&usb_1_ss0_qmpphy_out {
- remote-endpoint = <&pmic_glink_ss0_ss_in>;
-};
-
-&usb_1_ss1_hsphy {
- vdd-supply = <&vreg_l3j_0p8>;
- vdda12-supply = <&vreg_l2j_1p2>;
-
- phys = <&smb2360_1_eusb2_repeater>;
-
- status = "okay";
-};
-
-&usb_1_ss1_qmpphy {
- vdda-phy-supply = <&vreg_l2j_1p2>;
- vdda-pll-supply = <&vreg_l2d_0p9>;
-
- status = "okay";
-};
-
-&usb_1_ss1 {
- status = "okay";
-};
-
-&usb_1_ss1_dwc3 {
- dr_mode = "host";
-};
-
-&usb_1_ss1_dwc3_hs {
- remote-endpoint = <&pmic_glink_ss1_hs_in>;
-};
-
-&usb_1_ss1_qmpphy_out {
- remote-endpoint = <&pmic_glink_ss1_ss_in>;
-};
-
-&usb_1_ss2_hsphy {
- vdd-supply = <&vreg_l3j_0p8>;
- vdda12-supply = <&vreg_l2j_1p2>;
-
- phys = <&smb2360_2_eusb2_repeater>;
-
- status = "okay";
-};
-
-&usb_1_ss2_qmpphy {
- vdda-phy-supply = <&vreg_l2j_1p2>;
- vdda-pll-supply = <&vreg_l2d_0p9>;
-
- status = "okay";
-};
-
-&usb_1_ss2 {
- status = "okay";
-};
-
-&usb_1_ss2_dwc3 {
- dr_mode = "host";
-};
-
-&usb_1_ss2_dwc3_hs {
- remote-endpoint = <&pmic_glink_ss2_hs_in>;
-};
-
-&usb_1_ss2_qmpphy_out {
- remote-endpoint = <&pmic_glink_ss2_ss_in>;
+&gpu_zap_shader {
+ firmware-name = "qcom/x1e80100/gen70500_zap.mbn";
};
diff --git a/arch/arm64/boot/dts/qcom/x1e80100.dtsi b/arch/arm64/boot/dts/qcom/x1e80100.dtsi
index a244cbb84aecc23ce11414c41f2e5d0905f455ee..9d14d53180734ed3eda2ed70b54e9ee8acbcd892 100644
--- a/arch/arm64/boot/dts/qcom/x1e80100.dtsi
+++ b/arch/arm64/boot/dts/qcom/x1e80100.dtsi
@@ -3751,7 +3751,7 @@ gpu: gpu@3d00000 {
status = "disabled";
- zap-shader {
+ gpu_zap_shader: zap-shader {
memory-region = <&gpu_microcode_mem>;
};
--
2.48.1
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related [flat|nested] 22+ messages in thread* [PATCH 6/6] arm64: dts: qcom: Add X1P42100 SoC and CRD
2025-01-25 3:31 [PATCH 0/6] X1P42100 DT and PCIe PHY bits Konrad Dybcio
` (4 preceding siblings ...)
2025-01-25 3:31 ` [PATCH 5/6] arm64: dts: qcom: Commonize X1 CRD DTSI Konrad Dybcio
@ 2025-01-25 3:31 ` Konrad Dybcio
2025-01-29 18:10 ` [PATCH 0/6] X1P42100 DT and PCIe PHY bits Jens Glathe
6 siblings, 0 replies; 22+ messages in thread
From: Konrad Dybcio @ 2025-01-25 3:31 UTC (permalink / raw)
To: Vinod Koul, Kishon Vijay Abraham I, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Konrad Dybcio
Cc: Marijn Suijten, linux-arm-msm, linux-phy, devicetree,
linux-kernel, Konrad Dybcio
From: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
The X1 family is split into two parts: the 10- and 12-core parts are
variants of the same silicon with different fusing, whereas the 8-core
ones are a separate design. Thankfully, the software interface is only
barely different, letting us reuse much of the existing X1 work.
Introduce support for the X1P42100 SoC and the CRD based on it, through
overlaying some bits. Everything we already support on X1E80100 and
friends, minus the GPU, should work as-is.
Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/Makefile | 1 +
arch/arm64/boot/dts/qcom/x1e80100-pmics.dtsi | 2 +-
arch/arm64/boot/dts/qcom/x1e80100.dtsi | 30 +++++------
arch/arm64/boot/dts/qcom/x1p42100-crd.dts | 17 ++++++
arch/arm64/boot/dts/qcom/x1p42100.dtsi | 81 ++++++++++++++++++++++++++++
5 files changed, 115 insertions(+), 16 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile
index 140b0b2abfb555b8ef61bd9ed0217d8997800809..b54f45b3bec812f4f029c5a991ad3ea30585d4e5 100644
--- a/arch/arm64/boot/dts/qcom/Makefile
+++ b/arch/arm64/boot/dts/qcom/Makefile
@@ -298,3 +298,4 @@ dtb-$(CONFIG_ARCH_QCOM) += x1e80100-lenovo-yoga-slim7x.dtb
dtb-$(CONFIG_ARCH_QCOM) += x1e80100-microsoft-romulus13.dtb
dtb-$(CONFIG_ARCH_QCOM) += x1e80100-microsoft-romulus15.dtb
dtb-$(CONFIG_ARCH_QCOM) += x1e80100-qcp.dtb
+dtb-$(CONFIG_ARCH_QCOM) += x1p42100-crd.dtb
diff --git a/arch/arm64/boot/dts/qcom/x1e80100-pmics.dtsi b/arch/arm64/boot/dts/qcom/x1e80100-pmics.dtsi
index d7a2a2b8fc6c30bdb10df81eac7d92306998838f..bf6cdede156bc66f681c53f9bd19966bae23da14 100644
--- a/arch/arm64/boot/dts/qcom/x1e80100-pmics.dtsi
+++ b/arch/arm64/boot/dts/qcom/x1e80100-pmics.dtsi
@@ -110,7 +110,7 @@ trip1 {
};
};
- pmc8380-6-thermal {
+ pmc8380_6_thermal: pmc8380-6-thermal {
polling-delay-passive = <100>;
thermal-sensors = <&pmc8380_6_temp_alarm>;
diff --git a/arch/arm64/boot/dts/qcom/x1e80100.dtsi b/arch/arm64/boot/dts/qcom/x1e80100.dtsi
index 9d14d53180734ed3eda2ed70b54e9ee8acbcd892..4ebb0943970e65241b9b073f5f46a99fb34ead41 100644
--- a/arch/arm64/boot/dts/qcom/x1e80100.dtsi
+++ b/arch/arm64/boot/dts/qcom/x1e80100.dtsi
@@ -252,7 +252,7 @@ core3 {
};
};
- cluster2 {
+ cpu_map_cluster2: cluster2 {
core0 {
cpu = <&cpu8>;
};
@@ -8203,7 +8203,7 @@ opp-9 {
};
/* cluster0 */
- pmu@240b3400 {
+ bwmon_cluster0: pmu@240b3400 {
compatible = "qcom,x1e80100-cpu-bwmon", "qcom,sdm845-bwmon";
reg = <0 0x240b3400 0 0x600>;
@@ -8213,6 +8213,19 @@ pmu@240b3400 {
&gem_noc SLAVE_LLCC QCOM_ICC_TAG_ACTIVE_ONLY>;
operating-points-v2 = <&cpu_bwmon_opp_table>;
+ };
+
+ /* cluster2 */
+ bwmon_cluster2: pmu@240b5400 {
+ compatible = "qcom,x1e80100-cpu-bwmon", "qcom,sdm845-bwmon";
+ reg = <0 0x240b5400 0 0x600>;
+
+ interrupts = <GIC_SPI 581 IRQ_TYPE_LEVEL_HIGH>;
+
+ interconnects = <&gem_noc MASTER_APPSS_PROC QCOM_ICC_TAG_ACTIVE_ONLY
+ &gem_noc SLAVE_LLCC QCOM_ICC_TAG_ACTIVE_ONLY>;
+
+ operating-points-v2 = <&cpu_bwmon_opp_table>;
cpu_bwmon_opp_table: opp-table {
compatible = "operating-points-v2";
@@ -8243,19 +8256,6 @@ opp-5 {
};
};
- /* cluster2 */
- pmu@240b5400 {
- compatible = "qcom,x1e80100-cpu-bwmon", "qcom,sdm845-bwmon";
- reg = <0 0x240b5400 0 0x600>;
-
- interrupts = <GIC_SPI 581 IRQ_TYPE_LEVEL_HIGH>;
-
- interconnects = <&gem_noc MASTER_APPSS_PROC QCOM_ICC_TAG_ACTIVE_ONLY
- &gem_noc SLAVE_LLCC QCOM_ICC_TAG_ACTIVE_ONLY>;
-
- operating-points-v2 = <&cpu_bwmon_opp_table>;
- };
-
/* cluster1 */
pmu@240b6400 {
compatible = "qcom,x1e80100-cpu-bwmon", "qcom,sdm845-bwmon";
diff --git a/arch/arm64/boot/dts/qcom/x1p42100-crd.dts b/arch/arm64/boot/dts/qcom/x1p42100-crd.dts
new file mode 100644
index 0000000000000000000000000000000000000000..cf07860a63e97c388909fb5721ae7b9729b6c586
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/x1p42100-crd.dts
@@ -0,0 +1,17 @@
+// SPDX-License-Identifier: BSD-3-Clause
+/*
+ * Copyright (c) 2025 Qualcomm Innovation Center, Inc. All rights reserved.
+ */
+
+/dts-v1/;
+
+#include "x1p42100.dtsi"
+#include "x1-crd.dtsi"
+
+/delete-node/ &pmc8380_6;
+/delete-node/ &pmc8380_6_thermal;
+
+/ {
+ model = "Qualcomm Technologies, Inc. X1P42100 CRD";
+ compatible = "qcom,x1p42100-crd", "qcom,x1p42100";
+};
diff --git a/arch/arm64/boot/dts/qcom/x1p42100.dtsi b/arch/arm64/boot/dts/qcom/x1p42100.dtsi
new file mode 100644
index 0000000000000000000000000000000000000000..27f479010bc330eb6445269a1c46bf78ec6f1bd4
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/x1p42100.dtsi
@@ -0,0 +1,81 @@
+// SPDX-License-Identifier: BSD-3-Clause
+/*
+ * Copyright (c) 2025 Qualcomm Innovation Center, Inc. All rights reserved.
+ */
+
+/* X1P42100 is heavily based on X1E80100, with some meaningful differences */
+#include "x1e80100.dtsi"
+
+/delete-node/ &bwmon_cluster0;
+/delete-node/ &cluster_pd2;
+/delete-node/ &cpu_map_cluster2;
+/delete-node/ &cpu8;
+/delete-node/ &cpu9;
+/delete-node/ &cpu10;
+/delete-node/ &cpu11;
+/delete-node/ &cpu_pd8;
+/delete-node/ &cpu_pd9;
+/delete-node/ &cpu_pd10;
+/delete-node/ &cpu_pd11;
+/delete-node/ &pcie3_phy;
+
+&gcc {
+ compatible = "qcom,x1p42100-gcc", "qcom,x1e80100-gcc";
+};
+
+/* The GPU is physically different and will be brought up later */
+&gpu {
+ /delete-property/ compatible;
+};
+
+&gpucc {
+ compatible = "qcom,x1p42100-gpucc";
+};
+
+/* PCIe3 has half the lanes compared to X1E80100 */
+&pcie3 {
+ num-lanes = <4>;
+};
+
+&pcie6a_phy {
+ compatible = "qcom,x1p42100-qmp-gen4x4-pcie-phy";
+};
+
+&soc {
+ /* The PCIe3 PHY on X1P42100 uses a different IP block */
+ pcie3_phy: phy@1bd4000 {
+ compatible = "qcom,x1p42100-qmp-gen4x4-pcie-phy";
+ reg = <0x0 0x01bd4000 0x0 0x2000>,
+ <0x0 0x01bd6000 0x0 0x2000>;
+
+ clocks = <&gcc GCC_PCIE_3_PHY_AUX_CLK>,
+ <&gcc GCC_PCIE_3_CFG_AHB_CLK>,
+ <&tcsr TCSR_PCIE_8L_CLKREF_EN>,
+ <&gcc GCC_PCIE_3_PHY_RCHNG_CLK>,
+ <&gcc GCC_PCIE_3_PIPE_CLK>,
+ <&gcc GCC_PCIE_3_PIPEDIV2_CLK>;
+ clock-names = "aux",
+ "cfg_ahb",
+ "ref",
+ "rchng",
+ "pipe",
+ "pipediv2";
+
+ resets = <&gcc GCC_PCIE_3_PHY_BCR>,
+ <&gcc GCC_PCIE_3_NOCSR_COM_PHY_BCR>;
+ reset-names = "phy",
+ "phy_nocsr";
+
+ assigned-clocks = <&gcc GCC_PCIE_3_PHY_RCHNG_CLK>;
+ assigned-clock-rates = <100000000>;
+
+ power-domains = <&gcc GCC_PCIE_3_PHY_GDSC>;
+
+ #clock-cells = <0>;
+ clock-output-names = "pcie3_pipe_clk";
+
+ #phy-cells = <0>;
+
+ status = "disabled";
+ };
+};
--
2.48.1
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related [flat|nested] 22+ messages in thread* Re: [PATCH 0/6] X1P42100 DT and PCIe PHY bits
2025-01-25 3:31 [PATCH 0/6] X1P42100 DT and PCIe PHY bits Konrad Dybcio
` (5 preceding siblings ...)
2025-01-25 3:31 ` [PATCH 6/6] arm64: dts: qcom: Add X1P42100 SoC and CRD Konrad Dybcio
@ 2025-01-29 18:10 ` Jens Glathe
6 siblings, 0 replies; 22+ messages in thread
From: Jens Glathe @ 2025-01-29 18:10 UTC (permalink / raw)
To: Konrad Dybcio, Vinod Koul, Kishon Vijay Abraham I, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson
Cc: Marijn Suijten, linux-arm-msm, linux-phy, devicetree,
linux-kernel, Konrad Dybcio
On 25.01.25 04:31, Konrad Dybcio wrote:
> X1P42100 is a(n indirect) derivative of X1E80100 - the silicon is
> actually different and it's not a fused down part.
>
> Introduce the DTS bits required to support it by mostly reusing the
> X1E SoC and CRD DTSIs. The most notable differences from our software
> PoV are a different GPU (support for which will be added later), 4
> less CPUs and some nuances in the PCIe hardware.
>
> This series very strictly depends on the NOCSR PCIe PHY reset patches.
>
> Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
> ---
> Konrad Dybcio (6):
> dt-bindings: phy: qcom,qmp-pcie: Add X1P42100 PCIe Gen4x4 PHY
> dt-bindings: phy: qcom,qmp-pcie: Drop reset number constraints
> phy: qcom: qmp-pcie: Add X1P42100 Gen4x4 PHY
> arm64: dts: qcom: x1e80100: Wire up PCIe PHY NOCSR resets
> arm64: dts: qcom: Commonize X1 CRD DTSI
> arm64: dts: qcom: Add X1P42100 SoC and CRD
>
> .../bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml | 26 +-
> arch/arm64/boot/dts/qcom/Makefile | 1 +
> .../dts/qcom/{x1e80100-crd.dts => x1-crd.dtsi} | 7 -
> arch/arm64/boot/dts/qcom/x1e80100-crd.dts | 1270 +-------------------
> arch/arm64/boot/dts/qcom/x1e80100-pmics.dtsi | 2 +-
> arch/arm64/boot/dts/qcom/x1e80100.dtsi | 44 +-
> arch/arm64/boot/dts/qcom/x1p42100-crd.dts | 17 +
> arch/arm64/boot/dts/qcom/x1p42100.dtsi | 81 ++
> drivers/phy/qualcomm/phy-qcom-qmp-pcie.c | 18 +
> 9 files changed, 148 insertions(+), 1318 deletions(-)
> ---
> base-commit: d7dfdec72fb32629d1affc32ff37a66a7fd1fb53
> change-id: 20250125-topic-x1p4_dts-3b9509bce3a3
> prerequisite-message-id: 20250121094140.4006801-1-quic_wenbyao@quicinc.com
> prerequisite-patch-id: 719a1c1319a8f25be57f1e9bc68887684ff0d7cd
> prerequisite-patch-id: 44ff71b8033fc91867a83a2f8f063fd0d9951d5e
>
> Best regards,
Hi Konrad,
I applied the series, and its successfully tested on Lenovo Thinkbook 16
G7 QOY. [1] Thank you!
[1]
https://github.com/jglathe/linux_ms_dev_kit/commits/jg/ubuntu-qcom-x1e-6.13/
Tested-by: Jens Glathe <jens.glathe@oldschoolsolutions.biz>
with best regards
Jens
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply [flat|nested] 22+ messages in thread