You've already forked linux-apfs
mirror of
https://github.com/linux-apfs/linux-apfs.git
synced 2026-05-01 15:00:59 -07:00
Merge tag 'pci-v4.12-changes' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci
Pull PCI updates from Bjorn Helgaas: - add framework for supporting PCIe devices in Endpoint mode (Kishon Vijay Abraham I) - use non-postable PCI config space mappings when possible (Lorenzo Pieralisi) - clean up and unify mmap of PCI BARs (David Woodhouse) - export and unify Function Level Reset support (Christoph Hellwig) - avoid FLR for Intel 82579 NICs (Sasha Neftin) - add pci_request_irq() and pci_free_irq() helpers (Christoph Hellwig) - short-circuit config access failures for disconnected devices (Keith Busch) - remove D3 sleep delay when possible (Adrian Hunter) - freeze PME scan before suspending devices (Lukas Wunner) - stop disabling MSI/MSI-X in pci_device_shutdown() (Prarit Bhargava) - disable boot interrupt quirk for ASUS M2N-LR (Stefan Assmann) - add arch-specific alignment control to improve device passthrough by avoiding multiple BARs in a page (Yongji Xie) - add sysfs sriov_drivers_autoprobe to control VF driver binding (Bodong Wang) - allow slots below PCI-to-PCIe "reverse bridges" (Bjorn Helgaas) - fix crashes when unbinding host controllers that don't support removal (Brian Norris) - add driver for MicroSemi Switchtec management interface (Logan Gunthorpe) - add driver for Faraday Technology FTPCI100 host bridge (Linus Walleij) - add i.MX7D support (Andrey Smirnov) - use generic MSI support for Aardvark (Thomas Petazzoni) - make Rockchip driver modular (Brian Norris) - advertise 128-byte Read Completion Boundary support for Rockchip (Shawn Lin) - advertise PCI_EXP_LNKSTA_SLC for Rockchip root port (Shawn Lin) - convert atomic_t to refcount_t in HV driver (Elena Reshetova) - add CPU IRQ affinity in HV driver (K. Y. Srinivasan) - fix PCI bus removal in HV driver (Long Li) - add support for ThunderX2 DMA alias topology (Jayachandran C) - add ThunderX pass2.x 2nd node MCFG quirk (Tomasz Nowicki) - add ITE 8893 bridge DMA alias quirk (Jarod Wilson) - restrict Cavium ACS quirk only to CN81xx/CN83xx/CN88xx devices (Manish Jaggi) * tag 'pci-v4.12-changes' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci: (146 commits) PCI: Don't allow unbinding host controllers that aren't prepared ARM: DRA7: clockdomain: Change the CLKTRCTRL of CM_PCIE_CLKSTCTRL to SW_WKUP MAINTAINERS: Add PCI Endpoint maintainer Documentation: PCI: Add userguide for PCI endpoint test function tools: PCI: Add sample test script to invoke pcitest tools: PCI: Add a userspace tool to test PCI endpoint Documentation: misc-devices: Add Documentation for pci-endpoint-test driver misc: Add host side PCI driver for PCI test function device PCI: Add device IDs for DRA74x and DRA72x dt-bindings: PCI: dra7xx: Add DT bindings to enable unaligned access PCI: dwc: dra7xx: Workaround for errata id i870 dt-bindings: PCI: dra7xx: Add DT bindings for PCI dra7xx EP mode PCI: dwc: dra7xx: Add EP mode support PCI: dwc: dra7xx: Facilitate wrapper and MSI interrupts to be enabled independently dt-bindings: PCI: Add DT bindings for PCI designware EP mode PCI: dwc: designware: Add EP mode support Documentation: PCI: Add binding documentation for pci-test endpoint function ixgbe: Use pcie_flr() instead of duplicating it IB/hfi1: Use pcie_flr() instead of duplicating it PCI: imx6: Fix spelling mistake: "contol" -> "control" ...
This commit is contained in:
Linus Torvalds
@@ -301,3 +301,25 @@ Contact: Emil Velikov <emil.l.velikov@gmail.com>
|
||||
Description:
|
||||
This file contains the revision field of the PCI device.
|
||||
The value comes from device config space. The file is read only.
|
||||
|
||||
What: /sys/bus/pci/devices/.../sriov_drivers_autoprobe
|
||||
Date: April 2017
|
||||
Contact: Bodong Wang<bodong@mellanox.com>
|
||||
Description:
|
||||
This file is associated with the PF of a device that
|
||||
supports SR-IOV. It determines whether newly-enabled VFs
|
||||
are immediately bound to a driver. It initially contains
|
||||
1, which means the kernel automatically binds VFs to a
|
||||
compatible driver immediately after they are enabled. If
|
||||
an application writes 0 to the file before enabling VFs,
|
||||
the kernel will not bind VFs to a driver.
|
||||
|
||||
A typical use case is to write 0 to this file, then enable
|
||||
VFs, then assign the newly-created VFs to virtual machines.
|
||||
Note that changing this file does not affect already-
|
||||
enabled VFs. In this scenario, the user must first disable
|
||||
the VFs, write 0 to sriov_drivers_autoprobe, then re-enable
|
||||
the VFs.
|
||||
|
||||
This is similar to /sys/bus/pci/drivers_autoprobe, but
|
||||
affects only the VFs associated with a specific PF.
|
||||
|
||||
@@ -0,0 +1,96 @@
|
||||
switchtec - Microsemi Switchtec PCI Switch Management Endpoint
|
||||
|
||||
For details on this subsystem look at Documentation/switchtec.txt.
|
||||
|
||||
What: /sys/class/switchtec
|
||||
Date: 05-Jan-2017
|
||||
KernelVersion: v4.11
|
||||
Contact: Logan Gunthorpe <logang@deltatee.com>
|
||||
Description: The switchtec class subsystem folder.
|
||||
Each registered switchtec driver is represented by a switchtecX
|
||||
subfolder (X being an integer >= 0).
|
||||
|
||||
|
||||
What: /sys/class/switchtec/switchtec[0-9]+/component_id
|
||||
Date: 05-Jan-2017
|
||||
KernelVersion: v4.11
|
||||
Contact: Logan Gunthorpe <logang@deltatee.com>
|
||||
Description: Component identifier as stored in the hardware (eg. PM8543)
|
||||
(read only)
|
||||
Values: arbitrary string.
|
||||
|
||||
|
||||
What: /sys/class/switchtec/switchtec[0-9]+/component_revision
|
||||
Date: 05-Jan-2017
|
||||
KernelVersion: v4.11
|
||||
Contact: Logan Gunthorpe <logang@deltatee.com>
|
||||
Description: Component revision stored in the hardware (read only)
|
||||
Values: integer.
|
||||
|
||||
|
||||
What: /sys/class/switchtec/switchtec[0-9]+/component_vendor
|
||||
Date: 05-Jan-2017
|
||||
KernelVersion: v4.11
|
||||
Contact: Logan Gunthorpe <logang@deltatee.com>
|
||||
Description: Component vendor as stored in the hardware (eg. MICROSEM)
|
||||
(read only)
|
||||
Values: arbitrary string.
|
||||
|
||||
|
||||
What: /sys/class/switchtec/switchtec[0-9]+/device_version
|
||||
Date: 05-Jan-2017
|
||||
KernelVersion: v4.11
|
||||
Contact: Logan Gunthorpe <logang@deltatee.com>
|
||||
Description: Device version as stored in the hardware (read only)
|
||||
Values: integer.
|
||||
|
||||
|
||||
What: /sys/class/switchtec/switchtec[0-9]+/fw_version
|
||||
Date: 05-Jan-2017
|
||||
KernelVersion: v4.11
|
||||
Contact: Logan Gunthorpe <logang@deltatee.com>
|
||||
Description: Currently running firmware version (read only)
|
||||
Values: integer (in hexadecimal).
|
||||
|
||||
|
||||
What: /sys/class/switchtec/switchtec[0-9]+/partition
|
||||
Date: 05-Jan-2017
|
||||
KernelVersion: v4.11
|
||||
Contact: Logan Gunthorpe <logang@deltatee.com>
|
||||
Description: Partition number for this device in the switch (read only)
|
||||
Values: integer.
|
||||
|
||||
|
||||
What: /sys/class/switchtec/switchtec[0-9]+/partition_count
|
||||
Date: 05-Jan-2017
|
||||
KernelVersion: v4.11
|
||||
Contact: Logan Gunthorpe <logang@deltatee.com>
|
||||
Description: Total number of partitions in the switch (read only)
|
||||
Values: integer.
|
||||
|
||||
|
||||
What: /sys/class/switchtec/switchtec[0-9]+/product_id
|
||||
Date: 05-Jan-2017
|
||||
KernelVersion: v4.11
|
||||
Contact: Logan Gunthorpe <logang@deltatee.com>
|
||||
Description: Product identifier as stored in the hardware (eg. PSX 48XG3)
|
||||
(read only)
|
||||
Values: arbitrary string.
|
||||
|
||||
|
||||
What: /sys/class/switchtec/switchtec[0-9]+/product_revision
|
||||
Date: 05-Jan-2017
|
||||
KernelVersion: v4.11
|
||||
Contact: Logan Gunthorpe <logang@deltatee.com>
|
||||
Description: Product revision stored in the hardware (eg. RevB)
|
||||
(read only)
|
||||
Values: arbitrary string.
|
||||
|
||||
|
||||
What: /sys/class/switchtec/switchtec[0-9]+/product_vendor
|
||||
Date: 05-Jan-2017
|
||||
KernelVersion: v4.11
|
||||
Contact: Logan Gunthorpe <logang@deltatee.com>
|
||||
Description: Product vendor as stored in the hardware (eg. MICROSEM)
|
||||
(read only)
|
||||
Values: arbitrary string.
|
||||
@@ -12,3 +12,13 @@ pci.txt
|
||||
- info on the PCI subsystem for device driver authors
|
||||
pcieaer-howto.txt
|
||||
- the PCI Express Advanced Error Reporting Driver Guide HOWTO
|
||||
endpoint/pci-endpoint.txt
|
||||
- guide to add endpoint controller driver and endpoint function driver.
|
||||
endpoint/pci-endpoint-cfs.txt
|
||||
- guide to use configfs to configure the PCI endpoint function.
|
||||
endpoint/pci-test-function.txt
|
||||
- specification of *PCI test* function device.
|
||||
endpoint/pci-test-howto.txt
|
||||
- userguide for PCI endpoint test function.
|
||||
endpoint/function/binding/
|
||||
- binding documentation for PCI endpoint function
|
||||
|
||||
@@ -0,0 +1,17 @@
|
||||
PCI TEST ENDPOINT FUNCTION
|
||||
|
||||
name: Should be "pci_epf_test" to bind to the pci_epf_test driver.
|
||||
|
||||
Configurable Fields:
|
||||
vendorid : should be 0x104c
|
||||
deviceid : should be 0xb500 for DRA74x and 0xb501 for DRA72x
|
||||
revid : don't care
|
||||
progif_code : don't care
|
||||
subclass_code : don't care
|
||||
baseclass_code : should be 0xff
|
||||
cache_line_size : don't care
|
||||
subsys_vendor_id : don't care
|
||||
subsys_id : don't care
|
||||
interrupt_pin : Should be 1 - INTA, 2 - INTB, 3 - INTC, 4 -INTD
|
||||
msi_interrupts : Should be 1 to 32 depending on the number of MSI interrupts
|
||||
to test
|
||||
@@ -0,0 +1,105 @@
|
||||
CONFIGURING PCI ENDPOINT USING CONFIGFS
|
||||
Kishon Vijay Abraham I <kishon@ti.com>
|
||||
|
||||
The PCI Endpoint Core exposes configfs entry (pci_ep) to configure the
|
||||
PCI endpoint function and to bind the endpoint function
|
||||
with the endpoint controller. (For introducing other mechanisms to
|
||||
configure the PCI Endpoint Function refer to [1]).
|
||||
|
||||
*) Mounting configfs
|
||||
|
||||
The PCI Endpoint Core layer creates pci_ep directory in the mounted configfs
|
||||
directory. configfs can be mounted using the following command.
|
||||
|
||||
mount -t configfs none /sys/kernel/config
|
||||
|
||||
*) Directory Structure
|
||||
|
||||
The pci_ep configfs has two directories at its root: controllers and
|
||||
functions. Every EPC device present in the system will have an entry in
|
||||
the *controllers* directory and and every EPF driver present in the system
|
||||
will have an entry in the *functions* directory.
|
||||
|
||||
/sys/kernel/config/pci_ep/
|
||||
.. controllers/
|
||||
.. functions/
|
||||
|
||||
*) Creating EPF Device
|
||||
|
||||
Every registered EPF driver will be listed in controllers directory. The
|
||||
entries corresponding to EPF driver will be created by the EPF core.
|
||||
|
||||
/sys/kernel/config/pci_ep/functions/
|
||||
.. <EPF Driver1>/
|
||||
... <EPF Device 11>/
|
||||
... <EPF Device 21>/
|
||||
.. <EPF Driver2>/
|
||||
... <EPF Device 12>/
|
||||
... <EPF Device 22>/
|
||||
|
||||
In order to create a <EPF device> of the type probed by <EPF Driver>, the
|
||||
user has to create a directory inside <EPF DriverN>.
|
||||
|
||||
Every <EPF device> directory consists of the following entries that can be
|
||||
used to configure the standard configuration header of the endpoint function.
|
||||
(These entries are created by the framework when any new <EPF Device> is
|
||||
created)
|
||||
|
||||
.. <EPF Driver1>/
|
||||
... <EPF Device 11>/
|
||||
... vendorid
|
||||
... deviceid
|
||||
... revid
|
||||
... progif_code
|
||||
... subclass_code
|
||||
... baseclass_code
|
||||
... cache_line_size
|
||||
... subsys_vendor_id
|
||||
... subsys_id
|
||||
... interrupt_pin
|
||||
|
||||
*) EPC Device
|
||||
|
||||
Every registered EPC device will be listed in controllers directory. The
|
||||
entries corresponding to EPC device will be created by the EPC core.
|
||||
|
||||
/sys/kernel/config/pci_ep/controllers/
|
||||
.. <EPC Device1>/
|
||||
... <Symlink EPF Device11>/
|
||||
... <Symlink EPF Device12>/
|
||||
... start
|
||||
.. <EPC Device2>/
|
||||
... <Symlink EPF Device21>/
|
||||
... <Symlink EPF Device22>/
|
||||
... start
|
||||
|
||||
The <EPC Device> directory will have a list of symbolic links to
|
||||
<EPF Device>. These symbolic links should be created by the user to
|
||||
represent the functions present in the endpoint device.
|
||||
|
||||
The <EPC Device> directory will also have a *start* field. Once
|
||||
"1" is written to this field, the endpoint device will be ready to
|
||||
establish the link with the host. This is usually done after
|
||||
all the EPF devices are created and linked with the EPC device.
|
||||
|
||||
|
||||
| controllers/
|
||||
| <Directory: EPC name>/
|
||||
| <Symbolic Link: Function>
|
||||
| start
|
||||
| functions/
|
||||
| <Directory: EPF driver>/
|
||||
| <Directory: EPF device>/
|
||||
| vendorid
|
||||
| deviceid
|
||||
| revid
|
||||
| progif_code
|
||||
| subclass_code
|
||||
| baseclass_code
|
||||
| cache_line_size
|
||||
| subsys_vendor_id
|
||||
| subsys_id
|
||||
| interrupt_pin
|
||||
| function
|
||||
|
||||
[1] -> Documentation/PCI/endpoint/pci-endpoint.txt
|
||||
@@ -0,0 +1,215 @@
|
||||
PCI ENDPOINT FRAMEWORK
|
||||
Kishon Vijay Abraham I <kishon@ti.com>
|
||||
|
||||
This document is a guide to use the PCI Endpoint Framework in order to create
|
||||
endpoint controller driver, endpoint function driver, and using configfs
|
||||
interface to bind the function driver to the controller driver.
|
||||
|
||||
1. Introduction
|
||||
|
||||
Linux has a comprehensive PCI subsystem to support PCI controllers that
|
||||
operates in Root Complex mode. The subsystem has capability to scan PCI bus,
|
||||
assign memory resources and IRQ resources, load PCI driver (based on
|
||||
vendor ID, device ID), support other services like hot-plug, power management,
|
||||
advanced error reporting and virtual channels.
|
||||
|
||||
However the PCI controller IP integrated in some SoCs is capable of operating
|
||||
either in Root Complex mode or Endpoint mode. PCI Endpoint Framework will
|
||||
add endpoint mode support in Linux. This will help to run Linux in an
|
||||
EP system which can have a wide variety of use cases from testing or
|
||||
validation, co-processor accelerator, etc.
|
||||
|
||||
2. PCI Endpoint Core
|
||||
|
||||
The PCI Endpoint Core layer comprises 3 components: the Endpoint Controller
|
||||
library, the Endpoint Function library, and the configfs layer to bind the
|
||||
endpoint function with the endpoint controller.
|
||||
|
||||
2.1 PCI Endpoint Controller(EPC) Library
|
||||
|
||||
The EPC library provides APIs to be used by the controller that can operate
|
||||
in endpoint mode. It also provides APIs to be used by function driver/library
|
||||
in order to implement a particular endpoint function.
|
||||
|
||||
2.1.1 APIs for the PCI controller Driver
|
||||
|
||||
This section lists the APIs that the PCI Endpoint core provides to be used
|
||||
by the PCI controller driver.
|
||||
|
||||
*) devm_pci_epc_create()/pci_epc_create()
|
||||
|
||||
The PCI controller driver should implement the following ops:
|
||||
* write_header: ops to populate configuration space header
|
||||
* set_bar: ops to configure the BAR
|
||||
* clear_bar: ops to reset the BAR
|
||||
* alloc_addr_space: ops to allocate in PCI controller address space
|
||||
* free_addr_space: ops to free the allocated address space
|
||||
* raise_irq: ops to raise a legacy or MSI interrupt
|
||||
* start: ops to start the PCI link
|
||||
* stop: ops to stop the PCI link
|
||||
|
||||
The PCI controller driver can then create a new EPC device by invoking
|
||||
devm_pci_epc_create()/pci_epc_create().
|
||||
|
||||
*) devm_pci_epc_destroy()/pci_epc_destroy()
|
||||
|
||||
The PCI controller driver can destroy the EPC device created by either
|
||||
devm_pci_epc_create() or pci_epc_create() using devm_pci_epc_destroy() or
|
||||
pci_epc_destroy().
|
||||
|
||||
*) pci_epc_linkup()
|
||||
|
||||
In order to notify all the function devices that the EPC device to which
|
||||
they are linked has established a link with the host, the PCI controller
|
||||
driver should invoke pci_epc_linkup().
|
||||
|
||||
*) pci_epc_mem_init()
|
||||
|
||||
Initialize the pci_epc_mem structure used for allocating EPC addr space.
|
||||
|
||||
*) pci_epc_mem_exit()
|
||||
|
||||
Cleanup the pci_epc_mem structure allocated during pci_epc_mem_init().
|
||||
|
||||
2.1.2 APIs for the PCI Endpoint Function Driver
|
||||
|
||||
This section lists the APIs that the PCI Endpoint core provides to be used
|
||||
by the PCI endpoint function driver.
|
||||
|
||||
*) pci_epc_write_header()
|
||||
|
||||
The PCI endpoint function driver should use pci_epc_write_header() to
|
||||
write the standard configuration header to the endpoint controller.
|
||||
|
||||
*) pci_epc_set_bar()
|
||||
|
||||
The PCI endpoint function driver should use pci_epc_set_bar() to configure
|
||||
the Base Address Register in order for the host to assign PCI addr space.
|
||||
Register space of the function driver is usually configured
|
||||
using this API.
|
||||
|
||||
*) pci_epc_clear_bar()
|
||||
|
||||
The PCI endpoint function driver should use pci_epc_clear_bar() to reset
|
||||
the BAR.
|
||||
|
||||
*) pci_epc_raise_irq()
|
||||
|
||||
The PCI endpoint function driver should use pci_epc_raise_irq() to raise
|
||||
Legacy Interrupt or MSI Interrupt.
|
||||
|
||||
*) pci_epc_mem_alloc_addr()
|
||||
|
||||
The PCI endpoint function driver should use pci_epc_mem_alloc_addr(), to
|
||||
allocate memory address from EPC addr space which is required to access
|
||||
RC's buffer
|
||||
|
||||
*) pci_epc_mem_free_addr()
|
||||
|
||||
The PCI endpoint function driver should use pci_epc_mem_free_addr() to
|
||||
free the memory space allocated using pci_epc_mem_alloc_addr().
|
||||
|
||||
2.1.3 Other APIs
|
||||
|
||||
There are other APIs provided by the EPC library. These are used for binding
|
||||
the EPF device with EPC device. pci-ep-cfs.c can be used as reference for
|
||||
using these APIs.
|
||||
|
||||
*) pci_epc_get()
|
||||
|
||||
Get a reference to the PCI endpoint controller based on the device name of
|
||||
the controller.
|
||||
|
||||
*) pci_epc_put()
|
||||
|
||||
Release the reference to the PCI endpoint controller obtained using
|
||||
pci_epc_get()
|
||||
|
||||
*) pci_epc_add_epf()
|
||||
|
||||
Add a PCI endpoint function to a PCI endpoint controller. A PCIe device
|
||||
can have up to 8 functions according to the specification.
|
||||
|
||||
*) pci_epc_remove_epf()
|
||||
|
||||
Remove the PCI endpoint function from PCI endpoint controller.
|
||||
|
||||
*) pci_epc_start()
|
||||
|
||||
The PCI endpoint function driver should invoke pci_epc_start() once it
|
||||
has configured the endpoint function and wants to start the PCI link.
|
||||
|
||||
*) pci_epc_stop()
|
||||
|
||||
The PCI endpoint function driver should invoke pci_epc_stop() to stop
|
||||
the PCI LINK.
|
||||
|
||||
2.2 PCI Endpoint Function(EPF) Library
|
||||
|
||||
The EPF library provides APIs to be used by the function driver and the EPC
|
||||
library to provide endpoint mode functionality.
|
||||
|
||||
2.2.1 APIs for the PCI Endpoint Function Driver
|
||||
|
||||
This section lists the APIs that the PCI Endpoint core provides to be used
|
||||
by the PCI endpoint function driver.
|
||||
|
||||
*) pci_epf_register_driver()
|
||||
|
||||
The PCI Endpoint Function driver should implement the following ops:
|
||||
* bind: ops to perform when a EPC device has been bound to EPF device
|
||||
* unbind: ops to perform when a binding has been lost between a EPC
|
||||
device and EPF device
|
||||
* linkup: ops to perform when the EPC device has established a
|
||||
connection with a host system
|
||||
|
||||
The PCI Function driver can then register the PCI EPF driver by using
|
||||
pci_epf_register_driver().
|
||||
|
||||
*) pci_epf_unregister_driver()
|
||||
|
||||
The PCI Function driver can unregister the PCI EPF driver by using
|
||||
pci_epf_unregister_driver().
|
||||
|
||||
*) pci_epf_alloc_space()
|
||||
|
||||
The PCI Function driver can allocate space for a particular BAR using
|
||||
pci_epf_alloc_space().
|
||||
|
||||
*) pci_epf_free_space()
|
||||
|
||||
The PCI Function driver can free the allocated space
|
||||
(using pci_epf_alloc_space) by invoking pci_epf_free_space().
|
||||
|
||||
2.2.2 APIs for the PCI Endpoint Controller Library
|
||||
This section lists the APIs that the PCI Endpoint core provides to be used
|
||||
by the PCI endpoint controller library.
|
||||
|
||||
*) pci_epf_linkup()
|
||||
|
||||
The PCI endpoint controller library invokes pci_epf_linkup() when the
|
||||
EPC device has established the connection to the host.
|
||||
|
||||
2.2.2 Other APIs
|
||||
There are other APIs provided by the EPF library. These are used to notify
|
||||
the function driver when the EPF device is bound to the EPC device.
|
||||
pci-ep-cfs.c can be used as reference for using these APIs.
|
||||
|
||||
*) pci_epf_create()
|
||||
|
||||
Create a new PCI EPF device by passing the name of the PCI EPF device.
|
||||
This name will be used to bind the the EPF device to a EPF driver.
|
||||
|
||||
*) pci_epf_destroy()
|
||||
|
||||
Destroy the created PCI EPF device.
|
||||
|
||||
*) pci_epf_bind()
|
||||
|
||||
pci_epf_bind() should be invoked when the EPF device has been bound to
|
||||
a EPC device.
|
||||
|
||||
*) pci_epf_unbind()
|
||||
|
||||
pci_epf_unbind() should be invoked when the binding between EPC device
|
||||
and EPF device is lost.
|
||||
@@ -0,0 +1,66 @@
|
||||
PCI TEST
|
||||
Kishon Vijay Abraham I <kishon@ti.com>
|
||||
|
||||
Traditionally PCI RC has always been validated by using standard
|
||||
PCI cards like ethernet PCI cards or USB PCI cards or SATA PCI cards.
|
||||
However with the addition of EP-core in linux kernel, it is possible
|
||||
to configure a PCI controller that can operate in EP mode to work as
|
||||
a test device.
|
||||
|
||||
The PCI endpoint test device is a virtual device (defined in software)
|
||||
used to test the endpoint functionality and serve as a sample driver
|
||||
for other PCI endpoint devices (to use the EP framework).
|
||||
|
||||
The PCI endpoint test device has the following registers:
|
||||
|
||||
1) PCI_ENDPOINT_TEST_MAGIC
|
||||
2) PCI_ENDPOINT_TEST_COMMAND
|
||||
3) PCI_ENDPOINT_TEST_STATUS
|
||||
4) PCI_ENDPOINT_TEST_SRC_ADDR
|
||||
5) PCI_ENDPOINT_TEST_DST_ADDR
|
||||
6) PCI_ENDPOINT_TEST_SIZE
|
||||
7) PCI_ENDPOINT_TEST_CHECKSUM
|
||||
|
||||
*) PCI_ENDPOINT_TEST_MAGIC
|
||||
|
||||
This register will be used to test BAR0. A known pattern will be written
|
||||
and read back from MAGIC register to verify BAR0.
|
||||
|
||||
*) PCI_ENDPOINT_TEST_COMMAND:
|
||||
|
||||
This register will be used by the host driver to indicate the function
|
||||
that the endpoint device must perform.
|
||||
|
||||
Bitfield Description:
|
||||
Bit 0 : raise legacy IRQ
|
||||
Bit 1 : raise MSI IRQ
|
||||
Bit 2 - 7 : MSI interrupt number
|
||||
Bit 8 : read command (read data from RC buffer)
|
||||
Bit 9 : write command (write data to RC buffer)
|
||||
Bit 10 : copy command (copy data from one RC buffer to another
|
||||
RC buffer)
|
||||
|
||||
*) PCI_ENDPOINT_TEST_STATUS
|
||||
|
||||
This register reflects the status of the PCI endpoint device.
|
||||
|
||||
Bitfield Description:
|
||||
Bit 0 : read success
|
||||
Bit 1 : read fail
|
||||
Bit 2 : write success
|
||||
Bit 3 : write fail
|
||||
Bit 4 : copy success
|
||||
Bit 5 : copy fail
|
||||
Bit 6 : IRQ raised
|
||||
Bit 7 : source address is invalid
|
||||
Bit 8 : destination address is invalid
|
||||
|
||||
*) PCI_ENDPOINT_TEST_SRC_ADDR
|
||||
|
||||
This register contains the source address (RC buffer address) for the
|
||||
COPY/READ command.
|
||||
|
||||
*) PCI_ENDPOINT_TEST_DST_ADDR
|
||||
|
||||
This register contains the destination address (RC buffer address) for
|
||||
the COPY/WRITE command.
|
||||
@@ -0,0 +1,179 @@
|
||||
PCI TEST USERGUIDE
|
||||
Kishon Vijay Abraham I <kishon@ti.com>
|
||||
|
||||
This document is a guide to help users use pci-epf-test function driver
|
||||
and pci_endpoint_test host driver for testing PCI. The list of steps to
|
||||
be followed in the host side and EP side is given below.
|
||||
|
||||
1. Endpoint Device
|
||||
|
||||
1.1 Endpoint Controller Devices
|
||||
|
||||
To find the list of endpoint controller devices in the system:
|
||||
|
||||
# ls /sys/class/pci_epc/
|
||||
51000000.pcie_ep
|
||||
|
||||
If PCI_ENDPOINT_CONFIGFS is enabled
|
||||
# ls /sys/kernel/config/pci_ep/controllers
|
||||
51000000.pcie_ep
|
||||
|
||||
1.2 Endpoint Function Drivers
|
||||
|
||||
To find the list of endpoint function drivers in the system:
|
||||
|
||||
# ls /sys/bus/pci-epf/drivers
|
||||
pci_epf_test
|
||||
|
||||
If PCI_ENDPOINT_CONFIGFS is enabled
|
||||
# ls /sys/kernel/config/pci_ep/functions
|
||||
pci_epf_test
|
||||
|
||||
1.3 Creating pci-epf-test Device
|
||||
|
||||
PCI endpoint function device can be created using the configfs. To create
|
||||
pci-epf-test device, the following commands can be used
|
||||
|
||||
# mount -t configfs none /sys/kernel/config
|
||||
# cd /sys/kernel/config/pci_ep/
|
||||
# mkdir functions/pci_epf_test/func1
|
||||
|
||||
The "mkdir func1" above creates the pci-epf-test function device that will
|
||||
be probed by pci_epf_test driver.
|
||||
|
||||
The PCI endpoint framework populates the directory with the following
|
||||
configurable fields.
|
||||
|
||||
# ls functions/pci_epf_test/func1
|
||||
baseclass_code interrupt_pin revid subsys_vendor_id
|
||||
cache_line_size msi_interrupts subclass_code vendorid
|
||||
deviceid progif_code subsys_id
|
||||
|
||||
The PCI endpoint function driver populates these entries with default values
|
||||
when the device is bound to the driver. The pci-epf-test driver populates
|
||||
vendorid with 0xffff and interrupt_pin with 0x0001
|
||||
|
||||
# cat functions/pci_epf_test/func1/vendorid
|
||||
0xffff
|
||||
# cat functions/pci_epf_test/func1/interrupt_pin
|
||||
0x0001
|
||||
|
||||
1.4 Configuring pci-epf-test Device
|
||||
|
||||
The user can configure the pci-epf-test device using configfs entry. In order
|
||||
to change the vendorid and the number of MSI interrupts used by the function
|
||||
device, the following commands can be used.
|
||||
|
||||
# echo 0x104c > functions/pci_epf_test/func1/vendorid
|
||||
# echo 0xb500 > functions/pci_epf_test/func1/deviceid
|
||||
# echo 16 > functions/pci_epf_test/func1/msi_interrupts
|
||||
|
||||
1.5 Binding pci-epf-test Device to EP Controller
|
||||
|
||||
In order for the endpoint function device to be useful, it has to be bound to
|
||||
a PCI endpoint controller driver. Use the configfs to bind the function
|
||||
device to one of the controller driver present in the system.
|
||||
|
||||
# ln -s functions/pci_epf_test/func1 controllers/51000000.pcie_ep/
|
||||
|
||||
Once the above step is completed, the PCI endpoint is ready to establish a link
|
||||
with the host.
|
||||
|
||||
1.6 Start the Link
|
||||
|
||||
In order for the endpoint device to establish a link with the host, the _start_
|
||||
field should be populated with '1'.
|
||||
|
||||
# echo 1 > controllers/51000000.pcie_ep/start
|
||||
|
||||
2. RootComplex Device
|
||||
|
||||
2.1 lspci Output
|
||||
|
||||
Note that the devices listed here correspond to the value populated in 1.4 above
|
||||
|
||||
00:00.0 PCI bridge: Texas Instruments Device 8888 (rev 01)
|
||||
01:00.0 Unassigned class [ff00]: Texas Instruments Device b500
|
||||
|
||||
2.2 Using Endpoint Test function Device
|
||||
|
||||
pcitest.sh added in tools/pci/ can be used to run all the default PCI endpoint
|
||||
tests. Before pcitest.sh can be used pcitest.c should be compiled using the
|
||||
following commands.
|
||||
|
||||
cd <kernel-dir>
|
||||
make headers_install ARCH=arm
|
||||
arm-linux-gnueabihf-gcc -Iusr/include tools/pci/pcitest.c -o pcitest
|
||||
cp pcitest <rootfs>/usr/sbin/
|
||||
cp tools/pci/pcitest.sh <rootfs>
|
||||
|
||||
2.2.1 pcitest.sh Output
|
||||
# ./pcitest.sh
|
||||
BAR tests
|
||||
|
||||
BAR0: OKAY
|
||||
BAR1: OKAY
|
||||
BAR2: OKAY
|
||||
BAR3: OKAY
|
||||
BAR4: NOT OKAY
|
||||
BAR5: NOT OKAY
|
||||
|
||||
Interrupt tests
|
||||
|
||||
LEGACY IRQ: NOT OKAY
|
||||
MSI1: OKAY
|
||||
MSI2: OKAY
|
||||
MSI3: OKAY
|
||||
MSI4: OKAY
|
||||
MSI5: OKAY
|
||||
MSI6: OKAY
|
||||
MSI7: OKAY
|
||||
MSI8: OKAY
|
||||
MSI9: OKAY
|
||||
MSI10: OKAY
|
||||
MSI11: OKAY
|
||||
MSI12: OKAY
|
||||
MSI13: OKAY
|
||||
MSI14: OKAY
|
||||
MSI15: OKAY
|
||||
MSI16: OKAY
|
||||
MSI17: NOT OKAY
|
||||
MSI18: NOT OKAY
|
||||
MSI19: NOT OKAY
|
||||
MSI20: NOT OKAY
|
||||
MSI21: NOT OKAY
|
||||
MSI22: NOT OKAY
|
||||
MSI23: NOT OKAY
|
||||
MSI24: NOT OKAY
|
||||
MSI25: NOT OKAY
|
||||
MSI26: NOT OKAY
|
||||
MSI27: NOT OKAY
|
||||
MSI28: NOT OKAY
|
||||
MSI29: NOT OKAY
|
||||
MSI30: NOT OKAY
|
||||
MSI31: NOT OKAY
|
||||
MSI32: NOT OKAY
|
||||
|
||||
Read Tests
|
||||
|
||||
READ ( 1 bytes): OKAY
|
||||
READ ( 1024 bytes): OKAY
|
||||
READ ( 1025 bytes): OKAY
|
||||
READ (1024000 bytes): OKAY
|
||||
READ (1024001 bytes): OKAY
|
||||
|
||||
Write Tests
|
||||
|
||||
WRITE ( 1 bytes): OKAY
|
||||
WRITE ( 1024 bytes): OKAY
|
||||
WRITE ( 1025 bytes): OKAY
|
||||
WRITE (1024000 bytes): OKAY
|
||||
WRITE (1024001 bytes): OKAY
|
||||
|
||||
Copy Tests
|
||||
|
||||
COPY ( 1 bytes): OKAY
|
||||
COPY ( 1024 bytes): OKAY
|
||||
COPY ( 1025 bytes): OKAY
|
||||
COPY (1024000 bytes): OKAY
|
||||
COPY (1024001 bytes): OKAY
|
||||
@@ -68,6 +68,18 @@ To disable SR-IOV capability:
|
||||
echo 0 > \
|
||||
/sys/bus/pci/devices/<DOMAIN:BUS:DEVICE.FUNCTION>/sriov_numvfs
|
||||
|
||||
To enable auto probing VFs by a compatible driver on the host, run
|
||||
command below before enabling SR-IOV capabilities. This is the
|
||||
default behavior.
|
||||
echo 1 > \
|
||||
/sys/bus/pci/devices/<DOMAIN:BUS:DEVICE.FUNCTION>/sriov_drivers_autoprobe
|
||||
|
||||
To disable auto probing VFs by a compatible driver on the host, run
|
||||
command below before enabling SR-IOV capabilities. Updating this
|
||||
entry will not affect VFs which are already probed.
|
||||
echo 0 > \
|
||||
/sys/bus/pci/devices/<DOMAIN:BUS:DEVICE.FUNCTION>/sriov_drivers_autoprobe
|
||||
|
||||
3.2 Usage example
|
||||
|
||||
Following piece of code illustrates the usage of the SR-IOV API.
|
||||
|
||||
@@ -6,30 +6,40 @@ Required properties:
|
||||
- reg-names: Must be "config" for the PCIe configuration space.
|
||||
(The old way of getting the configuration address space from "ranges"
|
||||
is deprecated and should be avoided.)
|
||||
- num-lanes: number of lanes to use
|
||||
RC mode:
|
||||
- #address-cells: set to <3>
|
||||
- #size-cells: set to <2>
|
||||
- device_type: set to "pci"
|
||||
- ranges: ranges for the PCI memory and I/O regions
|
||||
- #interrupt-cells: set to <1>
|
||||
- interrupt-map-mask and interrupt-map: standard PCI properties
|
||||
to define the mapping of the PCIe interface to interrupt
|
||||
- interrupt-map-mask and interrupt-map: standard PCI
|
||||
properties to define the mapping of the PCIe interface to interrupt
|
||||
numbers.
|
||||
- num-lanes: number of lanes to use
|
||||
EP mode:
|
||||
- num-ib-windows: number of inbound address translation
|
||||
windows
|
||||
- num-ob-windows: number of outbound address translation
|
||||
windows
|
||||
|
||||
Optional properties:
|
||||
- num-viewport: number of view ports configured in hardware. If a platform
|
||||
does not specify it, the driver assumes 2.
|
||||
- num-lanes: number of lanes to use (this property should be specified unless
|
||||
the link is brought already up in BIOS)
|
||||
- reset-gpio: gpio pin number of power good signal
|
||||
- bus-range: PCI bus numbers covered (it is recommended for new devicetrees to
|
||||
specify this property, to keep backwards compatibility a range of 0x00-0xff
|
||||
is assumed if not present)
|
||||
- clocks: Must contain an entry for each entry in clock-names.
|
||||
See ../clocks/clock-bindings.txt for details.
|
||||
- clock-names: Must include the following entries:
|
||||
- "pcie"
|
||||
- "pcie_bus"
|
||||
RC mode:
|
||||
- num-viewport: number of view ports configured in
|
||||
hardware. If a platform does not specify it, the driver assumes 2.
|
||||
- bus-range: PCI bus numbers covered (it is recommended
|
||||
for new devicetrees to specify this property, to keep backwards
|
||||
compatibility a range of 0x00-0xff is assumed if not present)
|
||||
EP mode:
|
||||
- max-functions: maximum number of functions that can be
|
||||
configured
|
||||
|
||||
Example configuration:
|
||||
|
||||
|
||||
@@ -0,0 +1,129 @@
|
||||
Faraday Technology FTPCI100 PCI Host Bridge
|
||||
|
||||
This PCI bridge is found inside that Cortina Systems Gemini SoC platform and
|
||||
is a generic IP block from Faraday Technology. It exists in two variants:
|
||||
plain and dual PCI. The plain version embeds a cascading interrupt controller
|
||||
into the host bridge. The dual version routes the interrupts to the host
|
||||
chips interrupt controller.
|
||||
|
||||
The host controller appear on the PCI bus with vendor ID 0x159b (Faraday
|
||||
Technology) and product ID 0x4321.
|
||||
|
||||
Mandatory properties:
|
||||
|
||||
- compatible: ranging from specific to generic, should be one of
|
||||
"cortina,gemini-pci", "faraday,ftpci100"
|
||||
"cortina,gemini-pci-dual", "faraday,ftpci100-dual"
|
||||
"faraday,ftpci100"
|
||||
"faraday,ftpci100-dual"
|
||||
- reg: memory base and size for the host bridge
|
||||
- #address-cells: set to <3>
|
||||
- #size-cells: set to <2>
|
||||
- #interrupt-cells: set to <1>
|
||||
- bus-range: set to <0x00 0xff>
|
||||
- device_type, set to "pci"
|
||||
- ranges: see pci.txt
|
||||
- interrupt-map-mask: see pci.txt
|
||||
- interrupt-map: see pci.txt
|
||||
- dma-ranges: three ranges for the inbound memory region. The ranges must
|
||||
be aligned to a 1MB boundary, and may be 1MB, 2MB, 4MB, 8MB, 16MB, 32MB, 64MB,
|
||||
128MB, 256MB, 512MB, 1GB or 2GB in size. The memory should be marked as
|
||||
pre-fetchable.
|
||||
|
||||
Mandatory subnodes:
|
||||
- For "faraday,ftpci100" a node representing the interrupt-controller inside the
|
||||
host bridge is mandatory. It has the following mandatory properties:
|
||||
- interrupt: see interrupt-controller/interrupts.txt
|
||||
- interrupt-parent: see interrupt-controller/interrupts.txt
|
||||
- interrupt-controller: see interrupt-controller/interrupts.txt
|
||||
- #address-cells: set to <0>
|
||||
- #interrupt-cells: set to <1>
|
||||
|
||||
I/O space considerations:
|
||||
|
||||
The plain variant has 128MiB of non-prefetchable memory space, whereas the
|
||||
"dual" variant has 64MiB. Take this into account when describing the ranges.
|
||||
|
||||
Interrupt map considerations:
|
||||
|
||||
The "dual" variant will get INT A, B, C, D from the system interrupt controller
|
||||
and should point to respective interrupt in that controller in its
|
||||
interrupt-map.
|
||||
|
||||
The code which is the only documentation of how the Faraday PCI (the non-dual
|
||||
variant) interrupts assigns the default interrupt mapping/swizzling has
|
||||
typically been like this, doing the swizzling on the interrupt controller side
|
||||
rather than in the interconnect:
|
||||
|
||||
interrupt-map-mask = <0xf800 0 0 7>;
|
||||
interrupt-map =
|
||||
<0x4800 0 0 1 &pci_intc 0>, /* Slot 9 */
|
||||
<0x4800 0 0 2 &pci_intc 1>,
|
||||
<0x4800 0 0 3 &pci_intc 2>,
|
||||
<0x4800 0 0 4 &pci_intc 3>,
|
||||
<0x5000 0 0 1 &pci_intc 1>, /* Slot 10 */
|
||||
<0x5000 0 0 2 &pci_intc 2>,
|
||||
<0x5000 0 0 3 &pci_intc 3>,
|
||||
<0x5000 0 0 4 &pci_intc 0>,
|
||||
<0x5800 0 0 1 &pci_intc 2>, /* Slot 11 */
|
||||
<0x5800 0 0 2 &pci_intc 3>,
|
||||
<0x5800 0 0 3 &pci_intc 0>,
|
||||
<0x5800 0 0 4 &pci_intc 1>,
|
||||
<0x6000 0 0 1 &pci_intc 3>, /* Slot 12 */
|
||||
<0x6000 0 0 2 &pci_intc 0>,
|
||||
<0x6000 0 0 3 &pci_intc 1>,
|
||||
<0x6000 0 0 4 &pci_intc 2>;
|
||||
|
||||
Example:
|
||||
|
||||
pci@50000000 {
|
||||
compatible = "cortina,gemini-pci", "faraday,ftpci100";
|
||||
reg = <0x50000000 0x100>;
|
||||
interrupts = <8 IRQ_TYPE_LEVEL_HIGH>, /* PCI A */
|
||||
<26 IRQ_TYPE_LEVEL_HIGH>, /* PCI B */
|
||||
<27 IRQ_TYPE_LEVEL_HIGH>, /* PCI C */
|
||||
<28 IRQ_TYPE_LEVEL_HIGH>; /* PCI D */
|
||||
#address-cells = <3>;
|
||||
#size-cells = <2>;
|
||||
#interrupt-cells = <1>;
|
||||
|
||||
bus-range = <0x00 0xff>;
|
||||
ranges = /* 1MiB I/O space 0x50000000-0x500fffff */
|
||||
<0x01000000 0 0 0x50000000 0 0x00100000>,
|
||||
/* 128MiB non-prefetchable memory 0x58000000-0x5fffffff */
|
||||
<0x02000000 0 0x58000000 0x58000000 0 0x08000000>;
|
||||
|
||||
/* DMA ranges */
|
||||
dma-ranges =
|
||||
/* 128MiB at 0x00000000-0x07ffffff */
|
||||
<0x02000000 0 0x00000000 0x00000000 0 0x08000000>,
|
||||
/* 64MiB at 0x00000000-0x03ffffff */
|
||||
<0x02000000 0 0x00000000 0x00000000 0 0x04000000>,
|
||||
/* 64MiB at 0x00000000-0x03ffffff */
|
||||
<0x02000000 0 0x00000000 0x00000000 0 0x04000000>;
|
||||
|
||||
interrupt-map-mask = <0xf800 0 0 7>;
|
||||
interrupt-map =
|
||||
<0x4800 0 0 1 &pci_intc 0>, /* Slot 9 */
|
||||
<0x4800 0 0 2 &pci_intc 1>,
|
||||
<0x4800 0 0 3 &pci_intc 2>,
|
||||
<0x4800 0 0 4 &pci_intc 3>,
|
||||
<0x5000 0 0 1 &pci_intc 1>, /* Slot 10 */
|
||||
<0x5000 0 0 2 &pci_intc 2>,
|
||||
<0x5000 0 0 3 &pci_intc 3>,
|
||||
<0x5000 0 0 4 &pci_intc 0>,
|
||||
<0x5800 0 0 1 &pci_intc 2>, /* Slot 11 */
|
||||
<0x5800 0 0 2 &pci_intc 3>,
|
||||
<0x5800 0 0 3 &pci_intc 0>,
|
||||
<0x5800 0 0 4 &pci_intc 1>,
|
||||
<0x6000 0 0 1 &pci_intc 3>, /* Slot 12 */
|
||||
<0x6000 0 0 2 &pci_intc 0>,
|
||||
<0x6000 0 0 3 &pci_intc 0>,
|
||||
<0x6000 0 0 4 &pci_intc 0>;
|
||||
pci_intc: interrupt-controller {
|
||||
interrupt-parent = <&intcon>;
|
||||
interrupt-controller;
|
||||
#address-cells = <0>;
|
||||
#interrupt-cells = <1>;
|
||||
};
|
||||
};
|
||||
@@ -4,7 +4,11 @@ This PCIe host controller is based on the Synopsis Designware PCIe IP
|
||||
and thus inherits all the common properties defined in designware-pcie.txt.
|
||||
|
||||
Required properties:
|
||||
- compatible: "fsl,imx6q-pcie", "fsl,imx6sx-pcie", "fsl,imx6qp-pcie"
|
||||
- compatible:
|
||||
- "fsl,imx6q-pcie"
|
||||
- "fsl,imx6sx-pcie",
|
||||
- "fsl,imx6qp-pcie"
|
||||
- "fsl,imx7d-pcie"
|
||||
- reg: base address and length of the PCIe controller
|
||||
- interrupts: A list of interrupt outputs of the controller. Must contain an
|
||||
entry for each entry in the interrupt-names property.
|
||||
@@ -34,6 +38,14 @@ Additional required properties for imx6sx-pcie:
|
||||
- clock names: Must include the following additional entries:
|
||||
- "pcie_inbound_axi"
|
||||
|
||||
Additional required properties for imx7d-pcie:
|
||||
- power-domains: Must be set to a phandle pointing to PCIE_PHY power domain
|
||||
- resets: Must contain phandles to PCIe-related reset lines exposed by SRC
|
||||
IP block
|
||||
- reset-names: Must contain the following entires:
|
||||
- "pciephy"
|
||||
- "apps"
|
||||
|
||||
Example:
|
||||
|
||||
pcie@0x01000000 {
|
||||
|
||||
@@ -1,17 +1,22 @@
|
||||
TI PCI Controllers
|
||||
|
||||
PCIe Designware Controller
|
||||
- compatible: Should be "ti,dra7-pcie""
|
||||
- reg : Two register ranges as listed in the reg-names property
|
||||
- reg-names : The first entry must be "ti-conf" for the TI specific registers
|
||||
The second entry must be "rc-dbics" for the designware pcie
|
||||
registers
|
||||
The third entry must be "config" for the PCIe configuration space
|
||||
- compatible: Should be "ti,dra7-pcie" for RC
|
||||
Should be "ti,dra7-pcie-ep" for EP
|
||||
- phys : list of PHY specifiers (used by generic PHY framework)
|
||||
- phy-names : must be "pcie-phy0", "pcie-phy1", "pcie-phyN".. based on the
|
||||
number of PHYs as specified in *phys* property.
|
||||
- ti,hwmods : Name of the hwmod associated to the pcie, "pcie<X>",
|
||||
where <X> is the instance number of the pcie from the HW spec.
|
||||
- num-lanes as specified in ../designware-pcie.txt
|
||||
|
||||
HOST MODE
|
||||
=========
|
||||
- reg : Two register ranges as listed in the reg-names property
|
||||
- reg-names : The first entry must be "ti-conf" for the TI specific registers
|
||||
The second entry must be "rc-dbics" for the DesignWare PCIe
|
||||
registers
|
||||
The third entry must be "config" for the PCIe configuration space
|
||||
- interrupts : Two interrupt entries must be specified. The first one is for
|
||||
main interrupt line and the second for MSI interrupt line.
|
||||
- #address-cells,
|
||||
@@ -19,13 +24,36 @@ PCIe Designware Controller
|
||||
#interrupt-cells,
|
||||
device_type,
|
||||
ranges,
|
||||
num-lanes,
|
||||
interrupt-map-mask,
|
||||
interrupt-map : as specified in ../designware-pcie.txt
|
||||
|
||||
DEVICE MODE
|
||||
===========
|
||||
- reg : Four register ranges as listed in the reg-names property
|
||||
- reg-names : "ti-conf" for the TI specific registers
|
||||
"ep_dbics" for the standard configuration registers as
|
||||
they are locally accessed within the DIF CS space
|
||||
"ep_dbics2" for the standard configuration registers as
|
||||
they are locally accessed within the DIF CS2 space
|
||||
"addr_space" used to map remote RC address space
|
||||
- interrupts : one interrupt entries must be specified for main interrupt.
|
||||
- num-ib-windows : number of inbound address translation windows
|
||||
- num-ob-windows : number of outbound address translation windows
|
||||
- ti,syscon-unaligned-access: phandle to the syscon DT node. The 1st argument
|
||||
should contain the register offset within syscon
|
||||
and the 2nd argument should contain the bit field
|
||||
for setting the bit to enable unaligned
|
||||
access.
|
||||
|
||||
Optional Property:
|
||||
- gpios : Should be added if a gpio line is required to drive PERST# line
|
||||
|
||||
NOTE: Two DT nodes may be added for each PCI controller; one for host
|
||||
mode and another for device mode. So in order for PCI to
|
||||
work in host mode, EP mode DT node should be disabled and in order to PCI to
|
||||
work in EP mode, host mode DT node should be disabled. Host mode and EP
|
||||
mode are mutually exclusive.
|
||||
|
||||
Example:
|
||||
axi {
|
||||
compatible = "simple-bus";
|
||||
|
||||
@@ -342,8 +342,10 @@ PER-CPU MEM
|
||||
devm_free_percpu()
|
||||
|
||||
PCI
|
||||
pcim_enable_device() : after success, all PCI ops become managed
|
||||
pcim_pin_device() : keep PCI device enabled after release
|
||||
devm_pci_remap_cfgspace() : ioremap PCI configuration space
|
||||
devm_pci_remap_cfg_resource() : ioremap PCI configuration space resource
|
||||
pcim_enable_device() : after success, all PCI ops become managed
|
||||
pcim_pin_device() : keep PCI device enabled after release
|
||||
|
||||
PHY
|
||||
devm_usb_get_phy()
|
||||
|
||||
@@ -113,9 +113,18 @@ Supporting PCI access on new platforms
|
||||
--------------------------------------
|
||||
|
||||
In order to support PCI resource mapping as described above, Linux platform
|
||||
code must define HAVE_PCI_MMAP and provide a pci_mmap_page_range function.
|
||||
Platforms are free to only support subsets of the mmap functionality, but
|
||||
useful return codes should be provided.
|
||||
code should ideally define ARCH_GENERIC_PCI_MMAP_RESOURCE and use the generic
|
||||
implementation of that functionality. To support the historical interface of
|
||||
mmap() through files in /proc/bus/pci, platforms may also set HAVE_PCI_MMAP.
|
||||
|
||||
Alternatively, platforms which set HAVE_PCI_MMAP may provide their own
|
||||
implementation of pci_mmap_page_range() instead of defining
|
||||
ARCH_GENERIC_PCI_MMAP_RESOURCE.
|
||||
|
||||
Platforms which support write-combining maps of PCI resources must define
|
||||
arch_can_pci_mmap_wc() which shall evaluate to non-zero at runtime when
|
||||
write-combining is permitted. Platforms which support maps of I/O resources
|
||||
define arch_can_pci_mmap_io() similarly.
|
||||
|
||||
Legacy resources are protected by the HAVE_PCI_LEGACY define. Platforms
|
||||
wishing to support legacy functionality should define it and provide
|
||||
|
||||
@@ -191,6 +191,7 @@ Code Seq#(hex) Include File Comments
|
||||
'W' 00-1F linux/watchdog.h conflict!
|
||||
'W' 00-1F linux/wanrouter.h conflict! (pre 3.9)
|
||||
'W' 00-3F sound/asound.h conflict!
|
||||
'W' 40-5F drivers/pci/switch/switchtec.c
|
||||
'X' all fs/xfs/xfs_fs.h conflict!
|
||||
and fs/xfs/linux-2.6/xfs_ioctl32.h
|
||||
and include/linux/falloc.h
|
||||
|
||||
@@ -0,0 +1,35 @@
|
||||
Driver for PCI Endpoint Test Function
|
||||
|
||||
This driver should be used as a host side driver if the root complex is
|
||||
connected to a configurable PCI endpoint running *pci_epf_test* function
|
||||
driver configured according to [1].
|
||||
|
||||
The "pci_endpoint_test" driver can be used to perform the following tests.
|
||||
|
||||
The PCI driver for the test device performs the following tests
|
||||
*) verifying addresses programmed in BAR
|
||||
*) raise legacy IRQ
|
||||
*) raise MSI IRQ
|
||||
*) read data
|
||||
*) write data
|
||||
*) copy data
|
||||
|
||||
This misc driver creates /dev/pci-endpoint-test.<num> for every
|
||||
*pci_epf_test* function connected to the root complex and "ioctls"
|
||||
should be used to perform the above tests.
|
||||
|
||||
ioctl
|
||||
-----
|
||||
PCITEST_BAR: Tests the BAR. The number of the BAR to be tested
|
||||
should be passed as argument.
|
||||
PCITEST_LEGACY_IRQ: Tests legacy IRQ
|
||||
PCITEST_MSI: Tests message signalled interrupts. The MSI number
|
||||
to be tested should be passed as argument.
|
||||
PCITEST_WRITE: Perform write tests. The size of the buffer should be passed
|
||||
as argument.
|
||||
PCITEST_READ: Perform read tests. The size of the buffer should be passed
|
||||
as argument.
|
||||
PCITEST_COPY: Perform read tests. The size of the buffer should be passed
|
||||
as argument.
|
||||
|
||||
[1] -> Documentation/PCI/endpoint/function/binding/pci-test.txt
|
||||
@@ -0,0 +1,80 @@
|
||||
========================
|
||||
Linux Switchtec Support
|
||||
========================
|
||||
|
||||
Microsemi's "Switchtec" line of PCI switch devices is already
|
||||
supported by the kernel with standard PCI switch drivers. However, the
|
||||
Switchtec device advertises a special management endpoint which
|
||||
enables some additional functionality. This includes:
|
||||
|
||||
* Packet and Byte Counters
|
||||
* Firmware Upgrades
|
||||
* Event and Error logs
|
||||
* Querying port link status
|
||||
* Custom user firmware commands
|
||||
|
||||
The switchtec kernel module implements this functionality.
|
||||
|
||||
|
||||
Interface
|
||||
=========
|
||||
|
||||
The primary means of communicating with the Switchtec management firmware is
|
||||
through the Memory-mapped Remote Procedure Call (MRPC) interface.
|
||||
Commands are submitted to the interface with a 4-byte command
|
||||
identifier and up to 1KB of command specific data. The firmware will
|
||||
respond with a 4 bytes return code and up to 1KB of command specific
|
||||
data. The interface only processes a single command at a time.
|
||||
|
||||
|
||||
Userspace Interface
|
||||
===================
|
||||
|
||||
The MRPC interface will be exposed to userspace through a simple char
|
||||
device: /dev/switchtec#, one for each management endpoint in the system.
|
||||
|
||||
The char device has the following semantics:
|
||||
|
||||
* A write must consist of at least 4 bytes and no more than 1028 bytes.
|
||||
The first four bytes will be interpreted as the command to run and
|
||||
the remainder will be used as the input data. A write will send the
|
||||
command to the firmware to begin processing.
|
||||
|
||||
* Each write must be followed by exactly one read. Any double write will
|
||||
produce an error and any read that doesn't follow a write will
|
||||
produce an error.
|
||||
|
||||
* A read will block until the firmware completes the command and return
|
||||
the four bytes of status plus up to 1024 bytes of output data. (The
|
||||
length will be specified by the size parameter of the read call --
|
||||
reading less than 4 bytes will produce an error.
|
||||
|
||||
* The poll call will also be supported for userspace applications that
|
||||
need to do other things while waiting for the command to complete.
|
||||
|
||||
The following IOCTLs are also supported by the device:
|
||||
|
||||
* SWITCHTEC_IOCTL_FLASH_INFO - Retrieve firmware length and number
|
||||
of partitions in the device.
|
||||
|
||||
* SWITCHTEC_IOCTL_FLASH_PART_INFO - Retrieve address and lengeth for
|
||||
any specified partition in flash.
|
||||
|
||||
* SWITCHTEC_IOCTL_EVENT_SUMMARY - Read a structure of bitmaps
|
||||
indicating all uncleared events.
|
||||
|
||||
* SWITCHTEC_IOCTL_EVENT_CTL - Get the current count, clear and set flags
|
||||
for any event. This ioctl takes in a switchtec_ioctl_event_ctl struct
|
||||
with the event_id, index and flags set (index being the partition or PFF
|
||||
number for non-global events). It returns whether the event has
|
||||
occurred, the number of times and any event specific data. The flags
|
||||
can be used to clear the count or enable and disable actions to
|
||||
happen when the event occurs.
|
||||
By using the SWITCHTEC_IOCTL_EVENT_FLAG_EN_POLL flag,
|
||||
you can set an event to trigger a poll command to return with
|
||||
POLLPRI. In this way, userspace can wait for events to occur.
|
||||
|
||||
* SWITCHTEC_IOCTL_PFF_TO_PORT and SWITCHTEC_IOCTL_PORT_TO_PFF convert
|
||||
between PCI Function Framework number (used by the event system)
|
||||
and Switchtec Logic Port ID and Partition number (which is more
|
||||
user friendly).
|
||||
+20
@@ -9723,6 +9723,15 @@ F: include/linux/pci*
|
||||
F: arch/x86/pci/
|
||||
F: arch/x86/kernel/quirks.c
|
||||
|
||||
PCI ENDPOINT SUBSYSTEM
|
||||
M: Kishon Vijay Abraham I <kishon@ti.com>
|
||||
L: linux-pci@vger.kernel.org
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/kishon/pci-endpoint.git
|
||||
S: Supported
|
||||
F: drivers/pci/endpoint/
|
||||
F: drivers/misc/pci_endpoint_test.c
|
||||
F: tools/pci/
|
||||
|
||||
PCI DRIVER FOR ALTERA PCIE IP
|
||||
M: Ley Foon Tan <lftan@altera.com>
|
||||
L: rfi@lists.rocketboards.org (moderated for non-subscribers)
|
||||
@@ -9797,6 +9806,17 @@ S: Maintained
|
||||
F: Documentation/devicetree/bindings/pci/aardvark-pci.txt
|
||||
F: drivers/pci/host/pci-aardvark.c
|
||||
|
||||
PCI DRIVER FOR MICROSEMI SWITCHTEC
|
||||
M: Kurt Schwemmer <kurt.schwemmer@microsemi.com>
|
||||
M: Stephen Bates <stephen.bates@microsemi.com>
|
||||
M: Logan Gunthorpe <logang@deltatee.com>
|
||||
L: linux-pci@vger.kernel.org
|
||||
S: Maintained
|
||||
F: Documentation/switchtec.txt
|
||||
F: Documentation/ABI/testing/sysfs-class-switchtec
|
||||
F: drivers/pci/switch/switchtec*
|
||||
F: include/uapi/linux/switchtec_ioctl.h
|
||||
|
||||
PCI DRIVER FOR NVIDIA TEGRA
|
||||
M: Thierry Reding <thierry.reding@gmail.com>
|
||||
L: linux-tegra@vger.kernel.org
|
||||
|
||||
@@ -186,6 +186,16 @@ static inline void pci_ioremap_set_mem_type(int mem_type) {}
|
||||
|
||||
extern int pci_ioremap_io(unsigned int offset, phys_addr_t phys_addr);
|
||||
|
||||
/*
|
||||
* PCI configuration space mapping function.
|
||||
*
|
||||
* The PCI specification does not allow configuration write
|
||||
* transactions to be posted. Add an arch specific
|
||||
* pci_remap_cfgspace() definition that is implemented
|
||||
* through strongly ordered memory mappings.
|
||||
*/
|
||||
#define pci_remap_cfgspace pci_remap_cfgspace
|
||||
void __iomem *pci_remap_cfgspace(resource_size_t res_cookie, size_t size);
|
||||
/*
|
||||
* Now, pick up the machine-defined IO definitions
|
||||
*/
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user