public inbox for linux-arm-kernel@lists.infradead.org
 help / color / mirror / Atom feed
From: Bjorn Helgaas <helgaas@kernel.org>
To: Achal Verma <a-verma1@ti.com>
Cc: Vignesh Raghavendra <vigneshr@ti.com>,
	Tom Joseph <tjoseph@cadence.com>,
	Lorenzo Pieralisi <lpieralisi@kernel.org>,
	Krzysztof Wilczy_ski <kw@linux.com>,
	Rob Herring <robh@kernel.org>,
	Bjorn Helgaas <bhelgaas@google.com>,
	linux-omap@vger.kernel.org, linux-pci@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] PCI: j721e: Fix delay before PERST# deassert
Date: Mon, 3 Jul 2023 11:21:56 -0500	[thread overview]
Message-ID: <20230703162156.GA525196@bhelgaas> (raw)
In-Reply-To: <20230703112914.68806-1-a-verma1@ti.com>

In subject, "Fix" doesn't convey much information.  Does it increase?
Decrease?  How much time are we talking about?  PERST# deassert is at
one end of the delay; what event is at the other end?

Some of these useful bits of information could appear in the subject
line.

On Mon, Jul 03, 2023 at 04:59:14PM +0530, Achal Verma wrote:
> As per the PCIe Card Electromechanical specification REV. 3.0, PERST#

I think the current rev of this spec is r5.0.  Can you cite that
instead?  I think the relevant section is r5.0, sec 2.9.2.

> signal should be de-asserted after minimum 100ms from the time power-rails
> become stable. Current delay of 100us is observed to be not enough on some
> custom platform implemented using TI's K3 SOCs.

Is this delay for the benefit of the Root Port or for the attached
Endpoint?  If the latter, my guess is that some Endpoints might
tolerate the current shorter delay, while others might require more,
and it doesn't sound like "TI's K3 SoC" would be relevant here.

> 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. 3.0 section 2.6.2:
> TPVPERL: Power stable to PERST# inactive - 100ms
> T-PERST-CLK: REFCLK stable before PERST# inactive - 100 usec.

Numbers like 100ms that come from the PCIe specs should have #defines
for them.  If we don't have one already, can you add one, please?

> Fixes: f3e25911a430 ("PCI: j721e: Add TI J721E PCIe driver")
> Signed-off-by: Achal Verma <a-verma1@ti.com>
> ---
>  drivers/pci/controller/cadence/pci-j721e.c | 9 ++++-----
>  1 file changed, 4 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/pci/controller/cadence/pci-j721e.c b/drivers/pci/controller/cadence/pci-j721e.c
> index e70213c9060a..fa2b4c11d2c4 100644
> --- a/drivers/pci/controller/cadence/pci-j721e.c
> +++ b/drivers/pci/controller/cadence/pci-j721e.c
> @@ -499,13 +499,12 @@ 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.
> +		 * 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(100);
>  			gpiod_set_value_cansleep(gpiod, 1);
>  		}
>  
> -- 
> 2.25.1
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  parent reply	other threads:[~2023-07-03 16:22 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-03 11:29 [PATCH] PCI: j721e: Fix delay before PERST# deassert Achal Verma
2023-07-03 13:49 ` Li Chen
2023-07-03 14:43   ` [EXTERNAL] " Verma, Achal
2023-07-03 16:21 ` Bjorn Helgaas [this message]
2023-07-04 16:06   ` Verma, Achal
2023-07-05 15:49     ` Bjorn Helgaas

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230703162156.GA525196@bhelgaas \
    --to=helgaas@kernel.org \
    --cc=a-verma1@ti.com \
    --cc=bhelgaas@google.com \
    --cc=kw@linux.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=lpieralisi@kernel.org \
    --cc=robh@kernel.org \
    --cc=tjoseph@cadence.com \
    --cc=vigneshr@ti.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox