2018-01-26 18:50:27 +00:00
|
|
|
// SPDX-License-Identifier: GPL-2.0
|
2015-04-08 18:21:35 +00:00
|
|
|
/*
|
|
|
|
* Copyright (C) 2014 Hauke Mehrtens <hauke@hauke-m.de>
|
2015-10-16 19:04:04 +00:00
|
|
|
* Copyright (C) 2015 Broadcom Corporation
|
2015-04-08 18:21:35 +00:00
|
|
|
*/
|
|
|
|
|
|
|
|
#include <linux/kernel.h>
|
|
|
|
#include <linux/pci.h>
|
2020-11-29 23:07:41 +00:00
|
|
|
#include <linux/pci-ecam.h>
|
2015-04-08 18:21:35 +00:00
|
|
|
#include <linux/msi.h>
|
|
|
|
#include <linux/clk.h>
|
|
|
|
#include <linux/module.h>
|
|
|
|
#include <linux/mbus.h>
|
|
|
|
#include <linux/slab.h>
|
|
|
|
#include <linux/delay.h>
|
|
|
|
#include <linux/interrupt.h>
|
2016-11-01 00:38:35 +00:00
|
|
|
#include <linux/irqchip/arm-gic-v3.h>
|
2015-04-08 18:21:35 +00:00
|
|
|
#include <linux/platform_device.h>
|
|
|
|
#include <linux/of_address.h>
|
|
|
|
#include <linux/of_pci.h>
|
|
|
|
#include <linux/of_irq.h>
|
|
|
|
#include <linux/of_platform.h>
|
|
|
|
#include <linux/phy/phy.h>
|
|
|
|
|
|
|
|
#include "pcie-iproc.h"
|
|
|
|
|
2017-09-05 17:33:33 +00:00
|
|
|
#define EP_PERST_SOURCE_SELECT_SHIFT 2
|
|
|
|
#define EP_PERST_SOURCE_SELECT BIT(EP_PERST_SOURCE_SELECT_SHIFT)
|
|
|
|
#define EP_MODE_SURVIVE_PERST_SHIFT 1
|
|
|
|
#define EP_MODE_SURVIVE_PERST BIT(EP_MODE_SURVIVE_PERST_SHIFT)
|
|
|
|
#define RC_PCIE_RST_OUTPUT_SHIFT 0
|
|
|
|
#define RC_PCIE_RST_OUTPUT BIT(RC_PCIE_RST_OUTPUT_SHIFT)
|
|
|
|
#define PAXC_RESET_MASK 0x7f
|
|
|
|
|
|
|
|
#define GIC_V3_CFG_SHIFT 0
|
|
|
|
#define GIC_V3_CFG BIT(GIC_V3_CFG_SHIFT)
|
|
|
|
|
|
|
|
#define MSI_ENABLE_CFG_SHIFT 0
|
|
|
|
#define MSI_ENABLE_CFG BIT(MSI_ENABLE_CFG_SHIFT)
|
|
|
|
|
|
|
|
#define CFG_IND_ADDR_MASK 0x00001ffc
|
|
|
|
|
|
|
|
#define CFG_ADDR_REG_NUM_MASK 0x00000ffc
|
2020-11-29 23:07:41 +00:00
|
|
|
#define CFG_ADDR_CFG_TYPE_1 1
|
2017-09-05 17:33:33 +00:00
|
|
|
|
|
|
|
#define SYS_RC_INTX_MASK 0xf
|
|
|
|
|
|
|
|
#define PCIE_PHYLINKUP_SHIFT 3
|
|
|
|
#define PCIE_PHYLINKUP BIT(PCIE_PHYLINKUP_SHIFT)
|
|
|
|
#define PCIE_DL_ACTIVE_SHIFT 2
|
|
|
|
#define PCIE_DL_ACTIVE BIT(PCIE_DL_ACTIVE_SHIFT)
|
|
|
|
|
|
|
|
#define APB_ERR_EN_SHIFT 0
|
|
|
|
#define APB_ERR_EN BIT(APB_ERR_EN_SHIFT)
|
|
|
|
|
2019-03-01 04:52:15 +00:00
|
|
|
#define CFG_RD_SUCCESS 0
|
|
|
|
#define CFG_RD_UR 1
|
|
|
|
#define CFG_RD_CRS 2
|
|
|
|
#define CFG_RD_CA 3
|
2017-09-05 17:33:33 +00:00
|
|
|
#define CFG_RETRY_STATUS 0xffff0001
|
|
|
|
#define CFG_RETRY_STATUS_TIMEOUT_US 500000 /* 500 milliseconds */
|
PCI: iproc: Work around Stingray CRS defects
Configuration Request Retry Status ("CRS") completions are a required part
of PCIe. A PCIe device may respond to config a request with a CRS
completion to indicate that it needs more time to initialize. A Root Port
that receives a CRS completion may automatically retry the request, or it
may treat the request as a failed transaction. For a failed read, it will
likely synthesize all 1's data, i.e., 0xffffffff, to complete the read to
the CPU.
CRS Software Visibility ("CRS SV") is an optional feature. Per PCIe r3.1,
sec 2.3.2, if supported and enabled, a Root Port that receives a CRS
completion for a config read of the Vendor ID will synthesize 0x0001 data
(an invalid Vendor ID) instead of retrying or failing the transaction. The
0x0001 data makes the CRS completion visible to software, so it can perform
other tasks while waiting for the device.
The iProc "Stingray" PCIe controller does not support CRS completions
correctly. From the Stingray PCIe Controller spec:
4.7.3.3. Retry Status On Configuration Cycle
Endpoints are allowed to generate retry status on configuration cycles.
In this case, the RC needs to re-issue the request. The IP does not
handle this because the number of configuration cycles needed will
probably be less than the total number of non-posted operations needed.
When a retry status is received on the User RX interface for a
configuration request that was sent on the User TX interface, it will be
indicated with a completion with the CMPL_STATUS field set to 2=CRS, and
the user will have to find the address and data values and send a new
transaction on the User TX interface. When the internal configuration
space returns a retry status during a configuration cycle (user_cscfg =
1) on the Command/Status interface, the pcie_cscrs will assert with the
pcie_csack signal to indicate the CRS status.
When the CRS Software Visibility Enable register in the Root Control
register is enabled, the IP will return the data value to 0x0001 for the
Vendor ID value and 0xffff (all 1’s) for the rest of the data in the
request for reads of offset 0 that return with CRS status. This is true
for both the User RX Interface and for the Command/Status interface.
When CRS Software Visibility is enabled, the CMPL_STATUS field of the
completion on the User RX Interface will not be 2=CRS and the pcie_cscrs
signal will not assert on the Command/Status interface.
The Stingray hardware never reissues configuration requests when it
receives CRS completions. Contrary to what sec 4.7.3.3 above says, when it
receives a CRS completion, it synthesizes 0xffff0001 data regardless of the
address of the read or the value of the CRS SV enable bit.
This is broken in two ways:
1) When CRS SV is disabled, the Root Port should never synthesize the
0x0001 value. If it receives a CRS completion, it should fail the
transaction and synthesize all 1's data.
2) When CRS SV is enabled, the Root Port should only synthesize 0x0001
data if it receives a CRS completion for a read of the Vendor ID. If it
receives a CRS completion for any other read, it should fail the
transaction and synthesize all 1's data.
This breaks pci_flr_wait(), which reads the Command register and expects to
see all 1's data if the read fails because of CRS completions. On
Stingray, it sees the incorrect 0xffff0001 data instead.
It also breaks config registers that contain the 0xffff0001 value. If we
read such a register, software can't distinguish a CRS completion from the
actual value read from the device.
On Stingray, if we read 0xffff0001 data, assume this indicates a CRS
completion and retry the read for 500ms. If we time out, return all 1's
(0xffffffff) data. Note that this corrupts registers that happen to
contain 0xffff0001.
Stingray advertises CRS SV support in its Root Capabilities register, and
the CRS SV enable bit is writable (even though the hardware ignores it).
Mask out PCI_EXP_RTCAP_CRSVIS so software doesn't try to use CRS SV.
Signed-off-by: Oza Pawandeep <oza.oza@broadcom.com>
[bhelgaas: changelog, add probe-time warning about corruption, don't
advertise CRS SV support, remove duplicate pci_generic_config_read32(),
fix alignment based on patch from Arnd Bergmann <arnd@arndb.de>]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2017-08-28 21:43:30 +00:00
|
|
|
|
2016-11-01 00:38:37 +00:00
|
|
|
/* derive the enum index of the outbound/inbound mapping registers */
|
2017-09-05 17:33:33 +00:00
|
|
|
#define MAP_REG(base_reg, index) ((base_reg) + (index) * 2)
|
2016-11-01 00:38:37 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Maximum number of outbound mapping window sizes that can be supported by any
|
|
|
|
* OARR/OMAP mapping pair
|
|
|
|
*/
|
2017-09-05 17:33:33 +00:00
|
|
|
#define MAX_NUM_OB_WINDOW_SIZES 4
|
2016-11-01 00:38:37 +00:00
|
|
|
|
2017-09-05 17:33:33 +00:00
|
|
|
#define OARR_VALID_SHIFT 0
|
|
|
|
#define OARR_VALID BIT(OARR_VALID_SHIFT)
|
|
|
|
#define OARR_SIZE_CFG_SHIFT 1
|
2015-10-16 13:18:24 +00:00
|
|
|
|
2016-11-01 00:38:39 +00:00
|
|
|
/*
|
|
|
|
* Maximum number of inbound mapping region sizes that can be supported by an
|
|
|
|
* IARR
|
|
|
|
*/
|
2017-09-05 17:33:33 +00:00
|
|
|
#define MAX_NUM_IB_REGION_SIZES 9
|
2016-11-01 00:38:39 +00:00
|
|
|
|
2017-09-05 17:33:33 +00:00
|
|
|
#define IMAP_VALID_SHIFT 0
|
|
|
|
#define IMAP_VALID BIT(IMAP_VALID_SHIFT)
|
2016-11-01 00:38:39 +00:00
|
|
|
|
2018-06-12 00:21:04 +00:00
|
|
|
#define IPROC_PCI_PM_CAP 0x48
|
|
|
|
#define IPROC_PCI_PM_CAP_MASK 0xffff
|
2017-09-05 17:27:11 +00:00
|
|
|
#define IPROC_PCI_EXP_CAP 0xac
|
2016-10-06 18:36:07 +00:00
|
|
|
|
2017-09-05 17:33:33 +00:00
|
|
|
#define IPROC_PCIE_REG_INVALID 0xffff
|
2015-12-04 17:34:59 +00:00
|
|
|
|
2016-11-01 00:38:37 +00:00
|
|
|
/**
|
2021-07-03 15:13:02 +00:00
|
|
|
* struct iproc_pcie_ob_map - iProc PCIe outbound mapping controller-specific
|
|
|
|
* parameters
|
2016-11-01 00:38:37 +00:00
|
|
|
* @window_sizes: list of supported outbound mapping window sizes in MB
|
|
|
|
* @nr_sizes: number of supported outbound mapping window sizes
|
|
|
|
*/
|
|
|
|
struct iproc_pcie_ob_map {
|
|
|
|
resource_size_t window_sizes[MAX_NUM_OB_WINDOW_SIZES];
|
|
|
|
unsigned int nr_sizes;
|
|
|
|
};
|
|
|
|
|
|
|
|
static const struct iproc_pcie_ob_map paxb_ob_map[] = {
|
|
|
|
{
|
|
|
|
/* OARR0/OMAP0 */
|
|
|
|
.window_sizes = { 128, 256 },
|
|
|
|
.nr_sizes = 2,
|
|
|
|
},
|
|
|
|
{
|
|
|
|
/* OARR1/OMAP1 */
|
|
|
|
.window_sizes = { 128, 256 },
|
|
|
|
.nr_sizes = 2,
|
|
|
|
},
|
|
|
|
};
|
|
|
|
|
2016-11-01 00:38:41 +00:00
|
|
|
static const struct iproc_pcie_ob_map paxb_v2_ob_map[] = {
|
|
|
|
{
|
|
|
|
/* OARR0/OMAP0 */
|
|
|
|
.window_sizes = { 128, 256 },
|
|
|
|
.nr_sizes = 2,
|
|
|
|
},
|
|
|
|
{
|
|
|
|
/* OARR1/OMAP1 */
|
|
|
|
.window_sizes = { 128, 256 },
|
|
|
|
.nr_sizes = 2,
|
|
|
|
},
|
|
|
|
{
|
|
|
|
/* OARR2/OMAP2 */
|
|
|
|
.window_sizes = { 128, 256, 512, 1024 },
|
|
|
|
.nr_sizes = 4,
|
|
|
|
},
|
|
|
|
{
|
|
|
|
/* OARR3/OMAP3 */
|
|
|
|
.window_sizes = { 128, 256, 512, 1024 },
|
|
|
|
.nr_sizes = 4,
|
|
|
|
},
|
|
|
|
};
|
|
|
|
|
2016-11-01 00:38:39 +00:00
|
|
|
/**
|
2021-07-03 15:13:02 +00:00
|
|
|
* enum iproc_pcie_ib_map_type - iProc PCIe inbound mapping type
|
|
|
|
* @IPROC_PCIE_IB_MAP_MEM: DDR memory
|
|
|
|
* @IPROC_PCIE_IB_MAP_IO: device I/O memory
|
|
|
|
* @IPROC_PCIE_IB_MAP_INVALID: invalid or unused
|
2016-11-01 00:38:39 +00:00
|
|
|
*/
|
|
|
|
enum iproc_pcie_ib_map_type {
|
|
|
|
IPROC_PCIE_IB_MAP_MEM = 0,
|
|
|
|
IPROC_PCIE_IB_MAP_IO,
|
|
|
|
IPROC_PCIE_IB_MAP_INVALID
|
|
|
|
};
|
|
|
|
|
|
|
|
/**
|
2021-07-03 15:13:02 +00:00
|
|
|
* struct iproc_pcie_ib_map - iProc PCIe inbound mapping controller-specific
|
|
|
|
* parameters
|
2016-11-01 00:38:39 +00:00
|
|
|
* @type: inbound mapping region type
|
|
|
|
* @size_unit: inbound mapping region size unit, could be SZ_1K, SZ_1M, or
|
|
|
|
* SZ_1G
|
|
|
|
* @region_sizes: list of supported inbound mapping region sizes in KB, MB, or
|
2019-05-30 13:05:58 +00:00
|
|
|
* GB, depending on the size unit
|
2016-11-01 00:38:39 +00:00
|
|
|
* @nr_sizes: number of supported inbound mapping region sizes
|
|
|
|
* @nr_windows: number of supported inbound mapping windows for the region
|
|
|
|
* @imap_addr_offset: register offset between the upper and lower 32-bit
|
|
|
|
* IMAP address registers
|
|
|
|
* @imap_window_offset: register offset between each IMAP window
|
|
|
|
*/
|
|
|
|
struct iproc_pcie_ib_map {
|
|
|
|
enum iproc_pcie_ib_map_type type;
|
|
|
|
unsigned int size_unit;
|
|
|
|
resource_size_t region_sizes[MAX_NUM_IB_REGION_SIZES];
|
|
|
|
unsigned int nr_sizes;
|
|
|
|
unsigned int nr_windows;
|
|
|
|
u16 imap_addr_offset;
|
|
|
|
u16 imap_window_offset;
|
|
|
|
};
|
|
|
|
|
2016-11-01 00:38:41 +00:00
|
|
|
static const struct iproc_pcie_ib_map paxb_v2_ib_map[] = {
|
|
|
|
{
|
|
|
|
/* IARR0/IMAP0 */
|
|
|
|
.type = IPROC_PCIE_IB_MAP_IO,
|
|
|
|
.size_unit = SZ_1K,
|
|
|
|
.region_sizes = { 32 },
|
|
|
|
.nr_sizes = 1,
|
|
|
|
.nr_windows = 8,
|
|
|
|
.imap_addr_offset = 0x40,
|
|
|
|
.imap_window_offset = 0x4,
|
|
|
|
},
|
|
|
|
{
|
2020-10-01 06:00:53 +00:00
|
|
|
/* IARR1/IMAP1 */
|
|
|
|
.type = IPROC_PCIE_IB_MAP_MEM,
|
|
|
|
.size_unit = SZ_1M,
|
|
|
|
.region_sizes = { 8 },
|
|
|
|
.nr_sizes = 1,
|
|
|
|
.nr_windows = 8,
|
|
|
|
.imap_addr_offset = 0x4,
|
|
|
|
.imap_window_offset = 0x8,
|
|
|
|
|
2016-11-01 00:38:41 +00:00
|
|
|
},
|
|
|
|
{
|
|
|
|
/* IARR2/IMAP2 */
|
|
|
|
.type = IPROC_PCIE_IB_MAP_MEM,
|
|
|
|
.size_unit = SZ_1M,
|
|
|
|
.region_sizes = { 64, 128, 256, 512, 1024, 2048, 4096, 8192,
|
|
|
|
16384 },
|
|
|
|
.nr_sizes = 9,
|
|
|
|
.nr_windows = 1,
|
|
|
|
.imap_addr_offset = 0x4,
|
|
|
|
.imap_window_offset = 0x8,
|
|
|
|
},
|
|
|
|
{
|
|
|
|
/* IARR3/IMAP3 */
|
|
|
|
.type = IPROC_PCIE_IB_MAP_MEM,
|
|
|
|
.size_unit = SZ_1G,
|
|
|
|
.region_sizes = { 1, 2, 4, 8, 16, 32 },
|
|
|
|
.nr_sizes = 6,
|
|
|
|
.nr_windows = 8,
|
|
|
|
.imap_addr_offset = 0x4,
|
|
|
|
.imap_window_offset = 0x8,
|
|
|
|
},
|
|
|
|
{
|
|
|
|
/* IARR4/IMAP4 */
|
|
|
|
.type = IPROC_PCIE_IB_MAP_MEM,
|
|
|
|
.size_unit = SZ_1G,
|
|
|
|
.region_sizes = { 32, 64, 128, 256, 512 },
|
|
|
|
.nr_sizes = 5,
|
|
|
|
.nr_windows = 8,
|
|
|
|
.imap_addr_offset = 0x4,
|
|
|
|
.imap_window_offset = 0x8,
|
|
|
|
},
|
|
|
|
};
|
|
|
|
|
2016-11-01 00:38:30 +00:00
|
|
|
/*
|
|
|
|
* iProc PCIe host registers
|
|
|
|
*/
|
2015-12-04 17:34:59 +00:00
|
|
|
enum iproc_pcie_reg {
|
2016-11-01 00:38:30 +00:00
|
|
|
/* clock/reset signal control */
|
2015-12-04 17:34:59 +00:00
|
|
|
IPROC_PCIE_CLK_CTRL = 0,
|
2016-11-01 00:38:30 +00:00
|
|
|
|
2016-11-01 00:38:35 +00:00
|
|
|
/*
|
|
|
|
* To allow MSI to be steered to an external MSI controller (e.g., ARM
|
|
|
|
* GICv3 ITS)
|
|
|
|
*/
|
|
|
|
IPROC_PCIE_MSI_GIC_MODE,
|
|
|
|
|
|
|
|
/*
|
|
|
|
* IPROC_PCIE_MSI_BASE_ADDR and IPROC_PCIE_MSI_WINDOW_SIZE define the
|
|
|
|
* window where the MSI posted writes are written, for the writes to be
|
|
|
|
* interpreted as MSI writes.
|
|
|
|
*/
|
|
|
|
IPROC_PCIE_MSI_BASE_ADDR,
|
|
|
|
IPROC_PCIE_MSI_WINDOW_SIZE,
|
|
|
|
|
|
|
|
/*
|
|
|
|
* To hold the address of the register where the MSI writes are
|
2021-10-06 23:38:27 +00:00
|
|
|
* programmed. When ARM GICv3 ITS is used, this should be programmed
|
2016-11-01 00:38:35 +00:00
|
|
|
* with the address of the GITS_TRANSLATER register.
|
|
|
|
*/
|
|
|
|
IPROC_PCIE_MSI_ADDR_LO,
|
|
|
|
IPROC_PCIE_MSI_ADDR_HI,
|
|
|
|
|
|
|
|
/* enable MSI */
|
|
|
|
IPROC_PCIE_MSI_EN_CFG,
|
|
|
|
|
2016-11-01 00:38:30 +00:00
|
|
|
/* allow access to root complex configuration space */
|
2015-12-04 17:34:59 +00:00
|
|
|
IPROC_PCIE_CFG_IND_ADDR,
|
|
|
|
IPROC_PCIE_CFG_IND_DATA,
|
2016-11-01 00:38:30 +00:00
|
|
|
|
|
|
|
/* allow access to device configuration space */
|
2015-12-04 17:34:59 +00:00
|
|
|
IPROC_PCIE_CFG_ADDR,
|
|
|
|
IPROC_PCIE_CFG_DATA,
|
2016-11-01 00:38:30 +00:00
|
|
|
|
|
|
|
/* enable INTx */
|
2015-12-04 17:34:59 +00:00
|
|
|
IPROC_PCIE_INTX_EN,
|
2016-11-01 00:38:30 +00:00
|
|
|
|
|
|
|
/* outbound address mapping */
|
2016-11-01 00:38:37 +00:00
|
|
|
IPROC_PCIE_OARR0,
|
|
|
|
IPROC_PCIE_OMAP0,
|
|
|
|
IPROC_PCIE_OARR1,
|
|
|
|
IPROC_PCIE_OMAP1,
|
|
|
|
IPROC_PCIE_OARR2,
|
|
|
|
IPROC_PCIE_OMAP2,
|
|
|
|
IPROC_PCIE_OARR3,
|
|
|
|
IPROC_PCIE_OMAP3,
|
2016-11-01 00:38:30 +00:00
|
|
|
|
2016-11-01 00:38:39 +00:00
|
|
|
/* inbound address mapping */
|
|
|
|
IPROC_PCIE_IARR0,
|
|
|
|
IPROC_PCIE_IMAP0,
|
|
|
|
IPROC_PCIE_IARR1,
|
|
|
|
IPROC_PCIE_IMAP1,
|
|
|
|
IPROC_PCIE_IARR2,
|
|
|
|
IPROC_PCIE_IMAP2,
|
|
|
|
IPROC_PCIE_IARR3,
|
|
|
|
IPROC_PCIE_IMAP3,
|
|
|
|
IPROC_PCIE_IARR4,
|
|
|
|
IPROC_PCIE_IMAP4,
|
|
|
|
|
2019-03-01 04:52:15 +00:00
|
|
|
/* config read status */
|
|
|
|
IPROC_PCIE_CFG_RD_STATUS,
|
|
|
|
|
2016-11-01 00:38:30 +00:00
|
|
|
/* link status */
|
2015-12-04 17:34:59 +00:00
|
|
|
IPROC_PCIE_LINK_STATUS,
|
2016-11-01 00:38:30 +00:00
|
|
|
|
2016-11-01 00:38:33 +00:00
|
|
|
/* enable APB error for unsupported requests */
|
|
|
|
IPROC_PCIE_APB_ERR_EN,
|
|
|
|
|
2016-11-01 00:38:30 +00:00
|
|
|
/* total number of core registers */
|
|
|
|
IPROC_PCIE_MAX_NUM_REG,
|
2015-12-04 17:34:59 +00:00
|
|
|
};
|
|
|
|
|
2016-11-01 00:38:32 +00:00
|
|
|
/* iProc PCIe PAXB BCMA registers */
|
2020-10-01 06:00:52 +00:00
|
|
|
static const u16 iproc_pcie_reg_paxb_bcma[IPROC_PCIE_MAX_NUM_REG] = {
|
2017-09-05 17:33:33 +00:00
|
|
|
[IPROC_PCIE_CLK_CTRL] = 0x000,
|
|
|
|
[IPROC_PCIE_CFG_IND_ADDR] = 0x120,
|
|
|
|
[IPROC_PCIE_CFG_IND_DATA] = 0x124,
|
|
|
|
[IPROC_PCIE_CFG_ADDR] = 0x1f8,
|
|
|
|
[IPROC_PCIE_CFG_DATA] = 0x1fc,
|
|
|
|
[IPROC_PCIE_INTX_EN] = 0x330,
|
|
|
|
[IPROC_PCIE_LINK_STATUS] = 0xf0c,
|
2016-11-01 00:38:32 +00:00
|
|
|
};
|
|
|
|
|
2015-12-04 17:34:59 +00:00
|
|
|
/* iProc PCIe PAXB registers */
|
2020-10-01 06:00:52 +00:00
|
|
|
static const u16 iproc_pcie_reg_paxb[IPROC_PCIE_MAX_NUM_REG] = {
|
2017-09-05 17:33:33 +00:00
|
|
|
[IPROC_PCIE_CLK_CTRL] = 0x000,
|
|
|
|
[IPROC_PCIE_CFG_IND_ADDR] = 0x120,
|
|
|
|
[IPROC_PCIE_CFG_IND_DATA] = 0x124,
|
|
|
|
[IPROC_PCIE_CFG_ADDR] = 0x1f8,
|
|
|
|
[IPROC_PCIE_CFG_DATA] = 0x1fc,
|
|
|
|
[IPROC_PCIE_INTX_EN] = 0x330,
|
|
|
|
[IPROC_PCIE_OARR0] = 0xd20,
|
|
|
|
[IPROC_PCIE_OMAP0] = 0xd40,
|
|
|
|
[IPROC_PCIE_OARR1] = 0xd28,
|
|
|
|
[IPROC_PCIE_OMAP1] = 0xd48,
|
|
|
|
[IPROC_PCIE_LINK_STATUS] = 0xf0c,
|
|
|
|
[IPROC_PCIE_APB_ERR_EN] = 0xf40,
|
2015-12-04 17:34:59 +00:00
|
|
|
};
|
|
|
|
|
2016-11-01 00:38:41 +00:00
|
|
|
/* iProc PCIe PAXB v2 registers */
|
2020-10-01 06:00:52 +00:00
|
|
|
static const u16 iproc_pcie_reg_paxb_v2[IPROC_PCIE_MAX_NUM_REG] = {
|
2017-09-05 17:33:33 +00:00
|
|
|
[IPROC_PCIE_CLK_CTRL] = 0x000,
|
|
|
|
[IPROC_PCIE_CFG_IND_ADDR] = 0x120,
|
|
|
|
[IPROC_PCIE_CFG_IND_DATA] = 0x124,
|
|
|
|
[IPROC_PCIE_CFG_ADDR] = 0x1f8,
|
|
|
|
[IPROC_PCIE_CFG_DATA] = 0x1fc,
|
|
|
|
[IPROC_PCIE_INTX_EN] = 0x330,
|
|
|
|
[IPROC_PCIE_OARR0] = 0xd20,
|
|
|
|
[IPROC_PCIE_OMAP0] = 0xd40,
|
|
|
|
[IPROC_PCIE_OARR1] = 0xd28,
|
|
|
|
[IPROC_PCIE_OMAP1] = 0xd48,
|
|
|
|
[IPROC_PCIE_OARR2] = 0xd60,
|
|
|
|
[IPROC_PCIE_OMAP2] = 0xd68,
|
|
|
|
[IPROC_PCIE_OARR3] = 0xdf0,
|
|
|
|
[IPROC_PCIE_OMAP3] = 0xdf8,
|
|
|
|
[IPROC_PCIE_IARR0] = 0xd00,
|
|
|
|
[IPROC_PCIE_IMAP0] = 0xc00,
|
2020-10-01 06:00:53 +00:00
|
|
|
[IPROC_PCIE_IARR1] = 0xd08,
|
|
|
|
[IPROC_PCIE_IMAP1] = 0xd70,
|
2017-09-05 17:33:33 +00:00
|
|
|
[IPROC_PCIE_IARR2] = 0xd10,
|
|
|
|
[IPROC_PCIE_IMAP2] = 0xcc0,
|
|
|
|
[IPROC_PCIE_IARR3] = 0xe00,
|
|
|
|
[IPROC_PCIE_IMAP3] = 0xe08,
|
|
|
|
[IPROC_PCIE_IARR4] = 0xe68,
|
|
|
|
[IPROC_PCIE_IMAP4] = 0xe70,
|
2019-03-01 04:52:15 +00:00
|
|
|
[IPROC_PCIE_CFG_RD_STATUS] = 0xee0,
|
2017-09-05 17:33:33 +00:00
|
|
|
[IPROC_PCIE_LINK_STATUS] = 0xf0c,
|
|
|
|
[IPROC_PCIE_APB_ERR_EN] = 0xf40,
|
2016-11-01 00:38:41 +00:00
|
|
|
};
|
|
|
|
|
2015-12-04 17:34:59 +00:00
|
|
|
/* iProc PCIe PAXC v1 registers */
|
2020-10-01 06:00:52 +00:00
|
|
|
static const u16 iproc_pcie_reg_paxc[IPROC_PCIE_MAX_NUM_REG] = {
|
2017-09-05 17:33:33 +00:00
|
|
|
[IPROC_PCIE_CLK_CTRL] = 0x000,
|
|
|
|
[IPROC_PCIE_CFG_IND_ADDR] = 0x1f0,
|
|
|
|
[IPROC_PCIE_CFG_IND_DATA] = 0x1f4,
|
|
|
|
[IPROC_PCIE_CFG_ADDR] = 0x1f8,
|
|
|
|
[IPROC_PCIE_CFG_DATA] = 0x1fc,
|
2015-12-04 17:34:59 +00:00
|
|
|
};
|
2015-10-16 13:18:24 +00:00
|
|
|
|
2016-11-01 00:38:35 +00:00
|
|
|
/* iProc PCIe PAXC v2 registers */
|
2020-10-01 06:00:52 +00:00
|
|
|
static const u16 iproc_pcie_reg_paxc_v2[IPROC_PCIE_MAX_NUM_REG] = {
|
2017-09-05 17:33:33 +00:00
|
|
|
[IPROC_PCIE_MSI_GIC_MODE] = 0x050,
|
|
|
|
[IPROC_PCIE_MSI_BASE_ADDR] = 0x074,
|
|
|
|
[IPROC_PCIE_MSI_WINDOW_SIZE] = 0x078,
|
|
|
|
[IPROC_PCIE_MSI_ADDR_LO] = 0x07c,
|
|
|
|
[IPROC_PCIE_MSI_ADDR_HI] = 0x080,
|
|
|
|
[IPROC_PCIE_MSI_EN_CFG] = 0x09c,
|
|
|
|
[IPROC_PCIE_CFG_IND_ADDR] = 0x1f0,
|
|
|
|
[IPROC_PCIE_CFG_IND_DATA] = 0x1f4,
|
|
|
|
[IPROC_PCIE_CFG_ADDR] = 0x1f8,
|
|
|
|
[IPROC_PCIE_CFG_DATA] = 0x1fc,
|
2016-11-01 00:38:35 +00:00
|
|
|
};
|
|
|
|
|
2018-06-12 00:21:04 +00:00
|
|
|
/*
|
|
|
|
* List of device IDs of controllers that have corrupted capability list that
|
|
|
|
* require SW fixup
|
|
|
|
*/
|
|
|
|
static const u16 iproc_pcie_corrupt_cap_did[] = {
|
|
|
|
0x16cd,
|
|
|
|
0x16f0,
|
|
|
|
0xd802,
|
|
|
|
0xd804
|
|
|
|
};
|
|
|
|
|
2015-07-22 01:29:40 +00:00
|
|
|
static inline struct iproc_pcie *iproc_data(struct pci_bus *bus)
|
2015-04-08 18:21:35 +00:00
|
|
|
{
|
2018-03-07 15:42:36 +00:00
|
|
|
struct iproc_pcie *pcie = bus->sysdata;
|
2015-07-22 01:29:40 +00:00
|
|
|
return pcie;
|
2015-04-08 18:21:35 +00:00
|
|
|
}
|
|
|
|
|
2015-12-04 17:34:59 +00:00
|
|
|
static inline bool iproc_pcie_reg_is_invalid(u16 reg_offset)
|
|
|
|
{
|
|
|
|
return !!(reg_offset == IPROC_PCIE_REG_INVALID);
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline u16 iproc_pcie_reg_offset(struct iproc_pcie *pcie,
|
|
|
|
enum iproc_pcie_reg reg)
|
|
|
|
{
|
|
|
|
return pcie->reg_offsets[reg];
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline u32 iproc_pcie_read_reg(struct iproc_pcie *pcie,
|
|
|
|
enum iproc_pcie_reg reg)
|
|
|
|
{
|
|
|
|
u16 offset = iproc_pcie_reg_offset(pcie, reg);
|
|
|
|
|
|
|
|
if (iproc_pcie_reg_is_invalid(offset))
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
return readl(pcie->base + offset);
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline void iproc_pcie_write_reg(struct iproc_pcie *pcie,
|
|
|
|
enum iproc_pcie_reg reg, u32 val)
|
|
|
|
{
|
|
|
|
u16 offset = iproc_pcie_reg_offset(pcie, reg);
|
|
|
|
|
|
|
|
if (iproc_pcie_reg_is_invalid(offset))
|
|
|
|
return;
|
|
|
|
|
|
|
|
writel(val, pcie->base + offset);
|
|
|
|
}
|
|
|
|
|
2021-07-03 15:13:02 +00:00
|
|
|
/*
|
2016-11-01 00:38:33 +00:00
|
|
|
* APB error forwarding can be disabled during access of configuration
|
|
|
|
* registers of the endpoint device, to prevent unsupported requests
|
|
|
|
* (typically seen during enumeration with multi-function devices) from
|
|
|
|
* triggering a system exception.
|
|
|
|
*/
|
|
|
|
static inline void iproc_pcie_apb_err_disable(struct pci_bus *bus,
|
|
|
|
bool disable)
|
|
|
|
{
|
|
|
|
struct iproc_pcie *pcie = iproc_data(bus);
|
|
|
|
u32 val;
|
|
|
|
|
|
|
|
if (bus->number && pcie->has_apb_err_disable) {
|
|
|
|
val = iproc_pcie_read_reg(pcie, IPROC_PCIE_APB_ERR_EN);
|
|
|
|
if (disable)
|
|
|
|
val &= ~APB_ERR_EN;
|
|
|
|
else
|
|
|
|
val |= APB_ERR_EN;
|
|
|
|
iproc_pcie_write_reg(pcie, IPROC_PCIE_APB_ERR_EN, val);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-08-28 21:43:24 +00:00
|
|
|
static void __iomem *iproc_pcie_map_ep_cfg_reg(struct iproc_pcie *pcie,
|
|
|
|
unsigned int busno,
|
2020-11-29 23:07:41 +00:00
|
|
|
unsigned int devfn,
|
2017-08-28 21:43:24 +00:00
|
|
|
int where)
|
|
|
|
{
|
|
|
|
u16 offset;
|
|
|
|
u32 val;
|
|
|
|
|
|
|
|
/* EP device access */
|
2020-11-29 23:07:41 +00:00
|
|
|
val = ALIGN_DOWN(PCIE_ECAM_OFFSET(busno, devfn, where), 4) |
|
|
|
|
CFG_ADDR_CFG_TYPE_1;
|
2017-08-28 21:43:24 +00:00
|
|
|
|
|
|
|
iproc_pcie_write_reg(pcie, IPROC_PCIE_CFG_ADDR, val);
|
|
|
|
offset = iproc_pcie_reg_offset(pcie, IPROC_PCIE_CFG_DATA);
|
|
|
|
|
|
|
|
if (iproc_pcie_reg_is_invalid(offset))
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
return (pcie->base + offset);
|
|
|
|
}
|
|
|
|
|
2019-03-01 04:52:15 +00:00
|
|
|
static unsigned int iproc_pcie_cfg_retry(struct iproc_pcie *pcie,
|
|
|
|
void __iomem *cfg_data_p)
|
PCI: iproc: Work around Stingray CRS defects
Configuration Request Retry Status ("CRS") completions are a required part
of PCIe. A PCIe device may respond to config a request with a CRS
completion to indicate that it needs more time to initialize. A Root Port
that receives a CRS completion may automatically retry the request, or it
may treat the request as a failed transaction. For a failed read, it will
likely synthesize all 1's data, i.e., 0xffffffff, to complete the read to
the CPU.
CRS Software Visibility ("CRS SV") is an optional feature. Per PCIe r3.1,
sec 2.3.2, if supported and enabled, a Root Port that receives a CRS
completion for a config read of the Vendor ID will synthesize 0x0001 data
(an invalid Vendor ID) instead of retrying or failing the transaction. The
0x0001 data makes the CRS completion visible to software, so it can perform
other tasks while waiting for the device.
The iProc "Stingray" PCIe controller does not support CRS completions
correctly. From the Stingray PCIe Controller spec:
4.7.3.3. Retry Status On Configuration Cycle
Endpoints are allowed to generate retry status on configuration cycles.
In this case, the RC needs to re-issue the request. The IP does not
handle this because the number of configuration cycles needed will
probably be less than the total number of non-posted operations needed.
When a retry status is received on the User RX interface for a
configuration request that was sent on the User TX interface, it will be
indicated with a completion with the CMPL_STATUS field set to 2=CRS, and
the user will have to find the address and data values and send a new
transaction on the User TX interface. When the internal configuration
space returns a retry status during a configuration cycle (user_cscfg =
1) on the Command/Status interface, the pcie_cscrs will assert with the
pcie_csack signal to indicate the CRS status.
When the CRS Software Visibility Enable register in the Root Control
register is enabled, the IP will return the data value to 0x0001 for the
Vendor ID value and 0xffff (all 1’s) for the rest of the data in the
request for reads of offset 0 that return with CRS status. This is true
for both the User RX Interface and for the Command/Status interface.
When CRS Software Visibility is enabled, the CMPL_STATUS field of the
completion on the User RX Interface will not be 2=CRS and the pcie_cscrs
signal will not assert on the Command/Status interface.
The Stingray hardware never reissues configuration requests when it
receives CRS completions. Contrary to what sec 4.7.3.3 above says, when it
receives a CRS completion, it synthesizes 0xffff0001 data regardless of the
address of the read or the value of the CRS SV enable bit.
This is broken in two ways:
1) When CRS SV is disabled, the Root Port should never synthesize the
0x0001 value. If it receives a CRS completion, it should fail the
transaction and synthesize all 1's data.
2) When CRS SV is enabled, the Root Port should only synthesize 0x0001
data if it receives a CRS completion for a read of the Vendor ID. If it
receives a CRS completion for any other read, it should fail the
transaction and synthesize all 1's data.
This breaks pci_flr_wait(), which reads the Command register and expects to
see all 1's data if the read fails because of CRS completions. On
Stingray, it sees the incorrect 0xffff0001 data instead.
It also breaks config registers that contain the 0xffff0001 value. If we
read such a register, software can't distinguish a CRS completion from the
actual value read from the device.
On Stingray, if we read 0xffff0001 data, assume this indicates a CRS
completion and retry the read for 500ms. If we time out, return all 1's
(0xffffffff) data. Note that this corrupts registers that happen to
contain 0xffff0001.
Stingray advertises CRS SV support in its Root Capabilities register, and
the CRS SV enable bit is writable (even though the hardware ignores it).
Mask out PCI_EXP_RTCAP_CRSVIS so software doesn't try to use CRS SV.
Signed-off-by: Oza Pawandeep <oza.oza@broadcom.com>
[bhelgaas: changelog, add probe-time warning about corruption, don't
advertise CRS SV support, remove duplicate pci_generic_config_read32(),
fix alignment based on patch from Arnd Bergmann <arnd@arndb.de>]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2017-08-28 21:43:30 +00:00
|
|
|
{
|
|
|
|
int timeout = CFG_RETRY_STATUS_TIMEOUT_US;
|
|
|
|
unsigned int data;
|
2019-03-01 04:52:15 +00:00
|
|
|
u32 status;
|
PCI: iproc: Work around Stingray CRS defects
Configuration Request Retry Status ("CRS") completions are a required part
of PCIe. A PCIe device may respond to config a request with a CRS
completion to indicate that it needs more time to initialize. A Root Port
that receives a CRS completion may automatically retry the request, or it
may treat the request as a failed transaction. For a failed read, it will
likely synthesize all 1's data, i.e., 0xffffffff, to complete the read to
the CPU.
CRS Software Visibility ("CRS SV") is an optional feature. Per PCIe r3.1,
sec 2.3.2, if supported and enabled, a Root Port that receives a CRS
completion for a config read of the Vendor ID will synthesize 0x0001 data
(an invalid Vendor ID) instead of retrying or failing the transaction. The
0x0001 data makes the CRS completion visible to software, so it can perform
other tasks while waiting for the device.
The iProc "Stingray" PCIe controller does not support CRS completions
correctly. From the Stingray PCIe Controller spec:
4.7.3.3. Retry Status On Configuration Cycle
Endpoints are allowed to generate retry status on configuration cycles.
In this case, the RC needs to re-issue the request. The IP does not
handle this because the number of configuration cycles needed will
probably be less than the total number of non-posted operations needed.
When a retry status is received on the User RX interface for a
configuration request that was sent on the User TX interface, it will be
indicated with a completion with the CMPL_STATUS field set to 2=CRS, and
the user will have to find the address and data values and send a new
transaction on the User TX interface. When the internal configuration
space returns a retry status during a configuration cycle (user_cscfg =
1) on the Command/Status interface, the pcie_cscrs will assert with the
pcie_csack signal to indicate the CRS status.
When the CRS Software Visibility Enable register in the Root Control
register is enabled, the IP will return the data value to 0x0001 for the
Vendor ID value and 0xffff (all 1’s) for the rest of the data in the
request for reads of offset 0 that return with CRS status. This is true
for both the User RX Interface and for the Command/Status interface.
When CRS Software Visibility is enabled, the CMPL_STATUS field of the
completion on the User RX Interface will not be 2=CRS and the pcie_cscrs
signal will not assert on the Command/Status interface.
The Stingray hardware never reissues configuration requests when it
receives CRS completions. Contrary to what sec 4.7.3.3 above says, when it
receives a CRS completion, it synthesizes 0xffff0001 data regardless of the
address of the read or the value of the CRS SV enable bit.
This is broken in two ways:
1) When CRS SV is disabled, the Root Port should never synthesize the
0x0001 value. If it receives a CRS completion, it should fail the
transaction and synthesize all 1's data.
2) When CRS SV is enabled, the Root Port should only synthesize 0x0001
data if it receives a CRS completion for a read of the Vendor ID. If it
receives a CRS completion for any other read, it should fail the
transaction and synthesize all 1's data.
This breaks pci_flr_wait(), which reads the Command register and expects to
see all 1's data if the read fails because of CRS completions. On
Stingray, it sees the incorrect 0xffff0001 data instead.
It also breaks config registers that contain the 0xffff0001 value. If we
read such a register, software can't distinguish a CRS completion from the
actual value read from the device.
On Stingray, if we read 0xffff0001 data, assume this indicates a CRS
completion and retry the read for 500ms. If we time out, return all 1's
(0xffffffff) data. Note that this corrupts registers that happen to
contain 0xffff0001.
Stingray advertises CRS SV support in its Root Capabilities register, and
the CRS SV enable bit is writable (even though the hardware ignores it).
Mask out PCI_EXP_RTCAP_CRSVIS so software doesn't try to use CRS SV.
Signed-off-by: Oza Pawandeep <oza.oza@broadcom.com>
[bhelgaas: changelog, add probe-time warning about corruption, don't
advertise CRS SV support, remove duplicate pci_generic_config_read32(),
fix alignment based on patch from Arnd Bergmann <arnd@arndb.de>]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2017-08-28 21:43:30 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* As per PCIe spec r3.1, sec 2.3.2, CRS Software Visibility only
|
|
|
|
* affects config reads of the Vendor ID. For config writes or any
|
|
|
|
* other config reads, the Root may automatically reissue the
|
|
|
|
* configuration request again as a new request.
|
|
|
|
*
|
|
|
|
* For config reads, this hardware returns CFG_RETRY_STATUS data
|
|
|
|
* when it receives a CRS completion, regardless of the address of
|
|
|
|
* the read or the CRS Software Visibility Enable bit. As a
|
|
|
|
* partial workaround for this, we retry in software any read that
|
|
|
|
* returns CFG_RETRY_STATUS.
|
|
|
|
*
|
|
|
|
* Note that a non-Vendor ID config register may have a value of
|
|
|
|
* CFG_RETRY_STATUS. If we read that, we can't distinguish it from
|
|
|
|
* a CRS completion, so we will incorrectly retry the read and
|
|
|
|
* eventually return the wrong data (0xffffffff).
|
|
|
|
*/
|
|
|
|
data = readl(cfg_data_p);
|
|
|
|
while (data == CFG_RETRY_STATUS && timeout--) {
|
2019-03-01 04:52:15 +00:00
|
|
|
/*
|
|
|
|
* CRS state is set in CFG_RD status register
|
|
|
|
* This will handle the case where CFG_RETRY_STATUS is
|
|
|
|
* valid config data.
|
|
|
|
*/
|
|
|
|
status = iproc_pcie_read_reg(pcie, IPROC_PCIE_CFG_RD_STATUS);
|
|
|
|
if (status != CFG_RD_CRS)
|
|
|
|
return data;
|
|
|
|
|
PCI: iproc: Work around Stingray CRS defects
Configuration Request Retry Status ("CRS") completions are a required part
of PCIe. A PCIe device may respond to config a request with a CRS
completion to indicate that it needs more time to initialize. A Root Port
that receives a CRS completion may automatically retry the request, or it
may treat the request as a failed transaction. For a failed read, it will
likely synthesize all 1's data, i.e., 0xffffffff, to complete the read to
the CPU.
CRS Software Visibility ("CRS SV") is an optional feature. Per PCIe r3.1,
sec 2.3.2, if supported and enabled, a Root Port that receives a CRS
completion for a config read of the Vendor ID will synthesize 0x0001 data
(an invalid Vendor ID) instead of retrying or failing the transaction. The
0x0001 data makes the CRS completion visible to software, so it can perform
other tasks while waiting for the device.
The iProc "Stingray" PCIe controller does not support CRS completions
correctly. From the Stingray PCIe Controller spec:
4.7.3.3. Retry Status On Configuration Cycle
Endpoints are allowed to generate retry status on configuration cycles.
In this case, the RC needs to re-issue the request. The IP does not
handle this because the number of configuration cycles needed will
probably be less than the total number of non-posted operations needed.
When a retry status is received on the User RX interface for a
configuration request that was sent on the User TX interface, it will be
indicated with a completion with the CMPL_STATUS field set to 2=CRS, and
the user will have to find the address and data values and send a new
transaction on the User TX interface. When the internal configuration
space returns a retry status during a configuration cycle (user_cscfg =
1) on the Command/Status interface, the pcie_cscrs will assert with the
pcie_csack signal to indicate the CRS status.
When the CRS Software Visibility Enable register in the Root Control
register is enabled, the IP will return the data value to 0x0001 for the
Vendor ID value and 0xffff (all 1’s) for the rest of the data in the
request for reads of offset 0 that return with CRS status. This is true
for both the User RX Interface and for the Command/Status interface.
When CRS Software Visibility is enabled, the CMPL_STATUS field of the
completion on the User RX Interface will not be 2=CRS and the pcie_cscrs
signal will not assert on the Command/Status interface.
The Stingray hardware never reissues configuration requests when it
receives CRS completions. Contrary to what sec 4.7.3.3 above says, when it
receives a CRS completion, it synthesizes 0xffff0001 data regardless of the
address of the read or the value of the CRS SV enable bit.
This is broken in two ways:
1) When CRS SV is disabled, the Root Port should never synthesize the
0x0001 value. If it receives a CRS completion, it should fail the
transaction and synthesize all 1's data.
2) When CRS SV is enabled, the Root Port should only synthesize 0x0001
data if it receives a CRS completion for a read of the Vendor ID. If it
receives a CRS completion for any other read, it should fail the
transaction and synthesize all 1's data.
This breaks pci_flr_wait(), which reads the Command register and expects to
see all 1's data if the read fails because of CRS completions. On
Stingray, it sees the incorrect 0xffff0001 data instead.
It also breaks config registers that contain the 0xffff0001 value. If we
read such a register, software can't distinguish a CRS completion from the
actual value read from the device.
On Stingray, if we read 0xffff0001 data, assume this indicates a CRS
completion and retry the read for 500ms. If we time out, return all 1's
(0xffffffff) data. Note that this corrupts registers that happen to
contain 0xffff0001.
Stingray advertises CRS SV support in its Root Capabilities register, and
the CRS SV enable bit is writable (even though the hardware ignores it).
Mask out PCI_EXP_RTCAP_CRSVIS so software doesn't try to use CRS SV.
Signed-off-by: Oza Pawandeep <oza.oza@broadcom.com>
[bhelgaas: changelog, add probe-time warning about corruption, don't
advertise CRS SV support, remove duplicate pci_generic_config_read32(),
fix alignment based on patch from Arnd Bergmann <arnd@arndb.de>]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2017-08-28 21:43:30 +00:00
|
|
|
udelay(1);
|
|
|
|
data = readl(cfg_data_p);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (data == CFG_RETRY_STATUS)
|
|
|
|
data = 0xffffffff;
|
|
|
|
|
|
|
|
return data;
|
|
|
|
}
|
|
|
|
|
2018-06-12 00:21:04 +00:00
|
|
|
static void iproc_pcie_fix_cap(struct iproc_pcie *pcie, int where, u32 *val)
|
|
|
|
{
|
|
|
|
u32 i, dev_id;
|
|
|
|
|
|
|
|
switch (where & ~0x3) {
|
|
|
|
case PCI_VENDOR_ID:
|
|
|
|
dev_id = *val >> 16;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Activate fixup for those controllers that have corrupted
|
|
|
|
* capability list registers
|
|
|
|
*/
|
|
|
|
for (i = 0; i < ARRAY_SIZE(iproc_pcie_corrupt_cap_did); i++)
|
|
|
|
if (dev_id == iproc_pcie_corrupt_cap_did[i])
|
|
|
|
pcie->fix_paxc_cap = true;
|
|
|
|
break;
|
|
|
|
|
|
|
|
case IPROC_PCI_PM_CAP:
|
|
|
|
if (pcie->fix_paxc_cap) {
|
|
|
|
/* advertise PM, force next capability to PCIe */
|
|
|
|
*val &= ~IPROC_PCI_PM_CAP_MASK;
|
|
|
|
*val |= IPROC_PCI_EXP_CAP << 8 | PCI_CAP_ID_PM;
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
|
|
|
|
case IPROC_PCI_EXP_CAP:
|
|
|
|
if (pcie->fix_paxc_cap) {
|
|
|
|
/* advertise root port, version 2, terminate here */
|
|
|
|
*val = (PCI_EXP_TYPE_ROOT_PORT << 4 | 2) << 16 |
|
|
|
|
PCI_CAP_ID_EXP;
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
|
|
|
|
case IPROC_PCI_EXP_CAP + PCI_EXP_RTCTL:
|
|
|
|
/* Don't advertise CRS SV support */
|
|
|
|
*val &= ~(PCI_EXP_RTCAP_CRSVIS << 16);
|
|
|
|
break;
|
|
|
|
|
|
|
|
default:
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
PCI: iproc: Work around Stingray CRS defects
Configuration Request Retry Status ("CRS") completions are a required part
of PCIe. A PCIe device may respond to config a request with a CRS
completion to indicate that it needs more time to initialize. A Root Port
that receives a CRS completion may automatically retry the request, or it
may treat the request as a failed transaction. For a failed read, it will
likely synthesize all 1's data, i.e., 0xffffffff, to complete the read to
the CPU.
CRS Software Visibility ("CRS SV") is an optional feature. Per PCIe r3.1,
sec 2.3.2, if supported and enabled, a Root Port that receives a CRS
completion for a config read of the Vendor ID will synthesize 0x0001 data
(an invalid Vendor ID) instead of retrying or failing the transaction. The
0x0001 data makes the CRS completion visible to software, so it can perform
other tasks while waiting for the device.
The iProc "Stingray" PCIe controller does not support CRS completions
correctly. From the Stingray PCIe Controller spec:
4.7.3.3. Retry Status On Configuration Cycle
Endpoints are allowed to generate retry status on configuration cycles.
In this case, the RC needs to re-issue the request. The IP does not
handle this because the number of configuration cycles needed will
probably be less than the total number of non-posted operations needed.
When a retry status is received on the User RX interface for a
configuration request that was sent on the User TX interface, it will be
indicated with a completion with the CMPL_STATUS field set to 2=CRS, and
the user will have to find the address and data values and send a new
transaction on the User TX interface. When the internal configuration
space returns a retry status during a configuration cycle (user_cscfg =
1) on the Command/Status interface, the pcie_cscrs will assert with the
pcie_csack signal to indicate the CRS status.
When the CRS Software Visibility Enable register in the Root Control
register is enabled, the IP will return the data value to 0x0001 for the
Vendor ID value and 0xffff (all 1’s) for the rest of the data in the
request for reads of offset 0 that return with CRS status. This is true
for both the User RX Interface and for the Command/Status interface.
When CRS Software Visibility is enabled, the CMPL_STATUS field of the
completion on the User RX Interface will not be 2=CRS and the pcie_cscrs
signal will not assert on the Command/Status interface.
The Stingray hardware never reissues configuration requests when it
receives CRS completions. Contrary to what sec 4.7.3.3 above says, when it
receives a CRS completion, it synthesizes 0xffff0001 data regardless of the
address of the read or the value of the CRS SV enable bit.
This is broken in two ways:
1) When CRS SV is disabled, the Root Port should never synthesize the
0x0001 value. If it receives a CRS completion, it should fail the
transaction and synthesize all 1's data.
2) When CRS SV is enabled, the Root Port should only synthesize 0x0001
data if it receives a CRS completion for a read of the Vendor ID. If it
receives a CRS completion for any other read, it should fail the
transaction and synthesize all 1's data.
This breaks pci_flr_wait(), which reads the Command register and expects to
see all 1's data if the read fails because of CRS completions. On
Stingray, it sees the incorrect 0xffff0001 data instead.
It also breaks config registers that contain the 0xffff0001 value. If we
read such a register, software can't distinguish a CRS completion from the
actual value read from the device.
On Stingray, if we read 0xffff0001 data, assume this indicates a CRS
completion and retry the read for 500ms. If we time out, return all 1's
(0xffffffff) data. Note that this corrupts registers that happen to
contain 0xffff0001.
Stingray advertises CRS SV support in its Root Capabilities register, and
the CRS SV enable bit is writable (even though the hardware ignores it).
Mask out PCI_EXP_RTCAP_CRSVIS so software doesn't try to use CRS SV.
Signed-off-by: Oza Pawandeep <oza.oza@broadcom.com>
[bhelgaas: changelog, add probe-time warning about corruption, don't
advertise CRS SV support, remove duplicate pci_generic_config_read32(),
fix alignment based on patch from Arnd Bergmann <arnd@arndb.de>]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2017-08-28 21:43:30 +00:00
|
|
|
static int iproc_pcie_config_read(struct pci_bus *bus, unsigned int devfn,
|
2017-09-05 17:33:33 +00:00
|
|
|
int where, int size, u32 *val)
|
PCI: iproc: Work around Stingray CRS defects
Configuration Request Retry Status ("CRS") completions are a required part
of PCIe. A PCIe device may respond to config a request with a CRS
completion to indicate that it needs more time to initialize. A Root Port
that receives a CRS completion may automatically retry the request, or it
may treat the request as a failed transaction. For a failed read, it will
likely synthesize all 1's data, i.e., 0xffffffff, to complete the read to
the CPU.
CRS Software Visibility ("CRS SV") is an optional feature. Per PCIe r3.1,
sec 2.3.2, if supported and enabled, a Root Port that receives a CRS
completion for a config read of the Vendor ID will synthesize 0x0001 data
(an invalid Vendor ID) instead of retrying or failing the transaction. The
0x0001 data makes the CRS completion visible to software, so it can perform
other tasks while waiting for the device.
The iProc "Stingray" PCIe controller does not support CRS completions
correctly. From the Stingray PCIe Controller spec:
4.7.3.3. Retry Status On Configuration Cycle
Endpoints are allowed to generate retry status on configuration cycles.
In this case, the RC needs to re-issue the request. The IP does not
handle this because the number of configuration cycles needed will
probably be less than the total number of non-posted operations needed.
When a retry status is received on the User RX interface for a
configuration request that was sent on the User TX interface, it will be
indicated with a completion with the CMPL_STATUS field set to 2=CRS, and
the user will have to find the address and data values and send a new
transaction on the User TX interface. When the internal configuration
space returns a retry status during a configuration cycle (user_cscfg =
1) on the Command/Status interface, the pcie_cscrs will assert with the
pcie_csack signal to indicate the CRS status.
When the CRS Software Visibility Enable register in the Root Control
register is enabled, the IP will return the data value to 0x0001 for the
Vendor ID value and 0xffff (all 1’s) for the rest of the data in the
request for reads of offset 0 that return with CRS status. This is true
for both the User RX Interface and for the Command/Status interface.
When CRS Software Visibility is enabled, the CMPL_STATUS field of the
completion on the User RX Interface will not be 2=CRS and the pcie_cscrs
signal will not assert on the Command/Status interface.
The Stingray hardware never reissues configuration requests when it
receives CRS completions. Contrary to what sec 4.7.3.3 above says, when it
receives a CRS completion, it synthesizes 0xffff0001 data regardless of the
address of the read or the value of the CRS SV enable bit.
This is broken in two ways:
1) When CRS SV is disabled, the Root Port should never synthesize the
0x0001 value. If it receives a CRS completion, it should fail the
transaction and synthesize all 1's data.
2) When CRS SV is enabled, the Root Port should only synthesize 0x0001
data if it receives a CRS completion for a read of the Vendor ID. If it
receives a CRS completion for any other read, it should fail the
transaction and synthesize all 1's data.
This breaks pci_flr_wait(), which reads the Command register and expects to
see all 1's data if the read fails because of CRS completions. On
Stingray, it sees the incorrect 0xffff0001 data instead.
It also breaks config registers that contain the 0xffff0001 value. If we
read such a register, software can't distinguish a CRS completion from the
actual value read from the device.
On Stingray, if we read 0xffff0001 data, assume this indicates a CRS
completion and retry the read for 500ms. If we time out, return all 1's
(0xffffffff) data. Note that this corrupts registers that happen to
contain 0xffff0001.
Stingray advertises CRS SV support in its Root Capabilities register, and
the CRS SV enable bit is writable (even though the hardware ignores it).
Mask out PCI_EXP_RTCAP_CRSVIS so software doesn't try to use CRS SV.
Signed-off-by: Oza Pawandeep <oza.oza@broadcom.com>
[bhelgaas: changelog, add probe-time warning about corruption, don't
advertise CRS SV support, remove duplicate pci_generic_config_read32(),
fix alignment based on patch from Arnd Bergmann <arnd@arndb.de>]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2017-08-28 21:43:30 +00:00
|
|
|
{
|
|
|
|
struct iproc_pcie *pcie = iproc_data(bus);
|
|
|
|
unsigned int busno = bus->number;
|
|
|
|
void __iomem *cfg_data_p;
|
|
|
|
unsigned int data;
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
/* root complex access */
|
|
|
|
if (busno == 0) {
|
|
|
|
ret = pci_generic_config_read32(bus, devfn, where, size, val);
|
2018-06-12 00:21:04 +00:00
|
|
|
if (ret == PCIBIOS_SUCCESSFUL)
|
|
|
|
iproc_pcie_fix_cap(pcie, where, val);
|
PCI: iproc: Work around Stingray CRS defects
Configuration Request Retry Status ("CRS") completions are a required part
of PCIe. A PCIe device may respond to config a request with a CRS
completion to indicate that it needs more time to initialize. A Root Port
that receives a CRS completion may automatically retry the request, or it
may treat the request as a failed transaction. For a failed read, it will
likely synthesize all 1's data, i.e., 0xffffffff, to complete the read to
the CPU.
CRS Software Visibility ("CRS SV") is an optional feature. Per PCIe r3.1,
sec 2.3.2, if supported and enabled, a Root Port that receives a CRS
completion for a config read of the Vendor ID will synthesize 0x0001 data
(an invalid Vendor ID) instead of retrying or failing the transaction. The
0x0001 data makes the CRS completion visible to software, so it can perform
other tasks while waiting for the device.
The iProc "Stingray" PCIe controller does not support CRS completions
correctly. From the Stingray PCIe Controller spec:
4.7.3.3. Retry Status On Configuration Cycle
Endpoints are allowed to generate retry status on configuration cycles.
In this case, the RC needs to re-issue the request. The IP does not
handle this because the number of configuration cycles needed will
probably be less than the total number of non-posted operations needed.
When a retry status is received on the User RX interface for a
configuration request that was sent on the User TX interface, it will be
indicated with a completion with the CMPL_STATUS field set to 2=CRS, and
the user will have to find the address and data values and send a new
transaction on the User TX interface. When the internal configuration
space returns a retry status during a configuration cycle (user_cscfg =
1) on the Command/Status interface, the pcie_cscrs will assert with the
pcie_csack signal to indicate the CRS status.
When the CRS Software Visibility Enable register in the Root Control
register is enabled, the IP will return the data value to 0x0001 for the
Vendor ID value and 0xffff (all 1’s) for the rest of the data in the
request for reads of offset 0 that return with CRS status. This is true
for both the User RX Interface and for the Command/Status interface.
When CRS Software Visibility is enabled, the CMPL_STATUS field of the
completion on the User RX Interface will not be 2=CRS and the pcie_cscrs
signal will not assert on the Command/Status interface.
The Stingray hardware never reissues configuration requests when it
receives CRS completions. Contrary to what sec 4.7.3.3 above says, when it
receives a CRS completion, it synthesizes 0xffff0001 data regardless of the
address of the read or the value of the CRS SV enable bit.
This is broken in two ways:
1) When CRS SV is disabled, the Root Port should never synthesize the
0x0001 value. If it receives a CRS completion, it should fail the
transaction and synthesize all 1's data.
2) When CRS SV is enabled, the Root Port should only synthesize 0x0001
data if it receives a CRS completion for a read of the Vendor ID. If it
receives a CRS completion for any other read, it should fail the
transaction and synthesize all 1's data.
This breaks pci_flr_wait(), which reads the Command register and expects to
see all 1's data if the read fails because of CRS completions. On
Stingray, it sees the incorrect 0xffff0001 data instead.
It also breaks config registers that contain the 0xffff0001 value. If we
read such a register, software can't distinguish a CRS completion from the
actual value read from the device.
On Stingray, if we read 0xffff0001 data, assume this indicates a CRS
completion and retry the read for 500ms. If we time out, return all 1's
(0xffffffff) data. Note that this corrupts registers that happen to
contain 0xffff0001.
Stingray advertises CRS SV support in its Root Capabilities register, and
the CRS SV enable bit is writable (even though the hardware ignores it).
Mask out PCI_EXP_RTCAP_CRSVIS so software doesn't try to use CRS SV.
Signed-off-by: Oza Pawandeep <oza.oza@broadcom.com>
[bhelgaas: changelog, add probe-time warning about corruption, don't
advertise CRS SV support, remove duplicate pci_generic_config_read32(),
fix alignment based on patch from Arnd Bergmann <arnd@arndb.de>]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2017-08-28 21:43:30 +00:00
|
|
|
|
2018-06-12 00:21:04 +00:00
|
|
|
return ret;
|
PCI: iproc: Work around Stingray CRS defects
Configuration Request Retry Status ("CRS") completions are a required part
of PCIe. A PCIe device may respond to config a request with a CRS
completion to indicate that it needs more time to initialize. A Root Port
that receives a CRS completion may automatically retry the request, or it
may treat the request as a failed transaction. For a failed read, it will
likely synthesize all 1's data, i.e., 0xffffffff, to complete the read to
the CPU.
CRS Software Visibility ("CRS SV") is an optional feature. Per PCIe r3.1,
sec 2.3.2, if supported and enabled, a Root Port that receives a CRS
completion for a config read of the Vendor ID will synthesize 0x0001 data
(an invalid Vendor ID) instead of retrying or failing the transaction. The
0x0001 data makes the CRS completion visible to software, so it can perform
other tasks while waiting for the device.
The iProc "Stingray" PCIe controller does not support CRS completions
correctly. From the Stingray PCIe Controller spec:
4.7.3.3. Retry Status On Configuration Cycle
Endpoints are allowed to generate retry status on configuration cycles.
In this case, the RC needs to re-issue the request. The IP does not
handle this because the number of configuration cycles needed will
probably be less than the total number of non-posted operations needed.
When a retry status is received on the User RX interface for a
configuration request that was sent on the User TX interface, it will be
indicated with a completion with the CMPL_STATUS field set to 2=CRS, and
the user will have to find the address and data values and send a new
transaction on the User TX interface. When the internal configuration
space returns a retry status during a configuration cycle (user_cscfg =
1) on the Command/Status interface, the pcie_cscrs will assert with the
pcie_csack signal to indicate the CRS status.
When the CRS Software Visibility Enable register in the Root Control
register is enabled, the IP will return the data value to 0x0001 for the
Vendor ID value and 0xffff (all 1’s) for the rest of the data in the
request for reads of offset 0 that return with CRS status. This is true
for both the User RX Interface and for the Command/Status interface.
When CRS Software Visibility is enabled, the CMPL_STATUS field of the
completion on the User RX Interface will not be 2=CRS and the pcie_cscrs
signal will not assert on the Command/Status interface.
The Stingray hardware never reissues configuration requests when it
receives CRS completions. Contrary to what sec 4.7.3.3 above says, when it
receives a CRS completion, it synthesizes 0xffff0001 data regardless of the
address of the read or the value of the CRS SV enable bit.
This is broken in two ways:
1) When CRS SV is disabled, the Root Port should never synthesize the
0x0001 value. If it receives a CRS completion, it should fail the
transaction and synthesize all 1's data.
2) When CRS SV is enabled, the Root Port should only synthesize 0x0001
data if it receives a CRS completion for a read of the Vendor ID. If it
receives a CRS completion for any other read, it should fail the
transaction and synthesize all 1's data.
This breaks pci_flr_wait(), which reads the Command register and expects to
see all 1's data if the read fails because of CRS completions. On
Stingray, it sees the incorrect 0xffff0001 data instead.
It also breaks config registers that contain the 0xffff0001 value. If we
read such a register, software can't distinguish a CRS completion from the
actual value read from the device.
On Stingray, if we read 0xffff0001 data, assume this indicates a CRS
completion and retry the read for 500ms. If we time out, return all 1's
(0xffffffff) data. Note that this corrupts registers that happen to
contain 0xffff0001.
Stingray advertises CRS SV support in its Root Capabilities register, and
the CRS SV enable bit is writable (even though the hardware ignores it).
Mask out PCI_EXP_RTCAP_CRSVIS so software doesn't try to use CRS SV.
Signed-off-by: Oza Pawandeep <oza.oza@broadcom.com>
[bhelgaas: changelog, add probe-time warning about corruption, don't
advertise CRS SV support, remove duplicate pci_generic_config_read32(),
fix alignment based on patch from Arnd Bergmann <arnd@arndb.de>]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2017-08-28 21:43:30 +00:00
|
|
|
}
|
|
|
|
|
2020-11-29 23:07:41 +00:00
|
|
|
cfg_data_p = iproc_pcie_map_ep_cfg_reg(pcie, busno, devfn, where);
|
PCI: iproc: Work around Stingray CRS defects
Configuration Request Retry Status ("CRS") completions are a required part
of PCIe. A PCIe device may respond to config a request with a CRS
completion to indicate that it needs more time to initialize. A Root Port
that receives a CRS completion may automatically retry the request, or it
may treat the request as a failed transaction. For a failed read, it will
likely synthesize all 1's data, i.e., 0xffffffff, to complete the read to
the CPU.
CRS Software Visibility ("CRS SV") is an optional feature. Per PCIe r3.1,
sec 2.3.2, if supported and enabled, a Root Port that receives a CRS
completion for a config read of the Vendor ID will synthesize 0x0001 data
(an invalid Vendor ID) instead of retrying or failing the transaction. The
0x0001 data makes the CRS completion visible to software, so it can perform
other tasks while waiting for the device.
The iProc "Stingray" PCIe controller does not support CRS completions
correctly. From the Stingray PCIe Controller spec:
4.7.3.3. Retry Status On Configuration Cycle
Endpoints are allowed to generate retry status on configuration cycles.
In this case, the RC needs to re-issue the request. The IP does not
handle this because the number of configuration cycles needed will
probably be less than the total number of non-posted operations needed.
When a retry status is received on the User RX interface for a
configuration request that was sent on the User TX interface, it will be
indicated with a completion with the CMPL_STATUS field set to 2=CRS, and
the user will have to find the address and data values and send a new
transaction on the User TX interface. When the internal configuration
space returns a retry status during a configuration cycle (user_cscfg =
1) on the Command/Status interface, the pcie_cscrs will assert with the
pcie_csack signal to indicate the CRS status.
When the CRS Software Visibility Enable register in the Root Control
register is enabled, the IP will return the data value to 0x0001 for the
Vendor ID value and 0xffff (all 1’s) for the rest of the data in the
request for reads of offset 0 that return with CRS status. This is true
for both the User RX Interface and for the Command/Status interface.
When CRS Software Visibility is enabled, the CMPL_STATUS field of the
completion on the User RX Interface will not be 2=CRS and the pcie_cscrs
signal will not assert on the Command/Status interface.
The Stingray hardware never reissues configuration requests when it
receives CRS completions. Contrary to what sec 4.7.3.3 above says, when it
receives a CRS completion, it synthesizes 0xffff0001 data regardless of the
address of the read or the value of the CRS SV enable bit.
This is broken in two ways:
1) When CRS SV is disabled, the Root Port should never synthesize the
0x0001 value. If it receives a CRS completion, it should fail the
transaction and synthesize all 1's data.
2) When CRS SV is enabled, the Root Port should only synthesize 0x0001
data if it receives a CRS completion for a read of the Vendor ID. If it
receives a CRS completion for any other read, it should fail the
transaction and synthesize all 1's data.
This breaks pci_flr_wait(), which reads the Command register and expects to
see all 1's data if the read fails because of CRS completions. On
Stingray, it sees the incorrect 0xffff0001 data instead.
It also breaks config registers that contain the 0xffff0001 value. If we
read such a register, software can't distinguish a CRS completion from the
actual value read from the device.
On Stingray, if we read 0xffff0001 data, assume this indicates a CRS
completion and retry the read for 500ms. If we time out, return all 1's
(0xffffffff) data. Note that this corrupts registers that happen to
contain 0xffff0001.
Stingray advertises CRS SV support in its Root Capabilities register, and
the CRS SV enable bit is writable (even though the hardware ignores it).
Mask out PCI_EXP_RTCAP_CRSVIS so software doesn't try to use CRS SV.
Signed-off-by: Oza Pawandeep <oza.oza@broadcom.com>
[bhelgaas: changelog, add probe-time warning about corruption, don't
advertise CRS SV support, remove duplicate pci_generic_config_read32(),
fix alignment based on patch from Arnd Bergmann <arnd@arndb.de>]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2017-08-28 21:43:30 +00:00
|
|
|
|
|
|
|
if (!cfg_data_p)
|
|
|
|
return PCIBIOS_DEVICE_NOT_FOUND;
|
|
|
|
|
2019-03-01 04:52:15 +00:00
|
|
|
data = iproc_pcie_cfg_retry(pcie, cfg_data_p);
|
PCI: iproc: Work around Stingray CRS defects
Configuration Request Retry Status ("CRS") completions are a required part
of PCIe. A PCIe device may respond to config a request with a CRS
completion to indicate that it needs more time to initialize. A Root Port
that receives a CRS completion may automatically retry the request, or it
may treat the request as a failed transaction. For a failed read, it will
likely synthesize all 1's data, i.e., 0xffffffff, to complete the read to
the CPU.
CRS Software Visibility ("CRS SV") is an optional feature. Per PCIe r3.1,
sec 2.3.2, if supported and enabled, a Root Port that receives a CRS
completion for a config read of the Vendor ID will synthesize 0x0001 data
(an invalid Vendor ID) instead of retrying or failing the transaction. The
0x0001 data makes the CRS completion visible to software, so it can perform
other tasks while waiting for the device.
The iProc "Stingray" PCIe controller does not support CRS completions
correctly. From the Stingray PCIe Controller spec:
4.7.3.3. Retry Status On Configuration Cycle
Endpoints are allowed to generate retry status on configuration cycles.
In this case, the RC needs to re-issue the request. The IP does not
handle this because the number of configuration cycles needed will
probably be less than the total number of non-posted operations needed.
When a retry status is received on the User RX interface for a
configuration request that was sent on the User TX interface, it will be
indicated with a completion with the CMPL_STATUS field set to 2=CRS, and
the user will have to find the address and data values and send a new
transaction on the User TX interface. When the internal configuration
space returns a retry status during a configuration cycle (user_cscfg =
1) on the Command/Status interface, the pcie_cscrs will assert with the
pcie_csack signal to indicate the CRS status.
When the CRS Software Visibility Enable register in the Root Control
register is enabled, the IP will return the data value to 0x0001 for the
Vendor ID value and 0xffff (all 1’s) for the rest of the data in the
request for reads of offset 0 that return with CRS status. This is true
for both the User RX Interface and for the Command/Status interface.
When CRS Software Visibility is enabled, the CMPL_STATUS field of the
completion on the User RX Interface will not be 2=CRS and the pcie_cscrs
signal will not assert on the Command/Status interface.
The Stingray hardware never reissues configuration requests when it
receives CRS completions. Contrary to what sec 4.7.3.3 above says, when it
receives a CRS completion, it synthesizes 0xffff0001 data regardless of the
address of the read or the value of the CRS SV enable bit.
This is broken in two ways:
1) When CRS SV is disabled, the Root Port should never synthesize the
0x0001 value. If it receives a CRS completion, it should fail the
transaction and synthesize all 1's data.
2) When CRS SV is enabled, the Root Port should only synthesize 0x0001
data if it receives a CRS completion for a read of the Vendor ID. If it
receives a CRS completion for any other read, it should fail the
transaction and synthesize all 1's data.
This breaks pci_flr_wait(), which reads the Command register and expects to
see all 1's data if the read fails because of CRS completions. On
Stingray, it sees the incorrect 0xffff0001 data instead.
It also breaks config registers that contain the 0xffff0001 value. If we
read such a register, software can't distinguish a CRS completion from the
actual value read from the device.
On Stingray, if we read 0xffff0001 data, assume this indicates a CRS
completion and retry the read for 500ms. If we time out, return all 1's
(0xffffffff) data. Note that this corrupts registers that happen to
contain 0xffff0001.
Stingray advertises CRS SV support in its Root Capabilities register, and
the CRS SV enable bit is writable (even though the hardware ignores it).
Mask out PCI_EXP_RTCAP_CRSVIS so software doesn't try to use CRS SV.
Signed-off-by: Oza Pawandeep <oza.oza@broadcom.com>
[bhelgaas: changelog, add probe-time warning about corruption, don't
advertise CRS SV support, remove duplicate pci_generic_config_read32(),
fix alignment based on patch from Arnd Bergmann <arnd@arndb.de>]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2017-08-28 21:43:30 +00:00
|
|
|
|
|
|
|
*val = data;
|
|
|
|
if (size <= 2)
|
|
|
|
*val = (data >> (8 * (where & 3))) & ((1 << (size * 8)) - 1);
|
|
|
|
|
2018-06-12 00:21:06 +00:00
|
|
|
/*
|
|
|
|
* For PAXC and PAXCv2, the total number of PFs that one can enumerate
|
|
|
|
* depends on the firmware configuration. Unfortunately, due to an ASIC
|
|
|
|
* bug, unconfigured PFs cannot be properly hidden from the root
|
|
|
|
* complex. As a result, write access to these PFs will cause bus lock
|
|
|
|
* up on the embedded processor
|
|
|
|
*
|
|
|
|
* Since all unconfigured PFs are left with an incorrect, staled device
|
|
|
|
* ID of 0x168e (PCI_DEVICE_ID_NX2_57810), we try to catch those access
|
|
|
|
* early here and reject them all
|
|
|
|
*/
|
|
|
|
#define DEVICE_ID_MASK 0xffff0000
|
|
|
|
#define DEVICE_ID_SHIFT 16
|
|
|
|
if (pcie->rej_unconfig_pf &&
|
|
|
|
(where & CFG_ADDR_REG_NUM_MASK) == PCI_VENDOR_ID)
|
|
|
|
if ((*val & DEVICE_ID_MASK) ==
|
|
|
|
(PCI_DEVICE_ID_NX2_57810 << DEVICE_ID_SHIFT))
|
|
|
|
return PCIBIOS_FUNC_NOT_SUPPORTED;
|
|
|
|
|
PCI: iproc: Work around Stingray CRS defects
Configuration Request Retry Status ("CRS") completions are a required part
of PCIe. A PCIe device may respond to config a request with a CRS
completion to indicate that it needs more time to initialize. A Root Port
that receives a CRS completion may automatically retry the request, or it
may treat the request as a failed transaction. For a failed read, it will
likely synthesize all 1's data, i.e., 0xffffffff, to complete the read to
the CPU.
CRS Software Visibility ("CRS SV") is an optional feature. Per PCIe r3.1,
sec 2.3.2, if supported and enabled, a Root Port that receives a CRS
completion for a config read of the Vendor ID will synthesize 0x0001 data
(an invalid Vendor ID) instead of retrying or failing the transaction. The
0x0001 data makes the CRS completion visible to software, so it can perform
other tasks while waiting for the device.
The iProc "Stingray" PCIe controller does not support CRS completions
correctly. From the Stingray PCIe Controller spec:
4.7.3.3. Retry Status On Configuration Cycle
Endpoints are allowed to generate retry status on configuration cycles.
In this case, the RC needs to re-issue the request. The IP does not
handle this because the number of configuration cycles needed will
probably be less than the total number of non-posted operations needed.
When a retry status is received on the User RX interface for a
configuration request that was sent on the User TX interface, it will be
indicated with a completion with the CMPL_STATUS field set to 2=CRS, and
the user will have to find the address and data values and send a new
transaction on the User TX interface. When the internal configuration
space returns a retry status during a configuration cycle (user_cscfg =
1) on the Command/Status interface, the pcie_cscrs will assert with the
pcie_csack signal to indicate the CRS status.
When the CRS Software Visibility Enable register in the Root Control
register is enabled, the IP will return the data value to 0x0001 for the
Vendor ID value and 0xffff (all 1’s) for the rest of the data in the
request for reads of offset 0 that return with CRS status. This is true
for both the User RX Interface and for the Command/Status interface.
When CRS Software Visibility is enabled, the CMPL_STATUS field of the
completion on the User RX Interface will not be 2=CRS and the pcie_cscrs
signal will not assert on the Command/Status interface.
The Stingray hardware never reissues configuration requests when it
receives CRS completions. Contrary to what sec 4.7.3.3 above says, when it
receives a CRS completion, it synthesizes 0xffff0001 data regardless of the
address of the read or the value of the CRS SV enable bit.
This is broken in two ways:
1) When CRS SV is disabled, the Root Port should never synthesize the
0x0001 value. If it receives a CRS completion, it should fail the
transaction and synthesize all 1's data.
2) When CRS SV is enabled, the Root Port should only synthesize 0x0001
data if it receives a CRS completion for a read of the Vendor ID. If it
receives a CRS completion for any other read, it should fail the
transaction and synthesize all 1's data.
This breaks pci_flr_wait(), which reads the Command register and expects to
see all 1's data if the read fails because of CRS completions. On
Stingray, it sees the incorrect 0xffff0001 data instead.
It also breaks config registers that contain the 0xffff0001 value. If we
read such a register, software can't distinguish a CRS completion from the
actual value read from the device.
On Stingray, if we read 0xffff0001 data, assume this indicates a CRS
completion and retry the read for 500ms. If we time out, return all 1's
(0xffffffff) data. Note that this corrupts registers that happen to
contain 0xffff0001.
Stingray advertises CRS SV support in its Root Capabilities register, and
the CRS SV enable bit is writable (even though the hardware ignores it).
Mask out PCI_EXP_RTCAP_CRSVIS so software doesn't try to use CRS SV.
Signed-off-by: Oza Pawandeep <oza.oza@broadcom.com>
[bhelgaas: changelog, add probe-time warning about corruption, don't
advertise CRS SV support, remove duplicate pci_generic_config_read32(),
fix alignment based on patch from Arnd Bergmann <arnd@arndb.de>]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2017-08-28 21:43:30 +00:00
|
|
|
return PCIBIOS_SUCCESSFUL;
|
|
|
|
}
|
|
|
|
|
2021-07-03 15:13:02 +00:00
|
|
|
/*
|
2015-04-08 18:21:35 +00:00
|
|
|
* Note access to the configuration registers are protected at the higher layer
|
|
|
|
* by 'pci_lock' in drivers/pci/access.c
|
|
|
|
*/
|
2017-06-28 20:13:50 +00:00
|
|
|
static void __iomem *iproc_pcie_map_cfg_bus(struct iproc_pcie *pcie,
|
2017-09-05 17:33:33 +00:00
|
|
|
int busno, unsigned int devfn,
|
2015-04-08 18:21:35 +00:00
|
|
|
int where)
|
|
|
|
{
|
2015-12-04 17:34:59 +00:00
|
|
|
u16 offset;
|
|
|
|
|
2015-04-08 18:21:35 +00:00
|
|
|
/* root complex access */
|
|
|
|
if (busno == 0) {
|
2020-11-29 23:07:41 +00:00
|
|
|
if (PCIE_ECAM_DEVFN(devfn) > 0)
|
2016-01-27 22:52:24 +00:00
|
|
|
return NULL;
|
|
|
|
|
2015-12-04 17:34:59 +00:00
|
|
|
iproc_pcie_write_reg(pcie, IPROC_PCIE_CFG_IND_ADDR,
|
|
|
|
where & CFG_IND_ADDR_MASK);
|
|
|
|
offset = iproc_pcie_reg_offset(pcie, IPROC_PCIE_CFG_IND_DATA);
|
|
|
|
if (iproc_pcie_reg_is_invalid(offset))
|
2015-04-08 18:21:35 +00:00
|
|
|
return NULL;
|
2015-12-04 17:34:59 +00:00
|
|
|
else
|
|
|
|
return (pcie->base + offset);
|
2015-04-08 18:21:35 +00:00
|
|
|
}
|
|
|
|
|
2020-11-29 23:07:41 +00:00
|
|
|
return iproc_pcie_map_ep_cfg_reg(pcie, busno, devfn, where);
|
2015-04-08 18:21:35 +00:00
|
|
|
}
|
|
|
|
|
2017-06-28 20:13:50 +00:00
|
|
|
static void __iomem *iproc_pcie_bus_map_cfg_bus(struct pci_bus *bus,
|
|
|
|
unsigned int devfn,
|
|
|
|
int where)
|
|
|
|
{
|
|
|
|
return iproc_pcie_map_cfg_bus(iproc_data(bus), bus->number, devfn,
|
|
|
|
where);
|
|
|
|
}
|
|
|
|
|
|
|
|
static int iproc_pci_raw_config_read32(struct iproc_pcie *pcie,
|
|
|
|
unsigned int devfn, int where,
|
|
|
|
int size, u32 *val)
|
|
|
|
{
|
|
|
|
void __iomem *addr;
|
|
|
|
|
|
|
|
addr = iproc_pcie_map_cfg_bus(pcie, 0, devfn, where & ~0x3);
|
2021-11-18 14:03:16 +00:00
|
|
|
if (!addr)
|
2017-06-28 20:13:50 +00:00
|
|
|
return PCIBIOS_DEVICE_NOT_FOUND;
|
|
|
|
|
|
|
|
*val = readl(addr);
|
|
|
|
|
|
|
|
if (size <= 2)
|
|
|
|
*val = (*val >> (8 * (where & 3))) & ((1 << (size * 8)) - 1);
|
|
|
|
|
|
|
|
return PCIBIOS_SUCCESSFUL;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int iproc_pci_raw_config_write32(struct iproc_pcie *pcie,
|
|
|
|
unsigned int devfn, int where,
|
|
|
|
int size, u32 val)
|
|
|
|
{
|
|
|
|
void __iomem *addr;
|
|
|
|
u32 mask, tmp;
|
|
|
|
|
|
|
|
addr = iproc_pcie_map_cfg_bus(pcie, 0, devfn, where & ~0x3);
|
|
|
|
if (!addr)
|
|
|
|
return PCIBIOS_DEVICE_NOT_FOUND;
|
|
|
|
|
|
|
|
if (size == 4) {
|
|
|
|
writel(val, addr);
|
|
|
|
return PCIBIOS_SUCCESSFUL;
|
|
|
|
}
|
|
|
|
|
|
|
|
mask = ~(((1 << (size * 8)) - 1) << ((where & 0x3) * 8));
|
|
|
|
tmp = readl(addr) & mask;
|
|
|
|
tmp |= val << ((where & 0x3) * 8);
|
|
|
|
writel(tmp, addr);
|
|
|
|
|
|
|
|
return PCIBIOS_SUCCESSFUL;
|
|
|
|
}
|
|
|
|
|
2016-11-01 00:38:33 +00:00
|
|
|
static int iproc_pcie_config_read32(struct pci_bus *bus, unsigned int devfn,
|
|
|
|
int where, int size, u32 *val)
|
|
|
|
{
|
|
|
|
int ret;
|
PCI: iproc: Work around Stingray CRS defects
Configuration Request Retry Status ("CRS") completions are a required part
of PCIe. A PCIe device may respond to config a request with a CRS
completion to indicate that it needs more time to initialize. A Root Port
that receives a CRS completion may automatically retry the request, or it
may treat the request as a failed transaction. For a failed read, it will
likely synthesize all 1's data, i.e., 0xffffffff, to complete the read to
the CPU.
CRS Software Visibility ("CRS SV") is an optional feature. Per PCIe r3.1,
sec 2.3.2, if supported and enabled, a Root Port that receives a CRS
completion for a config read of the Vendor ID will synthesize 0x0001 data
(an invalid Vendor ID) instead of retrying or failing the transaction. The
0x0001 data makes the CRS completion visible to software, so it can perform
other tasks while waiting for the device.
The iProc "Stingray" PCIe controller does not support CRS completions
correctly. From the Stingray PCIe Controller spec:
4.7.3.3. Retry Status On Configuration Cycle
Endpoints are allowed to generate retry status on configuration cycles.
In this case, the RC needs to re-issue the request. The IP does not
handle this because the number of configuration cycles needed will
probably be less than the total number of non-posted operations needed.
When a retry status is received on the User RX interface for a
configuration request that was sent on the User TX interface, it will be
indicated with a completion with the CMPL_STATUS field set to 2=CRS, and
the user will have to find the address and data values and send a new
transaction on the User TX interface. When the internal configuration
space returns a retry status during a configuration cycle (user_cscfg =
1) on the Command/Status interface, the pcie_cscrs will assert with the
pcie_csack signal to indicate the CRS status.
When the CRS Software Visibility Enable register in the Root Control
register is enabled, the IP will return the data value to 0x0001 for the
Vendor ID value and 0xffff (all 1’s) for the rest of the data in the
request for reads of offset 0 that return with CRS status. This is true
for both the User RX Interface and for the Command/Status interface.
When CRS Software Visibility is enabled, the CMPL_STATUS field of the
completion on the User RX Interface will not be 2=CRS and the pcie_cscrs
signal will not assert on the Command/Status interface.
The Stingray hardware never reissues configuration requests when it
receives CRS completions. Contrary to what sec 4.7.3.3 above says, when it
receives a CRS completion, it synthesizes 0xffff0001 data regardless of the
address of the read or the value of the CRS SV enable bit.
This is broken in two ways:
1) When CRS SV is disabled, the Root Port should never synthesize the
0x0001 value. If it receives a CRS completion, it should fail the
transaction and synthesize all 1's data.
2) When CRS SV is enabled, the Root Port should only synthesize 0x0001
data if it receives a CRS completion for a read of the Vendor ID. If it
receives a CRS completion for any other read, it should fail the
transaction and synthesize all 1's data.
This breaks pci_flr_wait(), which reads the Command register and expects to
see all 1's data if the read fails because of CRS completions. On
Stingray, it sees the incorrect 0xffff0001 data instead.
It also breaks config registers that contain the 0xffff0001 value. If we
read such a register, software can't distinguish a CRS completion from the
actual value read from the device.
On Stingray, if we read 0xffff0001 data, assume this indicates a CRS
completion and retry the read for 500ms. If we time out, return all 1's
(0xffffffff) data. Note that this corrupts registers that happen to
contain 0xffff0001.
Stingray advertises CRS SV support in its Root Capabilities register, and
the CRS SV enable bit is writable (even though the hardware ignores it).
Mask out PCI_EXP_RTCAP_CRSVIS so software doesn't try to use CRS SV.
Signed-off-by: Oza Pawandeep <oza.oza@broadcom.com>
[bhelgaas: changelog, add probe-time warning about corruption, don't
advertise CRS SV support, remove duplicate pci_generic_config_read32(),
fix alignment based on patch from Arnd Bergmann <arnd@arndb.de>]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2017-08-28 21:43:30 +00:00
|
|
|
struct iproc_pcie *pcie = iproc_data(bus);
|
2016-11-01 00:38:33 +00:00
|
|
|
|
|
|
|
iproc_pcie_apb_err_disable(bus, true);
|
2018-06-12 00:21:06 +00:00
|
|
|
if (pcie->iproc_cfg_read)
|
PCI: iproc: Work around Stingray CRS defects
Configuration Request Retry Status ("CRS") completions are a required part
of PCIe. A PCIe device may respond to config a request with a CRS
completion to indicate that it needs more time to initialize. A Root Port
that receives a CRS completion may automatically retry the request, or it
may treat the request as a failed transaction. For a failed read, it will
likely synthesize all 1's data, i.e., 0xffffffff, to complete the read to
the CPU.
CRS Software Visibility ("CRS SV") is an optional feature. Per PCIe r3.1,
sec 2.3.2, if supported and enabled, a Root Port that receives a CRS
completion for a config read of the Vendor ID will synthesize 0x0001 data
(an invalid Vendor ID) instead of retrying or failing the transaction. The
0x0001 data makes the CRS completion visible to software, so it can perform
other tasks while waiting for the device.
The iProc "Stingray" PCIe controller does not support CRS completions
correctly. From the Stingray PCIe Controller spec:
4.7.3.3. Retry Status On Configuration Cycle
Endpoints are allowed to generate retry status on configuration cycles.
In this case, the RC needs to re-issue the request. The IP does not
handle this because the number of configuration cycles needed will
probably be less than the total number of non-posted operations needed.
When a retry status is received on the User RX interface for a
configuration request that was sent on the User TX interface, it will be
indicated with a completion with the CMPL_STATUS field set to 2=CRS, and
the user will have to find the address and data values and send a new
transaction on the User TX interface. When the internal configuration
space returns a retry status during a configuration cycle (user_cscfg =
1) on the Command/Status interface, the pcie_cscrs will assert with the
pcie_csack signal to indicate the CRS status.
When the CRS Software Visibility Enable register in the Root Control
register is enabled, the IP will return the data value to 0x0001 for the
Vendor ID value and 0xffff (all 1’s) for the rest of the data in the
request for reads of offset 0 that return with CRS status. This is true
for both the User RX Interface and for the Command/Status interface.
When CRS Software Visibility is enabled, the CMPL_STATUS field of the
completion on the User RX Interface will not be 2=CRS and the pcie_cscrs
signal will not assert on the Command/Status interface.
The Stingray hardware never reissues configuration requests when it
receives CRS completions. Contrary to what sec 4.7.3.3 above says, when it
receives a CRS completion, it synthesizes 0xffff0001 data regardless of the
address of the read or the value of the CRS SV enable bit.
This is broken in two ways:
1) When CRS SV is disabled, the Root Port should never synthesize the
0x0001 value. If it receives a CRS completion, it should fail the
transaction and synthesize all 1's data.
2) When CRS SV is enabled, the Root Port should only synthesize 0x0001
data if it receives a CRS completion for a read of the Vendor ID. If it
receives a CRS completion for any other read, it should fail the
transaction and synthesize all 1's data.
This breaks pci_flr_wait(), which reads the Command register and expects to
see all 1's data if the read fails because of CRS completions. On
Stingray, it sees the incorrect 0xffff0001 data instead.
It also breaks config registers that contain the 0xffff0001 value. If we
read such a register, software can't distinguish a CRS completion from the
actual value read from the device.
On Stingray, if we read 0xffff0001 data, assume this indicates a CRS
completion and retry the read for 500ms. If we time out, return all 1's
(0xffffffff) data. Note that this corrupts registers that happen to
contain 0xffff0001.
Stingray advertises CRS SV support in its Root Capabilities register, and
the CRS SV enable bit is writable (even though the hardware ignores it).
Mask out PCI_EXP_RTCAP_CRSVIS so software doesn't try to use CRS SV.
Signed-off-by: Oza Pawandeep <oza.oza@broadcom.com>
[bhelgaas: changelog, add probe-time warning about corruption, don't
advertise CRS SV support, remove duplicate pci_generic_config_read32(),
fix alignment based on patch from Arnd Bergmann <arnd@arndb.de>]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2017-08-28 21:43:30 +00:00
|
|
|
ret = iproc_pcie_config_read(bus, devfn, where, size, val);
|
|
|
|
else
|
|
|
|
ret = pci_generic_config_read32(bus, devfn, where, size, val);
|
2016-11-01 00:38:33 +00:00
|
|
|
iproc_pcie_apb_err_disable(bus, false);
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int iproc_pcie_config_write32(struct pci_bus *bus, unsigned int devfn,
|
|
|
|
int where, int size, u32 val)
|
|
|
|
{
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
iproc_pcie_apb_err_disable(bus, true);
|
|
|
|
ret = pci_generic_config_write32(bus, devfn, where, size, val);
|
|
|
|
iproc_pcie_apb_err_disable(bus, false);
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2015-04-08 18:21:35 +00:00
|
|
|
static struct pci_ops iproc_pcie_ops = {
|
2017-06-28 20:13:50 +00:00
|
|
|
.map_bus = iproc_pcie_bus_map_cfg_bus,
|
2016-11-01 00:38:33 +00:00
|
|
|
.read = iproc_pcie_config_read32,
|
|
|
|
.write = iproc_pcie_config_write32,
|
2015-04-08 18:21:35 +00:00
|
|
|
};
|
|
|
|
|
PCI: iproc: Add 500ms delay during device shutdown
During soft reset (e.g., "reboot" from Linux) on some iProc-based SOCs, the
LCPLL clock and PERST both go off simultaneously. This seems in accordance
with the PCIe Card Electromechanical spec, r2.0, sec 2.2.3, which says the
clock goes inactive after PERST# goes active, but doesn't specify how long
the clock should be valid after PERST#.
However, we have observed that with the iProc Stingray, some Intel NVMe
endpoints, e.g., the P3700 400GB series, are not detected correctly upon
the next boot sequence unless the clock remains valid for some time after
PERST# is asserted.
Delay 500ms after asserting PERST# before performing a reboot. The 500ms
is experimentally determined.
Signed-off-by: Oza Pawandeep <oza.oza@broadcom.com>
[bhelgaas: changelog, add spec reference, fold in iproc_pcie_shutdown()
export from Arnd Bergmann <arnd@arndb.de>]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Ray Jui <ray.jui@broadcom.com>
Reviewed-by: Scott Branden <scott.branden@broadcom.com>
2017-08-28 21:43:35 +00:00
|
|
|
static void iproc_pcie_perst_ctrl(struct iproc_pcie *pcie, bool assert)
|
2015-04-08 18:21:35 +00:00
|
|
|
{
|
|
|
|
u32 val;
|
|
|
|
|
2016-11-01 00:38:31 +00:00
|
|
|
/*
|
|
|
|
* PAXC and the internal emulated endpoint device downstream should not
|
|
|
|
* be reset. If firmware has been loaded on the endpoint device at an
|
|
|
|
* earlier boot stage, reset here causes issues.
|
|
|
|
*/
|
|
|
|
if (pcie->ep_is_internal)
|
2015-12-04 17:34:59 +00:00
|
|
|
return;
|
|
|
|
|
PCI: iproc: Add 500ms delay during device shutdown
During soft reset (e.g., "reboot" from Linux) on some iProc-based SOCs, the
LCPLL clock and PERST both go off simultaneously. This seems in accordance
with the PCIe Card Electromechanical spec, r2.0, sec 2.2.3, which says the
clock goes inactive after PERST# goes active, but doesn't specify how long
the clock should be valid after PERST#.
However, we have observed that with the iProc Stingray, some Intel NVMe
endpoints, e.g., the P3700 400GB series, are not detected correctly upon
the next boot sequence unless the clock remains valid for some time after
PERST# is asserted.
Delay 500ms after asserting PERST# before performing a reboot. The 500ms
is experimentally determined.
Signed-off-by: Oza Pawandeep <oza.oza@broadcom.com>
[bhelgaas: changelog, add spec reference, fold in iproc_pcie_shutdown()
export from Arnd Bergmann <arnd@arndb.de>]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Ray Jui <ray.jui@broadcom.com>
Reviewed-by: Scott Branden <scott.branden@broadcom.com>
2017-08-28 21:43:35 +00:00
|
|
|
if (assert) {
|
|
|
|
val = iproc_pcie_read_reg(pcie, IPROC_PCIE_CLK_CTRL);
|
|
|
|
val &= ~EP_PERST_SOURCE_SELECT & ~EP_MODE_SURVIVE_PERST &
|
|
|
|
~RC_PCIE_RST_OUTPUT;
|
|
|
|
iproc_pcie_write_reg(pcie, IPROC_PCIE_CLK_CTRL, val);
|
|
|
|
udelay(250);
|
|
|
|
} else {
|
|
|
|
val = iproc_pcie_read_reg(pcie, IPROC_PCIE_CLK_CTRL);
|
|
|
|
val |= RC_PCIE_RST_OUTPUT;
|
|
|
|
iproc_pcie_write_reg(pcie, IPROC_PCIE_CLK_CTRL, val);
|
|
|
|
msleep(100);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
int iproc_pcie_shutdown(struct iproc_pcie *pcie)
|
|
|
|
{
|
|
|
|
iproc_pcie_perst_ctrl(pcie, true);
|
|
|
|
msleep(500);
|
|
|
|
|
|
|
|
return 0;
|
2015-04-08 18:21:35 +00:00
|
|
|
}
|
PCI: iproc: Add 500ms delay during device shutdown
During soft reset (e.g., "reboot" from Linux) on some iProc-based SOCs, the
LCPLL clock and PERST both go off simultaneously. This seems in accordance
with the PCIe Card Electromechanical spec, r2.0, sec 2.2.3, which says the
clock goes inactive after PERST# goes active, but doesn't specify how long
the clock should be valid after PERST#.
However, we have observed that with the iProc Stingray, some Intel NVMe
endpoints, e.g., the P3700 400GB series, are not detected correctly upon
the next boot sequence unless the clock remains valid for some time after
PERST# is asserted.
Delay 500ms after asserting PERST# before performing a reboot. The 500ms
is experimentally determined.
Signed-off-by: Oza Pawandeep <oza.oza@broadcom.com>
[bhelgaas: changelog, add spec reference, fold in iproc_pcie_shutdown()
export from Arnd Bergmann <arnd@arndb.de>]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Ray Jui <ray.jui@broadcom.com>
Reviewed-by: Scott Branden <scott.branden@broadcom.com>
2017-08-28 21:43:35 +00:00
|
|
|
EXPORT_SYMBOL_GPL(iproc_pcie_shutdown);
|
2015-04-08 18:21:35 +00:00
|
|
|
|
2017-06-28 20:13:50 +00:00
|
|
|
static int iproc_pcie_check_link(struct iproc_pcie *pcie)
|
2015-04-08 18:21:35 +00:00
|
|
|
{
|
2016-10-06 18:36:08 +00:00
|
|
|
struct device *dev = pcie->dev;
|
2017-06-28 20:13:50 +00:00
|
|
|
u32 hdr_type, link_ctrl, link_status, class, val;
|
2015-09-16 00:39:19 +00:00
|
|
|
bool link_is_active = false;
|
|
|
|
|
2015-12-04 17:34:59 +00:00
|
|
|
/*
|
|
|
|
* PAXC connects to emulated endpoint devices directly and does not
|
|
|
|
* have a Serdes. Therefore skip the link detection logic here.
|
|
|
|
*/
|
2016-11-01 00:38:30 +00:00
|
|
|
if (pcie->ep_is_internal)
|
2015-12-04 17:34:59 +00:00
|
|
|
return 0;
|
|
|
|
|
|
|
|
val = iproc_pcie_read_reg(pcie, IPROC_PCIE_LINK_STATUS);
|
2015-09-16 00:39:19 +00:00
|
|
|
if (!(val & PCIE_PHYLINKUP) || !(val & PCIE_DL_ACTIVE)) {
|
2016-10-06 18:36:08 +00:00
|
|
|
dev_err(dev, "PHY or data link is INACTIVE!\n");
|
2015-09-16 00:39:19 +00:00
|
|
|
return -ENODEV;
|
|
|
|
}
|
2015-04-08 18:21:35 +00:00
|
|
|
|
|
|
|
/* make sure we are not in EP mode */
|
2017-09-05 17:33:33 +00:00
|
|
|
iproc_pci_raw_config_read32(pcie, 0, PCI_HEADER_TYPE, 1, &hdr_type);
|
2015-04-08 18:21:35 +00:00
|
|
|
if ((hdr_type & 0x7f) != PCI_HEADER_TYPE_BRIDGE) {
|
2016-10-06 18:36:08 +00:00
|
|
|
dev_err(dev, "in EP mode, hdr=%#02x\n", hdr_type);
|
2015-04-08 18:21:35 +00:00
|
|
|
return -EFAULT;
|
|
|
|
}
|
|
|
|
|
2022-02-14 11:41:09 +00:00
|
|
|
/* force class to PCI_CLASS_BRIDGE_PCI_NORMAL (0x060400) */
|
2017-09-05 17:33:33 +00:00
|
|
|
#define PCI_BRIDGE_CTRL_REG_OFFSET 0x43c
|
2022-02-14 11:41:09 +00:00
|
|
|
#define PCI_BRIDGE_CTRL_REG_CLASS_MASK 0xffffff
|
2017-06-28 20:13:50 +00:00
|
|
|
iproc_pci_raw_config_read32(pcie, 0, PCI_BRIDGE_CTRL_REG_OFFSET,
|
|
|
|
4, &class);
|
2022-02-14 11:41:09 +00:00
|
|
|
class &= ~PCI_BRIDGE_CTRL_REG_CLASS_MASK;
|
|
|
|
class |= PCI_CLASS_BRIDGE_PCI_NORMAL;
|
2017-06-28 20:13:50 +00:00
|
|
|
iproc_pci_raw_config_write32(pcie, 0, PCI_BRIDGE_CTRL_REG_OFFSET,
|
|
|
|
4, class);
|
2015-04-08 18:21:35 +00:00
|
|
|
|
|
|
|
/* check link status to see if link is active */
|
2017-09-05 17:27:11 +00:00
|
|
|
iproc_pci_raw_config_read32(pcie, 0, IPROC_PCI_EXP_CAP + PCI_EXP_LNKSTA,
|
2017-06-28 20:13:50 +00:00
|
|
|
2, &link_status);
|
2015-04-08 18:21:35 +00:00
|
|
|
if (link_status & PCI_EXP_LNKSTA_NLW)
|
2015-09-16 00:39:19 +00:00
|
|
|
link_is_active = true;
|
2015-04-08 18:21:35 +00:00
|
|
|
|
|
|
|
if (!link_is_active) {
|
|
|
|
/* try GEN 1 link speed */
|
2017-09-05 17:33:33 +00:00
|
|
|
#define PCI_TARGET_LINK_SPEED_MASK 0xf
|
|
|
|
#define PCI_TARGET_LINK_SPEED_GEN2 0x2
|
|
|
|
#define PCI_TARGET_LINK_SPEED_GEN1 0x1
|
2017-06-28 20:13:50 +00:00
|
|
|
iproc_pci_raw_config_read32(pcie, 0,
|
2017-09-05 17:27:11 +00:00
|
|
|
IPROC_PCI_EXP_CAP + PCI_EXP_LNKCTL2,
|
|
|
|
4, &link_ctrl);
|
2015-04-08 18:21:35 +00:00
|
|
|
if ((link_ctrl & PCI_TARGET_LINK_SPEED_MASK) ==
|
|
|
|
PCI_TARGET_LINK_SPEED_GEN2) {
|
|
|
|
link_ctrl &= ~PCI_TARGET_LINK_SPEED_MASK;
|
|
|
|
link_ctrl |= PCI_TARGET_LINK_SPEED_GEN1;
|
2017-06-28 20:13:50 +00:00
|
|
|
iproc_pci_raw_config_write32(pcie, 0,
|
2017-09-05 17:27:11 +00:00
|
|
|
IPROC_PCI_EXP_CAP + PCI_EXP_LNKCTL2,
|
|
|
|
4, link_ctrl);
|
2015-04-08 18:21:35 +00:00
|
|
|
msleep(100);
|
|
|
|
|
2017-06-28 20:13:50 +00:00
|
|
|
iproc_pci_raw_config_read32(pcie, 0,
|
2017-09-05 17:27:11 +00:00
|
|
|
IPROC_PCI_EXP_CAP + PCI_EXP_LNKSTA,
|
|
|
|
2, &link_status);
|
2015-04-08 18:21:35 +00:00
|
|
|
if (link_status & PCI_EXP_LNKSTA_NLW)
|
2015-09-16 00:39:19 +00:00
|
|
|
link_is_active = true;
|
2015-04-08 18:21:35 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-10-06 18:36:08 +00:00
|
|
|
dev_info(dev, "link: %s\n", link_is_active ? "UP" : "DOWN");
|
2015-04-08 18:21:35 +00:00
|
|
|
|
|
|
|
return link_is_active ? 0 : -ENODEV;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void iproc_pcie_enable(struct iproc_pcie *pcie)
|
|
|
|
{
|
2015-12-04 17:34:59 +00:00
|
|
|
iproc_pcie_write_reg(pcie, IPROC_PCIE_INTX_EN, SYS_RC_INTX_MASK);
|
2015-04-08 18:21:35 +00:00
|
|
|
}
|
|
|
|
|
2016-11-01 00:38:37 +00:00
|
|
|
static inline bool iproc_pcie_ob_is_valid(struct iproc_pcie *pcie,
|
|
|
|
int window_idx)
|
|
|
|
{
|
|
|
|
u32 val;
|
|
|
|
|
|
|
|
val = iproc_pcie_read_reg(pcie, MAP_REG(IPROC_PCIE_OARR0, window_idx));
|
|
|
|
|
|
|
|
return !!(val & OARR_VALID);
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline int iproc_pcie_ob_write(struct iproc_pcie *pcie, int window_idx,
|
|
|
|
int size_idx, u64 axi_addr, u64 pci_addr)
|
|
|
|
{
|
|
|
|
struct device *dev = pcie->dev;
|
|
|
|
u16 oarr_offset, omap_offset;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Derive the OARR/OMAP offset from the first pair (OARR0/OMAP0) based
|
|
|
|
* on window index.
|
|
|
|
*/
|
|
|
|
oarr_offset = iproc_pcie_reg_offset(pcie, MAP_REG(IPROC_PCIE_OARR0,
|
|
|
|
window_idx));
|
|
|
|
omap_offset = iproc_pcie_reg_offset(pcie, MAP_REG(IPROC_PCIE_OMAP0,
|
|
|
|
window_idx));
|
|
|
|
if (iproc_pcie_reg_is_invalid(oarr_offset) ||
|
|
|
|
iproc_pcie_reg_is_invalid(omap_offset))
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Program the OARR registers. The upper 32-bit OARR register is
|
|
|
|
* always right after the lower 32-bit OARR register.
|
|
|
|
*/
|
|
|
|
writel(lower_32_bits(axi_addr) | (size_idx << OARR_SIZE_CFG_SHIFT) |
|
|
|
|
OARR_VALID, pcie->base + oarr_offset);
|
|
|
|
writel(upper_32_bits(axi_addr), pcie->base + oarr_offset + 4);
|
|
|
|
|
|
|
|
/* now program the OMAP registers */
|
|
|
|
writel(lower_32_bits(pci_addr), pcie->base + omap_offset);
|
|
|
|
writel(upper_32_bits(pci_addr), pcie->base + omap_offset + 4);
|
|
|
|
|
2018-06-12 00:21:07 +00:00
|
|
|
dev_dbg(dev, "ob window [%d]: offset 0x%x axi %pap pci %pap\n",
|
|
|
|
window_idx, oarr_offset, &axi_addr, &pci_addr);
|
|
|
|
dev_dbg(dev, "oarr lo 0x%x oarr hi 0x%x\n",
|
|
|
|
readl(pcie->base + oarr_offset),
|
|
|
|
readl(pcie->base + oarr_offset + 4));
|
|
|
|
dev_dbg(dev, "omap lo 0x%x omap hi 0x%x\n",
|
|
|
|
readl(pcie->base + omap_offset),
|
|
|
|
readl(pcie->base + omap_offset + 4));
|
2016-11-01 00:38:37 +00:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2021-07-03 15:13:02 +00:00
|
|
|
/*
|
2015-10-16 13:18:24 +00:00
|
|
|
* Some iProc SoCs require the SW to configure the outbound address mapping
|
|
|
|
*
|
|
|
|
* Outbound address translation:
|
|
|
|
*
|
|
|
|
* iproc_pcie_address = axi_address - axi_offset
|
|
|
|
* OARR = iproc_pcie_address
|
|
|
|
* OMAP = pci_addr
|
|
|
|
*
|
|
|
|
* axi_addr -> iproc_pcie_address -> OARR -> OMAP -> pci_address
|
|
|
|
*/
|
|
|
|
static int iproc_pcie_setup_ob(struct iproc_pcie *pcie, u64 axi_addr,
|
|
|
|
u64 pci_addr, resource_size_t size)
|
|
|
|
{
|
|
|
|
struct iproc_pcie_ob *ob = &pcie->ob;
|
2016-10-06 18:36:08 +00:00
|
|
|
struct device *dev = pcie->dev;
|
2016-11-01 00:38:37 +00:00
|
|
|
int ret = -EINVAL, window_idx, size_idx;
|
2015-10-16 13:18:24 +00:00
|
|
|
|
|
|
|
if (axi_addr < ob->axi_offset) {
|
2016-10-06 18:36:08 +00:00
|
|
|
dev_err(dev, "axi address %pap less than offset %pap\n",
|
2015-10-16 13:18:24 +00:00
|
|
|
&axi_addr, &ob->axi_offset);
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Translate the AXI address to the internal address used by the iProc
|
|
|
|
* PCIe core before programming the OARR
|
|
|
|
*/
|
|
|
|
axi_addr -= ob->axi_offset;
|
|
|
|
|
2016-11-01 00:38:37 +00:00
|
|
|
/* iterate through all OARR/OMAP mapping windows */
|
|
|
|
for (window_idx = ob->nr_windows - 1; window_idx >= 0; window_idx--) {
|
|
|
|
const struct iproc_pcie_ob_map *ob_map =
|
|
|
|
&pcie->ob_map[window_idx];
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If current outbound window is already in use, move on to the
|
|
|
|
* next one.
|
|
|
|
*/
|
|
|
|
if (iproc_pcie_ob_is_valid(pcie, window_idx))
|
|
|
|
continue;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Iterate through all supported window sizes within the
|
|
|
|
* OARR/OMAP pair to find a match. Go through the window sizes
|
|
|
|
* in a descending order.
|
|
|
|
*/
|
|
|
|
for (size_idx = ob_map->nr_sizes - 1; size_idx >= 0;
|
|
|
|
size_idx--) {
|
|
|
|
resource_size_t window_size =
|
|
|
|
ob_map->window_sizes[size_idx] * SZ_1M;
|
|
|
|
|
2019-03-01 04:52:16 +00:00
|
|
|
/*
|
|
|
|
* Keep iterating until we reach the last window and
|
|
|
|
* with the minimal window size at index zero. In this
|
|
|
|
* case, we take a compromise by mapping it using the
|
|
|
|
* minimum window size that can be supported
|
|
|
|
*/
|
|
|
|
if (size < window_size) {
|
|
|
|
if (size_idx > 0 || window_idx > 0)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* For the corner case of reaching the minimal
|
|
|
|
* window size that can be supported on the
|
|
|
|
* last window
|
|
|
|
*/
|
|
|
|
axi_addr = ALIGN_DOWN(axi_addr, window_size);
|
|
|
|
pci_addr = ALIGN_DOWN(pci_addr, window_size);
|
|
|
|
size = window_size;
|
|
|
|
}
|
2016-11-01 00:38:37 +00:00
|
|
|
|
|
|
|
if (!IS_ALIGNED(axi_addr, window_size) ||
|
|
|
|
!IS_ALIGNED(pci_addr, window_size)) {
|
|
|
|
dev_err(dev,
|
|
|
|
"axi %pap or pci %pap not aligned\n",
|
|
|
|
&axi_addr, &pci_addr);
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Match found! Program both OARR and OMAP and mark
|
|
|
|
* them as a valid entry.
|
|
|
|
*/
|
|
|
|
ret = iproc_pcie_ob_write(pcie, window_idx, size_idx,
|
|
|
|
axi_addr, pci_addr);
|
|
|
|
if (ret)
|
|
|
|
goto err_ob;
|
|
|
|
|
|
|
|
size -= window_size;
|
|
|
|
if (size == 0)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If we are here, we are done with the current window,
|
|
|
|
* but not yet finished all mappings. Need to move on
|
|
|
|
* to the next window.
|
|
|
|
*/
|
|
|
|
axi_addr += window_size;
|
|
|
|
pci_addr += window_size;
|
2015-10-16 13:18:24 +00:00
|
|
|
break;
|
2016-11-01 00:38:37 +00:00
|
|
|
}
|
2015-10-16 13:18:24 +00:00
|
|
|
}
|
|
|
|
|
2016-11-01 00:38:37 +00:00
|
|
|
err_ob:
|
|
|
|
dev_err(dev, "unable to configure outbound mapping\n");
|
|
|
|
dev_err(dev,
|
|
|
|
"axi %pap, axi offset %pap, pci %pap, res size %pap\n",
|
|
|
|
&axi_addr, &ob->axi_offset, &pci_addr, &size);
|
|
|
|
|
|
|
|
return ret;
|
2015-10-16 13:18:24 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static int iproc_pcie_map_ranges(struct iproc_pcie *pcie,
|
|
|
|
struct list_head *resources)
|
|
|
|
{
|
2016-10-06 18:36:08 +00:00
|
|
|
struct device *dev = pcie->dev;
|
2015-10-16 13:18:24 +00:00
|
|
|
struct resource_entry *window;
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
resource_list_for_each_entry(window, resources) {
|
|
|
|
struct resource *res = window->res;
|
|
|
|
u64 res_type = resource_type(res);
|
|
|
|
|
|
|
|
switch (res_type) {
|
|
|
|
case IORESOURCE_IO:
|
|
|
|
case IORESOURCE_BUS:
|
|
|
|
break;
|
|
|
|
case IORESOURCE_MEM:
|
|
|
|
ret = iproc_pcie_setup_ob(pcie, res->start,
|
|
|
|
res->start - window->offset,
|
|
|
|
resource_size(res));
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
break;
|
|
|
|
default:
|
2016-10-06 18:36:08 +00:00
|
|
|
dev_err(dev, "invalid resource %pR\n", res);
|
2015-10-16 13:18:24 +00:00
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2016-11-01 00:38:39 +00:00
|
|
|
static inline bool iproc_pcie_ib_is_in_use(struct iproc_pcie *pcie,
|
|
|
|
int region_idx)
|
|
|
|
{
|
|
|
|
const struct iproc_pcie_ib_map *ib_map = &pcie->ib_map[region_idx];
|
|
|
|
u32 val;
|
|
|
|
|
|
|
|
val = iproc_pcie_read_reg(pcie, MAP_REG(IPROC_PCIE_IARR0, region_idx));
|
|
|
|
|
|
|
|
return !!(val & (BIT(ib_map->nr_sizes) - 1));
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline bool iproc_pcie_ib_check_type(const struct iproc_pcie_ib_map *ib_map,
|
|
|
|
enum iproc_pcie_ib_map_type type)
|
|
|
|
{
|
|
|
|
return !!(ib_map->type == type);
|
|
|
|
}
|
|
|
|
|
|
|
|
static int iproc_pcie_ib_write(struct iproc_pcie *pcie, int region_idx,
|
|
|
|
int size_idx, int nr_windows, u64 axi_addr,
|
|
|
|
u64 pci_addr, resource_size_t size)
|
|
|
|
{
|
|
|
|
struct device *dev = pcie->dev;
|
|
|
|
const struct iproc_pcie_ib_map *ib_map = &pcie->ib_map[region_idx];
|
|
|
|
u16 iarr_offset, imap_offset;
|
|
|
|
u32 val;
|
|
|
|
int window_idx;
|
|
|
|
|
|
|
|
iarr_offset = iproc_pcie_reg_offset(pcie,
|
|
|
|
MAP_REG(IPROC_PCIE_IARR0, region_idx));
|
|
|
|
imap_offset = iproc_pcie_reg_offset(pcie,
|
|
|
|
MAP_REG(IPROC_PCIE_IMAP0, region_idx));
|
|
|
|
if (iproc_pcie_reg_is_invalid(iarr_offset) ||
|
|
|
|
iproc_pcie_reg_is_invalid(imap_offset))
|
|
|
|
return -EINVAL;
|
|
|
|
|
2018-06-12 00:21:07 +00:00
|
|
|
dev_dbg(dev, "ib region [%d]: offset 0x%x axi %pap pci %pap\n",
|
|
|
|
region_idx, iarr_offset, &axi_addr, &pci_addr);
|
2016-11-01 00:38:39 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Program the IARR registers. The upper 32-bit IARR register is
|
|
|
|
* always right after the lower 32-bit IARR register.
|
|
|
|
*/
|
|
|
|
writel(lower_32_bits(pci_addr) | BIT(size_idx),
|
|
|
|
pcie->base + iarr_offset);
|
|
|
|
writel(upper_32_bits(pci_addr), pcie->base + iarr_offset + 4);
|
|
|
|
|
2018-06-12 00:21:07 +00:00
|
|
|
dev_dbg(dev, "iarr lo 0x%x iarr hi 0x%x\n",
|
|
|
|
readl(pcie->base + iarr_offset),
|
|
|
|
readl(pcie->base + iarr_offset + 4));
|
2016-11-01 00:38:39 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Now program the IMAP registers. Each IARR region may have one or
|
|
|
|
* more IMAP windows.
|
|
|
|
*/
|
|
|
|
size >>= ilog2(nr_windows);
|
|
|
|
for (window_idx = 0; window_idx < nr_windows; window_idx++) {
|
|
|
|
val = readl(pcie->base + imap_offset);
|
|
|
|
val |= lower_32_bits(axi_addr) | IMAP_VALID;
|
|
|
|
writel(val, pcie->base + imap_offset);
|
|
|
|
writel(upper_32_bits(axi_addr),
|
|
|
|
pcie->base + imap_offset + ib_map->imap_addr_offset);
|
|
|
|
|
2018-06-12 00:21:07 +00:00
|
|
|
dev_dbg(dev, "imap window [%d] lo 0x%x hi 0x%x\n",
|
|
|
|
window_idx, readl(pcie->base + imap_offset),
|
|
|
|
readl(pcie->base + imap_offset +
|
|
|
|
ib_map->imap_addr_offset));
|
2016-11-01 00:38:39 +00:00
|
|
|
|
|
|
|
imap_offset += ib_map->imap_window_offset;
|
|
|
|
axi_addr += size;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int iproc_pcie_setup_ib(struct iproc_pcie *pcie,
|
2019-10-28 16:32:54 +00:00
|
|
|
struct resource_entry *entry,
|
2016-11-01 00:38:39 +00:00
|
|
|
enum iproc_pcie_ib_map_type type)
|
|
|
|
{
|
|
|
|
struct device *dev = pcie->dev;
|
|
|
|
struct iproc_pcie_ib *ib = &pcie->ib;
|
|
|
|
int ret;
|
|
|
|
unsigned int region_idx, size_idx;
|
2019-10-28 16:32:54 +00:00
|
|
|
u64 axi_addr = entry->res->start;
|
|
|
|
u64 pci_addr = entry->res->start - entry->offset;
|
|
|
|
resource_size_t size = resource_size(entry->res);
|
2016-11-01 00:38:39 +00:00
|
|
|
|
|
|
|
/* iterate through all IARR mapping regions */
|
|
|
|
for (region_idx = 0; region_idx < ib->nr_regions; region_idx++) {
|
|
|
|
const struct iproc_pcie_ib_map *ib_map =
|
|
|
|
&pcie->ib_map[region_idx];
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If current inbound region is already in use or not a
|
|
|
|
* compatible type, move on to the next.
|
|
|
|
*/
|
|
|
|
if (iproc_pcie_ib_is_in_use(pcie, region_idx) ||
|
|
|
|
!iproc_pcie_ib_check_type(ib_map, type))
|
|
|
|
continue;
|
|
|
|
|
|
|
|
/* iterate through all supported region sizes to find a match */
|
|
|
|
for (size_idx = 0; size_idx < ib_map->nr_sizes; size_idx++) {
|
|
|
|
resource_size_t region_size =
|
|
|
|
ib_map->region_sizes[size_idx] * ib_map->size_unit;
|
|
|
|
|
|
|
|
if (size != region_size)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
if (!IS_ALIGNED(axi_addr, region_size) ||
|
|
|
|
!IS_ALIGNED(pci_addr, region_size)) {
|
|
|
|
dev_err(dev,
|
|
|
|
"axi %pap or pci %pap not aligned\n",
|
|
|
|
&axi_addr, &pci_addr);
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Match found! Program IARR and all IMAP windows. */
|
|
|
|
ret = iproc_pcie_ib_write(pcie, region_idx, size_idx,
|
|
|
|
ib_map->nr_windows, axi_addr,
|
|
|
|
pci_addr, size);
|
|
|
|
if (ret)
|
|
|
|
goto err_ib;
|
|
|
|
else
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
}
|
|
|
|
}
|
|
|
|
ret = -EINVAL;
|
|
|
|
|
|
|
|
err_ib:
|
|
|
|
dev_err(dev, "unable to configure inbound mapping\n");
|
|
|
|
dev_err(dev, "axi %pap, pci %pap, res size %pap\n",
|
|
|
|
&axi_addr, &pci_addr, &size);
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int iproc_pcie_map_dma_ranges(struct iproc_pcie *pcie)
|
|
|
|
{
|
2019-05-03 14:05:34 +00:00
|
|
|
struct pci_host_bridge *host = pci_host_bridge_from_priv(pcie);
|
2019-10-28 16:32:54 +00:00
|
|
|
struct resource_entry *entry;
|
|
|
|
int ret = 0;
|
2016-11-01 00:38:39 +00:00
|
|
|
|
2019-10-28 16:32:54 +00:00
|
|
|
resource_list_for_each_entry(entry, &host->dma_ranges) {
|
2016-11-01 00:38:39 +00:00
|
|
|
/* Each range entry corresponds to an inbound mapping region */
|
2019-10-28 16:32:54 +00:00
|
|
|
ret = iproc_pcie_setup_ib(pcie, entry, IPROC_PCIE_IB_MAP_MEM);
|
2016-11-01 00:38:39 +00:00
|
|
|
if (ret)
|
2019-10-28 16:32:54 +00:00
|
|
|
break;
|
2016-11-01 00:38:39 +00:00
|
|
|
}
|
|
|
|
|
2019-05-03 14:05:34 +00:00
|
|
|
return ret;
|
2016-11-01 00:38:39 +00:00
|
|
|
}
|
|
|
|
|
2019-09-06 03:58:13 +00:00
|
|
|
static void iproc_pcie_invalidate_mapping(struct iproc_pcie *pcie)
|
|
|
|
{
|
|
|
|
struct iproc_pcie_ib *ib = &pcie->ib;
|
|
|
|
struct iproc_pcie_ob *ob = &pcie->ob;
|
|
|
|
int idx;
|
|
|
|
|
|
|
|
if (pcie->ep_is_internal)
|
|
|
|
return;
|
|
|
|
|
|
|
|
if (pcie->need_ob_cfg) {
|
|
|
|
/* iterate through all OARR mapping regions */
|
|
|
|
for (idx = ob->nr_windows - 1; idx >= 0; idx--) {
|
|
|
|
iproc_pcie_write_reg(pcie,
|
|
|
|
MAP_REG(IPROC_PCIE_OARR0, idx), 0);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (pcie->need_ib_cfg) {
|
|
|
|
/* iterate through all IARR mapping regions */
|
|
|
|
for (idx = 0; idx < ib->nr_regions; idx++) {
|
|
|
|
iproc_pcie_write_reg(pcie,
|
|
|
|
MAP_REG(IPROC_PCIE_IARR0, idx), 0);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-11-01 00:38:35 +00:00
|
|
|
static int iproce_pcie_get_msi(struct iproc_pcie *pcie,
|
|
|
|
struct device_node *msi_node,
|
|
|
|
u64 *msi_addr)
|
|
|
|
{
|
|
|
|
struct device *dev = pcie->dev;
|
|
|
|
int ret;
|
|
|
|
struct resource res;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Check if 'msi-map' points to ARM GICv3 ITS, which is the only
|
|
|
|
* supported external MSI controller that requires steering.
|
|
|
|
*/
|
|
|
|
if (!of_device_is_compatible(msi_node, "arm,gic-v3-its")) {
|
|
|
|
dev_err(dev, "unable to find compatible MSI controller\n");
|
|
|
|
return -ENODEV;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* derive GITS_TRANSLATER address from GICv3 */
|
|
|
|
ret = of_address_to_resource(msi_node, 0, &res);
|
|
|
|
if (ret < 0) {
|
|
|
|
dev_err(dev, "unable to obtain MSI controller resources\n");
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
*msi_addr = res.start + GITS_TRANSLATER;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2016-11-01 00:38:41 +00:00
|
|
|
static int iproc_pcie_paxb_v2_msi_steer(struct iproc_pcie *pcie, u64 msi_addr)
|
|
|
|
{
|
|
|
|
int ret;
|
2019-10-28 16:32:54 +00:00
|
|
|
struct resource_entry entry;
|
|
|
|
|
|
|
|
memset(&entry, 0, sizeof(entry));
|
|
|
|
entry.res = &entry.__res;
|
2016-11-01 00:38:41 +00:00
|
|
|
|
2019-10-28 16:32:54 +00:00
|
|
|
msi_addr &= ~(SZ_32K - 1);
|
|
|
|
entry.res->start = msi_addr;
|
|
|
|
entry.res->end = msi_addr + SZ_32K - 1;
|
2016-11-01 00:38:41 +00:00
|
|
|
|
2019-10-28 16:32:54 +00:00
|
|
|
ret = iproc_pcie_setup_ib(pcie, &entry, IPROC_PCIE_IB_MAP_IO);
|
2016-11-01 00:38:41 +00:00
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2018-06-12 00:21:05 +00:00
|
|
|
static void iproc_pcie_paxc_v2_msi_steer(struct iproc_pcie *pcie, u64 msi_addr,
|
|
|
|
bool enable)
|
2016-11-01 00:38:35 +00:00
|
|
|
{
|
|
|
|
u32 val;
|
|
|
|
|
2018-06-12 00:21:05 +00:00
|
|
|
if (!enable) {
|
|
|
|
/*
|
|
|
|
* Disable PAXC MSI steering. All write transfers will be
|
|
|
|
* treated as non-MSI transfers
|
|
|
|
*/
|
|
|
|
val = iproc_pcie_read_reg(pcie, IPROC_PCIE_MSI_EN_CFG);
|
|
|
|
val &= ~MSI_ENABLE_CFG;
|
|
|
|
iproc_pcie_write_reg(pcie, IPROC_PCIE_MSI_EN_CFG, val);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2016-11-01 00:38:35 +00:00
|
|
|
/*
|
|
|
|
* Program bits [43:13] of address of GITS_TRANSLATER register into
|
|
|
|
* bits [30:0] of the MSI base address register. In fact, in all iProc
|
|
|
|
* based SoCs, all I/O register bases are well below the 32-bit
|
|
|
|
* boundary, so we can safely assume bits [43:32] are always zeros.
|
|
|
|
*/
|
|
|
|
iproc_pcie_write_reg(pcie, IPROC_PCIE_MSI_BASE_ADDR,
|
|
|
|
(u32)(msi_addr >> 13));
|
|
|
|
|
|
|
|
/* use a default 8K window size */
|
|
|
|
iproc_pcie_write_reg(pcie, IPROC_PCIE_MSI_WINDOW_SIZE, 0);
|
|
|
|
|
|
|
|
/* steering MSI to GICv3 ITS */
|
|
|
|
val = iproc_pcie_read_reg(pcie, IPROC_PCIE_MSI_GIC_MODE);
|
|
|
|
val |= GIC_V3_CFG;
|
|
|
|
iproc_pcie_write_reg(pcie, IPROC_PCIE_MSI_GIC_MODE, val);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Program bits [43:2] of address of GITS_TRANSLATER register into the
|
|
|
|
* iProc MSI address registers.
|
|
|
|
*/
|
|
|
|
msi_addr >>= 2;
|
|
|
|
iproc_pcie_write_reg(pcie, IPROC_PCIE_MSI_ADDR_HI,
|
|
|
|
upper_32_bits(msi_addr));
|
|
|
|
iproc_pcie_write_reg(pcie, IPROC_PCIE_MSI_ADDR_LO,
|
|
|
|
lower_32_bits(msi_addr));
|
|
|
|
|
|
|
|
/* enable MSI */
|
|
|
|
val = iproc_pcie_read_reg(pcie, IPROC_PCIE_MSI_EN_CFG);
|
|
|
|
val |= MSI_ENABLE_CFG;
|
|
|
|
iproc_pcie_write_reg(pcie, IPROC_PCIE_MSI_EN_CFG, val);
|
|
|
|
}
|
|
|
|
|
|
|
|
static int iproc_pcie_msi_steer(struct iproc_pcie *pcie,
|
|
|
|
struct device_node *msi_node)
|
|
|
|
{
|
|
|
|
struct device *dev = pcie->dev;
|
|
|
|
int ret;
|
|
|
|
u64 msi_addr;
|
|
|
|
|
|
|
|
ret = iproce_pcie_get_msi(pcie, msi_node, &msi_addr);
|
|
|
|
if (ret < 0) {
|
|
|
|
dev_err(dev, "msi steering failed\n");
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
switch (pcie->type) {
|
2016-11-01 00:38:41 +00:00
|
|
|
case IPROC_PCIE_PAXB_V2:
|
|
|
|
ret = iproc_pcie_paxb_v2_msi_steer(pcie, msi_addr);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
break;
|
2016-11-01 00:38:35 +00:00
|
|
|
case IPROC_PCIE_PAXC_V2:
|
2018-06-12 00:21:05 +00:00
|
|
|
iproc_pcie_paxc_v2_msi_steer(pcie, msi_addr, true);
|
2016-11-01 00:38:35 +00:00
|
|
|
break;
|
|
|
|
default:
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2016-01-07 00:04:35 +00:00
|
|
|
static int iproc_pcie_msi_enable(struct iproc_pcie *pcie)
|
|
|
|
{
|
|
|
|
struct device_node *msi_node;
|
2016-11-01 00:38:35 +00:00
|
|
|
int ret;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Either the "msi-parent" or the "msi-map" phandle needs to exist
|
|
|
|
* for us to obtain the MSI node.
|
|
|
|
*/
|
2016-01-07 00:04:35 +00:00
|
|
|
|
|
|
|
msi_node = of_parse_phandle(pcie->dev->of_node, "msi-parent", 0);
|
2016-11-01 00:38:35 +00:00
|
|
|
if (!msi_node) {
|
|
|
|
const __be32 *msi_map = NULL;
|
|
|
|
int len;
|
|
|
|
u32 phandle;
|
|
|
|
|
|
|
|
msi_map = of_get_property(pcie->dev->of_node, "msi-map", &len);
|
|
|
|
if (!msi_map)
|
|
|
|
return -ENODEV;
|
|
|
|
|
|
|
|
phandle = be32_to_cpup(msi_map + 1);
|
|
|
|
msi_node = of_find_node_by_phandle(phandle);
|
|
|
|
if (!msi_node)
|
|
|
|
return -ENODEV;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Certain revisions of the iProc PCIe controller require additional
|
|
|
|
* configurations to steer the MSI writes towards an external MSI
|
|
|
|
* controller.
|
|
|
|
*/
|
|
|
|
if (pcie->need_msi_steer) {
|
|
|
|
ret = iproc_pcie_msi_steer(pcie, msi_node);
|
|
|
|
if (ret)
|
2019-02-27 04:40:41 +00:00
|
|
|
goto out_put_node;
|
2016-11-01 00:38:35 +00:00
|
|
|
}
|
2016-01-07 00:04:35 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* If another MSI controller is being used, the call below should fail
|
|
|
|
* but that is okay
|
|
|
|
*/
|
2019-02-27 04:40:41 +00:00
|
|
|
ret = iproc_msi_init(pcie, msi_node);
|
|
|
|
|
|
|
|
out_put_node:
|
|
|
|
of_node_put(msi_node);
|
|
|
|
return ret;
|
2016-01-07 00:04:35 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static void iproc_pcie_msi_disable(struct iproc_pcie *pcie)
|
|
|
|
{
|
|
|
|
iproc_msi_exit(pcie);
|
|
|
|
}
|
|
|
|
|
2016-11-01 00:38:30 +00:00
|
|
|
static int iproc_pcie_rev_init(struct iproc_pcie *pcie)
|
|
|
|
{
|
|
|
|
struct device *dev = pcie->dev;
|
|
|
|
unsigned int reg_idx;
|
|
|
|
const u16 *regs;
|
|
|
|
|
|
|
|
switch (pcie->type) {
|
2016-11-01 00:38:32 +00:00
|
|
|
case IPROC_PCIE_PAXB_BCMA:
|
|
|
|
regs = iproc_pcie_reg_paxb_bcma;
|
|
|
|
break;
|
2016-11-01 00:38:30 +00:00
|
|
|
case IPROC_PCIE_PAXB:
|
|
|
|
regs = iproc_pcie_reg_paxb;
|
2016-11-01 00:38:33 +00:00
|
|
|
pcie->has_apb_err_disable = true;
|
2016-11-01 00:38:37 +00:00
|
|
|
if (pcie->need_ob_cfg) {
|
|
|
|
pcie->ob_map = paxb_ob_map;
|
|
|
|
pcie->ob.nr_windows = ARRAY_SIZE(paxb_ob_map);
|
|
|
|
}
|
2016-11-01 00:38:30 +00:00
|
|
|
break;
|
2016-11-01 00:38:41 +00:00
|
|
|
case IPROC_PCIE_PAXB_V2:
|
|
|
|
regs = iproc_pcie_reg_paxb_v2;
|
2019-04-26 09:20:04 +00:00
|
|
|
pcie->iproc_cfg_read = true;
|
2016-11-01 00:38:41 +00:00
|
|
|
pcie->has_apb_err_disable = true;
|
|
|
|
if (pcie->need_ob_cfg) {
|
|
|
|
pcie->ob_map = paxb_v2_ob_map;
|
|
|
|
pcie->ob.nr_windows = ARRAY_SIZE(paxb_v2_ob_map);
|
|
|
|
}
|
|
|
|
pcie->ib.nr_regions = ARRAY_SIZE(paxb_v2_ib_map);
|
|
|
|
pcie->ib_map = paxb_v2_ib_map;
|
|
|
|
pcie->need_msi_steer = true;
|
PCI: iproc: Work around Stingray CRS defects
Configuration Request Retry Status ("CRS") completions are a required part
of PCIe. A PCIe device may respond to config a request with a CRS
completion to indicate that it needs more time to initialize. A Root Port
that receives a CRS completion may automatically retry the request, or it
may treat the request as a failed transaction. For a failed read, it will
likely synthesize all 1's data, i.e., 0xffffffff, to complete the read to
the CPU.
CRS Software Visibility ("CRS SV") is an optional feature. Per PCIe r3.1,
sec 2.3.2, if supported and enabled, a Root Port that receives a CRS
completion for a config read of the Vendor ID will synthesize 0x0001 data
(an invalid Vendor ID) instead of retrying or failing the transaction. The
0x0001 data makes the CRS completion visible to software, so it can perform
other tasks while waiting for the device.
The iProc "Stingray" PCIe controller does not support CRS completions
correctly. From the Stingray PCIe Controller spec:
4.7.3.3. Retry Status On Configuration Cycle
Endpoints are allowed to generate retry status on configuration cycles.
In this case, the RC needs to re-issue the request. The IP does not
handle this because the number of configuration cycles needed will
probably be less than the total number of non-posted operations needed.
When a retry status is received on the User RX interface for a
configuration request that was sent on the User TX interface, it will be
indicated with a completion with the CMPL_STATUS field set to 2=CRS, and
the user will have to find the address and data values and send a new
transaction on the User TX interface. When the internal configuration
space returns a retry status during a configuration cycle (user_cscfg =
1) on the Command/Status interface, the pcie_cscrs will assert with the
pcie_csack signal to indicate the CRS status.
When the CRS Software Visibility Enable register in the Root Control
register is enabled, the IP will return the data value to 0x0001 for the
Vendor ID value and 0xffff (all 1’s) for the rest of the data in the
request for reads of offset 0 that return with CRS status. This is true
for both the User RX Interface and for the Command/Status interface.
When CRS Software Visibility is enabled, the CMPL_STATUS field of the
completion on the User RX Interface will not be 2=CRS and the pcie_cscrs
signal will not assert on the Command/Status interface.
The Stingray hardware never reissues configuration requests when it
receives CRS completions. Contrary to what sec 4.7.3.3 above says, when it
receives a CRS completion, it synthesizes 0xffff0001 data regardless of the
address of the read or the value of the CRS SV enable bit.
This is broken in two ways:
1) When CRS SV is disabled, the Root Port should never synthesize the
0x0001 value. If it receives a CRS completion, it should fail the
transaction and synthesize all 1's data.
2) When CRS SV is enabled, the Root Port should only synthesize 0x0001
data if it receives a CRS completion for a read of the Vendor ID. If it
receives a CRS completion for any other read, it should fail the
transaction and synthesize all 1's data.
This breaks pci_flr_wait(), which reads the Command register and expects to
see all 1's data if the read fails because of CRS completions. On
Stingray, it sees the incorrect 0xffff0001 data instead.
It also breaks config registers that contain the 0xffff0001 value. If we
read such a register, software can't distinguish a CRS completion from the
actual value read from the device.
On Stingray, if we read 0xffff0001 data, assume this indicates a CRS
completion and retry the read for 500ms. If we time out, return all 1's
(0xffffffff) data. Note that this corrupts registers that happen to
contain 0xffff0001.
Stingray advertises CRS SV support in its Root Capabilities register, and
the CRS SV enable bit is writable (even though the hardware ignores it).
Mask out PCI_EXP_RTCAP_CRSVIS so software doesn't try to use CRS SV.
Signed-off-by: Oza Pawandeep <oza.oza@broadcom.com>
[bhelgaas: changelog, add probe-time warning about corruption, don't
advertise CRS SV support, remove duplicate pci_generic_config_read32(),
fix alignment based on patch from Arnd Bergmann <arnd@arndb.de>]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2017-08-28 21:43:30 +00:00
|
|
|
dev_warn(dev, "reads of config registers that contain %#x return incorrect data\n",
|
|
|
|
CFG_RETRY_STATUS);
|
2016-11-01 00:38:41 +00:00
|
|
|
break;
|
2016-11-01 00:38:30 +00:00
|
|
|
case IPROC_PCIE_PAXC:
|
|
|
|
regs = iproc_pcie_reg_paxc;
|
|
|
|
pcie->ep_is_internal = true;
|
2018-06-12 00:21:06 +00:00
|
|
|
pcie->iproc_cfg_read = true;
|
|
|
|
pcie->rej_unconfig_pf = true;
|
2016-11-01 00:38:30 +00:00
|
|
|
break;
|
2016-11-01 00:38:35 +00:00
|
|
|
case IPROC_PCIE_PAXC_V2:
|
|
|
|
regs = iproc_pcie_reg_paxc_v2;
|
|
|
|
pcie->ep_is_internal = true;
|
2018-06-12 00:21:06 +00:00
|
|
|
pcie->iproc_cfg_read = true;
|
|
|
|
pcie->rej_unconfig_pf = true;
|
2016-11-01 00:38:35 +00:00
|
|
|
pcie->need_msi_steer = true;
|
|
|
|
break;
|
2016-11-01 00:38:30 +00:00
|
|
|
default:
|
|
|
|
dev_err(dev, "incompatible iProc PCIe interface\n");
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
pcie->reg_offsets = devm_kcalloc(dev, IPROC_PCIE_MAX_NUM_REG,
|
|
|
|
sizeof(*pcie->reg_offsets),
|
|
|
|
GFP_KERNEL);
|
|
|
|
if (!pcie->reg_offsets)
|
|
|
|
return -ENOMEM;
|
|
|
|
|
|
|
|
/* go through the register table and populate all valid registers */
|
2016-11-01 00:38:35 +00:00
|
|
|
pcie->reg_offsets[0] = (pcie->type == IPROC_PCIE_PAXC_V2) ?
|
|
|
|
IPROC_PCIE_REG_INVALID : regs[0];
|
2016-11-01 00:38:30 +00:00
|
|
|
for (reg_idx = 1; reg_idx < IPROC_PCIE_MAX_NUM_REG; reg_idx++)
|
|
|
|
pcie->reg_offsets[reg_idx] = regs[reg_idx] ?
|
|
|
|
regs[reg_idx] : IPROC_PCIE_REG_INVALID;
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2015-05-24 20:37:02 +00:00
|
|
|
int iproc_pcie_setup(struct iproc_pcie *pcie, struct list_head *res)
|
2015-04-08 18:21:35 +00:00
|
|
|
{
|
2016-10-06 18:36:08 +00:00
|
|
|
struct device *dev;
|
2015-04-08 18:21:35 +00:00
|
|
|
int ret;
|
2020-10-01 06:00:54 +00:00
|
|
|
struct pci_dev *pdev;
|
2017-06-28 20:13:57 +00:00
|
|
|
struct pci_host_bridge *host = pci_host_bridge_from_priv(pcie);
|
2015-04-08 18:21:35 +00:00
|
|
|
|
2016-10-06 18:36:08 +00:00
|
|
|
dev = pcie->dev;
|
2016-11-01 00:38:30 +00:00
|
|
|
|
|
|
|
ret = iproc_pcie_rev_init(pcie);
|
|
|
|
if (ret) {
|
|
|
|
dev_err(dev, "unable to initialize controller parameters\n");
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2015-06-28 14:42:04 +00:00
|
|
|
ret = phy_init(pcie->phy);
|
|
|
|
if (ret) {
|
2016-10-06 18:36:08 +00:00
|
|
|
dev_err(dev, "unable to initialize PCIe PHY\n");
|
2015-06-28 14:42:04 +00:00
|
|
|
return ret;
|
|
|
|
}
|
2015-04-08 18:21:35 +00:00
|
|
|
|
2015-06-28 14:42:04 +00:00
|
|
|
ret = phy_power_on(pcie->phy);
|
|
|
|
if (ret) {
|
2016-10-06 18:36:08 +00:00
|
|
|
dev_err(dev, "unable to power on PCIe PHY\n");
|
2015-06-28 14:42:04 +00:00
|
|
|
goto err_exit_phy;
|
2015-04-08 18:21:35 +00:00
|
|
|
}
|
|
|
|
|
PCI: iproc: Add 500ms delay during device shutdown
During soft reset (e.g., "reboot" from Linux) on some iProc-based SOCs, the
LCPLL clock and PERST both go off simultaneously. This seems in accordance
with the PCIe Card Electromechanical spec, r2.0, sec 2.2.3, which says the
clock goes inactive after PERST# goes active, but doesn't specify how long
the clock should be valid after PERST#.
However, we have observed that with the iProc Stingray, some Intel NVMe
endpoints, e.g., the P3700 400GB series, are not detected correctly upon
the next boot sequence unless the clock remains valid for some time after
PERST# is asserted.
Delay 500ms after asserting PERST# before performing a reboot. The 500ms
is experimentally determined.
Signed-off-by: Oza Pawandeep <oza.oza@broadcom.com>
[bhelgaas: changelog, add spec reference, fold in iproc_pcie_shutdown()
export from Arnd Bergmann <arnd@arndb.de>]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Ray Jui <ray.jui@broadcom.com>
Reviewed-by: Scott Branden <scott.branden@broadcom.com>
2017-08-28 21:43:35 +00:00
|
|
|
iproc_pcie_perst_ctrl(pcie, true);
|
|
|
|
iproc_pcie_perst_ctrl(pcie, false);
|
2015-04-08 18:21:35 +00:00
|
|
|
|
2019-09-06 03:58:13 +00:00
|
|
|
iproc_pcie_invalidate_mapping(pcie);
|
|
|
|
|
2015-10-16 13:18:24 +00:00
|
|
|
if (pcie->need_ob_cfg) {
|
|
|
|
ret = iproc_pcie_map_ranges(pcie, res);
|
|
|
|
if (ret) {
|
2016-10-06 18:36:08 +00:00
|
|
|
dev_err(dev, "map failed\n");
|
2015-10-16 13:18:24 +00:00
|
|
|
goto err_power_off_phy;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2018-01-11 20:36:16 +00:00
|
|
|
if (pcie->need_ib_cfg) {
|
|
|
|
ret = iproc_pcie_map_dma_ranges(pcie);
|
|
|
|
if (ret && ret != -ENOENT)
|
|
|
|
goto err_power_off_phy;
|
|
|
|
}
|
2016-11-01 00:38:39 +00:00
|
|
|
|
2017-06-28 20:13:50 +00:00
|
|
|
ret = iproc_pcie_check_link(pcie);
|
2015-04-08 18:21:35 +00:00
|
|
|
if (ret) {
|
2016-10-06 18:36:08 +00:00
|
|
|
dev_err(dev, "no PCIe EP device detected\n");
|
2017-06-28 20:13:57 +00:00
|
|
|
goto err_power_off_phy;
|
2015-04-08 18:21:35 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
iproc_pcie_enable(pcie);
|
|
|
|
|
2016-01-07 00:04:35 +00:00
|
|
|
if (IS_ENABLED(CONFIG_PCI_MSI))
|
|
|
|
if (iproc_pcie_msi_enable(pcie))
|
2016-10-06 18:36:08 +00:00
|
|
|
dev_info(dev, "not using iProc MSI\n");
|
2016-01-07 00:04:35 +00:00
|
|
|
|
2017-06-28 20:13:57 +00:00
|
|
|
host->ops = &iproc_pcie_ops;
|
2018-03-07 15:42:36 +00:00
|
|
|
host->sysdata = pcie;
|
2017-06-28 20:14:07 +00:00
|
|
|
host->map_irq = pcie->map_irq;
|
2017-06-28 20:13:57 +00:00
|
|
|
|
2020-05-22 23:48:28 +00:00
|
|
|
ret = pci_host_probe(host);
|
2017-06-28 20:13:57 +00:00
|
|
|
if (ret < 0) {
|
|
|
|
dev_err(dev, "failed to scan host: %d\n", ret);
|
|
|
|
goto err_power_off_phy;
|
|
|
|
}
|
2016-12-01 20:34:52 +00:00
|
|
|
|
2020-10-01 06:00:54 +00:00
|
|
|
for_each_pci_bridge(pdev, host->bus) {
|
|
|
|
if (pci_pcie_type(pdev) == PCI_EXP_TYPE_ROOT_PORT)
|
|
|
|
pcie_print_link_status(pdev);
|
|
|
|
}
|
|
|
|
|
2015-04-08 18:21:35 +00:00
|
|
|
return 0;
|
|
|
|
|
|
|
|
err_power_off_phy:
|
2015-06-28 14:42:04 +00:00
|
|
|
phy_power_off(pcie->phy);
|
2015-04-08 18:21:35 +00:00
|
|
|
err_exit_phy:
|
2015-06-28 14:42:04 +00:00
|
|
|
phy_exit(pcie->phy);
|
2015-04-08 18:21:35 +00:00
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(iproc_pcie_setup);
|
|
|
|
|
|
|
|
int iproc_pcie_remove(struct iproc_pcie *pcie)
|
|
|
|
{
|
2020-05-22 23:48:28 +00:00
|
|
|
struct pci_host_bridge *host = pci_host_bridge_from_priv(pcie);
|
|
|
|
|
|
|
|
pci_stop_root_bus(host->bus);
|
|
|
|
pci_remove_root_bus(host->bus);
|
2015-04-08 18:21:35 +00:00
|
|
|
|
2016-01-07 00:04:35 +00:00
|
|
|
iproc_pcie_msi_disable(pcie);
|
|
|
|
|
2015-06-28 14:42:04 +00:00
|
|
|
phy_power_off(pcie->phy);
|
|
|
|
phy_exit(pcie->phy);
|
2015-04-08 18:21:35 +00:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(iproc_pcie_remove);
|
|
|
|
|
2018-06-12 00:21:05 +00:00
|
|
|
/*
|
|
|
|
* The MSI parsing logic in certain revisions of Broadcom PAXC based root
|
|
|
|
* complex does not work and needs to be disabled
|
|
|
|
*/
|
|
|
|
static void quirk_paxc_disable_msi_parsing(struct pci_dev *pdev)
|
|
|
|
{
|
|
|
|
struct iproc_pcie *pcie = iproc_data(pdev->bus);
|
|
|
|
|
|
|
|
if (pdev->hdr_type == PCI_HEADER_TYPE_BRIDGE)
|
|
|
|
iproc_pcie_paxc_v2_msi_steer(pcie, 0, false);
|
|
|
|
}
|
|
|
|
DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_BROADCOM, 0x16f0,
|
|
|
|
quirk_paxc_disable_msi_parsing);
|
|
|
|
DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_BROADCOM, 0xd802,
|
|
|
|
quirk_paxc_disable_msi_parsing);
|
|
|
|
DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_BROADCOM, 0xd804,
|
|
|
|
quirk_paxc_disable_msi_parsing);
|
|
|
|
|
2019-12-11 17:45:11 +00:00
|
|
|
static void quirk_paxc_bridge(struct pci_dev *pdev)
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* The PCI config space is shared with the PAXC root port and the first
|
|
|
|
* Ethernet device. So, we need to workaround this by telling the PCI
|
|
|
|
* code that the bridge is not an Ethernet device.
|
|
|
|
*/
|
|
|
|
if (pdev->hdr_type == PCI_HEADER_TYPE_BRIDGE)
|
2022-02-14 11:41:08 +00:00
|
|
|
pdev->class = PCI_CLASS_BRIDGE_PCI_NORMAL;
|
2019-12-11 17:45:11 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* MPSS is not being set properly (as it is currently 0). This is
|
|
|
|
* because that area of the PCI config space is hard coded to zero, and
|
|
|
|
* is not modifiable by firmware. Set this to 2 (e.g., 512 byte MPS)
|
|
|
|
* so that the MPS can be set to the real max value.
|
|
|
|
*/
|
|
|
|
pdev->pcie_mpss = 2;
|
|
|
|
}
|
|
|
|
DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_BROADCOM, 0x16cd, quirk_paxc_bridge);
|
|
|
|
DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_BROADCOM, 0x16f0, quirk_paxc_bridge);
|
|
|
|
DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_BROADCOM, 0xd750, quirk_paxc_bridge);
|
|
|
|
DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_BROADCOM, 0xd802, quirk_paxc_bridge);
|
|
|
|
DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_BROADCOM, 0xd804, quirk_paxc_bridge);
|
|
|
|
|
2015-04-08 18:21:35 +00:00
|
|
|
MODULE_AUTHOR("Ray Jui <rjui@broadcom.com>");
|
|
|
|
MODULE_DESCRIPTION("Broadcom iPROC PCIe common driver");
|
|
|
|
MODULE_LICENSE("GPL v2");
|