This series adds support to provide refclk to endpoint even in low
power states.
Due to some platform specific issues with CLKREQ signal, it is not being
propagated to the host and as host doesn't know the clkreq signal host is
not sending refclk. Due to this endpoint is seeing linkdown and going
to bad state.
To avoid those ref clk should be provided always to the endpoint. The
issue is coming only when ep intiates the L1.1 or L1.2 exit and clkreq
is not being propagated properly to the host.
Signed-off-by: Krishna chaitanya chundru <[email protected]>
---
Changes in v3:
- Updated the dt-binding description as suggested by Dmitry.
- Added the new macros for v5_20 and v6_20 as suggested by Dmitry.
- Link to v2: https://lore.kernel.org/r/[email protected]
Changes in v2:
- Added refclk cntrl registers to the applicable phy versions & added reg layout where
- refclk cntrl offset needs to be updated (Dmitry)
- Error out if refclk_always_on is set and there is no refclk control register to enable it (Dmitry)
- updated the dt-binding description & some nit's as suggested by (Bjorn)
- Link to v1: https://lore.kernel.org/r/[email protected]
---
Krishna chaitanya chundru (3):
dt-bindings: phy: qcom,qmp: Add PCIe qcom,refclk-always-on property
phy: qcom-qmp-pcie: Add endpoint refclk control register offset
phy: qcom-qmp-pcie: Add support for keeping refclk always on
.../bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml | 7 ++++
drivers/phy/qualcomm/phy-qcom-qmp-pcie.c | 40 ++++++++++++++++++++--
drivers/phy/qualcomm/phy-qcom-qmp-pcs-pcie-v5.h | 1 +
drivers/phy/qualcomm/phy-qcom-qmp-pcs-pcie-v5_20.h | 1 +
drivers/phy/qualcomm/phy-qcom-qmp-pcs-pcie-v6_20.h | 1 +
drivers/phy/qualcomm/phy-qcom-qmp-pcs-v5_20.h | 4 +++
drivers/phy/qualcomm/phy-qcom-qmp-pcs-v6_20.h | 4 +++
7 files changed, 55 insertions(+), 3 deletions(-)
---
base-commit: 71e68e182e382e951d6248bccc3c960dcec5a718
change-id: 20231106-refclk_always_on-9beae8297cb8
Best regards,
--
Krishna chaitanya chundru <[email protected]>
Document qcom,refclk-always-on property which is needed in some platforms
to supply refclk even in PCIe low power states.
Signed-off-by: Krishna chaitanya chundru <[email protected]>
---
.../devicetree/bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml | 7 +++++++
1 file changed, 7 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 2c3d6553a7ba..c747c9f35795 100644
--- a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml
@@ -93,6 +93,13 @@ properties:
"#phy-cells":
const: 0
+ qcom,refclk-always-on:
+ type: boolean
+ description: In some platform where PCIe switch is connected, pcie switch due to some design
+ limitation fails to propage clkreq signal to the host and due to that host will not send
+ refclk, which results in linkdown in L1.2 or L1.1 exit initiated by EP.
+ This property if set keeps refclk always on even in Low power states.
+
required:
- compatible
- reg
--
2.42.0
In PCIe low power states like L1.1 or L1.2 the phy will stop
supplying refclk to endpoint. If endpoint asserts clkreq to bring
back link L0, then RC needs to provide refclk to endpoint.
Some platforms with pcie switch fail to drive the clkreq signal to
the host from the endpoints because of the switch board design.
Due to that refclk needs to supplied to the endpoint always.
Add a flag to keep refclk always supplied to endpoint.
Signed-off-by: Krishna chaitanya chundru <[email protected]>
Reviewed-by: Dmitry Baryshkov <[email protected]>
---
drivers/phy/qualcomm/phy-qcom-qmp-pcie.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c b/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c
index 7fdf9b2596b6..e95f677817f7 100644
--- a/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c
+++ b/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c
@@ -43,6 +43,8 @@
/* QPHY_PCS_STATUS bit */
#define PHYSTATUS BIT(6)
#define PHYSTATUS_4_20 BIT(7)
+/* PCS_PCIE_ENDPOINT_REFCLK_CNTRL */
+#define EPCLK_ALWAYS_ON_EN BIT(6)
#define PHY_INIT_COMPLETE_TIMEOUT 10000
@@ -2264,6 +2266,8 @@ struct qmp_pcie {
struct phy *phy;
int mode;
+ bool refclk_always_on;
+
struct clk_fixed_rate pipe_clk_fixed;
};
@@ -3179,6 +3183,10 @@ static void qmp_pcie_init_registers(struct qmp_pcie *qmp, const struct qmp_phy_c
qmp_pcie_configure(pcs, tbls->pcs, tbls->pcs_num);
qmp_pcie_configure(pcs_misc, tbls->pcs_misc, tbls->pcs_misc_num);
+ if (qmp->refclk_always_on && cfg->regs[QPHY_PCS_ENDPOINT_REFCLK_CNTRL])
+ qphy_setbits(pcs_misc, cfg->regs[QPHY_PCS_ENDPOINT_REFCLK_CNTRL],
+ EPCLK_ALWAYS_ON_EN);
+
if (cfg->lanes >= 4 && qmp->tcsr_4ln_config) {
qmp_pcie_configure(serdes, cfg->serdes_4ln_tbl, cfg->serdes_4ln_num);
qmp_pcie_init_port_b(qmp, tbls);
@@ -3701,6 +3709,12 @@ static int qmp_pcie_probe(struct platform_device *pdev)
if (ret)
goto err_node_put;
+ qmp->refclk_always_on = of_property_read_bool(dev->of_node, "qcom,refclk-always-on");
+ if (qmp->refclk_always_on && !qmp->cfg->regs[QPHY_PCS_ENDPOINT_REFCLK_CNTRL]) {
+ dev_err(dev, "refclk is always on is present but refclk cntrl offset is not present\n");
+ goto err_node_put;
+ }
+
ret = phy_pipe_clk_register(qmp, np);
if (ret)
goto err_node_put;
--
2.42.0
Some platforms needs to keep endpoint refclk always on, for this
purpose add this offset for all the applicable phy versions.
And also add reg layout for few controllers as we are adding
endpoint refclk control register which changes based upon phy version.
Signed-off-by: Krishna chaitanya chundru <[email protected]>
Reviewed-by: Dmitry Baryshkov <[email protected]>
---
drivers/phy/qualcomm/phy-qcom-qmp-pcie.c | 26 +++++++++++++++++++---
drivers/phy/qualcomm/phy-qcom-qmp-pcs-pcie-v5.h | 1 +
drivers/phy/qualcomm/phy-qcom-qmp-pcs-pcie-v5_20.h | 1 +
drivers/phy/qualcomm/phy-qcom-qmp-pcs-pcie-v6_20.h | 1 +
drivers/phy/qualcomm/phy-qcom-qmp-pcs-v5_20.h | 4 ++++
drivers/phy/qualcomm/phy-qcom-qmp-pcs-v6_20.h | 4 ++++
6 files changed, 34 insertions(+), 3 deletions(-)
diff --git a/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c b/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c
index a63ca7424974..7fdf9b2596b6 100644
--- a/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c
+++ b/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c
@@ -77,6 +77,7 @@ enum qphy_reg_layout {
QPHY_START_CTRL,
QPHY_PCS_STATUS,
QPHY_PCS_POWER_DOWN_CONTROL,
+ QPHY_PCS_ENDPOINT_REFCLK_CNTRL,
/* Keep last to ensure regs_layout arrays are properly initialized */
QPHY_LAYOUT_SIZE
};
@@ -93,6 +94,7 @@ static const unsigned int pciephy_v3_regs_layout[QPHY_LAYOUT_SIZE] = {
[QPHY_START_CTRL] = QPHY_V3_PCS_START_CONTROL,
[QPHY_PCS_STATUS] = QPHY_V3_PCS_PCS_STATUS,
[QPHY_PCS_POWER_DOWN_CONTROL] = QPHY_V3_PCS_POWER_DOWN_CONTROL,
+ [QPHY_PCS_ENDPOINT_REFCLK_CNTRL] = QPHY_V3_PCS_ENDPOINT_REFCLK_CNTRL,
};
static const unsigned int sdm845_qhp_pciephy_regs_layout[QPHY_LAYOUT_SIZE] = {
@@ -107,6 +109,7 @@ static const unsigned int pciephy_v4_regs_layout[QPHY_LAYOUT_SIZE] = {
[QPHY_START_CTRL] = QPHY_V4_PCS_START_CONTROL,
[QPHY_PCS_STATUS] = QPHY_V4_PCS_PCS_STATUS1,
[QPHY_PCS_POWER_DOWN_CONTROL] = QPHY_V4_PCS_POWER_DOWN_CONTROL,
+ [QPHY_PCS_ENDPOINT_REFCLK_CNTRL] = QPHY_V4_PCS_PCIE_ENDPOINT_REFCLK_CNTRL,
};
static const unsigned int pciephy_v5_regs_layout[QPHY_LAYOUT_SIZE] = {
@@ -114,6 +117,23 @@ static const unsigned int pciephy_v5_regs_layout[QPHY_LAYOUT_SIZE] = {
[QPHY_START_CTRL] = QPHY_V5_PCS_START_CONTROL,
[QPHY_PCS_STATUS] = QPHY_V5_PCS_PCS_STATUS1,
[QPHY_PCS_POWER_DOWN_CONTROL] = QPHY_V5_PCS_POWER_DOWN_CONTROL,
+ [QPHY_PCS_ENDPOINT_REFCLK_CNTRL] = QPHY_V5_PCS_PCIE_ENDPOINT_REFCLK_CNTRL,
+};
+
+static const unsigned int pciephy_v5_20_regs_layout[QPHY_LAYOUT_SIZE] = {
+ [QPHY_SW_RESET] = QPHY_V5_20_PCS_SW_RESET,
+ [QPHY_START_CTRL] = QPHY_V5_20_PCS_START_CONTROL,
+ [QPHY_PCS_STATUS] = QPHY_V5_20_PCS_PCS_STATUS1,
+ [QPHY_PCS_POWER_DOWN_CONTROL] = QPHY_V5_20_PCS_POWER_DOWN_CONTROL,
+ [QPHY_PCS_ENDPOINT_REFCLK_CNTRL] = QPHY_V5_20_PCS_PCIE_ENDPOINT_REFCLK_CNTRL,
+};
+
+static const unsigned int pciephy_v6_20_regs_layout[QPHY_LAYOUT_SIZE] = {
+ [QPHY_SW_RESET] = QPHY_V6_20_PCS_SW_RESET,
+ [QPHY_START_CTRL] = QPHY_V6_20_PCS_START_CONTROL,
+ [QPHY_PCS_STATUS] = QPHY_V6_20_PCS_PCS_STATUS1,
+ [QPHY_PCS_POWER_DOWN_CONTROL] = QPHY_V6_20_PCS_POWER_DOWN_CONTROL,
+ [QPHY_PCS_ENDPOINT_REFCLK_CNTRL] = QPHY_PCIE_V6_20_PCS_ENDPOINT_REFCLK_CNTRL,
};
static const struct qmp_phy_init_tbl msm8998_pcie_serdes_tbl[] = {
@@ -2956,7 +2976,7 @@ static const struct qmp_phy_cfg sm8450_qmp_gen4x2_pciephy_cfg = {
.num_resets = ARRAY_SIZE(sdm845_pciephy_reset_l),
.vreg_list = qmp_phy_vreg_l,
.num_vregs = ARRAY_SIZE(qmp_phy_vreg_l),
- .regs = pciephy_v5_regs_layout,
+ .regs = pciephy_v5_20_regs_layout,
.pwrdn_ctrl = SW_PWRDN | REFCLK_DRV_DSBL,
.phy_status = PHYSTATUS_4_20,
@@ -3012,7 +3032,7 @@ static const struct qmp_phy_cfg sm8550_qmp_gen4x2_pciephy_cfg = {
.num_resets = ARRAY_SIZE(sdm845_pciephy_reset_l),
.vreg_list = sm8550_qmp_phy_vreg_l,
.num_vregs = ARRAY_SIZE(sm8550_qmp_phy_vreg_l),
- .regs = pciephy_v5_regs_layout,
+ .regs = pciephy_v6_20_regs_layout,
.pwrdn_ctrl = SW_PWRDN | REFCLK_DRV_DSBL,
.phy_status = PHYSTATUS_4_20,
@@ -3047,7 +3067,7 @@ static const struct qmp_phy_cfg sa8775p_qmp_gen4x2_pciephy_cfg = {
.num_resets = ARRAY_SIZE(sdm845_pciephy_reset_l),
.vreg_list = qmp_phy_vreg_l,
.num_vregs = ARRAY_SIZE(qmp_phy_vreg_l),
- .regs = pciephy_v5_regs_layout,
+ .regs = pciephy_v5_20_regs_layout,
.pwrdn_ctrl = SW_PWRDN | REFCLK_DRV_DSBL,
.phy_status = PHYSTATUS_4_20,
diff --git a/drivers/phy/qualcomm/phy-qcom-qmp-pcs-pcie-v5.h b/drivers/phy/qualcomm/phy-qcom-qmp-pcs-pcie-v5.h
index a469ae2a10a1..9b166286afda 100644
--- a/drivers/phy/qualcomm/phy-qcom-qmp-pcs-pcie-v5.h
+++ b/drivers/phy/qualcomm/phy-qcom-qmp-pcs-pcie-v5.h
@@ -11,6 +11,7 @@
#define QPHY_V5_PCS_PCIE_POWER_STATE_CONFIG2 0x0c
#define QPHY_V5_PCS_PCIE_POWER_STATE_CONFIG4 0x14
#define QPHY_V5_PCS_PCIE_ENDPOINT_REFCLK_DRIVE 0x20
+#define QPHY_V5_PCS_PCIE_ENDPOINT_REFCLK_CNTRL 0x24
#define QPHY_V5_PCS_PCIE_INT_AUX_CLK_CONFIG1 0x54
#define QPHY_V5_PCS_PCIE_OSC_DTCT_ACTIONS 0x94
#define QPHY_V5_PCS_PCIE_EQ_CONFIG2 0xa8
diff --git a/drivers/phy/qualcomm/phy-qcom-qmp-pcs-pcie-v5_20.h b/drivers/phy/qualcomm/phy-qcom-qmp-pcs-pcie-v5_20.h
index cdf8c04ea078..8b114e538a07 100644
--- a/drivers/phy/qualcomm/phy-qcom-qmp-pcs-pcie-v5_20.h
+++ b/drivers/phy/qualcomm/phy-qcom-qmp-pcs-pcie-v5_20.h
@@ -9,6 +9,7 @@
/* Only for QMP V5_20 PHY - PCIe PCS registers */
#define QPHY_V5_20_PCS_PCIE_POWER_STATE_CONFIG2 0x00c
#define QPHY_V5_20_PCS_PCIE_ENDPOINT_REFCLK_DRIVE 0x01c
+#define QPHY_V5_20_PCS_PCIE_ENDPOINT_REFCLK_CNTRL 0x020
#define QPHY_V5_20_PCS_PCIE_OSC_DTCT_MODE2_CONFIG5 0x084
#define QPHY_V5_20_PCS_PCIE_OSC_DTCT_ACTIONS 0x090
#define QPHY_V5_20_PCS_PCIE_EQ_CONFIG1 0x0a0
diff --git a/drivers/phy/qualcomm/phy-qcom-qmp-pcs-pcie-v6_20.h b/drivers/phy/qualcomm/phy-qcom-qmp-pcs-pcie-v6_20.h
index e3eb08776339..f7abe95c49ad 100644
--- a/drivers/phy/qualcomm/phy-qcom-qmp-pcs-pcie-v6_20.h
+++ b/drivers/phy/qualcomm/phy-qcom-qmp-pcs-pcie-v6_20.h
@@ -10,6 +10,7 @@
#define QPHY_PCIE_V6_20_PCS_POWER_STATE_CONFIG2 0x00c
#define QPHY_PCIE_V6_20_PCS_TX_RX_CONFIG 0x018
#define QPHY_PCIE_V6_20_PCS_ENDPOINT_REFCLK_DRIVE 0x01c
+#define QPHY_PCIE_V6_20_PCS_ENDPOINT_REFCLK_CNTRL 0x020
#define QPHY_PCIE_V6_20_PCS_OSC_DTCT_ATCIONS 0x090
#define QPHY_PCIE_V6_20_PCS_EQ_CONFIG1 0x0a0
#define QPHY_PCIE_V6_20_PCS_EQ_CONFIG5 0x108
diff --git a/drivers/phy/qualcomm/phy-qcom-qmp-pcs-v5_20.h b/drivers/phy/qualcomm/phy-qcom-qmp-pcs-v5_20.h
index f0754b6f9e3a..96f9232214d7 100644
--- a/drivers/phy/qualcomm/phy-qcom-qmp-pcs-v5_20.h
+++ b/drivers/phy/qualcomm/phy-qcom-qmp-pcs-v5_20.h
@@ -6,6 +6,10 @@
#ifndef QCOM_PHY_QMP_PCS_V5_20_H_
#define QCOM_PHY_QMP_PCS_V5_20_H_
+#define QPHY_V5_20_PCS_SW_RESET 0x000
+#define QPHY_V5_20_PCS_PCS_STATUS1 0x014
+#define QPHY_V5_20_PCS_POWER_DOWN_CONTROL 0x040
+#define QPHY_V5_20_PCS_START_CONTROL 0x044
#define QPHY_V5_20_PCS_G3S2_PRE_GAIN 0x170
#define QPHY_V5_20_PCS_RX_SIGDET_LVL 0x188
#define QPHY_V5_20_PCS_EQ_CONFIG2 0x1d8
diff --git a/drivers/phy/qualcomm/phy-qcom-qmp-pcs-v6_20.h b/drivers/phy/qualcomm/phy-qcom-qmp-pcs-v6_20.h
index 9c3f1e4950e6..cc3d40badb5d 100644
--- a/drivers/phy/qualcomm/phy-qcom-qmp-pcs-v6_20.h
+++ b/drivers/phy/qualcomm/phy-qcom-qmp-pcs-v6_20.h
@@ -7,6 +7,10 @@
#define QCOM_PHY_QMP_PCS_V6_20_H_
/* Only for QMP V6_20 PHY - USB/PCIe PCS registers */
+#define QPHY_V6_20_PCS_SW_RESET 0x000
+#define QPHY_V6_20_PCS_PCS_STATUS1 0x014
+#define QPHY_V6_20_PCS_POWER_DOWN_CONTROL 0x040
+#define QPHY_V6_20_PCS_START_CONTROL 0x044
#define QPHY_V6_20_PCS_G3S2_PRE_GAIN 0x178
#define QPHY_V6_20_PCS_RX_SIGDET_LVL 0x190
#define QPHY_V6_20_PCS_COM_ELECIDLE_DLY_SEL 0x1b8
--
2.42.0
On 27/11/2023 13:13, Krishna chaitanya chundru wrote:
> Document qcom,refclk-always-on property which is needed in some platforms
> to supply refclk even in PCIe low power states.
>
> Signed-off-by: Krishna chaitanya chundru <[email protected]>
> ---
> .../devicetree/bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml | 7 +++++++
> 1 file changed, 7 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 2c3d6553a7ba..c747c9f35795 100644
> --- a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml
> +++ b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml
> @@ -93,6 +93,13 @@ properties:
> "#phy-cells":
> const: 0
>
> + qcom,refclk-always-on:
> + type: boolean
> + description: In some platform where PCIe switch is connected, pcie switch due to some design
You received a comment to use proper wrapping: 80. Please implement it.
> + limitation fails to propage clkreq signal to the host and due to that host will not send
> + refclk, which results in linkdown in L1.2 or L1.1 exit initiated by EP.
> + This property if set keeps refclk always on even in Low power states.
The property name suggests that's the state of hardware - refclk is
always on. Description suggests you want to instruct OS to do something.
Again, third time (once from Bjorn, once from Dmitry), rephrase property
name and description to describe the hardware issue. I see description
improved, but not the property name. Again in the end of description you
say what Linux should do. Bindings do not describe Linux OS.
Best regards,
Krzysztof
On 11/28/2023 2:26 PM, Krzysztof Kozlowski wrote:
> On 27/11/2023 13:13, Krishna chaitanya chundru wrote:
>> Document qcom,refclk-always-on property which is needed in some platforms
>> to supply refclk even in PCIe low power states.
>>
>> Signed-off-by: Krishna chaitanya chundru <[email protected]>
>> ---
>> .../devicetree/bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml | 7 +++++++
>> 1 file changed, 7 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 2c3d6553a7ba..c747c9f35795 100644
>> --- a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml
>> +++ b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml
>> @@ -93,6 +93,13 @@ properties:
>> "#phy-cells":
>> const: 0
>>
>> + qcom,refclk-always-on:
>> + type: boolean
>> + description: In some platform where PCIe switch is connected, pcie switch due to some design
> You received a comment to use proper wrapping: 80. Please implement it.
I will update this.
>> + limitation fails to propage clkreq signal to the host and due to that host will not send
>> + refclk, which results in linkdown in L1.2 or L1.1 exit initiated by EP.
>> + This property if set keeps refclk always on even in Low power states.
> The property name suggests that's the state of hardware - refclk is
> always on. Description suggests you want to instruct OS to do something.
>
> Again, third time (once from Bjorn, once from Dmitry), rephrase property
> name and description to describe the hardware issue. I see description
> improved, but not the property name. Again in the end of description you
Both bjorn and Dmitry gave comments to change the description only, and
not the property name,
correct if I am wrong.
> say what Linux should do. Bindings do not describe Linux OS.
I will remove the last line in the next patch.
- Krishna Chaitanya.
>
> Best regards,
> Krzysztof
On Tue, Nov 28, 2023 at 02:49:18PM +0530, Krishna Chaitanya Chundru wrote:
>
> On 11/28/2023 2:26 PM, Krzysztof Kozlowski wrote:
> > On 27/11/2023 13:13, Krishna chaitanya chundru wrote:
> > > Document qcom,refclk-always-on property which is needed in some platforms
> > > to supply refclk even in PCIe low power states.
> > >
> > > Signed-off-by: Krishna chaitanya chundru <[email protected]>
> > > ---
> > > .../devicetree/bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml | 7 +++++++
> > > 1 file changed, 7 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 2c3d6553a7ba..c747c9f35795 100644
> > > --- a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml
> > > +++ b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml
> > > @@ -93,6 +93,13 @@ properties:
> > > "#phy-cells":
> > > const: 0
> > > + qcom,refclk-always-on:
> > > + type: boolean
> > > + description: In some platform where PCIe switch is connected, pcie switch due to some design
> > You received a comment to use proper wrapping: 80. Please implement it.
> I will update this.
> > > + limitation fails to propage clkreq signal to the host and due to that host will not send
> > > + refclk, which results in linkdown in L1.2 or L1.1 exit initiated by EP.
> > > + This property if set keeps refclk always on even in Low power states.
> > The property name suggests that's the state of hardware - refclk is
> > always on. Description suggests you want to instruct OS to do something.
> >
> > Again, third time (once from Bjorn, once from Dmitry), rephrase property
> > name and description to describe the hardware issue. I see description
> > improved, but not the property name. Again in the end of description you
>
> Both bjorn and Dmitry gave comments to change the description only, and not
> the property name,
>
> correct if I am wrong.
>
> > say what Linux should do. Bindings do not describe Linux OS.
>
> I will remove the last line in the next patch.
>
You should name the property as, "qcom,keep-refclk-always-on"
Also, no need to stuff the binding with "why this property is required", that
info should be part of the patch description. Just describe what this property
means in binding.
- Mani
> - Krishna Chaitanya.
>
> >
> > Best regards,
> > Krzysztof
>
--
மணிவண்ணன் சதாசிவம்
On Mon, Nov 27, 2023 at 05:43:51PM +0530, Krishna chaitanya chundru wrote:
> In PCIe low power states like L1.1 or L1.2 the phy will stop
> supplying refclk to endpoint. If endpoint asserts clkreq to bring
> back link L0, then RC needs to provide refclk to endpoint.
>
> Some platforms with pcie switch fail to drive the clkreq signal to
> the host from the endpoints because of the switch board design.
> Due to that refclk needs to supplied to the endpoint always.
>
> Add a flag to keep refclk always supplied to endpoint.
>
> Signed-off-by: Krishna chaitanya chundru <[email protected]>
> Reviewed-by: Dmitry Baryshkov <[email protected]>
> ---
> drivers/phy/qualcomm/phy-qcom-qmp-pcie.c | 14 ++++++++++++++
> 1 file changed, 14 insertions(+)
>
> diff --git a/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c b/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c
> index 7fdf9b2596b6..e95f677817f7 100644
> --- a/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c
> +++ b/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c
> @@ -43,6 +43,8 @@
> /* QPHY_PCS_STATUS bit */
> #define PHYSTATUS BIT(6)
> #define PHYSTATUS_4_20 BIT(7)
> +/* PCS_PCIE_ENDPOINT_REFCLK_CNTRL */
> +#define EPCLK_ALWAYS_ON_EN BIT(6)
>
> #define PHY_INIT_COMPLETE_TIMEOUT 10000
>
> @@ -2264,6 +2266,8 @@ struct qmp_pcie {
> struct phy *phy;
> int mode;
>
> + bool refclk_always_on;
> +
> struct clk_fixed_rate pipe_clk_fixed;
> };
>
> @@ -3179,6 +3183,10 @@ static void qmp_pcie_init_registers(struct qmp_pcie *qmp, const struct qmp_phy_c
> qmp_pcie_configure(pcs, tbls->pcs, tbls->pcs_num);
> qmp_pcie_configure(pcs_misc, tbls->pcs_misc, tbls->pcs_misc_num);
>
> + if (qmp->refclk_always_on && cfg->regs[QPHY_PCS_ENDPOINT_REFCLK_CNTRL])
> + qphy_setbits(pcs_misc, cfg->regs[QPHY_PCS_ENDPOINT_REFCLK_CNTRL],
> + EPCLK_ALWAYS_ON_EN);
> +
> if (cfg->lanes >= 4 && qmp->tcsr_4ln_config) {
> qmp_pcie_configure(serdes, cfg->serdes_4ln_tbl, cfg->serdes_4ln_num);
> qmp_pcie_init_port_b(qmp, tbls);
> @@ -3701,6 +3709,12 @@ static int qmp_pcie_probe(struct platform_device *pdev)
> if (ret)
> goto err_node_put;
>
> + qmp->refclk_always_on = of_property_read_bool(dev->of_node, "qcom,refclk-always-on");
> + if (qmp->refclk_always_on && !qmp->cfg->regs[QPHY_PCS_ENDPOINT_REFCLK_CNTRL]) {
> + dev_err(dev, "refclk is always on is present but refclk cntrl offset is not present\n");
"Firmware requested to keep REFCLK always ON, but driver missing offset\n"
- Mani
> + goto err_node_put;
> + }
> +
> ret = phy_pipe_clk_register(qmp, np);
> if (ret)
> goto err_node_put;
>
> --
> 2.42.0
>
>
--
மணிவண்ணன் சதாசிவம்
On 01/12/2023 07:07, Manivannan Sadhasivam wrote:
> On Tue, Nov 28, 2023 at 02:49:18PM +0530, Krishna Chaitanya Chundru wrote:
>>
>> On 11/28/2023 2:26 PM, Krzysztof Kozlowski wrote:
>>> On 27/11/2023 13:13, Krishna chaitanya chundru wrote:
>>>> Document qcom,refclk-always-on property which is needed in some platforms
>>>> to supply refclk even in PCIe low power states.
>>>>
>>>> Signed-off-by: Krishna chaitanya chundru <[email protected]>
>>>> ---
>>>> .../devicetree/bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml | 7 +++++++
>>>> 1 file changed, 7 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 2c3d6553a7ba..c747c9f35795 100644
>>>> --- a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml
>>>> +++ b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml
>>>> @@ -93,6 +93,13 @@ properties:
>>>> "#phy-cells":
>>>> const: 0
>>>> + qcom,refclk-always-on:
>>>> + type: boolean
>>>> + description: In some platform where PCIe switch is connected, pcie switch due to some design
>>> You received a comment to use proper wrapping: 80. Please implement it.
>> I will update this.
>>>> + limitation fails to propage clkreq signal to the host and due to that host will not send
>>>> + refclk, which results in linkdown in L1.2 or L1.1 exit initiated by EP.
>>>> + This property if set keeps refclk always on even in Low power states.
>>> The property name suggests that's the state of hardware - refclk is
>>> always on. Description suggests you want to instruct OS to do something.
>>>
>>> Again, third time (once from Bjorn, once from Dmitry), rephrase property
>>> name and description to describe the hardware issue. I see description
>>> improved, but not the property name. Again in the end of description you
>>
>> Both bjorn and Dmitry gave comments to change the description only, and not
>> the property name,
>>
>> correct if I am wrong.
>>
>>> say what Linux should do. Bindings do not describe Linux OS.
>>
>> I will remove the last line in the next patch.
>>
>
> You should name the property as, "qcom,keep-refclk-always-on"
Keep the clock by who? By driver? Then not, property should describe
physical phenomena or hardware issue being fixed here, not what driver
should do.
Best regards,
Krzysztof
On Fri, Dec 01, 2023 at 09:01:43AM +0100, Krzysztof Kozlowski wrote:
> On 01/12/2023 07:07, Manivannan Sadhasivam wrote:
> > On Tue, Nov 28, 2023 at 02:49:18PM +0530, Krishna Chaitanya Chundru wrote:
> >>
> >> On 11/28/2023 2:26 PM, Krzysztof Kozlowski wrote:
> >>> On 27/11/2023 13:13, Krishna chaitanya chundru wrote:
> >>>> Document qcom,refclk-always-on property which is needed in some platforms
> >>>> to supply refclk even in PCIe low power states.
> >>>>
> >>>> Signed-off-by: Krishna chaitanya chundru <[email protected]>
> >>>> ---
> >>>> .../devicetree/bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml | 7 +++++++
> >>>> 1 file changed, 7 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 2c3d6553a7ba..c747c9f35795 100644
> >>>> --- a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml
> >>>> +++ b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml
> >>>> @@ -93,6 +93,13 @@ properties:
> >>>> "#phy-cells":
> >>>> const: 0
> >>>> + qcom,refclk-always-on:
> >>>> + type: boolean
> >>>> + description: In some platform where PCIe switch is connected, pcie switch due to some design
> >>> You received a comment to use proper wrapping: 80. Please implement it.
> >> I will update this.
> >>>> + limitation fails to propage clkreq signal to the host and due to that host will not send
> >>>> + refclk, which results in linkdown in L1.2 or L1.1 exit initiated by EP.
> >>>> + This property if set keeps refclk always on even in Low power states.
> >>> The property name suggests that's the state of hardware - refclk is
> >>> always on. Description suggests you want to instruct OS to do something.
> >>>
> >>> Again, third time (once from Bjorn, once from Dmitry), rephrase property
> >>> name and description to describe the hardware issue. I see description
> >>> improved, but not the property name. Again in the end of description you
> >>
> >> Both bjorn and Dmitry gave comments to change the description only, and not
> >> the property name,
> >>
> >> correct if I am wrong.
> >>
> >>> say what Linux should do. Bindings do not describe Linux OS.
> >>
> >> I will remove the last line in the next patch.
> >>
> >
> > You should name the property as, "qcom,keep-refclk-always-on"
>
> Keep the clock by who? By driver? Then not, property should describe
> physical phenomena or hardware issue being fixed here, not what driver
> should do.
>
This property indeed fixes the hardware issue (though in board level) and I see
a plenty of properties similar to this one instructing the OS to keep some
resource ON to workaround hardware issues. So they are all wrong?
- Mani
>
> Best regards,
> Krzysztof
>
--
மணிவண்ணன் சதாசிவம்
On 01/12/2023 12:10, Manivannan Sadhasivam wrote:
> On Fri, Dec 01, 2023 at 09:01:43AM +0100, Krzysztof Kozlowski wrote:
>> On 01/12/2023 07:07, Manivannan Sadhasivam wrote:
>>> On Tue, Nov 28, 2023 at 02:49:18PM +0530, Krishna Chaitanya Chundru wrote:
>>>>
>>>> On 11/28/2023 2:26 PM, Krzysztof Kozlowski wrote:
>>>>> On 27/11/2023 13:13, Krishna chaitanya chundru wrote:
>>>>>> Document qcom,refclk-always-on property which is needed in some platforms
>>>>>> to supply refclk even in PCIe low power states.
>>>>>>
>>>>>> Signed-off-by: Krishna chaitanya chundru <[email protected]>
>>>>>> ---
>>>>>> .../devicetree/bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml | 7 +++++++
>>>>>> 1 file changed, 7 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 2c3d6553a7ba..c747c9f35795 100644
>>>>>> --- a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml
>>>>>> +++ b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml
>>>>>> @@ -93,6 +93,13 @@ properties:
>>>>>> "#phy-cells":
>>>>>> const: 0
>>>>>> + qcom,refclk-always-on:
>>>>>> + type: boolean
>>>>>> + description: In some platform where PCIe switch is connected, pcie switch due to some design
>>>>> You received a comment to use proper wrapping: 80. Please implement it.
>>>> I will update this.
>>>>>> + limitation fails to propage clkreq signal to the host and due to that host will not send
>>>>>> + refclk, which results in linkdown in L1.2 or L1.1 exit initiated by EP.
>>>>>> + This property if set keeps refclk always on even in Low power states.
>>>>> The property name suggests that's the state of hardware - refclk is
>>>>> always on. Description suggests you want to instruct OS to do something.
>>>>>
>>>>> Again, third time (once from Bjorn, once from Dmitry), rephrase property
>>>>> name and description to describe the hardware issue. I see description
>>>>> improved, but not the property name. Again in the end of description you
>>>>
>>>> Both bjorn and Dmitry gave comments to change the description only, and not
>>>> the property name,
>>>>
>>>> correct if I am wrong.
>>>>
>>>>> say what Linux should do. Bindings do not describe Linux OS.
>>>>
>>>> I will remove the last line in the next patch.
>>>>
>>>
>>> You should name the property as, "qcom,keep-refclk-always-on"
>>
>> Keep the clock by who? By driver? Then not, property should describe
>> physical phenomena or hardware issue being fixed here, not what driver
>> should do.
>>
>
> This property indeed fixes the hardware issue (though in board level) and I see
> a plenty of properties similar to this one instructing the OS to keep some
> resource ON to workaround hardware issues. So they are all wrong?
What I said before:
"Again, third time (once from Bjorn, once from Dmitry), rephrase
property name and description to describe the hardware issue. I see
description improved, but not the property name. Again in the end of
description you say what Linux should do. Bindings do not describe Linux
OS."
Best regards,
Krzysztof
On Fri, Dec 01, 2023 at 01:10:48PM +0100, Krzysztof Kozlowski wrote:
> On 01/12/2023 12:10, Manivannan Sadhasivam wrote:
> > On Fri, Dec 01, 2023 at 09:01:43AM +0100, Krzysztof Kozlowski wrote:
> >> On 01/12/2023 07:07, Manivannan Sadhasivam wrote:
> >>> On Tue, Nov 28, 2023 at 02:49:18PM +0530, Krishna Chaitanya Chundru wrote:
> >>>>
> >>>> On 11/28/2023 2:26 PM, Krzysztof Kozlowski wrote:
> >>>>> On 27/11/2023 13:13, Krishna chaitanya chundru wrote:
> >>>>>> Document qcom,refclk-always-on property which is needed in some platforms
> >>>>>> to supply refclk even in PCIe low power states.
> >>>>>>
> >>>>>> Signed-off-by: Krishna chaitanya chundru <[email protected]>
> >>>>>> ---
> >>>>>> .../devicetree/bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml | 7 +++++++
> >>>>>> 1 file changed, 7 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 2c3d6553a7ba..c747c9f35795 100644
> >>>>>> --- a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml
> >>>>>> +++ b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml
> >>>>>> @@ -93,6 +93,13 @@ properties:
> >>>>>> "#phy-cells":
> >>>>>> const: 0
> >>>>>> + qcom,refclk-always-on:
> >>>>>> + type: boolean
> >>>>>> + description: In some platform where PCIe switch is connected, pcie switch due to some design
> >>>>> You received a comment to use proper wrapping: 80. Please implement it.
> >>>> I will update this.
> >>>>>> + limitation fails to propage clkreq signal to the host and due to that host will not send
> >>>>>> + refclk, which results in linkdown in L1.2 or L1.1 exit initiated by EP.
> >>>>>> + This property if set keeps refclk always on even in Low power states.
> >>>>> The property name suggests that's the state of hardware - refclk is
> >>>>> always on. Description suggests you want to instruct OS to do something.
> >>>>>
> >>>>> Again, third time (once from Bjorn, once from Dmitry), rephrase property
> >>>>> name and description to describe the hardware issue. I see description
> >>>>> improved, but not the property name. Again in the end of description you
> >>>>
> >>>> Both bjorn and Dmitry gave comments to change the description only, and not
> >>>> the property name,
> >>>>
> >>>> correct if I am wrong.
> >>>>
> >>>>> say what Linux should do. Bindings do not describe Linux OS.
> >>>>
> >>>> I will remove the last line in the next patch.
> >>>>
> >>>
> >>> You should name the property as, "qcom,keep-refclk-always-on"
> >>
> >> Keep the clock by who? By driver? Then not, property should describe
> >> physical phenomena or hardware issue being fixed here, not what driver
> >> should do.
> >>
> >
> > This property indeed fixes the hardware issue (though in board level) and I see
> > a plenty of properties similar to this one instructing the OS to keep some
> > resource ON to workaround hardware issues. So they are all wrong?
>
> What I said before:
> "Again, third time (once from Bjorn, once from Dmitry), rephrase
> property name and description to describe the hardware issue. I see
> description improved, but not the property name. Again in the end of
> description you say what Linux should do. Bindings do not describe Linux
> OS."
>
You didn't answer my question:
"I see a plenty of properties similar to this one instructing the OS to keep some
resource ON to workaround hardware issues. So they are all wrong?"
If you say they are wrong, why are they approved in the first place?
- Mani
>
> Best regards,
> Krzysztof
>
--
மணிவண்ணன் சதாசிவம்
On 01/12/2023 13:30, Manivannan Sadhasivam wrote:
>> What I said before:
>> "Again, third time (once from Bjorn, once from Dmitry), rephrase
>> property name and description to describe the hardware issue. I see
>> description improved, but not the property name. Again in the end of
>> description you say what Linux should do. Bindings do not describe Linux
>> OS."
>>
>
> You didn't answer my question:
>
> "I see a plenty of properties similar to this one instructing the OS to keep some
> resource ON to workaround hardware issues. So they are all wrong?"
They are not the best, but it all depends on the individual case.
>
> If you say they are wrong, why are they approved in the first place?
Because we don't have time to keep digging what the driver is doing and
what is claimed in DT. Some people don't even CC us on the driver.
Best regards,
Krzysztof
On 1.12.2023 14:25, Krzysztof Kozlowski wrote:
> On 01/12/2023 13:30, Manivannan Sadhasivam wrote:
>>> What I said before:
>>> "Again, third time (once from Bjorn, once from Dmitry), rephrase
>>> property name and description to describe the hardware issue. I see
>>> description improved, but not the property name. Again in the end of
>>> description you say what Linux should do. Bindings do not describe Linux
>>> OS."
>>>
>>
>> You didn't answer my question:
>>
>> "I see a plenty of properties similar to this one instructing the OS to keep some
>> resource ON to workaround hardware issues. So they are all wrong?"
>
> They are not the best, but it all depends on the individual case.
>
>>
>> If you say they are wrong, why are they approved in the first place?
> Because we don't have time to keep digging what the driver is doing and
> what is claimed in DT. Some people don't even CC us on the driver.
Not sure if I asked this before, but can this not be set in the config
struct inside the driver?
Konrad
On Fri, Dec 01, 2023 at 10:29:11PM +0100, Konrad Dybcio wrote:
> On 1.12.2023 14:25, Krzysztof Kozlowski wrote:
> > On 01/12/2023 13:30, Manivannan Sadhasivam wrote:
> >>> What I said before:
> >>> "Again, third time (once from Bjorn, once from Dmitry), rephrase
> >>> property name and description to describe the hardware issue. I see
> >>> description improved, but not the property name. Again in the end of
> >>> description you say what Linux should do. Bindings do not describe Linux
> >>> OS."
> >>>
> >>
> >> You didn't answer my question:
> >>
> >> "I see a plenty of properties similar to this one instructing the OS to keep some
> >> resource ON to workaround hardware issues. So they are all wrong?"
> >
> > They are not the best, but it all depends on the individual case.
> >
> >>
> >> If you say they are wrong, why are they approved in the first place?
> > Because we don't have time to keep digging what the driver is doing and
> > what is claimed in DT. Some people don't even CC us on the driver.
> Not sure if I asked this before, but can this not be set in the config
> struct inside the driver?
>
This cannot be the default config for any platform as keeping refclk always on
will have some power penalty. Only if the hardware (EP or board design) has any
issue, we can turn on this option.
- Mani
> Konrad
--
மணிவண்ணன் சதாசிவம்
On Fri, Dec 01, 2023 at 02:25:44PM +0100, Krzysztof Kozlowski wrote:
> On 01/12/2023 13:30, Manivannan Sadhasivam wrote:
> >> What I said before:
> >> "Again, third time (once from Bjorn, once from Dmitry), rephrase
> >> property name and description to describe the hardware issue. I see
> >> description improved, but not the property name. Again in the end of
> >> description you say what Linux should do. Bindings do not describe Linux
> >> OS."
> >>
> >
> > You didn't answer my question:
> >
> > "I see a plenty of properties similar to this one instructing the OS to keep some
> > resource ON to workaround hardware issues. So they are all wrong?"
>
> They are not the best, but it all depends on the individual case.
>
> >
> > If you say they are wrong, why are they approved in the first place?
> Because we don't have time to keep digging what the driver is doing and
> what is claimed in DT. Some people don't even CC us on the driver.
>
OK. How about, "qcom,broken-refclk"? This reflects the fact that the default
refclk operation is broken on this platform, so the OS should be prepared for
it (by keeping it always on).
- Mani
>
> Best regards,
> Krzysztof
>
--
மணிவண்ணன் சதாசிவம்
On 06/12/2023 14:10, Manivannan Sadhasivam wrote:
>>>
>>> If you say they are wrong, why are they approved in the first place?
>> Because we don't have time to keep digging what the driver is doing and
>> what is claimed in DT. Some people don't even CC us on the driver.
>>
>
> OK. How about, "qcom,broken-refclk"? This reflects the fact that the default
> refclk operation is broken on this platform, so the OS should be prepared for
> it (by keeping it always on).
>
Sounds very good to me.
Best regards,
Krzysztof
On Wed, Dec 06, 2023 at 06:40:09PM +0530, Manivannan Sadhasivam wrote:
> OK. How about, "qcom,broken-refclk"? This reflects the fact that the default
> refclk operation is broken on this platform, so the OS should be prepared for
> it (by keeping it always on).
Shouldn't that be
qcom,broken-clkreq
since its the CLKREQ# signal used to request REFCLK that is broken, not
the REFCLK itself?
Johan
On Thu, Dec 07, 2023 at 10:51:09AM +0100, Johan Hovold wrote:
> On Wed, Dec 06, 2023 at 06:40:09PM +0530, Manivannan Sadhasivam wrote:
>
> > OK. How about, "qcom,broken-refclk"? This reflects the fact that the default
> > refclk operation is broken on this platform, so the OS should be prepared for
> > it (by keeping it always on).
>
> Shouldn't that be
>
> qcom,broken-clkreq
>
> since its the CLKREQ# signal used to request REFCLK that is broken, not
> the REFCLK itself?
>
Darn... You are right. I got carried away by the initial property name. Thanks
for spotting!
- Mani
> Johan
--
மணிவண்ணன் சதாசிவம்
On 12/6/23 14:07, Manivannan Sadhasivam wrote:
> On Fri, Dec 01, 2023 at 10:29:11PM +0100, Konrad Dybcio wrote:
>> On 1.12.2023 14:25, Krzysztof Kozlowski wrote:
>>> On 01/12/2023 13:30, Manivannan Sadhasivam wrote:
>>>>> What I said before:
>>>>> "Again, third time (once from Bjorn, once from Dmitry), rephrase
>>>>> property name and description to describe the hardware issue. I see
>>>>> description improved, but not the property name. Again in the end of
>>>>> description you say what Linux should do. Bindings do not describe Linux
>>>>> OS."
>>>>>
>>>>
>>>> You didn't answer my question:
>>>>
>>>> "I see a plenty of properties similar to this one instructing the OS to keep some
>>>> resource ON to workaround hardware issues. So they are all wrong?"
>>>
>>> They are not the best, but it all depends on the individual case.
>>>
>>>>
>>>> If you say they are wrong, why are they approved in the first place?
>>> Because we don't have time to keep digging what the driver is doing and
>>> what is claimed in DT. Some people don't even CC us on the driver.
>> Not sure if I asked this before, but can this not be set in the config
>> struct inside the driver?
>>
>
> This cannot be the default config for any platform as keeping refclk always on
> will have some power penalty. Only if the hardware (EP or board design) has any
> issue, we can turn on this option.
So, if I'm reading this right, this concerns some but not all
8280 boards?
Konrad
On Thu, Dec 07, 2023 at 03:42:52PM +0530, Manivannan Sadhasivam wrote:
> On Thu, Dec 07, 2023 at 10:51:09AM +0100, Johan Hovold wrote:
> > On Wed, Dec 06, 2023 at 06:40:09PM +0530, Manivannan Sadhasivam wrote:
> >
> > > OK. How about, "qcom,broken-refclk"? This reflects the fact that the default
> > > refclk operation is broken on this platform, so the OS should be prepared for
> > > it (by keeping it always on).
> >
> > Shouldn't that be
> >
> > qcom,broken-clkreq
> >
> > since its the CLKREQ# signal used to request REFCLK that is broken, not
> > the REFCLK itself?
> >
>
> Darn... You are right. I got carried away by the initial property name. Thanks
> for spotting!
Thinking some more on this after hitting send: It may still be wrong
with a 'broken-clkreq' property in the PHY instead of in the controller
(or endpoint).
Could there not be other ways to handle a broken clkreq signal so that
this really should be a decision made by the OS, for example, to disable
L1 substates and clock PM?
Simply leaving the refclk always on in the PHY seems like a bit of a
hack and I'm not even sure that can be considered correct.
Having a property that maps directly to that behaviour has rightly been
rejected, but it seems that simply renaming the flag but keeping it in
the PHY may still not be the right thing to do here.
Johan
On Thu, Dec 07, 2023 at 02:05:12PM +0100, Johan Hovold wrote:
> On Thu, Dec 07, 2023 at 03:42:52PM +0530, Manivannan Sadhasivam wrote:
> > On Thu, Dec 07, 2023 at 10:51:09AM +0100, Johan Hovold wrote:
> > > On Wed, Dec 06, 2023 at 06:40:09PM +0530, Manivannan Sadhasivam wrote:
> > >
> > > > OK. How about, "qcom,broken-refclk"? This reflects the fact that the default
> > > > refclk operation is broken on this platform, so the OS should be prepared for
> > > > it (by keeping it always on).
> > >
> > > Shouldn't that be
> > >
> > > qcom,broken-clkreq
> > >
> > > since its the CLKREQ# signal used to request REFCLK that is broken, not
> > > the REFCLK itself?
> > >
> >
> > Darn... You are right. I got carried away by the initial property name. Thanks
> > for spotting!
>
> Thinking some more on this after hitting send: It may still be wrong
> with a 'broken-clkreq' property in the PHY instead of in the controller
> (or endpoint).
>
> Could there not be other ways to handle a broken clkreq signal so that
> this really should be a decision made by the OS, for example, to disable
> L1 substates and clock PM?
>
One has to weigh the power consumption between keeping refclk always on and
disabling L1SS. Chaitanya, can you measure power consumption in both cases?
> Simply leaving the refclk always on in the PHY seems like a bit of a
> hack and I'm not even sure that can be considered correct.
>
I wouldn't agree it is a hack, even though it may sound like one. The option to
keep refclk always on in the PHY is precisely there for usecase like this.
- Mani
> Having a property that maps directly to that behaviour has rightly been
> rejected, but it seems that simply renaming the flag but keeping it in
> the PHY may still not be the right thing to do here.
>
> Johan
--
மணிவண்ணன் சதாசிவம்
On Thu, Dec 07, 2023 at 06:50:32PM +0530, Manivannan Sadhasivam wrote:
> On Thu, Dec 07, 2023 at 02:05:12PM +0100, Johan Hovold wrote:
> > On Thu, Dec 07, 2023 at 03:42:52PM +0530, Manivannan Sadhasivam wrote:
> > > On Thu, Dec 07, 2023 at 10:51:09AM +0100, Johan Hovold wrote:
> > > > Shouldn't that be
> > > >
> > > > qcom,broken-clkreq
> > > >
> > > > since its the CLKREQ# signal used to request REFCLK that is broken, not
> > > > the REFCLK itself?
> > > >
> > >
> > > Darn... You are right. I got carried away by the initial property name. Thanks
> > > for spotting!
> >
> > Thinking some more on this after hitting send: It may still be wrong
> > with a 'broken-clkreq' property in the PHY instead of in the controller
> > (or endpoint).
> >
> > Could there not be other ways to handle a broken clkreq signal so that
> > this really should be a decision made by the OS, for example, to disable
> > L1 substates and clock PM?
>
> One has to weigh the power consumption between keeping refclk always on and
> disabling L1SS. Chaitanya, can you measure power consumption in both cases?
Sure, my point was just that that's a policy decision and not something
that should be encoded in the devicetree (as was initially proposed).
And that the right place for the renamed property is not necessarily in
the PHY node either.
> > Simply leaving the refclk always on in the PHY seems like a bit of a
> > hack and I'm not even sure that can be considered correct.
>
> I wouldn't agree it is a hack, even though it may sound like one. The option to
> keep refclk always on in the PHY is precisely there for usecase like this.
I just skimmed the spec so perhaps I'm missing something, but there's
definitely wordings in there that explicitly says that L1 PM substates
must not be enabling unless you have a functioning CLKREQ# signal.
Johan
On Thu, Dec 07, 2023 at 02:36:49PM +0100, Johan Hovold wrote:
> On Thu, Dec 07, 2023 at 06:50:32PM +0530, Manivannan Sadhasivam wrote:
> > On Thu, Dec 07, 2023 at 02:05:12PM +0100, Johan Hovold wrote:
> > > On Thu, Dec 07, 2023 at 03:42:52PM +0530, Manivannan Sadhasivam wrote:
> > > > On Thu, Dec 07, 2023 at 10:51:09AM +0100, Johan Hovold wrote:
>
> > > > > Shouldn't that be
> > > > >
> > > > > qcom,broken-clkreq
> > > > >
> > > > > since its the CLKREQ# signal used to request REFCLK that is broken, not
> > > > > the REFCLK itself?
> > > > >
> > > >
> > > > Darn... You are right. I got carried away by the initial property name. Thanks
> > > > for spotting!
> > >
> > > Thinking some more on this after hitting send: It may still be wrong
> > > with a 'broken-clkreq' property in the PHY instead of in the controller
> > > (or endpoint).
> > >
> > > Could there not be other ways to handle a broken clkreq signal so that
> > > this really should be a decision made by the OS, for example, to disable
> > > L1 substates and clock PM?
> >
> > One has to weigh the power consumption between keeping refclk always on and
> > disabling L1SS. Chaitanya, can you measure power consumption in both cases?
>
> Sure, my point was just that that's a policy decision and not something
> that should be encoded in the devicetree (as was initially proposed).
>
> And that the right place for the renamed property is not necessarily in
> the PHY node either.
>
> > > Simply leaving the refclk always on in the PHY seems like a bit of a
> > > hack and I'm not even sure that can be considered correct.
> >
> > I wouldn't agree it is a hack, even though it may sound like one. The option to
> > keep refclk always on in the PHY is precisely there for usecase like this.
>
> I just skimmed the spec so perhaps I'm missing something, but there's
> definitely wordings in there that explicitly says that L1 PM substates
> must not be enabling unless you have a functioning CLKREQ# signal.
>
I checked 'PCI Express Base spec 4.0', and there is a wording in 'Section 5.5
L1 PM Substates':
For L1 PM ... each port must have a unique instance of the signal (CLKREQ#) and
the upstream and downstream port CLKREQ# signals must be connected.
So yes, we should not enable L1 PM substates in this case. And also it appears
to me that the property should be part of the controller node, since CLKREQ# is
handled by the controller instance.
- Mani
> Johan
--
மணிவண்ணன் சதாசிவம்