All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marek Vasut <marex@denx.de>
To: Tim Harvey <tharvey@gateworks.com>
Cc: "linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	Bjorn Helgaas <bhelgaas@google.com>, Frank Li <lznuaa@gmail.com>,
	Jingoo Han <jg1.han@samsung.com>,
	Mohit KUMAR <Mohit.KUMAR@st.com>,
	Pratyush Anand <pratyush.anand@st.com>,
	Richard Zhu <r65037@freescale.com>,
	Sascha Hauer <s.hauer@pengutronix.de>,
	Sean Cross <xobs@kosagi.com>, Shawn Guo <shawn.guo@linaro.org>,
	Siva Reddy Kallam <siva.kallam@samsung.com>,
	Srikanth T Shivanand <ts.srikanth@samsung.com>,
	Troy Kisky <troy.kisky@boundarydevices.com>,
	Yinghai Lu <yinghai@kernel.org>
Subject: Re: [PATCH 6/6] PCI: designware: Fix DT resource retrieval
Date: Wed, 16 Oct 2013 16:05:12 +0200	[thread overview]
Message-ID: <201310161605.12500.marex@denx.de> (raw)
In-Reply-To: <CAJ+vNU0e1LDFuqt_PCaycrrrD=dYRPU6fKEQZxkskO4hcJFcRw@mail.gmail.com>

Hi Tim,

> On Tue, Oct 15, 2013 at 9:06 AM, Marek Vasut <marex@denx.de> wrote:
> > The resource retrieval from the DT was not done right. This resulted
> > in bogus values in the IO/MEM window configuration. I re-used the code
> > implementation from pci-tegra.c to do the resource retrieval correctly.
> > 
> > This in turn resulted in very strange behavior on two different kinds
> > of setup:
> > 
> > Setup #1:                             ,-------> Intel i210 (igb driver)
> > 
> >            i.MX6 root port -----> PCIe switch
> >            
> >                                       `-------> Empty slot
> > 
> > Setup #2:                             ,-------> Marvell Yukon (sky2
> > driver)
> > 
> >            i.MX6 root port -----> PCIe switch
> >            
> >                                       `-------> Empty slot
> > 
> > Both setups expressed the same behavior. The system booted and the
> > ethernet controllers were properly detected. After the controllers
> > were configured and just after they reported "Ethernet Link Up", the
> > entire system froze. It is now clear this happened because the resources
> > were incorrectly configured, which in turn means the iATU was also not
> > configured correctly.
> > 
> > Signed-off-by: Marek Vasut <marex@denx.de>
> > Cc: Bjorn Helgaas <bhelgaas@google.com>
> > Cc: Frank Li <lznuaa@gmail.com>
> > Cc: Jingoo Han <jg1.han@samsung.com>
> > Cc: Mohit KUMAR <Mohit.KUMAR@st.com>
> > Cc: Pratyush Anand <pratyush.anand@st.com>
> > Cc: Richard Zhu <r65037@freescale.com>
> > Cc: Sascha Hauer <s.hauer@pengutronix.de>
> > Cc: Sean Cross <xobs@kosagi.com>
> > Cc: Shawn Guo <shawn.guo@linaro.org>
> > Cc: Siva Reddy Kallam <siva.kallam@samsung.com>
> > Cc: Srikanth T Shivanand <ts.srikanth@samsung.com>
> > Cc: Tim Harvey <tharvey@gateworks.com>
> > Cc: Troy Kisky <troy.kisky@boundarydevices.com>
> > Cc: Yinghai Lu <yinghai@kernel.org>
> > ---
> > 
> >  drivers/pci/host/pcie-designware.c | 17 ++++++-----------
> >  1 file changed, 6 insertions(+), 11 deletions(-)
> > 
> > diff --git a/drivers/pci/host/pcie-designware.c
> > b/drivers/pci/host/pcie-designware.c index 5d183ae..97c5951 100644
> > --- a/drivers/pci/host/pcie-designware.c
> > +++ b/drivers/pci/host/pcie-designware.c
> > @@ -370,6 +370,7 @@ int __init dw_pcie_host_init(struct pcie_port *pp)
> > 
> >         struct device_node *np = pp->dev->of_node;
> >         struct of_pci_range range;
> >         struct of_pci_range_parser parser;
> > 
> > +       struct resource res;
> > 
> >         u32 val;
> >         
> >         struct irq_domain *irq_domain;
> > 
> > @@ -381,28 +382,22 @@ int __init dw_pcie_host_init(struct pcie_port *pp)
> > 
> >         /* Get the I/O and memory ranges from DT */
> >         for_each_of_pci_range(&parser, &range) {
> > 
> > -               unsigned long restype = range.flags &
> > IORESOURCE_TYPE_BITS; +               of_pci_range_to_resource(&range,
> > np, &res);
> > +               unsigned long restype = res.flags & IORESOURCE_TYPE_BITS;
> > 
> >                 if (restype == IORESOURCE_IO) {
> > 
> > -                       of_pci_range_to_resource(&range, np, &pp->io);
> > +                       memcpy(&pp->io, &res, sizeof(res));
> > 
> >                         pp->io.name = "I/O";
> > 
> > -                       pp->io.start = max_t(resource_size_t,
> > -                                            PCIBIOS_MIN_IO,
> > -                                            range.pci_addr +
> > global_io_offset); -                       pp->io.end =
> > min_t(resource_size_t,
> > -                                          IO_SPACE_LIMIT,
> > -                                          range.pci_addr + range.size
> > -                                          + global_io_offset);
> 
> Nak - removing the adjustment to io.start/io.end breaks the io space
> mapping as the entire io-space allocation gets taken by the root
> complex.  This causes any device that requests io space to fail to
> obtain it (your igb driver from Setup1 apparently doesn't use io space
> where my sky2 device from Setup2 above does).

OK. I still think this kind of restype comparison is bogus. The range.flags and 
IORESOURCE_.* do not match bit-wise. Do we agree on this part? I also agree -- 
as disussed with you -- that there might be bugs in the DT bindings. I will 
repost the V2s later tonight.

--->8---
unsigned long restype = range.flags & IORESOURCE_TYPE_BITS;
[...]
if (restype == IORESOURCE_MEM) {
---8<---

> If I put back the adjustment to io.start/io.end above my sky2 device
> gets its io resource properly but still hangs the bus after a few
> interrupts.  Are you sure you don't have other changes that you
> haven't posted yet that could have addressed the hang you get when you
> bring up your igb device?

I'm absolutely positive. I double-checked this now. One more patch I have is 
this IRQ fixup, but that's all.

    pcie: correct the irq map when pcie switch is used

> I agree that the the 'hang' we are seeing is a bus-hang caused by an
> improper iATU mapping, however I'm not convinced its a dts parsing
> issue.
> 
> Tim


> > 
> > -                       of_pci_range_to_resource(&range, np, &pp->mem);
> > +                       memcpy(&pp->mem, &res, sizeof(res));
> > 
> >                         pp->mem.name = "MEM";
> >                         pp->config.mem_size = resource_size(&pp->mem);
> >                         pp->config.mem_bus_addr = range.pci_addr;
> >                 
> >                 }
> >                 if (restype == 0) {
> > 
> > -                       of_pci_range_to_resource(&range, np, &pp->cfg);
> > +                       memcpy(&pp->cfg, &res, sizeof(res));
> > 
> >                         pp->config.cfg0_size = resource_size(&pp->cfg)/2;
> >                         pp->config.cfg1_size = resource_size(&pp->cfg)/2;
> >                 
> >                 }
> > 
> > --
> > 1.8.4.rc3

WARNING: multiple messages have this Message-ID (diff)
From: marex@denx.de (Marek Vasut)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 6/6] PCI: designware: Fix DT resource retrieval
Date: Wed, 16 Oct 2013 16:05:12 +0200	[thread overview]
Message-ID: <201310161605.12500.marex@denx.de> (raw)
In-Reply-To: <CAJ+vNU0e1LDFuqt_PCaycrrrD=dYRPU6fKEQZxkskO4hcJFcRw@mail.gmail.com>

Hi Tim,

> On Tue, Oct 15, 2013 at 9:06 AM, Marek Vasut <marex@denx.de> wrote:
> > The resource retrieval from the DT was not done right. This resulted
> > in bogus values in the IO/MEM window configuration. I re-used the code
> > implementation from pci-tegra.c to do the resource retrieval correctly.
> > 
> > This in turn resulted in very strange behavior on two different kinds
> > of setup:
> > 
> > Setup #1:                             ,-------> Intel i210 (igb driver)
> > 
> >            i.MX6 root port -----> PCIe switch
> >            
> >                                       `-------> Empty slot
> > 
> > Setup #2:                             ,-------> Marvell Yukon (sky2
> > driver)
> > 
> >            i.MX6 root port -----> PCIe switch
> >            
> >                                       `-------> Empty slot
> > 
> > Both setups expressed the same behavior. The system booted and the
> > ethernet controllers were properly detected. After the controllers
> > were configured and just after they reported "Ethernet Link Up", the
> > entire system froze. It is now clear this happened because the resources
> > were incorrectly configured, which in turn means the iATU was also not
> > configured correctly.
> > 
> > Signed-off-by: Marek Vasut <marex@denx.de>
> > Cc: Bjorn Helgaas <bhelgaas@google.com>
> > Cc: Frank Li <lznuaa@gmail.com>
> > Cc: Jingoo Han <jg1.han@samsung.com>
> > Cc: Mohit KUMAR <Mohit.KUMAR@st.com>
> > Cc: Pratyush Anand <pratyush.anand@st.com>
> > Cc: Richard Zhu <r65037@freescale.com>
> > Cc: Sascha Hauer <s.hauer@pengutronix.de>
> > Cc: Sean Cross <xobs@kosagi.com>
> > Cc: Shawn Guo <shawn.guo@linaro.org>
> > Cc: Siva Reddy Kallam <siva.kallam@samsung.com>
> > Cc: Srikanth T Shivanand <ts.srikanth@samsung.com>
> > Cc: Tim Harvey <tharvey@gateworks.com>
> > Cc: Troy Kisky <troy.kisky@boundarydevices.com>
> > Cc: Yinghai Lu <yinghai@kernel.org>
> > ---
> > 
> >  drivers/pci/host/pcie-designware.c | 17 ++++++-----------
> >  1 file changed, 6 insertions(+), 11 deletions(-)
> > 
> > diff --git a/drivers/pci/host/pcie-designware.c
> > b/drivers/pci/host/pcie-designware.c index 5d183ae..97c5951 100644
> > --- a/drivers/pci/host/pcie-designware.c
> > +++ b/drivers/pci/host/pcie-designware.c
> > @@ -370,6 +370,7 @@ int __init dw_pcie_host_init(struct pcie_port *pp)
> > 
> >         struct device_node *np = pp->dev->of_node;
> >         struct of_pci_range range;
> >         struct of_pci_range_parser parser;
> > 
> > +       struct resource res;
> > 
> >         u32 val;
> >         
> >         struct irq_domain *irq_domain;
> > 
> > @@ -381,28 +382,22 @@ int __init dw_pcie_host_init(struct pcie_port *pp)
> > 
> >         /* Get the I/O and memory ranges from DT */
> >         for_each_of_pci_range(&parser, &range) {
> > 
> > -               unsigned long restype = range.flags &
> > IORESOURCE_TYPE_BITS; +               of_pci_range_to_resource(&range,
> > np, &res);
> > +               unsigned long restype = res.flags & IORESOURCE_TYPE_BITS;
> > 
> >                 if (restype == IORESOURCE_IO) {
> > 
> > -                       of_pci_range_to_resource(&range, np, &pp->io);
> > +                       memcpy(&pp->io, &res, sizeof(res));
> > 
> >                         pp->io.name = "I/O";
> > 
> > -                       pp->io.start = max_t(resource_size_t,
> > -                                            PCIBIOS_MIN_IO,
> > -                                            range.pci_addr +
> > global_io_offset); -                       pp->io.end =
> > min_t(resource_size_t,
> > -                                          IO_SPACE_LIMIT,
> > -                                          range.pci_addr + range.size
> > -                                          + global_io_offset);
> 
> Nak - removing the adjustment to io.start/io.end breaks the io space
> mapping as the entire io-space allocation gets taken by the root
> complex.  This causes any device that requests io space to fail to
> obtain it (your igb driver from Setup1 apparently doesn't use io space
> where my sky2 device from Setup2 above does).

OK. I still think this kind of restype comparison is bogus. The range.flags and 
IORESOURCE_.* do not match bit-wise. Do we agree on this part? I also agree -- 
as disussed with you -- that there might be bugs in the DT bindings. I will 
repost the V2s later tonight.

--->8---
unsigned long restype = range.flags & IORESOURCE_TYPE_BITS;
[...]
if (restype == IORESOURCE_MEM) {
---8<---

> If I put back the adjustment to io.start/io.end above my sky2 device
> gets its io resource properly but still hangs the bus after a few
> interrupts.  Are you sure you don't have other changes that you
> haven't posted yet that could have addressed the hang you get when you
> bring up your igb device?

I'm absolutely positive. I double-checked this now. One more patch I have is 
this IRQ fixup, but that's all.

    pcie: correct the irq map when pcie switch is used

> I agree that the the 'hang' we are seeing is a bus-hang caused by an
> improper iATU mapping, however I'm not convinced its a dts parsing
> issue.
> 
> Tim


> > 
> > -                       of_pci_range_to_resource(&range, np, &pp->mem);
> > +                       memcpy(&pp->mem, &res, sizeof(res));
> > 
> >                         pp->mem.name = "MEM";
> >                         pp->config.mem_size = resource_size(&pp->mem);
> >                         pp->config.mem_bus_addr = range.pci_addr;
> >                 
> >                 }
> >                 if (restype == 0) {
> > 
> > -                       of_pci_range_to_resource(&range, np, &pp->cfg);
> > +                       memcpy(&pp->cfg, &res, sizeof(res));
> > 
> >                         pp->config.cfg0_size = resource_size(&pp->cfg)/2;
> >                         pp->config.cfg1_size = resource_size(&pp->cfg)/2;
> >                 
> >                 }
> > 
> > --
> > 1.8.4.rc3

  parent reply	other threads:[~2013-10-16 14:05 UTC|newest]

Thread overview: 62+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-15 16:06 [PATCH 0/6] PCI: imx6: Random fixes Marek Vasut
2013-10-15 16:06 ` Marek Vasut
2013-10-15 16:06 ` [PATCH 1/6] PCI: imx6: Make reset-gpio optional Marek Vasut
2013-10-15 16:06   ` Marek Vasut
2013-10-16  1:24   ` Jingoo Han
2013-10-16  1:24     ` Jingoo Han
2013-10-15 16:06 ` [PATCH 2/6] PCI: imx6: Fix the clock for PCIe Marek Vasut
2013-10-15 16:06   ` Marek Vasut
2013-10-15 16:06 ` [PATCH 3/6] ARM: dts: imx6qdl: " Marek Vasut
2013-10-15 16:06   ` Marek Vasut
2013-10-15 16:06 ` [PATCH 4/6] PCI: imx6: Probe the PCIe in fs_initcall() Marek Vasut
2013-10-15 16:06   ` Marek Vasut
2013-10-17 23:31   ` Tim Harvey
2013-10-17 23:31     ` Tim Harvey
2013-10-15 16:06 ` [PATCH 5/6] PCI: imx6: Force Gen1 operation Marek Vasut
2013-10-15 16:06   ` Marek Vasut
2013-10-16  5:54   ` Pratyush Anand
2013-10-16  5:54     ` Pratyush Anand
2013-10-16 13:57     ` Marek Vasut
2013-10-16 13:57       ` Marek Vasut
2013-10-17  7:02       ` Zhu Richard-R65037
2013-10-17  7:02         ` Zhu Richard-R65037
2013-10-17 17:34         ` Marek Vasut
2013-10-17 17:34           ` Marek Vasut
2013-10-18  2:12           ` Zhu Richard-R65037
2013-10-18  2:12             ` Zhu Richard-R65037
2013-10-19  5:07             ` Marek Vasut
2013-10-19  5:07               ` Marek Vasut
2013-10-21  6:33               ` Zhu Richard-R65037
2013-10-21  6:33                 ` Zhu Richard-R65037
2013-10-18  5:04   ` Tim Harvey
2013-10-18  5:04     ` Tim Harvey
2013-10-15 16:06 ` [PATCH 6/6] PCI: designware: Fix DT resource retrieval Marek Vasut
2013-10-15 16:06   ` Marek Vasut
2013-10-16  0:15   ` Tim Harvey
2013-10-16  0:15     ` Tim Harvey
2013-10-16  3:56     ` Jingoo Han
2013-10-16  3:56       ` Jingoo Han
2013-10-16 14:05     ` Marek Vasut [this message]
2013-10-16 14:05       ` Marek Vasut
2013-10-15 16:34 ` [PATCH 0/6] PCI: imx6: Random fixes Marek Vasut
2013-10-15 16:34   ` Marek Vasut
2013-10-16  0:03 ` Jingoo Han
2013-10-16  0:03   ` Jingoo Han
2013-10-16  0:08   ` Marek Vasut
2013-10-16  0:08     ` Marek Vasut
2013-10-29 19:14 ` Bjorn Helgaas
2013-10-29 19:14   ` Bjorn Helgaas
2013-10-30 14:52   ` Marek Vasut
2013-10-30 14:52     ` Marek Vasut
2013-10-30 16:25     ` Bjorn Helgaas
2013-10-30 16:25       ` Bjorn Helgaas
2013-10-31  1:26       ` Shawn Guo
2013-10-31  1:26         ` Shawn Guo
2013-10-31  1:38         ` Jingoo Han
2013-10-31  1:38           ` Jingoo Han
2013-10-31 17:36     ` Bjorn Helgaas
2013-10-31 17:36       ` Bjorn Helgaas
2013-11-11 13:32 ` Jürgen Beisert
2013-11-11 13:32   ` Jürgen Beisert
2013-11-11 13:48   ` Marek Vasut
2013-11-11 13:48     ` Marek Vasut

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=201310161605.12500.marex@denx.de \
    --to=marex@denx.de \
    --cc=Mohit.KUMAR@st.com \
    --cc=bhelgaas@google.com \
    --cc=jg1.han@samsung.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=lznuaa@gmail.com \
    --cc=pratyush.anand@st.com \
    --cc=r65037@freescale.com \
    --cc=s.hauer@pengutronix.de \
    --cc=shawn.guo@linaro.org \
    --cc=siva.kallam@samsung.com \
    --cc=tharvey@gateworks.com \
    --cc=troy.kisky@boundarydevices.com \
    --cc=ts.srikanth@samsung.com \
    --cc=xobs@kosagi.com \
    --cc=yinghai@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 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.