Linux PCI subsystem discussion ()

Bjorn Helgaas | 17 May 2013 21:48

Picon

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

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:

Bjorn Helgaas | 17 May 2013 19:31

Picon

Re: enabling aspm on ati radeon

On Thu, May 16, 2013 at 4:10 PM, Phillip Susi <psusi <at> ubuntu.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 05/16/2013 12:42 PM, Bjorn Helgaas wrote:
>> Can you collect a complete dmesg log and complete "lspci -vv" output, please?
> ...

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".

(Continue reading)

Yijing Wang | 17 May 2013 11:55

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

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 Corporation Device 343a
 |           +-0d.1  Intel Corporation Device 343b
 |           +-0d.7  Intel Corporation Device 341b
 [....snip.....]
 |           +-16.3  Intel Corporation 5520/5500/X58 Chipset QuickData Technology Device
 |           \-16.7  Intel Corporation 5520/5500/X58 Chipset QuickData Technology Device
 \-[0000:00]-+-00.0  Intel Corporation 5520/5500/X58 I/O Hub to ESI Port
             +-01.0-[0000:01]--+-00.0  Intel Corporation 82576 Gigabit Network Connection
             |                 \-00.1  Intel Corporation 82576 Gigabit Network Connection
             +-03.0-[0000:02]----00.0  LSI Logic / Symbios Logic SAS1064ET PCI-Express Fusion-MPT SAS
             +-04.0-[0000:03]--

(Continue reading)

Thomas Petazzoni | 16 May 2013 17:55

[PATCHv10 0/9] PCIe support for the Armada 370 and Armada XP SoCs

Hello,

This series of patches introduces PCIe support for the Marvell Armada
370 and Armada XP.

I'd like this code to be merged for 3.11.

For easier testing, the code has been pushed to:

  git://github.com/MISL-EBU-System-SW/mainline-public.git marvell-pcie-v10

This PATCHv10 follows:
 * PATCHv9, sent on May, 16th 2013
 * PATCHv8, sent on April, 9th 2013
 * PATCHv7, sent on March, 27th 2013
 * PATCHv6, sent on March, 26st 2013
 * PATCHv5, sent on March, 21st 2013
 * PATCHv4, sent on March, 8th 2013
 * PATCHv3, sent on February, 12th 2013
 * PATCHv2, sent on January, 28th 2013
 * RFCv1, sent on December, 7th 2012

Changes between v9 and v10:

 * Mark mvebu_pcie_init() as __init, as reported by Ezequiel
   Garcia. platform_driver_probe() is __init_or_module, so when
   !CONFIG_MODULES is used, platform_driver_probe() belongs to the
   __init section.

 * Mark two other small functions as __init, just because they are

(Continue reading)

Jiang Liu | 16 May 2013 17:50

Picon

[RFC PATCH v2, part3 00/11] Introduce PCI bus lock and state machine

Hi all,
	About one year ago, I started to solve issues triggered by concurrent
PCI device hotplug operations, and several different solutions have been
sent to community for comments. Now we have made important changes to the
solution, so start again with a "v1".

This is the second take to resolve race conditions when hot-plugging PCI
devices/host bridges. Instead of using a globla lock to serialize all hotplug
operations as in previous version, now we introduce a state machine and lock
mechanism for PCI buses to serialize hotplug operations. For discussions
related to previous version, please refer to:
http://comments.gmane.org/gmane.linux.kernel.pci/15007

This patch-set is still in early stages, so sending it out just requesting
for comments. Any comments are welcomed, especially about whether it's the
right/suitable way to solve these race condition issues.

There are multiple methods to trigger PCI hotplug requests/operations
concurrently, such as:
1. Sysfs interfaces exported by the PCI core subsystem
	/sys/devices/pcissss:bb/ssss:bb:dd.f/.../remove
	/sys/devices/pcissss:bb/ssss:bb:dd.f/.../rescan
	/sys/devices/pcissss:bb/ssss:bb:dd.f/.../pci_bus/ssss:bb/rescan
	/sys/bus/pci/rescan
2. Sysfs interfaces exported by the PCI hotplug subsystem
	/sys/bus/pci/slots/xx/power
3. PCI hotplug events triggered by PCI Hotplug Controllers
4. ACPI hotplug events for PCI host bridges
5. Driver binding/unbinding events
	binding/unbinding pci drivers with SR-IOV support

(Continue reading)

Thomas Petazzoni | 15 May 2013 15:25

[PATCHv9 0/9] PCIe support for the Armada 370 and Armada XP SoCs

Hello,

This series of patches introduces PCIe support for the Marvell Armada
370 and Armada XP. It has been rebased on top of 3.10-rc1, uses the
latest of/pci code from Andrew Murray, fixes the build failure that
was detected on powerpc64, and a regression that was introduced
between the v7 and the v8 of this patch set. See below for a detailed
changelog.

I'd like this code to be merged for 3.11.

For easier testing, the code has been pushed to:

  git://github.com/MISL-EBU-System-SW/mainline-public.git marvell-pcie-v9

This PATCHv9 follows:
 * PATCHv8, sent on April, 9th 2013
 * PATCHv7, sent on March, 27th 2013
 * PATCHv6, sent on March, 26st 2013
 * PATCHv5, sent on March, 21st 2013
 * PATCHv4, sent on March, 8th 2013
 * PATCHv3, sent on February, 12th 2013
 * PATCHv2, sent on January, 28th 2013
 * RFCv1, sent on December, 7th 2012

Changes between v8 and v9:

 * Rebased on top of 3.10-rc1. Since the PCIe Device Tree informations
   were merged in 3.10-rc1, it allowed to reduce quite significantly
   the size of this patch set.

(Continue reading)

Sarah Sharp | 15 May 2013 07:39

Picon

Re: [OPW kernel] dma_set_coherent_mask

On Wed, May 15, 2013 at 05:41:12AM +0300, Xenia Ragiadakou wrote:
> Hi Sarah, (again)
> 
> Also I noticed that  dma_set_coherent_mask() is not called somewhere,
> which according to DMA-API-HOWTO.txt, means the even if the DMA mask
> is set to 64 bits by dma_set_mask, dma_alloc_coherent and
> dma_pool_alloc wont return 64 bit addresses (32 MSbits wont be
> addressed).

Another good question for Alan, and the USB and PCI list.

(Alan, Ksenia is one of the applicants for the FOSS Outreach Program for
Women that I've been coordinating: http://kernelnewbies.org/OPWIntro)

We do allocate memory using DMA pools, and we do want 64-bit context
addresses if the xHCI host controller can handle it.

The xHCI driver calls dma_set_mask, but not dma_set_coherent_mask():

                temp = xhci_readl(xhci, &xhci->cap_regs->hcc_params);
                if (HCC_64BIT_ADDR(temp)) {
                        xhci_dbg(xhci, "Enabling 64-bit DMA addresses.\n");
                        dma_set_mask(hcd->self.controller, DMA_BIT_MASK(64));
                } else {
                        dma_set_mask(hcd->self.controller, DMA_BIT_MASK(32));
                }

Alan, should it be calling dma_set_coherent_mask()?  I think I may have
noticed the context addresses were never 64-bit addresses, but I didn't
think to look whether the host supported 64-bit addresses.  I just

(Continue reading)

Alexander Duyck | 15 May 2013 03:58

Picon

Re: [PATCH] pci: Avoid reentrant calls to work_on_cpu

On 05/14/2013 05:32 PM, Or Gerlitz wrote:
> On Tue, May 14, 2013 at 6:26 PM, Alexander Duyck
> <alexander.h.duyck <at> intel.com> wrote:
>>
>> This change is meant to fix a deadlock seen when pci_enable_sriov was
>> called from within a driver's probe routine.  The issue was that
>> work_on_cpu calls flush_work which attempts to flush a work queue for a
>> cpu that we are currently working in.  In order to avoid the reentrant
>> path we just skip the call to work_on_cpu in the case that the device
>> node matches our current node.
>>
>> Reported-by: Yinghai Lu <yinghai <at> kernel.org>
>> Signed-off-by: Alexander Duyck <alexander.h.duyck <at> intel.com>
>> ---
>>
>> This patch is meant to address the issue pointed out in an earlier patch
>> sent by Yinghai Lu titled:
>>   [PATCH 6/7] PCI: Make sure VF's driver get attached after PF's
>>
>>  drivers/pci/pci-driver.c |   14 +++++++++-----
>>  1 files changed, 9 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/pci/pci-driver.c b/drivers/pci/pci-driver.c
>> index 79277fb..caeb1c0 100644
>> --- a/drivers/pci/pci-driver.c
>> +++ b/drivers/pci/pci-driver.c
>>  <at>  <at>  -277,12 +277,16  <at>  <at>  static int pci_call_probe(struct pci_driver *drv,
>> struct pci_dev *dev,
>>         int error, node;
>>         struct drv_dev_and_id ddi = { drv, dev, id };

(Continue reading)

Alexander Duyck | 15 May 2013 00:26

Picon

[PATCH] pci: Avoid reentrant calls to work_on_cpu

This change is meant to fix a deadlock seen when pci_enable_sriov was
called from within a driver's probe routine.  The issue was that
work_on_cpu calls flush_work which attempts to flush a work queue for a
cpu that we are currently working in.  In order to avoid the reentrant
path we just skip the call to work_on_cpu in the case that the device
node matches our current node.

Reported-by: Yinghai Lu <yinghai <at> kernel.org>
Signed-off-by: Alexander Duyck <alexander.h.duyck <at> intel.com>
---

This patch is meant to address the issue pointed out in an earlier patch
sent by Yinghai Lu titled:
  [PATCH 6/7] PCI: Make sure VF's driver get attached after PF's

 drivers/pci/pci-driver.c |   14 +++++++++-----
 1 files changed, 9 insertions(+), 5 deletions(-)

diff --git a/drivers/pci/pci-driver.c b/drivers/pci/pci-driver.c
index 79277fb..caeb1c0 100644
--- a/drivers/pci/pci-driver.c
+++ b/drivers/pci/pci-driver.c
 <at>  <at>  -277,12 +277,16  <at>  <at>  static int pci_call_probe(struct pci_driver *drv, struct pci_dev *dev,
 	int error, node;
 	struct drv_dev_and_id ddi = { drv, dev, id };

-	/* Execute driver initialization on node where the device's
-	   bus is attached to.  This way the driver likely allocates
-	   its local memory on the right node without any need to
-	   change it. */

(Continue reading)

Jiang Liu | 14 May 2013 18:51

Picon

[RFC PATCH v2, part 2 01/18] PCI: introduce hotplug-safe PCI bus iterators

Introduce hotplug-safe PCI bus iterators as below, which hold a
reference on the returned PCI bus object.
bool pci_bus_exists(int domain, int busnr);
struct pci_bus *pci_get_bus(int domain, int busnr);
struct pci_bus *pci_get_next_bus(struct pci_bus *from);
struct pci_bus *pci_get_next_root_bus(struct pci_bus *from);
#define for_each_pci_bus(b) for (b = NULL; (b = pci_get_next_bus(b)); )
#define for_each_pci_root_bus(b)  \
		for (b = NULL; (b = pci_get_next_root_bus(b)); )

The long-term goal is to remove hotplug-unsafe pci_find_bus(),
pci_find_next_bus() and the global pci_root_buses list.

These new interfaces may be a littler slower than existing interfaces,
but it should be acceptable because they are not used on hot paths.

Signed-off-by: Jiang Liu <jiang.liu <at> huawei.com>
Cc: linux-pci <at> vger.kernel.org
Cc: linux-kernel <at> vger.kernel.org
---
 drivers/pci/pci.h    |   1 +
 drivers/pci/probe.c  |   2 +-
 drivers/pci/search.c | 159 +++++++++++++++++++++++++++++++++++++++++----------
 include/linux/pci.h  |  23 +++++++-
 4 files changed, 153 insertions(+), 32 deletions(-)

diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h
index 68678ed..8fe15f6 100644
--- a/drivers/pci/pci.h
+++ b/drivers/pci/pci.h

(Continue reading)

Jimmie Mayfield | 14 May 2013 17:06

Seeking advice: Restoring MSI-X after device reset


Hi.  I'm looking for advice on how a device driver should handle 
restoring MSI-X following a device reset.  Here's my situation: we have an 
MSI-X-capable device that for various reasons might be reset by the
device driver.  One of the features of this device is that a reset also
wipes out the MSI-X structure in MMIO address space.  

So this leads to my question:  what is the recommended way for the driver 
to restore MSI-X following such a reset?  

I suppose one (perhaps naive) way would be to do something like this:
   free all IRQs
   pci_disable_msix();
   reset device
   pci_enable_msix()
   request new IRQs

That seems unclean.  Is there a better way?

JM

Group

gmane.linux.kernel.pci.

Search Archive

Page

1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11

May 2013

Language

Change language

Options

Current view: Threads only / Showing only 20 lines / Not hiding cited text.
Change to All messages, whole messages, or hide cited text.

Post a message
NNTP Newsgroup
Classic Gmane web interface
XML

XML

RSS Feed
List Information

About Gmane

Recent entries

[PATCH] lspci: Fully decode ASPM support from Link Capabilities (17 May 2013)
enabling aspm on ati radeon (17 May 2013)
[PATCH -v2 0/7] Add hostbridge resource release to support root bus ho (17 May 2013)
[PATCHv10 0/9] PCIe support for the Armada 370 and Armada XP SoCs (16 May 2013)
[RFC PATCH v2, part3 00/11] Introduce PCI bus lock and state machine (16 May 2013)
[PATCHv9 0/9] PCIe support for the Armada 370 and Armada XP SoCs (15 May 2013)
[OPW kernel] dma_set_coherent_mask (15 May 2013)
[PATCH] pci: Avoid reentrant calls to work_on_cpu (15 May 2013)
[PATCH] pci: Avoid reentrant calls to work_on_cpu (15 May 2013)
[RFC PATCH v2, part 2 01/18] PCI: introduce hotplug-safe PCI bus itera (14 May 2013)
Seeking advice: Restoring MSI-X after device reset (14 May 2013)
[PATCH 0/2] fix the pci device malfunction if a wrong bus address is a (14 May 2013)
[PATCH v1 1/2] ACPI, PCI: remove unused global list acpi_pci_roots in (14 May 2013)
[PATCH v2] PCI: Reset PCIe devices to stop ongoing DMA (14 May 2013)
[PATCH v2, part 1 0/9] Prepare for introducing PCI bus lock interfaces (13 May 2013)
[PATCH v3 -tip x86/apic 0/2] PCI/MSI: Allocate as many multiple-MSIs a (13 May 2013)
3.8.2: stale pci device info for a previously inserted express card (10 May 2013)
[PATCH] PCI/ACPI: Check acpi_resource_to_address64() return value (9 May 2013)
[GIT PULL] PCI updates for v3.10 (9 May 2013)
Masked MSIs expectations (9 May 2013)
[PATCH] aerdrv: Move cper_print_pcie() out of interrupt context (8 May 2013)

Archives

231	May 2013
484	April 2013
467	March 2013
327	February 2013
486	January 2013
200	December 2012
197	November 2012
337	October 2012
397	September 2012
346	August 2012
317	July 2012
382	June 2012
358	May 2012
383	April 2012
303	March 2012
254	February 2012
266	January 2012
114	December 2011
270	November 2011
272	October 2011
237	September 2011
194	August 2011
115	July 2011
186	June 2011
206	May 2011
147	April 2011
119	March 2011
70	February 2011
95	January 2011
84	December 2010
97	November 2010
166	October 2010
112	September 2010
91	August 2010
122	July 2010
250	June 2010
169	May 2010
329	April 2010
242	March 2010
240	February 2010
396	January 2010
264	December 2009
340	November 2009
238	October 2009
336	September 2009
292	August 2009
227	July 2009
544	June 2009
261	May 2009
314	April 2009
458	March 2009
462	February 2009
441	January 2009
345	December 2008
464	November 2008
605	October 2008
383	September 2008
239	August 2008
354	July 2008
111	June 2008
1	January 2002

Design

Zawodny | Right Menu | Left Menu

Your Own Design

Paste the URL of your CSS below. Download CSS template