gmane.linux.kernel.pci

Re: [PATCH 2/2] PCI: unset the resource if we can't get the correct CPU address

Kevin Hao — 2013-05-19T02:24:45

Does any x86 expert can confirm whether the assumption that "the pci host
bridge address regions should cover all the bus address we can use for the
pci device or bridge under this pci host bridge" is true or not on x86?
It seems definitely wrong in logical. But things always happen out of
expectation in reality. :-)

Thanks,
Kevin

Re: enabling aspm on ati radeon

Bjorn Helgaas — 2013-05-17T23:52:02

setpci will write whatever you tell it to; it doesn't check any
constraints like "is ASPM supported?"  But the Link Capabilities
register is read-only per spec, so likely you won't be able to change
that field, at least not by writing it directly.

You can always try using setpci to set the ASPM enable bits in the
Link Control register on both the bridge and the device.  When
enabling, I think you're supposed to do the upstream end of the link
first, then the downstream end (and the reverse for disabling).


lspci tells you that:

00:01.0 PCI bridge: Intel Corporation Xeon E3-1200/2nd Generation Core
Processor Family PCI Express Root Port
        Bus: primary=00, secondary=01, subordinate=01, sec-latency=0

The "secondary=01" means the bridge leads to bus 01, which is where
the 01:00.0 device is.

Bjorn

Re: Subject : [ PATCH ] pci-reset-error_state-to-pci_channel_io_normal-at-report_slot_reset

Rafael J. Wysocki — 2013-05-17T23:56:34

This is a dirty trick to make pci_restore_state(dev) always work here
(because it checks dev->state_saved and does nothing if it isn't set).
I suppose.


Thanks,
Rafael

Re: enabling aspm on ati radeon

Phillip Susi — 2013-05-17T23:36:53

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 05/17/2013 05:28 PM, Bjorn Helgaas wrote:> A link has two ends.
Both ends have to support ASPM in order for it

Got you... I guess I was still thinking regular PCI and the naming
"root complex" made me think it was the whole root bridge, when it
really is that particular x16 pcie port that goes to the radeon.


I'll check the Intel spec sheet again, but I'm pretty sure it really
does support ASPM.  The CPU probably allows writes to the register,
and my bios must have configured it to say it doesn't support aspm.  I
guess I just need to wrangle setpci into trying to enable it despite
it not advertising support, or maybe see if I can get grub to poke the
capability register to make it say it supports it.

One question I have though is how to identify which port device
corresponds to which downstream device connected to it.  In other
words, how do you know 00:01.0 links to 01:00.0 ( other than seeing
that it's the x16 and knowing the radeon is plugged into the x

Re: mpt2sas,mpt3sas watchdog device removal

Joe Lawrence — 2013-05-17T21:42:37

On Fri, 17 May 2013 09:29:06 -0600
Bjorn Helgaas <bhelgaas< at >google.com> wrote:


Thanks for commenting, Bjorn.  I think this approach more closely
represents what this watchdog is trying to accomplish.  

Off list, Sreekanth from LSI tested and noticed a few issues with this
patch:

 - mpt2sas_base_stop_watchdog is called twice: The call from
   mpt2sas_base_detach is safe, but now unnecessary (as a call was
   added earlier up in the PCI driver callbacks to ensure that the
   watchdog was out of the way.) This second invocation can be removed.

 - If the watchdog detects a bad IOC, the watchdog remains running:
   The watchdog workqueue isn't cleaned up until
   mpt2sas_base_stop_watchdog is called, so in the case that the
   watchdog removes the device from SCSI topo, the workqueue will
   remain unused until PCI .remove/.shutdown cleans it up. Perhaps a
   single watchdog that iterates over all adapters would be simpler?

Finally, if SCSI topo detachment is all that is interesting here, would
it make more

Re: enabling aspm on ati radeon

Phillip Susi — 2013-05-17T21:12:16

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 5/17/2013 4:24 PM, Bjorn Helgaas wrote:

That's what I was asking about before when I said surely the bridge
higher up doesn't have to have aspm enabled in order to enable it on
the downstream link?


00:01.0 says it is the root complex, so wouldn't that make it upstream
of *everything*?  As I understand it, the root complex is built into
the CPU and has 16 lanes going to the video slot, and another 4 lanes
running at gen3 speed that Intel calls the DMI that goes to the PCH,
which has some internal functions, and bridges to another 20 pcie lanes.

Since the root complex is built into the cpu, I wouldn't think ASPM
could possibly make sense on it, so it showing that it doesn't support
ASPM makes sense to me.  That doesn't seem like it should preclude
using ASPM on the link down to the video card.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJRlp0wAAoJEJrBOlT6nu7

Re: enabling aspm on ati radeon

Bjorn Helgaas — 2013-05-17T20:24:10

Don't worry about the lspci -xxx output.  I think the lspci patch
should resolve that, and it's not related to your original issue.


The driver does not need to do anything to enable ASPM.  I'm sure we
can figure out what's going on here, but I need to review some of the
patches in my queue, so I don't have time to grub around in ASPM at
the moment.

If you want to take a look yourself, I'd start by adding printks in
the pcie_aspm_init_link_state() path.  You can probably figure out
where things go wrong pretty quickly.

Oh, wait a minute...  You mentioned the radeon driver.  The Radeon
device in your system is at 01:00.0, and that is below the 00:01.0
bridge that said "ASPM unknown."  If the bridge leading to the Radeon
device doesn't support ASPM, then of course, we won't be able to turn
on ASPM for it.

That doesn't explain why we don't turn on ASPM for the *other* devices
(03:00.0, 05:00.0, 06:00.0, 09:00.0) though.

Bjorn

Re: [PATCH 4/4] ARM: tegra: pcie: Enable PCIe controller on Cardhu

Stephen Warren — 2013-05-17T19:48:36

...

Is there some reset/enable GPIO or regulator that needs to be programmed
to enable the PCIe USB3 controller? Take a look at the schematic. If you
can make it work by tweaking those GPIOs/... manually, then we can
ignore this issue and fix it up later, since it's not directly related
to the PCIe controller driver patches. It's more important to get this
Ethernet working than USB, I think.


Can you please word-wrap your email less than 80 columns? It's quite
hard to read.

I don't quite understand your question. The PCIe driver implements the
functions that access config space. I don't recall that being influenced
by anything much in the device tree, except for the 3rd entry in the
top-level PCIe controller's reg property:

        pcie-controller {
                compatible = "nvidia,tegra30-pcie";
                device_type = "pci";
                reg = <0x00003000 0x00000800   /* PADS registers */
                       0x00003800 0x00000200   /* AFI registers */
                       0x10000000 0

[PATCH] lspci: Fully decode ASPM support from Link Capabilities

Bjorn Helgaas — 2013-05-17T19:48:19

The ASPM Support field in Link Capabilities is two bits, and all four
possible encodings are defined as of PCIe spec r3.0.  Previously, lspci
only decoded values 1, 2, and 3.  This adds 0, so lspci will show "ASPM
not supported" instead of "ASPM unknown".

Signed-off-by: Bjorn Helgaas <bhelgaas< at >google.com>
---
 ls-caps.c |    2 ++
 1 file changed, 2 insertions(+)

diff --git a/ls-caps.c b/ls-caps.c
index bddb455..752a771 100644
--- a/ls-caps.c
+++ b/ls-caps.c
< at >< at > -728,6 +728,8 < at >< at > static char *aspm_support(int code)
 {
   switch (code)
     {
+      case 0:
+        return "not supported";
       case 1:
 return "L0s";
       case 2:

Re: enabling aspm on ati radeon

Phillip Susi — 2013-05-17T18:04:42

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 5/17/2013 1:31 PM, Bjorn Helgaas wrote:

I'll get that as soon as I get home, but why would the ASPM status of
the root complex have anything to do with the rest of the devices?
Enabling ASPM on one link doesn't require it to be enabled on all
upstream links does it?


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJRlnE6AAoJEJrBOlT6nu75nWUIAI7iOcoOklDWhS1FriQJmXTm
X8OJ4VZB8VVPeIuzrW+I6sppUrxqpnnxvrJT7Trnh5SDwwJjwx3m6BVrZHphrlCN
armoZ5jLSuBS9mn4mpeAOfUS7uypAuyL4fEo6DYJa9fPZycL1LukjkuwZMRJ+bfw
sjXQ7soHC52r2wxWhDHZbOl9UEWtYHhBypoI+PpYMO00lQp3gGnJXedm2zHti+a3
2ZtIieydLw++nXDr18WxDbJ5h1rQi626rVip0IcO6VUhhNxcd8hzGFkRAc7vNodw
bjW6wp8f+sddfX5uHkh9zYzwaEblLgBkxqw93xzRdh1ujJHet4R/jL1NTLZ8EZY=
=W4Uc
-----END PGP SIGNATURE-----

Re: enabling aspm on ati radeon

Bjorn Helgaas — 2013-05-17T17:31:15

Thanks.  The BIOS gave us control over ASPM via _OSC, and you have
these devices where it looks like we should be enabling ASPM, because
it's supported on both ends of the link:

    00:1c.1 bridge to [bus 03] ASPM L0s L1, ASPM disabled
      03:00.0 ASPM L0s L1, ASPM disabled
    00:1c.3 bridge to [bus 05] ASPM L0s L1, ASPM Disabled
      05:00.0 ASPM L0s L1, ASPM Disabled
    00:1c.4 bridge to [bus 06] ASPM L0s L1, ASPM Disabled
      06:00.0 ASPM L0s L1, ASPM Disabled
    00:1c.7 bridge to [bus 09] ASPM L0s L1, ASPM Disabled
      09:00.0 ASPM L0s L1, ASPM Disabled

You also have this bridge where lspci says "ASPM unknown":

    00:01.0 bridge to [bus 01] ASPM unknown

Just out of curiosity, can you collect the output of "lspci -xxxs
00:01.0"?  There are only two bits in the Link Capabilities ASPM
support field, and all four encodings are defined, so I'm curious
about why lspci says "unknown".

Bjorn

Re: [PATCH] mpt2sas,mpt3sas: make watchdog instantiated device removal safe

Bjorn Helgaas — 2013-05-17T15:29:02

[+cc linux-pci]

On Wed, May 15, 2013 at 11:26 AM, Joe Lawrence <joe.lawrence< at >stratus.com> wrote:

I think it's a mistake to use the strategy of verifying that a pci_dev
still exists.  The driver should be written so that if you have a
pci_dev pointer, you are guaranteed that the pci_dev is still valid.
The driver should clean up any asynchronous threads or pending work
items that keep a pci_dev pointer in its .remove() method, which is
before the pci_dev is deallocated.

If a driver keeps a pointer to a struct pci_dev after .remove()
returns, that's a bug.

Bjorn

Re: mpt2sas,mpt3sas watchdog device removal

Bjorn Helgaas — 2013-05-17T15:29:06

[+cc linux-pci]

On Wed, May 15, 2013 at 11:29 AM, Joe Lawrence <joe.lawrence< at >stratus.com> wrote:

I don't know the details of the SCSI detachment, but this approach
looks much cleaner to me.

Thanks for doing all this work, Joe.  I know this isn't finished, but
it looks like a great step in making these drivers simpler and more
reliable.

Bjorn

Re: [PATCH 2/2] PCI: unset the resource if we can't get the correct CPU address

Liu Jiang — 2013-05-17T14:51:20

Hi Kevin,
       I'm not sure about this assumption "the pci host bridge address 
regions should cover
all the bus address we can use for the pci device or bridge under this 
pci controller".
I have a fear that it may cause regressions to some legacy x86 
platforms, such as an AMD
platform with PCI based IOAPICs, though I have no evidences for it.
Regards!
Gerry

[PATCH -v2 7/7] PCI/IA64: introduce probe_pci_root_info() to manage _CRS resource

Yijing Wang — 2013-05-17T09:55:50

Currently, initialize _CRS resource code in IA64 make pci_acpi_scan_root()
some lengthiness. Introduce probe_pci_root_info() to manage it like in X86,

Signed-off-by: Yijing Wang <wangyijing< at >huawei.com>
---
 arch/ia64/pci/pci.c |   91 +++++++++++++++++++++++++++-----------------------
 1 files changed, 49 insertions(+), 42 deletions(-)

diff --git a/arch/ia64/pci/pci.c b/arch/ia64/pci/pci.c
index 2857a83..8076225 100644
--- a/arch/ia64/pci/pci.c
+++ b/arch/ia64/pci/pci.c
< at >< at > -365,6 +365,48 < at >< at > static void release_pci_root_info(struct pci_host_bridge *bridge)
 __release_pci_root_info(info);
 }
 
+static void
+probe_pci_root_info(struct pci_root_info *info, struct acpi_device *device,
+int busnum, int domain)
+{
+char *name;
+
+name = kmalloc(16, GFP_KERNEL);
+if (!name)
+return;
+
+sprintf(name, "PCI Bus %04x:%02x", domain, busnum);
+info->bridge = device;
+info->name = name;
+
+acpi_walk_resources(device->handle, METHOD_NAME__CRS, count_window,
+&info->res_num);
+if (info->res_num) {
+info->r

[PATCH -v2 6/7] PCI/IA64: add host bridge resource release for _CRS path

Yijing Wang — 2013-05-17T09:55:49

Set IA64 host bridge release function to make sure root bridge
related resources get freed during root bus removal.

Signed-off-by: Yijing Wang <wangyijing< at >huawei.com>
Signed-off-by: Jiang Liu <jiang.liu< at >huawei.com>
Cc: Tony Luck <tony.luck< at >intel.com>
Cc: Fenghua Yu <fenghua.yu< at >intel.com>
Cc: Yinghai Lu <yinghai< at >kernel.org>
Cc: Greg Kroah-Hartman <gregkh< at >linuxfoundation.org>
Cc: linux-ia64< at >vger.kernel.org
---
 arch/ia64/pci/pci.c |   11 ++++++++++-
 1 files changed, 10 insertions(+), 1 deletions(-)

diff --git a/arch/ia64/pci/pci.c b/arch/ia64/pci/pci.c
index 658030f..2857a83 100644
--- a/arch/ia64/pci/pci.c
+++ b/arch/ia64/pci/pci.c
< at >< at > -358,6 +358,13 < at >< at > static void __release_pci_root_info(struct pci_root_info *info)
 kfree(info);
 }
 
+static void release_pci_root_info(struct pci_host_bridge *bridge)
+{
+struct pci_root_info *info = bridge->release_data;
+
+__release_pci_root_info(info);
+}
+
 struct pci_bus *pci_acpi_scan_root(struct acpi_pci_root *root)
 {
 struct acpi_device *device = root->device;
< at >

[PATCH -v2 2/7] PCI/IA64: SN: remove sn_pci_window_fixup()

Yijing Wang — 2013-05-17T09:55:45

Currently, pcibios_bus_to_resource() and pcibios_resource_to_bus()
functions use pci_host_bridge_window in pci_host_bridge to translate
bus side to/from cpu side addresses. Pci_window in pci_controller
under IA64 is no used again, so remove this function.

Signed-off-by: Yijing Wang <wangyijing< at >huawei.com>
Cc: Tony Luck <tony.luck< at >intel.com>
Cc: Fenghua Yu <fenghua.yu< at >intel.com>
Cc: linux-ia64< at >vger.kernel.org
---
 arch/ia64/sn/kernel/io_init.c |   49 +----------------------------------------
 1 files changed, 1 insertions(+), 48 deletions(-)

diff --git a/arch/ia64/sn/kernel/io_init.c b/arch/ia64/sn/kernel/io_init.c
index 238e2c5..99710f5 100644
--- a/arch/ia64/sn/kernel/io_init.c
+++ b/arch/ia64/sn/kernel/io_init.c
< at >< at > -149,48 +149,6 < at >< at > sn_legacy_pci_window_fixup(struct pci_controller *controller,
 }
 
 /*
- * sn_pci_window_fixup() - Create a pci_window for each device resource.
- *   It will setup pci_windows for use by
- *   pcibios_bus_to_resource(), pcibios_resource_to_bus(),
- *   etc.
- */
-st

[PATCH -v2 1/7] PCI/X86: fix always use info->res[0] to store _CRS resource when pci=nocrs set

Yijing Wang — 2013-05-17T09:55:44

We should increase info->res_num before checking pci_use_crs return, otherwise
only the res[0] of pci_root_info will be used during setup_resource() when
pci=nocrs set. And the old resource value will be overwritten by new resource item.

Signed-off-by: Yijing Wang <wangyijing< at >huawei.com>
Cc: Yinghai Lu <yinghai< at >kernel.org>
Cc: Jiang Liu <liuj97< at >gmail.com>
Cc: "Rafael J. Wysocki" <rafael.j.wysocki< at >intel.com>
Cc: Feng Tang <feng.tang< at >intel.com>
---
 arch/x86/pci/acpi.c |    7 ++-----
 1 files changed, 2 insertions(+), 5 deletions(-)

diff --git a/arch/x86/pci/acpi.c b/arch/x86/pci/acpi.c
index 3e72425..662dfdf 100644
--- a/arch/x86/pci/acpi.c
+++ b/arch/x86/pci/acpi.c
< at >< at > -324,14 +324,11 < at >< at > setup_resource(struct acpi_resource *acpi_res, void *data)
 res->start = start;
 res->end = end;
 info->res_offset[info->res_num] = addr.translation_offset;
+info->res_num++;
 
-if (!pci_use_crs) {
+if (!pci_use_crs)
 dev_printk(KERN_DEBUG, &info->bridge->dev,
    "host bridge window %pR (ignored)\n", res);
-re

[PATCH -v2 0/7] Add hostbridge resource release to support root bus hotplug in IA64

Yijing Wang — 2013-05-17T09:55:43

v1->v2: update the patchset description in this cover letter.

Hi Bjorn,
   I update this patchset description, and add some MMIO and dmesg info in order to describe
this problem more clearly. I hope it can make you review this patch easier.

Before applied this patchset, there is a problem when we do root bus hotplug in IA64. Because
we do not release MMIO and ioport resource occupied by root bus.

1. Before hot remove pci root bus

-+-[0000:40]-+-00.0-[0000:41]--
 |           +-01.0-[0000:42]--+-00.0  Intel Corporation 82576 Gigabit Network Connection
 |           |                 \-00.1  Intel Corporation 82576 Gigabit Network Connection
 |           +-03.0-[0000:43]----00.0  LSI Logic / Symbios Logic SAS1064ET PCI-Express Fusion-MPT SAS
 |           +-04.0-[0000:44]--
 |           +-05.0-[0000:45]--
 |           +-07.0-[0000:46]--+-00.0  Intel Corporation 82576 Gigabit Network Connection
 |           |                 \-00.1  Intel Corporation 82576 Gigabit Network Connection
 |           +-0d.0  Intel

Re: [PATCHv9 5/9] clk: mvebu: create parent-child relation for PCIe clocks on Armada 370

Mike Turquette — 2013-05-17T07:08:26

Quoting Jason Cooper (2013-05-16 08:06:16)

Yeah that all sounds good to me.  I'll review the restructure patches
shortly.

Regards,
Mike

Re: is L1 really disabled in iwlwifi

Emmanuel Grumbach — 2013-05-17T05:49:01

Good for me - now I would be notified that something wrong happened.