From: Jisheng Zhang <jszhang@marvell.com>
To: Joao Pinto <Joao.Pinto@synopsys.com>
Cc: <jingoohan1@gmail.com>, <pratyush.anand@gmail.com>,
<bhelgaas@google.com>, <linux-pci@vger.kernel.org>,
<linux-kernel@vger.kernel.org>,
<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH 2/2] PCI: designware: let dw_pcie_link_up() beware of LTSSM training bit
Date: Mon, 18 Jul 2016 10:38:51 +0800 [thread overview]
Message-ID: <20160718103851.7cd3984a@xhacker> (raw)
In-Reply-To: <2e9d2b8c-f4c3-aa6d-38be-314213db7727@synopsys.com>
Dear Joao,
On Fri, 15 Jul 2016 16:10:24 +0100 Joao Pinto wrote:
> Hi,
>
> On 7/6/2016 11:59 AM, Jisheng Zhang wrote:
> > The link may be UP but still in link training. In this case, we can't
> > think the link is up and operating correctly. So we need to teach
> > dw_pcie_link_up() beware of the PCIE_PHY_DEBUG_R1_LINK_IN_TRAINING bit.
> >
> > This patch also rewrite PCIE_PHY_DEBUG_R1_LINK_UP definition so that
> > it's consistent with other MACROS.
> >
> > Signed-off-by: Jisheng Zhang <jszhang@marvell.com>
> > ---
> > drivers/pci/host/pcie-designware.c | 6 ++++--
> > 1 file changed, 4 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/pci/host/pcie-designware.c b/drivers/pci/host/pcie-designware.c
> > index 9df879a..29e10dd 100644
> > --- a/drivers/pci/host/pcie-designware.c
> > +++ b/drivers/pci/host/pcie-designware.c
> > @@ -73,7 +73,8 @@
> > /* PCIe Port Logic registers */
> > #define PLR_OFFSET 0x700
> > #define PCIE_PHY_DEBUG_R1 (PLR_OFFSET + 0x2c)
> > -#define PCIE_PHY_DEBUG_R1_LINK_UP 0x00000010
> > +#define PCIE_PHY_DEBUG_R1_LINK_UP (0x1 << 4)
> > +#define PCIE_PHY_DEBUG_R1_LINK_IN_TRAINING (0x1 << 29)
>
> According to the databook bit 29 is inside a range that is dedicated to M-PCIe.
> Have you checked bit 29 state by experience?
bit 29 here is bit 61 of cxpl_debug_info(64bit) in databook, the debug info is
composited by debug 0 and debug 1 registers.
I checked databook 4.3 and 4.21, bit 29 (bit 61 in databook) isn't dedicated to
M-PCIe. I think you may misread the bit 29 here as the bit29 in databook?
Databook indeed mentioned that bit[31:28] is reserved for M-PCIe
And after more code checking, I think this is not only marvell have this
case(link is up but still in link training), but pci-imx6.c also has this
case, we could check imx6_pcie_link_up() for reference.
Thanks,
Jisheng
>
> >
> > /* Parameters for the waiting for link up routine */
> > #define LINK_WAIT_MAX_RETRIES 10
> > @@ -417,7 +418,8 @@ int dw_pcie_link_up(struct pcie_port *pp)
> > return pp->ops->link_up(pp);
> >
> > val = readl(pp->dbi_base + PCIE_PHY_DEBUG_R1);
> > - return val & PCIE_PHY_DEBUG_R1_LINK_UP;
> > + return ((val & PCIE_PHY_DEBUG_R1_LINK_UP) &&
> > + (!(val & PCIE_PHY_DEBUG_R1_LINK_IN_TRAINING)));
> > }
> >
> > static int dw_pcie_msi_map(struct irq_domain *domain, unsigned int irq,
> >
>
> Thanks,
> Joao
WARNING: multiple messages have this Message-ID (diff)
From: jszhang@marvell.com (Jisheng Zhang)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 2/2] PCI: designware: let dw_pcie_link_up() beware of LTSSM training bit
Date: Mon, 18 Jul 2016 10:38:51 +0800 [thread overview]
Message-ID: <20160718103851.7cd3984a@xhacker> (raw)
In-Reply-To: <2e9d2b8c-f4c3-aa6d-38be-314213db7727@synopsys.com>
Dear Joao,
On Fri, 15 Jul 2016 16:10:24 +0100 Joao Pinto wrote:
> Hi,
>
> On 7/6/2016 11:59 AM, Jisheng Zhang wrote:
> > The link may be UP but still in link training. In this case, we can't
> > think the link is up and operating correctly. So we need to teach
> > dw_pcie_link_up() beware of the PCIE_PHY_DEBUG_R1_LINK_IN_TRAINING bit.
> >
> > This patch also rewrite PCIE_PHY_DEBUG_R1_LINK_UP definition so that
> > it's consistent with other MACROS.
> >
> > Signed-off-by: Jisheng Zhang <jszhang@marvell.com>
> > ---
> > drivers/pci/host/pcie-designware.c | 6 ++++--
> > 1 file changed, 4 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/pci/host/pcie-designware.c b/drivers/pci/host/pcie-designware.c
> > index 9df879a..29e10dd 100644
> > --- a/drivers/pci/host/pcie-designware.c
> > +++ b/drivers/pci/host/pcie-designware.c
> > @@ -73,7 +73,8 @@
> > /* PCIe Port Logic registers */
> > #define PLR_OFFSET 0x700
> > #define PCIE_PHY_DEBUG_R1 (PLR_OFFSET + 0x2c)
> > -#define PCIE_PHY_DEBUG_R1_LINK_UP 0x00000010
> > +#define PCIE_PHY_DEBUG_R1_LINK_UP (0x1 << 4)
> > +#define PCIE_PHY_DEBUG_R1_LINK_IN_TRAINING (0x1 << 29)
>
> According to the databook bit 29 is inside a range that is dedicated to M-PCIe.
> Have you checked bit 29 state by experience?
bit 29 here is bit 61 of cxpl_debug_info(64bit) in databook, the debug info is
composited by debug 0 and debug 1 registers.
I checked databook 4.3 and 4.21, bit 29 (bit 61 in databook) isn't dedicated to
M-PCIe. I think you may misread the bit 29 here as the bit29 in databook?
Databook indeed mentioned that bit[31:28] is reserved for M-PCIe
And after more code checking, I think this is not only marvell have this
case(link is up but still in link training), but pci-imx6.c also has this
case, we could check imx6_pcie_link_up() for reference.
Thanks,
Jisheng
>
> >
> > /* Parameters for the waiting for link up routine */
> > #define LINK_WAIT_MAX_RETRIES 10
> > @@ -417,7 +418,8 @@ int dw_pcie_link_up(struct pcie_port *pp)
> > return pp->ops->link_up(pp);
> >
> > val = readl(pp->dbi_base + PCIE_PHY_DEBUG_R1);
> > - return val & PCIE_PHY_DEBUG_R1_LINK_UP;
> > + return ((val & PCIE_PHY_DEBUG_R1_LINK_UP) &&
> > + (!(val & PCIE_PHY_DEBUG_R1_LINK_IN_TRAINING)));
> > }
> >
> > static int dw_pcie_msi_map(struct irq_domain *domain, unsigned int irq,
> >
>
> Thanks,
> Joao
next prev parent reply other threads:[~2016-07-18 2:43 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-06 10:59 [PATCH 0/2] PCI: designware: let dw_pcie_link_up() beware of LTSSM training bit Jisheng Zhang
2016-07-06 10:59 ` Jisheng Zhang
2016-07-06 10:59 ` [PATCH 1/2] PCI: designware: mv parameters for wait for link into pcie-designware.c Jisheng Zhang
2016-07-06 10:59 ` Jisheng Zhang
2016-07-06 10:59 ` [PATCH 2/2] PCI: designware: let dw_pcie_link_up() beware of LTSSM training bit Jisheng Zhang
2016-07-06 10:59 ` Jisheng Zhang
2016-07-15 15:10 ` Joao Pinto
2016-07-15 15:10 ` Joao Pinto
2016-07-18 2:38 ` Jisheng Zhang [this message]
2016-07-18 2:38 ` Jisheng Zhang
2016-07-21 10:11 ` Joao Pinto
2016-07-21 10:11 ` Joao Pinto
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=20160718103851.7cd3984a@xhacker \
--to=jszhang@marvell.com \
--cc=Joao.Pinto@synopsys.com \
--cc=bhelgaas@google.com \
--cc=jingoohan1@gmail.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=pratyush.anand@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.