Donate to e Foundation | Murena handsets with /e/OS | Own a part of Murena! Learn more

Commit 60e8d3e1 authored by Linus Torvalds's avatar Linus Torvalds
Browse files

Merge tag 'pci-v4.11-changes' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci 

Pull PCI updates from Bjorn Helgaas:

 - add ASPM L1 substate support

 - enable PCIe Extended Tags when supported

 - configure PCIe MPS settings on iProc, Versatile, X-Gene, and Xilinx

 - increase VPD access timeout

 - add ACS quirks for Intel Union Point, Qualcomm QDF2400 and QDF2432

 - use new pci_irq_alloc_vectors() in more drivers

 - fix MSI affinity memory leak

 - remove unused MSI interfaces and update documentation

 - remove unused AER .link_reset() callback

 - avoid pci_lock / p->pi_lock deadlock seen with perf

 - serialize sysfs enable/disable num_vfs operations

 - move DesignWare IP from drivers/pci/host/ to drivers/pci/dwc/ and
   refactor so we can support both hosts and endpoints

 - add DT ECAM-like support for HiSilicon Hip06/Hip07 controllers

 - add Rockchip system power management support

 - add Thunder-X cn81xx and cn83xx support

 - add Exynos 5440 PCIe PHY support

* tag 'pci-v4.11-changes' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci: (93 commits)
  PCI: dwc: Remove dependency of designware on CONFIG_PCI
  PCI: dwc: Add CONFIG_PCIE_DW_HOST to enable PCI dwc host
  PCI: dwc: Split pcie-designware.c into host and core files
  PCI: dwc: designware: Fix style errors in pcie-designware.c
  PCI: dwc: designware: Parse "num-lanes" property in dw_pcie_setup_rc()
  PCI: dwc: all: Split struct pcie_port into host-only and core structures
  PCI: dwc: designware: Get device pointer at the start of dw_pcie_host_init()
  PCI: dwc: all: Rename cfg_read/cfg_write to read/write
  PCI: dwc: all: Use platform_set_drvdata() to save private data
  PCI: dwc: designware: Move register defines to designware header file
  PCI: dwc: Use PTR_ERR_OR_ZERO to simplify code
  PCI: dra7xx: Group PHY API invocations
  PCI: dra7xx: Enable MSI and legacy interrupts simultaneously
  PCI: dra7xx: Add support to force RC to work in GEN1 mode
  PCI: dra7xx: Simplify probe code with devm_gpiod_get_optional()
  PCI: Move DesignWare IP support to new drivers/pci/dwc/ directory
  PCI: exynos: Support the PHY generic framework
  Documentation: binding: Modify the exynos5440 PCIe binding
  phy: phy-exynos-pcie: Add support for Exynos PCIe PHY
  Documentation: samsung-phy: Add exynos-pcie-phy binding
  ...
parents 190c3ee0 c4d052ce

Documentation/PCI/MSI-HOWTO.txt

+2 −4
Original line number Diff line number Diff line
@@ -162,8 +162,6 @@ The following old APIs to enable and disable MSI or MSI-X interrupts should 
not be used in new code:



  pci_enable_msi()		/* deprecated */

  pci_enable_msi_range()	/* deprecated */

  pci_enable_msi_exact()	/* deprecated */

  pci_disable_msi()		/* deprecated */

  pci_enable_msix_range()	/* deprecated */

  pci_enable_msix_exact()	/* deprecated */
@@ -268,5 +266,5 @@ or disabled (0). If 0 is found in any of the msi_bus files belonging 
to bridges between the PCI root and the device, MSIs are disabled.



It is also worth checking the device driver to see whether it supports MSIs.

For example, it may contain calls to pci_enable_msi_range() or

pci_enable_msix_range().
 
For example, it may contain calls to pci_irq_alloc_vectors() with the

PCI_IRQ_MSI or PCI_IRQ_MSIX flags.

Documentation/PCI/PCIEBUS-HOWTO.txt

+7 −26
Original line number Diff line number Diff line
@@ -161,21 +161,13 @@ Since all service drivers of a PCI-PCI Bridge Port device are 
allowed to run simultaneously, below lists a few of possible resource

conflicts with proposed solutions.



6.1 MSI Vector Resource



The MSI capability structure enables a device software driver to call

pci_enable_msi to request MSI based interrupts. Once MSI interrupts

are enabled on a device, it stays in this mode until a device driver

calls pci_disable_msi to disable MSI interrupts and revert back to

INTx emulation mode. Since service drivers of the same PCI-PCI Bridge

port share the same physical device, if an individual service driver

calls pci_enable_msi/pci_disable_msi it may result unpredictable

behavior. For example, two service drivers run simultaneously on the

same physical Root Port. Both service drivers call pci_enable_msi to

request MSI based interrupts. A service driver may not know whether

any other service drivers have run on this Root Port. If either one

of them calls pci_disable_msi, it puts the other service driver

in a wrong interrupt mode.

6.1 MSI and MSI-X Vector Resource



Once MSI or MSI-X interrupts are enabled on a device, it stays in this

mode until they are disabled again.  Since service drivers of the same

PCI-PCI Bridge port share the same physical device, if an individual

service driver enables or disables MSI/MSI-X mode it may result

unpredictable behavior.



To avoid this situation all service drivers are not permitted to

switch interrupt mode on its device. The PCI Express Port Bus driver
@@ -187,17 +179,6 @@ driver. Service drivers should use (struct pcie_device*)dev->irq to 
call request_irq/free_irq. In addition, the interrupt mode is stored

in the field interrupt_mode of struct pcie_device.



6.2 MSI-X Vector Resources



Similar to the MSI a device driver for an MSI-X capable device can

call pci_enable_msix to request MSI-X interrupts. All service drivers

are not permitted to switch interrupt mode on its device. The PCI

Express Port Bus driver is responsible for determining the interrupt

mode and this should be transparent to service drivers. Any attempt

by service driver to call pci_enable_msix/pci_disable_msix may

result unpredictable behavior. Service drivers should use

(struct pcie_device*)dev->irq and call request_irq/free_irq.



6.3 PCI Memory/IO Mapped Regions



Service drivers for PCI Express Power Management (PME), Advanced

Documentation/PCI/pci-error-recovery.txt

+3 −21
Original line number Diff line number Diff line
@@ -78,7 +78,6 @@ struct pci_error_handlers 
{

	int (*error_detected)(struct pci_dev *dev, enum pci_channel_state);

	int (*mmio_enabled)(struct pci_dev *dev);

	int (*link_reset)(struct pci_dev *dev);

	int (*slot_reset)(struct pci_dev *dev);

	void (*resume)(struct pci_dev *dev);

};
@@ -104,8 +103,7 @@ if it implements any, it must implement error_detected(). If a callback 
is not implemented, the corresponding feature is considered unsupported.

For example, if mmio_enabled() and resume() aren't there, then it

is assumed that the driver is not doing any direct recovery and requires

a slot reset. If link_reset() is not implemented, the card is assumed to

not care about link resets. Typically a driver will want to know about

a slot reset.  Typically a driver will want to know about

a slot_reset().



The actual steps taken by a platform to recover from a PCI error
@@ -232,25 +230,9 @@ proceeds to STEP 4 (Slot Reset) 


STEP 3: Link Reset

------------------

The platform resets the link, and then calls the link_reset() callback

on all affected device drivers.  This is a PCI-Express specific state

The platform resets the link.  This is a PCI-Express specific step

and is done whenever a non-fatal error has been detected that can be

"solved" by resetting the link. This call informs the driver of the

reset and the driver should check to see if the device appears to be

in working condition.



The driver is not supposed to restart normal driver I/O operations

at this point.  It should limit itself to "probing" the device to

check its recoverability status. If all is right, then the platform

will call resume() once all drivers have ack'd link_reset().



	Result codes:

		(identical to STEP 3 (MMIO Enabled)



The platform then proceeds to either STEP 4 (Slot Reset) or STEP 5

(Resume Operations).



>>> The current powerpc implementation does not implement this callback.

"solved" by resetting the link.



STEP 4: Slot Reset

------------------

Documentation/PCI/pci.txt

+12 −12
Original line number Diff line number Diff line
@@ -382,18 +382,18 @@ The fundamental difference between MSI and MSI-X is how multiple 
"vectors" get allocated. MSI requires contiguous blocks of vectors

while MSI-X can allocate several individual ones.



MSI capability can be enabled by calling pci_enable_msi() or

pci_enable_msix() before calling request_irq(). This causes

the PCI support to program CPU vector data into the PCI device

capability registers.



If your PCI device supports both, try to enable MSI-X first.

Only one can be enabled at a time.  Many architectures, chip-sets,

or BIOSes do NOT support MSI or MSI-X and the call to pci_enable_msi/msix

will fail. This is important to note since many drivers have

two (or more) interrupt handlers: one for MSI/MSI-X and another for IRQs.

They choose which handler to register with request_irq() based on the

return value from pci_enable_msi/msix().

MSI capability can be enabled by calling pci_alloc_irq_vectors() with the

PCI_IRQ_MSI and/or PCI_IRQ_MSIX flags before calling request_irq(). This

causes the PCI support to program CPU vector data into the PCI device

capability registers. Many architectures, chip-sets, or BIOSes do NOT

support MSI or MSI-X and a call to pci_alloc_irq_vectors with just

the PCI_IRQ_MSI and PCI_IRQ_MSIX flags will fail, so try to always

specify PCI_IRQ_LEGACY as well.



Drivers that have different interrupt handlers for MSI/MSI-X and

legacy INTx should chose the right one based on the msi_enabled

and msix_enabled flags in the pci_dev structure after calling

pci_alloc_irq_vectors.



There are (at least) two really good reasons for using MSI:

1) MSI is an exclusive interrupt vector by definition.

Documentation/devicetree/bindings/pci/hisilicon-pcie.txt

+37 −0
Original line number Diff line number Diff line
@@ -42,3 +42,40 @@ Hip05 Example (note that Hip06 is the same except compatible): 
				 0x0 0 0 4 &mbigen_pcie 4 13>;

		status = "ok";

	};



HiSilicon Hip06/Hip07 PCIe host bridge DT (almost-ECAM) description.

The properties and their meanings are identical to those described in

host-generic-pci.txt except as listed below.



Properties of the host controller node that differ from

host-generic-pci.txt:



- compatible     : Must be "hisilicon,pcie-almost-ecam"



- reg            : Two entries: First the ECAM configuration space for any

		   other bus underneath the root bus. Second, the base

		   and size of the HiSilicon host bridge registers include

		   the RC's own config space.



Example:

	pcie0: pcie@a0090000 {

		compatible = "hisilicon,pcie-almost-ecam";

		reg = <0 0xb0000000 0 0x2000000>,  /*  ECAM configuration space */

		      <0 0xa0090000 0 0x10000>; /* host bridge registers */

		bus-range = <0  31>;

		msi-map = <0x0000 &its_dsa 0x0000 0x2000>;

		msi-map-mask = <0xffff>;

		#address-cells = <3>;

		#size-cells = <2>;

		device_type = "pci";

		dma-coherent;

		ranges = <0x02000000 0 0xb2000000 0x0 0xb2000000 0 0x5ff0000

			  0x01000000 0 0 0 0xb7ff0000 0 0x10000>;

		#interrupt-cells = <1>;

		interrupt-map-mask = <0xf800 0 0 7>;

		interrupt-map = <0x0 0 0 1 &mbigen_pcie0 650 4

				 0x0 0 0 2 &mbigen_pcie0 650 4

				 0x0 0 0 3 &mbigen_pcie0 650 4

				 0x0 0 0 4 &mbigen_pcie0 650 4>;

		status = "ok";

	};