diff mbox series

[v3] PCI: j721e: Delay 100ms T_PVPERL from power stable to PERST# inactive

Message ID 20230707095119.447952-1-a-verma1@ti.com
State New
Headers
Series [v3] PCI: j721e: Delay 100ms T_PVPERL from power stable to PERST# inactive |

Commit Message

Achal Verma July 7, 2023, 9:51 a.m. UTC 
  As per the PCIe Card Electromechanical specification REV. 5.0, PERST#
signal should be de-asserted after minimum 100ms from the time power-rails
become stable. So, to ensure 100ms delay to give sufficient time for
power-rails and refclk to become stable, change delay from 100us to 100ms.

From PCIe Card Electromechanical specification REV. 5.0 section 2.9.2:
TPVPERL: Power stable to PERST# inactive - 100ms

Fixes: f3e25911a430 ("PCI: j721e: Add TI J721E PCIe driver")
Signed-off-by: Achal Verma <a-verma1@ti.com>
---

Changes from v2:
* Fix commit message.

Change from v1:
* Add macro for delay value.

 drivers/pci/controller/cadence/pci-j721e.c | 11 +++++------
 drivers/pci/pci.h                          |  2 ++
 2 files changed, 7 insertions(+), 6 deletions(-)

Comments

Achal Verma July 14, 2023, 6:46 a.m. UTC | #1 
On 7/7/2023 3:21 PM, Achal Verma wrote:
> As per the PCIe Card Electromechanical specification REV. 5.0, PERST#
> signal should be de-asserted after minimum 100ms from the time power-rails
> become stable. So, to ensure 100ms delay to give sufficient time for
> power-rails and refclk to become stable, change delay from 100us to 100ms.
> 
>  From PCIe Card Electromechanical specification REV. 5.0 section 2.9.2:
> TPVPERL: Power stable to PERST# inactive - 100ms
> 
> Fixes: f3e25911a430 ("PCI: j721e: Add TI J721E PCIe driver")
> Signed-off-by: Achal Verma <a-verma1@ti.com>
Hello Bjorn,

Could you please bless this with "Reviewed-by" tag.

Thanks,
Achal Verma
> ---
> 
> Changes from v2:
> * Fix commit message.
> 
> Change from v1:
> * Add macro for delay value.
> 
>   drivers/pci/controller/cadence/pci-j721e.c | 11 +++++------
>   drivers/pci/pci.h                          |  2 ++
>   2 files changed, 7 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/pci/controller/cadence/pci-j721e.c b/drivers/pci/controller/cadence/pci-j721e.c
> index e70213c9060a..32b6a7dc3cff 100644
> --- a/drivers/pci/controller/cadence/pci-j721e.c
> +++ b/drivers/pci/controller/cadence/pci-j721e.c
> @@ -498,14 +498,13 @@ static int j721e_pcie_probe(struct platform_device *pdev)
>   
>   		/*
>   		 * "Power Sequencing and Reset Signal Timings" table in
> -		 * PCI EXPRESS CARD ELECTROMECHANICAL SPECIFICATION, REV. 3.0
> -		 * indicates PERST# should be deasserted after minimum of 100us
> -		 * once REFCLK is stable. The REFCLK to the connector in RC
> -		 * mode is selected while enabling the PHY. So deassert PERST#
> -		 * after 100 us.
> +		 * PCI EXPRESS CARD ELECTROMECHANICAL SPECIFICATION, REV. 5.0
> +		 * indicates PERST# should be deasserted after minimum of 100ms
> +		 * after power rails achieve specified operating limits and
> +		 * within this period reference clock should also become stable.
>   		 */
>   		if (gpiod) {
> -			usleep_range(100, 200);
> +			msleep(PCIE_TPVPERL_DELAY_MS);
>   			gpiod_set_value_cansleep(gpiod, 1);
>   		}
>   
> diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h
> index a4c397434057..6ab2367e5867 100644
> --- a/drivers/pci/pci.h
> +++ b/drivers/pci/pci.h
> @@ -13,6 +13,8 @@
>   
>   #define PCIE_LINK_RETRAIN_TIMEOUT_MS	1000
>   
> +#define PCIE_TPVPERL_DELAY_MS	100	/* see PCIe CEM r5.0, sec 2.9.2 */
> +
>   extern const unsigned char pcie_link_speed[];
>   extern bool pci_early_dump;
>
Bjorn Helgaas July 18, 2023, 3:55 p.m. UTC | #2 
On Fri, Jul 07, 2023 at 03:21:19PM +0530, Achal Verma wrote:
> As per the PCIe Card Electromechanical specification REV. 5.0, PERST#
> signal should be de-asserted after minimum 100ms from the time power-rails
> become stable. So, to ensure 100ms delay to give sufficient time for
> power-rails and refclk to become stable, change delay from 100us to 100ms.
> 
> From PCIe Card Electromechanical specification REV. 5.0 section 2.9.2:
> TPVPERL: Power stable to PERST# inactive - 100ms
> 
> Fixes: f3e25911a430 ("PCI: j721e: Add TI J721E PCIe driver")
> Signed-off-by: Achal Verma <a-verma1@ti.com>
> ---
> 
> Changes from v2:
> * Fix commit message.
> 
> Change from v1:
> * Add macro for delay value.
> 
>  drivers/pci/controller/cadence/pci-j721e.c | 11 +++++------
>  drivers/pci/pci.h                          |  2 ++
>  2 files changed, 7 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/pci/controller/cadence/pci-j721e.c b/drivers/pci/controller/cadence/pci-j721e.c
> index e70213c9060a..32b6a7dc3cff 100644
> --- a/drivers/pci/controller/cadence/pci-j721e.c
> +++ b/drivers/pci/controller/cadence/pci-j721e.c
> @@ -498,14 +498,13 @@ static int j721e_pcie_probe(struct platform_device *pdev)
>  
>  		/*
>  		 * "Power Sequencing and Reset Signal Timings" table in
> -		 * PCI EXPRESS CARD ELECTROMECHANICAL SPECIFICATION, REV. 3.0
> -		 * indicates PERST# should be deasserted after minimum of 100us
> -		 * once REFCLK is stable. The REFCLK to the connector in RC
> -		 * mode is selected while enabling the PHY. So deassert PERST#
> -		 * after 100 us.
> +		 * PCI EXPRESS CARD ELECTROMECHANICAL SPECIFICATION, REV. 5.0
> +		 * indicates PERST# should be deasserted after minimum of 100ms
> +		 * after power rails achieve specified operating limits and
> +		 * within this period reference clock should also become stable.

I think the problem is not that the current code is *wrong*, because
we do need to observe T_PERST-CLK, but that it failed to *also*
account for T_PVPERL.

There are two delays before deasserting PERST#:

  T_PVPERL: delay after power becomes stable
  T_PERST-CLK: delay after REFCLK becomes stable

I assume power is enabled by phy_power_on(), and REFCLK is enabled by
clk_prepare_enable():

  cdns_pcie_init_phy
    cdns_pcie_enable_phy
      phy_power_on             <-- power becomes stable
  clk_prepare_enable           <-- REFCLK becomes stable
  if (gpiod)
    usleep_range
    gpiod_set_value_cansleep(gpiod, 1)   <-- deassert PERST#

I don't actually know if phy_power_on() guarantees that power is
stable before it returns.  But I guess that's our assumption?
Similarly for clk_prepare_enable().

In any case, we have to observe both delays.  They overlap, and
T_PVPERL is 1000 times longer than T_PERST-CLK, so there might be
enough slop in an msleep(100) to cover both, but I think I would do
the simple-minded:

  msleep(PCIE_TPVPERL_MS);
  usleep_range(PCIE_TPERST_CLK_US, 2 * PCIE_TPERST_CLK_US);

This is slightly more conservative than necessary because they
overlap, but at least it shows that we thought about both of them.

>  		if (gpiod) {
> -			usleep_range(100, 200);
> +			msleep(PCIE_TPVPERL_DELAY_MS);
>  			gpiod_set_value_cansleep(gpiod, 1);

I wish this local variable were named something like "perst_gpiod"
instead of "gpiod".  We already know from its use in
gpiod_set_value_cansleep() that it's a GPIO.  What's NOT obvious from
the context is that this is the PERST# signal.

Tangent: it looks like the DT "reset" property that I'm assuming
controls PERST# is optional.  How do we enforce these delays if that
property is missing?

> diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h
> index a4c397434057..6ab2367e5867 100644
> --- a/drivers/pci/pci.h
> +++ b/drivers/pci/pci.h
> @@ -13,6 +13,8 @@
>  
>  #define PCIE_LINK_RETRAIN_TIMEOUT_MS	1000
>  
> +#define PCIE_TPVPERL_DELAY_MS	100	/* see PCIe CEM r5.0, sec 2.9.2 */
> +
>  extern const unsigned char pcie_link_speed[];
>  extern bool pci_early_dump;
>  
> -- 
> 2.25.1
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Achal Verma Aug. 2, 2023, 9:08 a.m. UTC | #3 
On 7/18/2023 9:25 PM, Bjorn Helgaas wrote:
> On Fri, Jul 07, 2023 at 03:21:19PM +0530, Achal Verma wrote:
>> As per the PCIe Card Electromechanical specification REV. 5.0, PERST#
>> signal should be de-asserted after minimum 100ms from the time power-rails
>> become stable. So, to ensure 100ms delay to give sufficient time for
>> power-rails and refclk to become stable, change delay from 100us to 100ms.
>>
>>  From PCIe Card Electromechanical specification REV. 5.0 section 2.9.2:
>> TPVPERL: Power stable to PERST# inactive - 100ms
>>
>> Fixes: f3e25911a430 ("PCI: j721e: Add TI J721E PCIe driver")
>> Signed-off-by: Achal Verma <a-verma1@ti.com>
>> ---
>>
>> Changes from v2:
>> * Fix commit message.
>>
>> Change from v1:
>> * Add macro for delay value.
>>
>>   drivers/pci/controller/cadence/pci-j721e.c | 11 +++++------
>>   drivers/pci/pci.h                          |  2 ++
>>   2 files changed, 7 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/pci/controller/cadence/pci-j721e.c b/drivers/pci/controller/cadence/pci-j721e.c
>> index e70213c9060a..32b6a7dc3cff 100644
>> --- a/drivers/pci/controller/cadence/pci-j721e.c
>> +++ b/drivers/pci/controller/cadence/pci-j721e.c
>> @@ -498,14 +498,13 @@ static int j721e_pcie_probe(struct platform_device *pdev)
>>   
>>   		/*
>>   		 * "Power Sequencing and Reset Signal Timings" table in
>> -		 * PCI EXPRESS CARD ELECTROMECHANICAL SPECIFICATION, REV. 3.0
>> -		 * indicates PERST# should be deasserted after minimum of 100us
>> -		 * once REFCLK is stable. The REFCLK to the connector in RC
>> -		 * mode is selected while enabling the PHY. So deassert PERST#
>> -		 * after 100 us.
>> +		 * PCI EXPRESS CARD ELECTROMECHANICAL SPECIFICATION, REV. 5.0
>> +		 * indicates PERST# should be deasserted after minimum of 100ms
>> +		 * after power rails achieve specified operating limits and
>> +		 * within this period reference clock should also become stable.
> 
> I think the problem is not that the current code is *wrong*, because
> we do need to observe T_PERST-CLK, but that it failed to *also*
> account for T_PVPERL.
> 
> There are two delays before deasserting PERST#:
> 
>    T_PVPERL: delay after power becomes stable
>    T_PERST-CLK: delay after REFCLK becomes stable
> 
> I assume power is enabled by phy_power_on(), and REFCLK is enabled by
> clk_prepare_enable():
> 
>    cdns_pcie_init_phy
>      cdns_pcie_enable_phy
>        phy_power_on             <-- power becomes stable
>    clk_prepare_enable           <-- REFCLK becomes stable
>    if (gpiod)
>      usleep_range
>      gpiod_set_value_cansleep(gpiod, 1)   <-- deassert PERST#
> 
> I don't actually know if phy_power_on() guarantees that power is
> stable before it returns.  But I guess that's our assumption?
> Similarly for clk_prepare_enable().
> 
> In any case, we have to observe both delays.  They overlap, and
> T_PVPERL is 1000 times longer than T_PERST-CLK, so there might be
> enough slop in an msleep(100) to cover both, but I think I would do
> the simple-minded:
> 
>    msleep(PCIE_TPVPERL_MS);
>    usleep_range(PCIE_TPERST_CLK_US, 2 * PCIE_TPERST_CLK_US);
> 
I think adding 100us more is not required since as you said and as also 
mentioned in CEM spec, 100ms covers for both power rails and refclock to
get stable and 2 consecutive sleep call looks different to me.
But if still required (please let me know), will do the suggested 
change, along with other fixes you asked below.
> This is slightly more conservative than necessary because they
> overlap, but at least it shows that we thought about both of them.
> 
>>   		if (gpiod) {
>> -			usleep_range(100, 200);
>> +			msleep(PCIE_TPVPERL_DELAY_MS);
>>   			gpiod_set_value_cansleep(gpiod, 1);
> 
> I wish this local variable were named something like "perst_gpiod"
> instead of "gpiod".  We already know from its use in
> gpiod_set_value_cansleep() that it's a GPIO.  What's NOT obvious from
> the context is that this is the PERST# signal.
sure will change variable name to perst_gpiod.
> 
> Tangent: it looks like the DT "reset" property that I'm assuming
> controls PERST# is optional.  How do we enforce these delays if that
> property is missing?
> 
yes gpiod_get shouldn't be optional, will fix this too.

>> diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h
>> index a4c397434057..6ab2367e5867 100644
>> --- a/drivers/pci/pci.h
>> +++ b/drivers/pci/pci.h
>> @@ -13,6 +13,8 @@
>>   
>>   #define PCIE_LINK_RETRAIN_TIMEOUT_MS	1000
>>   
>> +#define PCIE_TPVPERL_DELAY_MS	100	/* see PCIe CEM r5.0, sec 2.9.2 */
>> +
>>   extern const unsigned char pcie_link_speed[];
>>   extern bool pci_early_dump;
>>   
>> -- 
>> 2.25.1
>>
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Bjorn Helgaas Aug. 2, 2023, 7:24 p.m. UTC | #4 
On Wed, Aug 02, 2023 at 02:38:02PM +0530, Verma, Achal wrote:
> On 7/18/2023 9:25 PM, Bjorn Helgaas wrote:
> > On Fri, Jul 07, 2023 at 03:21:19PM +0530, Achal Verma wrote:
> > > As per the PCIe Card Electromechanical specification REV. 5.0, PERST#
> > > signal should be de-asserted after minimum 100ms from the time power-rails
> > > become stable. So, to ensure 100ms delay to give sufficient time for
> > > power-rails and refclk to become stable, change delay from 100us to 100ms.
> > > 
> > >  From PCIe Card Electromechanical specification REV. 5.0 section 2.9.2:
> > > TPVPERL: Power stable to PERST# inactive - 100ms
> > > 
> > > Fixes: f3e25911a430 ("PCI: j721e: Add TI J721E PCIe driver")
> > > Signed-off-by: Achal Verma <a-verma1@ti.com>
> > > ---
> > > 
> > > Changes from v2:
> > > * Fix commit message.
> > > 
> > > Change from v1:
> > > * Add macro for delay value.
> > > 
> > >   drivers/pci/controller/cadence/pci-j721e.c | 11 +++++------
> > >   drivers/pci/pci.h                          |  2 ++
> > >   2 files changed, 7 insertions(+), 6 deletions(-)
> > > 
> > > diff --git a/drivers/pci/controller/cadence/pci-j721e.c b/drivers/pci/controller/cadence/pci-j721e.c
> > > index e70213c9060a..32b6a7dc3cff 100644
> > > --- a/drivers/pci/controller/cadence/pci-j721e.c
> > > +++ b/drivers/pci/controller/cadence/pci-j721e.c
> > > @@ -498,14 +498,13 @@ static int j721e_pcie_probe(struct platform_device *pdev)
> > >   		/*
> > >   		 * "Power Sequencing and Reset Signal Timings" table in
> > > -		 * PCI EXPRESS CARD ELECTROMECHANICAL SPECIFICATION, REV. 3.0
> > > -		 * indicates PERST# should be deasserted after minimum of 100us
> > > -		 * once REFCLK is stable. The REFCLK to the connector in RC
> > > -		 * mode is selected while enabling the PHY. So deassert PERST#
> > > -		 * after 100 us.
> > > +		 * PCI EXPRESS CARD ELECTROMECHANICAL SPECIFICATION, REV. 5.0
> > > +		 * indicates PERST# should be deasserted after minimum of 100ms
> > > +		 * after power rails achieve specified operating limits and
> > > +		 * within this period reference clock should also become stable.
> > 
> > I think the problem is not that the current code is *wrong*, because
> > we do need to observe T_PERST-CLK, but that it failed to *also*
> > account for T_PVPERL.
> > 
> > There are two delays before deasserting PERST#:
> > 
> >    T_PVPERL: delay after power becomes stable
> >    T_PERST-CLK: delay after REFCLK becomes stable
> > 
> > I assume power is enabled by phy_power_on(), and REFCLK is enabled by
> > clk_prepare_enable():
> > 
> >    cdns_pcie_init_phy
> >      cdns_pcie_enable_phy
> >        phy_power_on             <-- power becomes stable
> >    clk_prepare_enable           <-- REFCLK becomes stable
> >    if (gpiod)
> >      usleep_range
> >      gpiod_set_value_cansleep(gpiod, 1)   <-- deassert PERST#
> > 
> > I don't actually know if phy_power_on() guarantees that power is
> > stable before it returns.  But I guess that's our assumption?
> > Similarly for clk_prepare_enable().
> > 
> > In any case, we have to observe both delays.  They overlap, and
> > T_PVPERL is 1000 times longer than T_PERST-CLK, so there might be
> > enough slop in an msleep(100) to cover both, but I think I would do
> > the simple-minded:
> > 
> >    msleep(PCIE_TPVPERL_MS);
> >    usleep_range(PCIE_TPERST_CLK_US, 2 * PCIE_TPERST_CLK_US);
> > 
> I think adding 100us more is not required since as you said and as also
> mentioned in CEM spec, 100ms covers for both power rails and refclock to
> get stable and 2 consecutive sleep call looks different to me.
> But if still required (please let me know), will do the suggested change,
> along with other fixes you asked below.

If REFCLK is stable when clk_prepare_enable() returns, and we don't
start the msleep(PCIE_TPVPERL_MS) until then, it should be safe.  
Maybe mention T_PERST-CLK in a comment, e.g.,

  PCIe CEM r5.0, sec 2.2.1, requires both T_PVPERL (100ms) between
  power stable and PERST# inactive and T_PERST_CLK (100us) between
  REFCLK stable and PERST# inactive.  Starting the T_PVPERL delay
  after REFCLK is stable means that delay covers T_PERST_CLK as well.

Bjorn
diff mbox series

Patch

diff --git a/drivers/pci/controller/cadence/pci-j721e.c b/drivers/pci/controller/cadence/pci-j721e.c
index e70213c9060a..32b6a7dc3cff 100644
--- a/drivers/pci/controller/cadence/pci-j721e.c
+++ b/drivers/pci/controller/cadence/pci-j721e.c
@@ -498,14 +498,13 @@  static int j721e_pcie_probe(struct platform_device *pdev)
 
 		/*
 		 * "Power Sequencing and Reset Signal Timings" table in
-		 * PCI EXPRESS CARD ELECTROMECHANICAL SPECIFICATION, REV. 3.0
-		 * indicates PERST# should be deasserted after minimum of 100us
-		 * once REFCLK is stable. The REFCLK to the connector in RC
-		 * mode is selected while enabling the PHY. So deassert PERST#
-		 * after 100 us.
+		 * PCI EXPRESS CARD ELECTROMECHANICAL SPECIFICATION, REV. 5.0
+		 * indicates PERST# should be deasserted after minimum of 100ms
+		 * after power rails achieve specified operating limits and
+		 * within this period reference clock should also become stable.
 		 */
 		if (gpiod) {
-			usleep_range(100, 200);
+			msleep(PCIE_TPVPERL_DELAY_MS);
 			gpiod_set_value_cansleep(gpiod, 1);
 		}
 
diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h
index a4c397434057..6ab2367e5867 100644
--- a/drivers/pci/pci.h
+++ b/drivers/pci/pci.h
@@ -13,6 +13,8 @@ 
 
 #define PCIE_LINK_RETRAIN_TIMEOUT_MS	1000
 
+#define PCIE_TPVPERL_DELAY_MS	100	/* see PCIe CEM r5.0, sec 2.9.2 */
+
 extern const unsigned char pcie_link_speed[];
 extern bool pci_early_dump;