From: Bjorn Helgaas <helgaas@kernel.org>
To: Joao Pinto <Joao.Pinto@synopsys.com>
Cc: arnd@arndb.de, linux-pci@vger.kernel.org,
linux-kernel@vger.kernel.org, CARLOS.PALMINHA@synopsys.com
Subject: Re: [PATCH] link up validation moved to pcie-designware
Date: Mon, 8 Feb 2016 10:41:04 -0600 [thread overview]
Message-ID: <20160208164104.GA17268@localhost> (raw)
In-Reply-To: <b00bf38b4351831b97892b747d48c9206fbab9c7.1454935205.git.jpinto@synopsys.com>
On Mon, Feb 08, 2016 at 12:43:58PM +0000, Joao Pinto wrote:
> This patch goal is to centralize in pcie-designware the link up
> validation. A new function was added to pci-designware that is
> responsible for doing such a task. This was implemented in a form that
> permits flexibility for all SoCs.
>
> Signed-off-by: Joao Pinto <jpinto@synopsys.com>
> ---
> drivers/pci/host/pci-dra7xx.c | 11 +++--------
> drivers/pci/host/pci-exynos.c | 11 ++---------
> drivers/pci/host/pci-imx6.c | 11 +++--------
> drivers/pci/host/pcie-designware.c | 20 ++++++++++++++++++++
> drivers/pci/host/pcie-designware.h | 2 ++
> drivers/pci/host/pcie-spear13xx.c | 12 ++----------
> 6 files changed, 32 insertions(+), 35 deletions(-)
> +int dw_pcie_check_link_is_up(struct pcie_port *pp, int max_ret, int sleep_min,
> + int sleep_max)
I think "dw_pcie_wait_for_link()" would be a more descriptive name.
I doubt that the variations between drivers in number of retries and
amount of time to wait are meaningful. I suspect most of those
numbers are made up or copied from other drivers. So we might not
need the max_ret, sleep_min, and sleep_max parameters at all.
Even if there really are important differences, I suspect the only
important thing is the total time we're prepared to wait, and we can
leave it up to dw_pcie_wait_for_link() to decide how to split that up
into sleep ranges and retries.
> +{
> + int retries;
> +
> + /* check if the link is up or not */
> + for (retries = 0; retries < max_ret; retries++) {
> + if (dw_pcie_link_up(pp)) {
> + dev_info(pp->dev, "link up\n");
> + return 0;
> + }
> + usleep_range(sleep_min, sleep_max);
> + }
> +
> + dev_err(pp->dev, "phy link never came up\n");
> +
> + return 1;
> +}
next prev parent reply other threads:[~2016-02-08 16:41 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-08 12:43 [PATCH] link up validation moved to pcie-designware Joao Pinto
2016-02-08 13:03 ` Gabriele Paoloni
2016-02-08 15:12 ` Joao Pinto
2016-02-08 15:29 ` Gabriele Paoloni
2016-02-08 15:30 ` Joao Pinto
2016-02-25 16:28 ` Bjorn Helgaas
2016-02-08 16:40 ` Arnd Bergmann
2016-02-08 16:41 ` Bjorn Helgaas [this message]
2016-02-08 16:43 ` Joao Pinto
2016-02-08 16:46 ` Arnd Bergmann
2016-02-08 16:48 ` Joao Pinto
2016-02-09 15:28 ` Arnd Bergmann
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=20160208164104.GA17268@localhost \
--to=helgaas@kernel.org \
--cc=CARLOS.PALMINHA@synopsys.com \
--cc=Joao.Pinto@synopsys.com \
--cc=arnd@arndb.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
/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;
as well as URLs for NNTP newsgroup(s).