2019-12-16 11:01:09 +00:00
|
|
|
// SPDX-License-Identifier: GPL-2.0+
|
|
|
|
/* Copyright (C) 2009 - 2019 Broadcom */
|
|
|
|
|
|
|
|
#include <linux/bitfield.h>
|
2019-12-16 11:01:10 +00:00
|
|
|
#include <linux/bitops.h>
|
2019-12-16 11:01:09 +00:00
|
|
|
#include <linux/clk.h>
|
|
|
|
#include <linux/compiler.h>
|
|
|
|
#include <linux/delay.h>
|
|
|
|
#include <linux/init.h>
|
|
|
|
#include <linux/interrupt.h>
|
|
|
|
#include <linux/io.h>
|
2023-02-09 18:25:03 +00:00
|
|
|
#include <linux/iopoll.h>
|
2019-12-16 11:01:09 +00:00
|
|
|
#include <linux/ioport.h>
|
2019-12-16 11:01:10 +00:00
|
|
|
#include <linux/irqchip/chained_irq.h>
|
2019-12-16 11:01:09 +00:00
|
|
|
#include <linux/irqdomain.h>
|
|
|
|
#include <linux/kernel.h>
|
|
|
|
#include <linux/list.h>
|
|
|
|
#include <linux/log2.h>
|
|
|
|
#include <linux/module.h>
|
2019-12-16 11:01:10 +00:00
|
|
|
#include <linux/msi.h>
|
2019-12-16 11:01:09 +00:00
|
|
|
#include <linux/of_address.h>
|
|
|
|
#include <linux/of_irq.h>
|
|
|
|
#include <linux/of_pci.h>
|
|
|
|
#include <linux/of_platform.h>
|
|
|
|
#include <linux/pci.h>
|
2020-11-29 23:07:39 +00:00
|
|
|
#include <linux/pci-ecam.h>
|
2019-12-16 11:01:09 +00:00
|
|
|
#include <linux/printk.h>
|
PCI: brcmstb: Enable child bus device regulators from DT
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2124638
Upstream Status: 9e6be018b26347c26a93e63fb50a37ee2c9311de
commit 9e6be018b26347c26a93e63fb50a37ee2c9311de
Author: Jim Quinlan <jim2101024@gmail.com>
Date: Mon Jul 25 11:12:53 2022 -0400
PCI: brcmstb: Enable child bus device regulators from DT
Some platforms have power regulators for slots or devices below Root Ports.
On platforms like Raspberry Pi 4, these regulators are described in the
Root Port device tree node, since they logically belong to the Root Port,
not to the host bridge itself.
Add an .add_bus() hook (called when pci_alloc_child_bus() allocates the
secondary ("child") bus for a bridge), and look for such regulators. If we
find some, enable them before bringing up the link and enumerating devices
on the child bus.
Similarly, when pci_remove_bus() calls the ops->remove_bus() hook, disable
the regulators.
The regulators that may be described in a Root Port DT device are:
vpcie3v3
vpcie3v3aux
vpcie12v
These control power to the device downstream from the Root Port.
[bhelgaas: commit log, name hooks brcm_pcie_add_bus(), etc, since we only
support one set of subregulator info, save info in struct brcm_pcie instead
of dev->driver_data, move brcm_pcie_start_link() from probe to .add_bus()
(from subsequent patch)]
Link: https://lore.kernel.org/r/20220725151258.42574-5-jim2101024@gmail.com
Signed-off-by: Jim Quinlan <jim2101024@gmail.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Tested-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Myron Stowe <mstowe@redhat.com>
2022-09-13 23:22:17 +00:00
|
|
|
#include <linux/regulator/consumer.h>
|
2020-09-11 17:52:26 +00:00
|
|
|
#include <linux/reset.h>
|
2019-12-16 11:01:09 +00:00
|
|
|
#include <linux/sizes.h>
|
|
|
|
#include <linux/slab.h>
|
|
|
|
#include <linux/string.h>
|
|
|
|
#include <linux/types.h>
|
|
|
|
|
|
|
|
#include "../pci.h"
|
|
|
|
|
|
|
|
/* BRCM_PCIE_CAP_REGS - Offset for the mandatory capability config regs */
|
|
|
|
#define BRCM_PCIE_CAP_REGS 0x00ac
|
|
|
|
|
|
|
|
/* Broadcom STB PCIe Register Offsets */
|
|
|
|
#define PCIE_RC_CFG_VENDOR_VENDOR_SPECIFIC_REG1 0x0188
|
|
|
|
#define PCIE_RC_CFG_VENDOR_VENDOR_SPECIFIC_REG1_ENDIAN_MODE_BAR2_MASK 0xc
|
|
|
|
#define PCIE_RC_CFG_VENDOR_SPCIFIC_REG1_LITTLE_ENDIAN 0x0
|
|
|
|
|
|
|
|
#define PCIE_RC_CFG_PRIV1_ID_VAL3 0x043c
|
|
|
|
#define PCIE_RC_CFG_PRIV1_ID_VAL3_CLASS_CODE_MASK 0xffffff
|
|
|
|
|
2020-05-07 20:15:43 +00:00
|
|
|
#define PCIE_RC_CFG_PRIV1_LINK_CAPABILITY 0x04dc
|
|
|
|
#define PCIE_RC_CFG_PRIV1_LINK_CAPABILITY_ASPM_SUPPORT_MASK 0xc00
|
|
|
|
|
PCI: brcmstb: Configure HW CLKREQ# mode appropriate for downstream device
JIRA: https://issues.redhat.com/browse/RHEL-28627
Upstream Status: e2596dcf1e9dfd5904d50f796c19b03c94a3b8b4
commit e2596dcf1e9dfd5904d50f796c19b03c94a3b8b4
Author: Jim Quinlan <james.quinlan@broadcom.com>
Date: Mon Nov 13 13:56:06 2023 -0500
PCI: brcmstb: Configure HW CLKREQ# mode appropriate for downstream device
The Broadcom STB/CM PCIe HW core, which is also used in RPi SOCs, must be
deliberately set by the PCIe RC HW into one of three mutually exclusive
modes:
"safe" -- No CLKREQ# expected or required, refclk is always provided. This
mode should work for all devices but is not be capable of any refclk
power savings.
"no-l1ss" -- CLKREQ# is expected to be driven by the downstream device for
CPM and ASPM L0s and L1. Provides Clock Power Management, L0s, and L1,
but cannot provide L1 substate (L1SS) power savings. If the downstream
device connected to the RC is L1SS capable AND the OS enables L1SS, all
PCIe traffic may abruptly halt, potentially hanging the system.
"default" -- Bidirectional CLKREQ# between the RC and downstream device.
Provides ASPM L0s, L1, and L1SS, but not compliant to provide Clock
Power Management; specifically, may not be able to meet the T_CLRon max
timing of 400ns as specified in "Dynamic Clock Control", section
3.2.5.2.2 of the PCIe Express Mini CEM 2.1 specification. This
situation is atypical and should happen only with older devices.
Previously, this driver always set the mode to "no-l1ss", as almost all
STB/CM boards operate in this mode. But now there is interest in
activating L1SS power savings from STB/CM customers, which requires "aspm"
mode. In addition, a bug was filed for RPi4 CM platform because most
devices did not work in "no-l1ss" mode.
Note that the mode is specified by the DT property "brcm,clkreq-mode". If
this property is omitted, then "default" mode is chosen.
Note: Since L1 substates are now possible, a modification was made
regarding an internal bus timeout: During long periods of the PCIe RC HW
being in an L1SS sleep state, there may be a timeout on an internal bus
access, even though there may not be any PCIe access involved. Such a
timeout will cause a subsequent CPU abort.
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=217276
Link: https://lore.kernel.org/linux-pci/20231113185607.1756-3-james.quinlan@broadcom.com
Tested-by: Cyril Brulebois <cyril@debamax.com>
Tested-by: Florian Fainelli <florian.fainelli@broadcom.com>
Signed-off-by: Jim Quinlan <james.quinlan@broadcom.com>
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Signed-off-by: Myron Stowe <mstowe@redhat.com>
2024-03-14 15:53:58 +00:00
|
|
|
#define PCIE_RC_CFG_PRIV1_ROOT_CAP 0x4f8
|
|
|
|
#define PCIE_RC_CFG_PRIV1_ROOT_CAP_L1SS_MODE_MASK 0xf8
|
|
|
|
|
2019-12-16 11:01:09 +00:00
|
|
|
#define PCIE_RC_DL_MDIO_ADDR 0x1100
|
|
|
|
#define PCIE_RC_DL_MDIO_WR_DATA 0x1104
|
|
|
|
#define PCIE_RC_DL_MDIO_RD_DATA 0x1108
|
|
|
|
|
|
|
|
#define PCIE_MISC_MISC_CTRL 0x4008
|
2023-02-09 18:27:43 +00:00
|
|
|
#define PCIE_MISC_MISC_CTRL_PCIE_RCB_64B_MODE_MASK 0x80
|
|
|
|
#define PCIE_MISC_MISC_CTRL_PCIE_RCB_MPS_MODE_MASK 0x400
|
2019-12-16 11:01:09 +00:00
|
|
|
#define PCIE_MISC_MISC_CTRL_SCB_ACCESS_EN_MASK 0x1000
|
|
|
|
#define PCIE_MISC_MISC_CTRL_CFG_READ_UR_MODE_MASK 0x2000
|
|
|
|
#define PCIE_MISC_MISC_CTRL_MAX_BURST_SIZE_MASK 0x300000
|
2020-09-11 17:52:29 +00:00
|
|
|
|
2019-12-16 11:01:09 +00:00
|
|
|
#define PCIE_MISC_MISC_CTRL_SCB0_SIZE_MASK 0xf8000000
|
PCI: brcmstb: Set additional internal memory DMA viewport sizes
The Raspberry Pi (RPI) is currently the only chip using this driver
(pcie-brcmstb.c). There, only one memory controller is used, without an
extension region, and the SCB0 viewport size is set to the size of the
first and only dma-range region. Other BrcmSTB SOCs have more complicated
memory configurations that require setting additional viewport sizes.
BrcmSTB PCIe controllers are intimately connected to the memory
controller(s) on the SOC. The SOC may have one to three memory
controllers; they are indicated by the term SCBi. Each controller has a
base region and an optional extension region. In physical memory, the base
and extension regions of a controller are not adjacent, but in PCIe-space
they are.
There is a "viewport" for each memory controller that allows DMA from
endpoint devices. Each viewport's size must be set to a power of two, and
that size must be equal to or larger than the amount of memory each
controller supports which is the sum of base region and its optional
extension. Further, the 1-3 viewports are also adjacent in PCIe-space.
Unfortunately the viewport sizes cannot be ascertained from the
"dma-ranges" property so they have their own property, "brcm,scb-sizes".
This is because dma-range information does not indicate what memory
controller it is associated. For example, consider the following case
where the size of one dma-range is 2GB and the second dma-range is 1GB:
/* Case 1: SCB0 size set to 4GB */
dma-range0: 2GB (from memc0-base)
dma-range1: 1GB (from memc0-extension)
/* Case 2: SCB0 size set to 2GB, SCB1 size set to 1GB */
dma-range0: 2GB (from memc0-base)
dma-range1: 1GB (from memc0-extension)
By just looking at the dma-ranges information, one cannot tell which
situation applies. That is why an additional property is needed. Its
length indicates the number of memory controllers being used and each value
indicates the viewport size.
Note that the RPI DT does not have a "brcm,scb-sizes" property value,
as it is assumed that it only requires one memory controller and no
extension. So the optional use of "brcm,scb-sizes" will be backwards
compatible.
One last layer of complexity exists: all of the viewports sizes must be
added and rounded up to a power of two to determine what the "BAR" size is.
Further, an offset must be given that indicates the base PCIe address of
this "BAR". The use of the term BAR is typically associated with endpoint
devices, and the term is used here because the PCIe HW may be used as an RC
or an EP. In the former case, all of the system memory appears in a single
"BAR" region in PCIe memory. As it turns out, BrcmSTB PCIe HW is rarely
used in the EP role and its system of mapping memory is an artifact that
requires multiple dma-ranges regions.
Link: https://lore.kernel.org/r/20200911175232.19016-8-james.quinlan@broadcom.com
Signed-off-by: Jim Quinlan <james.quinlan@broadcom.com>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
2020-09-11 17:52:27 +00:00
|
|
|
#define PCIE_MISC_MISC_CTRL_SCB1_SIZE_MASK 0x07c00000
|
|
|
|
#define PCIE_MISC_MISC_CTRL_SCB2_SIZE_MASK 0x0000001f
|
|
|
|
#define SCB_SIZE_MASK(x) PCIE_MISC_MISC_CTRL_SCB ## x ## _SIZE_MASK
|
2019-12-16 11:01:09 +00:00
|
|
|
|
|
|
|
#define PCIE_MISC_CPU_2_PCIE_MEM_WIN0_LO 0x400c
|
|
|
|
#define PCIE_MEM_WIN0_LO(win) \
|
2020-05-07 20:15:41 +00:00
|
|
|
PCIE_MISC_CPU_2_PCIE_MEM_WIN0_LO + ((win) * 8)
|
2019-12-16 11:01:09 +00:00
|
|
|
|
|
|
|
#define PCIE_MISC_CPU_2_PCIE_MEM_WIN0_HI 0x4010
|
|
|
|
#define PCIE_MEM_WIN0_HI(win) \
|
2020-05-07 20:15:41 +00:00
|
|
|
PCIE_MISC_CPU_2_PCIE_MEM_WIN0_HI + ((win) * 8)
|
2019-12-16 11:01:09 +00:00
|
|
|
|
2025-02-17 19:35:10 +00:00
|
|
|
/*
|
|
|
|
* NOTE: You may see the term "BAR" in a number of register names used by
|
|
|
|
* this driver. The term is an artifact of when the HW core was an
|
|
|
|
* endpoint device (EP). Now it is a root complex (RC) and anywhere a
|
|
|
|
* register has the term "BAR" it is related to an inbound window.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#define PCIE_BRCM_MAX_INBOUND_WINS 16
|
2019-12-16 11:01:09 +00:00
|
|
|
#define PCIE_MISC_RC_BAR1_CONFIG_LO 0x402c
|
|
|
|
#define PCIE_MISC_RC_BAR1_CONFIG_LO_SIZE_MASK 0x1f
|
|
|
|
|
2025-02-17 19:35:10 +00:00
|
|
|
#define PCIE_MISC_RC_BAR4_CONFIG_LO 0x40d4
|
2019-12-16 11:01:09 +00:00
|
|
|
|
|
|
|
|
2019-12-16 11:01:10 +00:00
|
|
|
#define PCIE_MISC_MSI_BAR_CONFIG_LO 0x4044
|
|
|
|
#define PCIE_MISC_MSI_BAR_CONFIG_HI 0x4048
|
|
|
|
|
|
|
|
#define PCIE_MISC_MSI_DATA_CONFIG 0x404c
|
2020-09-11 17:52:28 +00:00
|
|
|
#define PCIE_MISC_MSI_DATA_CONFIG_VAL_32 0xffe06540
|
|
|
|
#define PCIE_MISC_MSI_DATA_CONFIG_VAL_8 0xfff86540
|
2019-12-16 11:01:10 +00:00
|
|
|
|
2019-12-16 11:01:09 +00:00
|
|
|
#define PCIE_MISC_PCIE_CTRL 0x4064
|
|
|
|
#define PCIE_MISC_PCIE_CTRL_PCIE_L23_REQUEST_MASK 0x1
|
2020-09-11 17:52:25 +00:00
|
|
|
#define PCIE_MISC_PCIE_CTRL_PCIE_PERSTB_MASK 0x4
|
2019-12-16 11:01:09 +00:00
|
|
|
|
|
|
|
#define PCIE_MISC_PCIE_STATUS 0x4068
|
|
|
|
#define PCIE_MISC_PCIE_STATUS_PCIE_PORT_MASK 0x80
|
|
|
|
#define PCIE_MISC_PCIE_STATUS_PCIE_DL_ACTIVE_MASK 0x20
|
|
|
|
#define PCIE_MISC_PCIE_STATUS_PCIE_PHYLINKUP_MASK 0x10
|
|
|
|
#define PCIE_MISC_PCIE_STATUS_PCIE_LINK_IN_L23_MASK 0x40
|
|
|
|
|
2020-09-11 17:52:28 +00:00
|
|
|
#define PCIE_MISC_REVISION 0x406c
|
|
|
|
#define BRCM_PCIE_HW_REV_33 0x0303
|
2020-12-10 18:04:21 +00:00
|
|
|
#define BRCM_PCIE_HW_REV_3_20 0x0320
|
2020-09-11 17:52:28 +00:00
|
|
|
|
2019-12-16 11:01:09 +00:00
|
|
|
#define PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_LIMIT 0x4070
|
|
|
|
#define PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_LIMIT_LIMIT_MASK 0xfff00000
|
|
|
|
#define PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_LIMIT_BASE_MASK 0xfff0
|
|
|
|
#define PCIE_MEM_WIN0_BASE_LIMIT(win) \
|
|
|
|
PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_LIMIT + ((win) * 4)
|
|
|
|
|
|
|
|
#define PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_HI 0x4080
|
|
|
|
#define PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_HI_BASE_MASK 0xff
|
|
|
|
#define PCIE_MEM_WIN0_BASE_HI(win) \
|
|
|
|
PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_HI + ((win) * 8)
|
|
|
|
|
|
|
|
#define PCIE_MISC_CPU_2_PCIE_MEM_WIN0_LIMIT_HI 0x4084
|
|
|
|
#define PCIE_MISC_CPU_2_PCIE_MEM_WIN0_LIMIT_HI_LIMIT_MASK 0xff
|
|
|
|
#define PCIE_MEM_WIN0_LIMIT_HI(win) \
|
|
|
|
PCIE_MISC_CPU_2_PCIE_MEM_WIN0_LIMIT_HI + ((win) * 8)
|
|
|
|
|
|
|
|
#define PCIE_MISC_HARD_PCIE_HARD_DEBUG_CLKREQ_DEBUG_ENABLE_MASK 0x2
|
PCI: brcmstb: Configure HW CLKREQ# mode appropriate for downstream device
JIRA: https://issues.redhat.com/browse/RHEL-28627
Upstream Status: e2596dcf1e9dfd5904d50f796c19b03c94a3b8b4
commit e2596dcf1e9dfd5904d50f796c19b03c94a3b8b4
Author: Jim Quinlan <james.quinlan@broadcom.com>
Date: Mon Nov 13 13:56:06 2023 -0500
PCI: brcmstb: Configure HW CLKREQ# mode appropriate for downstream device
The Broadcom STB/CM PCIe HW core, which is also used in RPi SOCs, must be
deliberately set by the PCIe RC HW into one of three mutually exclusive
modes:
"safe" -- No CLKREQ# expected or required, refclk is always provided. This
mode should work for all devices but is not be capable of any refclk
power savings.
"no-l1ss" -- CLKREQ# is expected to be driven by the downstream device for
CPM and ASPM L0s and L1. Provides Clock Power Management, L0s, and L1,
but cannot provide L1 substate (L1SS) power savings. If the downstream
device connected to the RC is L1SS capable AND the OS enables L1SS, all
PCIe traffic may abruptly halt, potentially hanging the system.
"default" -- Bidirectional CLKREQ# between the RC and downstream device.
Provides ASPM L0s, L1, and L1SS, but not compliant to provide Clock
Power Management; specifically, may not be able to meet the T_CLRon max
timing of 400ns as specified in "Dynamic Clock Control", section
3.2.5.2.2 of the PCIe Express Mini CEM 2.1 specification. This
situation is atypical and should happen only with older devices.
Previously, this driver always set the mode to "no-l1ss", as almost all
STB/CM boards operate in this mode. But now there is interest in
activating L1SS power savings from STB/CM customers, which requires "aspm"
mode. In addition, a bug was filed for RPi4 CM platform because most
devices did not work in "no-l1ss" mode.
Note that the mode is specified by the DT property "brcm,clkreq-mode". If
this property is omitted, then "default" mode is chosen.
Note: Since L1 substates are now possible, a modification was made
regarding an internal bus timeout: During long periods of the PCIe RC HW
being in an L1SS sleep state, there may be a timeout on an internal bus
access, even though there may not be any PCIe access involved. Such a
timeout will cause a subsequent CPU abort.
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=217276
Link: https://lore.kernel.org/linux-pci/20231113185607.1756-3-james.quinlan@broadcom.com
Tested-by: Cyril Brulebois <cyril@debamax.com>
Tested-by: Florian Fainelli <florian.fainelli@broadcom.com>
Signed-off-by: Jim Quinlan <james.quinlan@broadcom.com>
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Signed-off-by: Myron Stowe <mstowe@redhat.com>
2024-03-14 15:53:58 +00:00
|
|
|
#define PCIE_MISC_HARD_PCIE_HARD_DEBUG_L1SS_ENABLE_MASK 0x200000
|
2019-12-16 11:01:09 +00:00
|
|
|
#define PCIE_MISC_HARD_PCIE_HARD_DEBUG_SERDES_IDDQ_MASK 0x08000000
|
2022-09-13 23:17:57 +00:00
|
|
|
#define PCIE_BMIPS_MISC_HARD_PCIE_HARD_DEBUG_SERDES_IDDQ_MASK 0x00800000
|
PCI: brcmstb: Configure HW CLKREQ# mode appropriate for downstream device
JIRA: https://issues.redhat.com/browse/RHEL-28627
Upstream Status: e2596dcf1e9dfd5904d50f796c19b03c94a3b8b4
commit e2596dcf1e9dfd5904d50f796c19b03c94a3b8b4
Author: Jim Quinlan <james.quinlan@broadcom.com>
Date: Mon Nov 13 13:56:06 2023 -0500
PCI: brcmstb: Configure HW CLKREQ# mode appropriate for downstream device
The Broadcom STB/CM PCIe HW core, which is also used in RPi SOCs, must be
deliberately set by the PCIe RC HW into one of three mutually exclusive
modes:
"safe" -- No CLKREQ# expected or required, refclk is always provided. This
mode should work for all devices but is not be capable of any refclk
power savings.
"no-l1ss" -- CLKREQ# is expected to be driven by the downstream device for
CPM and ASPM L0s and L1. Provides Clock Power Management, L0s, and L1,
but cannot provide L1 substate (L1SS) power savings. If the downstream
device connected to the RC is L1SS capable AND the OS enables L1SS, all
PCIe traffic may abruptly halt, potentially hanging the system.
"default" -- Bidirectional CLKREQ# between the RC and downstream device.
Provides ASPM L0s, L1, and L1SS, but not compliant to provide Clock
Power Management; specifically, may not be able to meet the T_CLRon max
timing of 400ns as specified in "Dynamic Clock Control", section
3.2.5.2.2 of the PCIe Express Mini CEM 2.1 specification. This
situation is atypical and should happen only with older devices.
Previously, this driver always set the mode to "no-l1ss", as almost all
STB/CM boards operate in this mode. But now there is interest in
activating L1SS power savings from STB/CM customers, which requires "aspm"
mode. In addition, a bug was filed for RPi4 CM platform because most
devices did not work in "no-l1ss" mode.
Note that the mode is specified by the DT property "brcm,clkreq-mode". If
this property is omitted, then "default" mode is chosen.
Note: Since L1 substates are now possible, a modification was made
regarding an internal bus timeout: During long periods of the PCIe RC HW
being in an L1SS sleep state, there may be a timeout on an internal bus
access, even though there may not be any PCIe access involved. Such a
timeout will cause a subsequent CPU abort.
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=217276
Link: https://lore.kernel.org/linux-pci/20231113185607.1756-3-james.quinlan@broadcom.com
Tested-by: Cyril Brulebois <cyril@debamax.com>
Tested-by: Florian Fainelli <florian.fainelli@broadcom.com>
Signed-off-by: Jim Quinlan <james.quinlan@broadcom.com>
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Signed-off-by: Myron Stowe <mstowe@redhat.com>
2024-03-14 15:53:58 +00:00
|
|
|
#define PCIE_CLKREQ_MASK \
|
|
|
|
(PCIE_MISC_HARD_PCIE_HARD_DEBUG_CLKREQ_DEBUG_ENABLE_MASK | \
|
|
|
|
PCIE_MISC_HARD_PCIE_HARD_DEBUG_L1SS_ENABLE_MASK)
|
2020-09-11 17:52:28 +00:00
|
|
|
|
2025-02-17 19:35:10 +00:00
|
|
|
#define PCIE_MISC_UBUS_BAR1_CONFIG_REMAP 0x40ac
|
|
|
|
#define PCIE_MISC_UBUS_BAR1_CONFIG_REMAP_ACCESS_EN_MASK BIT(0)
|
|
|
|
#define PCIE_MISC_UBUS_BAR4_CONFIG_REMAP 0x410c
|
|
|
|
|
2020-09-11 17:52:28 +00:00
|
|
|
#define PCIE_MSI_INTR2_BASE 0x4500
|
2025-02-17 19:34:45 +00:00
|
|
|
|
|
|
|
/* Offsets from INTR2_CPU and MSI_INTR2 BASE offsets */
|
2020-09-11 17:52:28 +00:00
|
|
|
#define MSI_INT_STATUS 0x0
|
|
|
|
#define MSI_INT_CLR 0x8
|
|
|
|
#define MSI_INT_MASK_SET 0x10
|
|
|
|
#define MSI_INT_MASK_CLR 0x14
|
2019-12-16 11:01:09 +00:00
|
|
|
|
|
|
|
#define PCIE_EXT_CFG_DATA 0x8000
|
|
|
|
#define PCIE_EXT_CFG_INDEX 0x9000
|
|
|
|
|
|
|
|
#define PCIE_RGR1_SW_INIT_1_PERST_MASK 0x1
|
PCI: brcmstb: Add bcm7278 register info
Add in compatibility strings and code for three Broadcom STB chips. Some
of the register locations, shifts, and masks are different for certain
chips, requiring the use of different constants based on of_id.
We would like to add the following at this time to the match list but we
need to wait until the end of this patchset so that everything works.
{ .compatible = "brcm,bcm7211-pcie", .data = &generic_cfg },
{ .compatible = "brcm,bcm7278-pcie", .data = &bcm7278_cfg },
{ .compatible = "brcm,bcm7216-pcie", .data = &bcm7278_cfg },
{ .compatible = "brcm,bcm7445-pcie", .data = &generic_cfg },
Link: https://lore.kernel.org/r/20200911175232.19016-4-james.quinlan@broadcom.com
Signed-off-by: Jim Quinlan <jquinlan@broadcom.com>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
Acked-by: Rob Herring <robh@kernel.org>
2020-09-11 17:52:23 +00:00
|
|
|
#define PCIE_RGR1_SW_INIT_1_PERST_SHIFT 0x0
|
2019-12-16 11:01:09 +00:00
|
|
|
|
2020-09-11 17:52:25 +00:00
|
|
|
#define RGR1_SW_INIT_1_INIT_GENERIC_MASK 0x2
|
|
|
|
#define RGR1_SW_INIT_1_INIT_GENERIC_SHIFT 0x1
|
|
|
|
#define RGR1_SW_INIT_1_INIT_7278_MASK 0x1
|
|
|
|
#define RGR1_SW_INIT_1_INIT_7278_SHIFT 0x0
|
2019-12-16 11:01:09 +00:00
|
|
|
|
|
|
|
/* PCIe parameters */
|
|
|
|
#define BRCM_NUM_PCIE_OUT_WINS 0x4
|
2019-12-16 11:01:10 +00:00
|
|
|
#define BRCM_INT_PCI_MSI_NR 32
|
2020-09-11 17:52:28 +00:00
|
|
|
#define BRCM_INT_PCI_MSI_LEGACY_NR 8
|
|
|
|
#define BRCM_INT_PCI_MSI_SHIFT 0
|
2022-03-28 22:50:37 +00:00
|
|
|
#define BRCM_INT_PCI_MSI_MASK GENMASK(BRCM_INT_PCI_MSI_NR - 1, 0)
|
|
|
|
#define BRCM_INT_PCI_MSI_LEGACY_MASK GENMASK(31, \
|
|
|
|
32 - BRCM_INT_PCI_MSI_LEGACY_NR)
|
2019-12-16 11:01:10 +00:00
|
|
|
|
2022-03-15 20:41:25 +00:00
|
|
|
/* MSI target addresses */
|
2019-12-16 11:01:10 +00:00
|
|
|
#define BRCM_MSI_TARGET_ADDR_LT_4GB 0x0fffffffcULL
|
|
|
|
#define BRCM_MSI_TARGET_ADDR_GT_4GB 0xffffffffcULL
|
2019-12-16 11:01:09 +00:00
|
|
|
|
|
|
|
/* MDIO registers */
|
|
|
|
#define MDIO_PORT0 0x0
|
|
|
|
#define MDIO_DATA_MASK 0x7fffffff
|
|
|
|
#define MDIO_PORT_MASK 0xf0000
|
|
|
|
#define MDIO_REGAD_MASK 0xffff
|
|
|
|
#define MDIO_CMD_MASK 0xfff00000
|
|
|
|
#define MDIO_CMD_READ 0x1
|
|
|
|
#define MDIO_CMD_WRITE 0x0
|
|
|
|
#define MDIO_DATA_DONE_MASK 0x80000000
|
|
|
|
#define MDIO_RD_DONE(x) (((x) & MDIO_DATA_DONE_MASK) ? 1 : 0)
|
|
|
|
#define MDIO_WT_DONE(x) (((x) & MDIO_DATA_DONE_MASK) ? 0 : 1)
|
|
|
|
#define SSC_REGS_ADDR 0x1100
|
|
|
|
#define SET_ADDR_OFFSET 0x1f
|
|
|
|
#define SSC_CNTL_OFFSET 0x2
|
|
|
|
#define SSC_CNTL_OVRD_EN_MASK 0x8000
|
|
|
|
#define SSC_CNTL_OVRD_VAL_MASK 0x4000
|
|
|
|
#define SSC_STATUS_OFFSET 0x1
|
|
|
|
#define SSC_STATUS_SSC_MASK 0x400
|
|
|
|
#define SSC_STATUS_PLL_LOCK_MASK 0x800
|
PCI: brcmstb: Set additional internal memory DMA viewport sizes
The Raspberry Pi (RPI) is currently the only chip using this driver
(pcie-brcmstb.c). There, only one memory controller is used, without an
extension region, and the SCB0 viewport size is set to the size of the
first and only dma-range region. Other BrcmSTB SOCs have more complicated
memory configurations that require setting additional viewport sizes.
BrcmSTB PCIe controllers are intimately connected to the memory
controller(s) on the SOC. The SOC may have one to three memory
controllers; they are indicated by the term SCBi. Each controller has a
base region and an optional extension region. In physical memory, the base
and extension regions of a controller are not adjacent, but in PCIe-space
they are.
There is a "viewport" for each memory controller that allows DMA from
endpoint devices. Each viewport's size must be set to a power of two, and
that size must be equal to or larger than the amount of memory each
controller supports which is the sum of base region and its optional
extension. Further, the 1-3 viewports are also adjacent in PCIe-space.
Unfortunately the viewport sizes cannot be ascertained from the
"dma-ranges" property so they have their own property, "brcm,scb-sizes".
This is because dma-range information does not indicate what memory
controller it is associated. For example, consider the following case
where the size of one dma-range is 2GB and the second dma-range is 1GB:
/* Case 1: SCB0 size set to 4GB */
dma-range0: 2GB (from memc0-base)
dma-range1: 1GB (from memc0-extension)
/* Case 2: SCB0 size set to 2GB, SCB1 size set to 1GB */
dma-range0: 2GB (from memc0-base)
dma-range1: 1GB (from memc0-extension)
By just looking at the dma-ranges information, one cannot tell which
situation applies. That is why an additional property is needed. Its
length indicates the number of memory controllers being used and each value
indicates the viewport size.
Note that the RPI DT does not have a "brcm,scb-sizes" property value,
as it is assumed that it only requires one memory controller and no
extension. So the optional use of "brcm,scb-sizes" will be backwards
compatible.
One last layer of complexity exists: all of the viewports sizes must be
added and rounded up to a power of two to determine what the "BAR" size is.
Further, an offset must be given that indicates the base PCIe address of
this "BAR". The use of the term BAR is typically associated with endpoint
devices, and the term is used here because the PCIe HW may be used as an RC
or an EP. In the former case, all of the system memory appears in a single
"BAR" region in PCIe memory. As it turns out, BrcmSTB PCIe HW is rarely
used in the EP role and its system of mapping memory is an artifact that
requires multiple dma-ranges regions.
Link: https://lore.kernel.org/r/20200911175232.19016-8-james.quinlan@broadcom.com
Signed-off-by: Jim Quinlan <james.quinlan@broadcom.com>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
2020-09-11 17:52:27 +00:00
|
|
|
#define PCIE_BRCM_MAX_MEMC 3
|
2019-12-16 11:01:09 +00:00
|
|
|
|
2025-02-17 19:34:45 +00:00
|
|
|
#define IDX_ADDR(pcie) ((pcie)->reg_offsets[EXT_CFG_INDEX])
|
|
|
|
#define DATA_ADDR(pcie) ((pcie)->reg_offsets[EXT_CFG_DATA])
|
|
|
|
#define PCIE_RGR1_SW_INIT_1(pcie) ((pcie)->reg_offsets[RGR1_SW_INIT_1])
|
|
|
|
#define HARD_DEBUG(pcie) ((pcie)->reg_offsets[PCIE_HARD_DEBUG])
|
|
|
|
#define INTR2_CPU_BASE(pcie) ((pcie)->reg_offsets[PCIE_INTR2_CPU_BASE])
|
PCI: brcmstb: Add bcm7278 register info
Add in compatibility strings and code for three Broadcom STB chips. Some
of the register locations, shifts, and masks are different for certain
chips, requiring the use of different constants based on of_id.
We would like to add the following at this time to the match list but we
need to wait until the end of this patchset so that everything works.
{ .compatible = "brcm,bcm7211-pcie", .data = &generic_cfg },
{ .compatible = "brcm,bcm7278-pcie", .data = &bcm7278_cfg },
{ .compatible = "brcm,bcm7216-pcie", .data = &bcm7278_cfg },
{ .compatible = "brcm,bcm7445-pcie", .data = &generic_cfg },
Link: https://lore.kernel.org/r/20200911175232.19016-4-james.quinlan@broadcom.com
Signed-off-by: Jim Quinlan <jquinlan@broadcom.com>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
Acked-by: Rob Herring <robh@kernel.org>
2020-09-11 17:52:23 +00:00
|
|
|
|
2020-09-11 17:52:25 +00:00
|
|
|
/* Rescal registers */
|
|
|
|
#define PCIE_DVT_PMU_PCIE_PHY_CTRL 0xc700
|
|
|
|
#define PCIE_DVT_PMU_PCIE_PHY_CTRL_DAST_NFLDS 0x3
|
|
|
|
#define PCIE_DVT_PMU_PCIE_PHY_CTRL_DAST_DIG_RESET_MASK 0x4
|
|
|
|
#define PCIE_DVT_PMU_PCIE_PHY_CTRL_DAST_DIG_RESET_SHIFT 0x2
|
|
|
|
#define PCIE_DVT_PMU_PCIE_PHY_CTRL_DAST_RESET_MASK 0x2
|
|
|
|
#define PCIE_DVT_PMU_PCIE_PHY_CTRL_DAST_RESET_SHIFT 0x1
|
|
|
|
#define PCIE_DVT_PMU_PCIE_PHY_CTRL_DAST_PWRDN_MASK 0x1
|
|
|
|
#define PCIE_DVT_PMU_PCIE_PHY_CTRL_DAST_PWRDN_SHIFT 0x0
|
|
|
|
|
|
|
|
/* Forward declarations */
|
|
|
|
struct brcm_pcie;
|
|
|
|
|
PCI: brcmstb: Add bcm7278 register info
Add in compatibility strings and code for three Broadcom STB chips. Some
of the register locations, shifts, and masks are different for certain
chips, requiring the use of different constants based on of_id.
We would like to add the following at this time to the match list but we
need to wait until the end of this patchset so that everything works.
{ .compatible = "brcm,bcm7211-pcie", .data = &generic_cfg },
{ .compatible = "brcm,bcm7278-pcie", .data = &bcm7278_cfg },
{ .compatible = "brcm,bcm7216-pcie", .data = &bcm7278_cfg },
{ .compatible = "brcm,bcm7445-pcie", .data = &generic_cfg },
Link: https://lore.kernel.org/r/20200911175232.19016-4-james.quinlan@broadcom.com
Signed-off-by: Jim Quinlan <jquinlan@broadcom.com>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
Acked-by: Rob Herring <robh@kernel.org>
2020-09-11 17:52:23 +00:00
|
|
|
enum {
|
|
|
|
RGR1_SW_INIT_1,
|
|
|
|
EXT_CFG_INDEX,
|
|
|
|
EXT_CFG_DATA,
|
2025-02-17 19:34:45 +00:00
|
|
|
PCIE_HARD_DEBUG,
|
|
|
|
PCIE_INTR2_CPU_BASE,
|
PCI: brcmstb: Add bcm7278 register info
Add in compatibility strings and code for three Broadcom STB chips. Some
of the register locations, shifts, and masks are different for certain
chips, requiring the use of different constants based on of_id.
We would like to add the following at this time to the match list but we
need to wait until the end of this patchset so that everything works.
{ .compatible = "brcm,bcm7211-pcie", .data = &generic_cfg },
{ .compatible = "brcm,bcm7278-pcie", .data = &bcm7278_cfg },
{ .compatible = "brcm,bcm7216-pcie", .data = &bcm7278_cfg },
{ .compatible = "brcm,bcm7445-pcie", .data = &generic_cfg },
Link: https://lore.kernel.org/r/20200911175232.19016-4-james.quinlan@broadcom.com
Signed-off-by: Jim Quinlan <jquinlan@broadcom.com>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
Acked-by: Rob Herring <robh@kernel.org>
2020-09-11 17:52:23 +00:00
|
|
|
};
|
|
|
|
|
2025-02-17 19:35:32 +00:00
|
|
|
enum pcie_soc_base {
|
PCI: brcmstb: Add bcm7278 register info
Add in compatibility strings and code for three Broadcom STB chips. Some
of the register locations, shifts, and masks are different for certain
chips, requiring the use of different constants based on of_id.
We would like to add the following at this time to the match list but we
need to wait until the end of this patchset so that everything works.
{ .compatible = "brcm,bcm7211-pcie", .data = &generic_cfg },
{ .compatible = "brcm,bcm7278-pcie", .data = &bcm7278_cfg },
{ .compatible = "brcm,bcm7216-pcie", .data = &bcm7278_cfg },
{ .compatible = "brcm,bcm7445-pcie", .data = &generic_cfg },
Link: https://lore.kernel.org/r/20200911175232.19016-4-james.quinlan@broadcom.com
Signed-off-by: Jim Quinlan <jquinlan@broadcom.com>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
Acked-by: Rob Herring <robh@kernel.org>
2020-09-11 17:52:23 +00:00
|
|
|
GENERIC,
|
PCI: brcmstb: Sort enums, pcie_offsets[], pcie_cfg_data, .compatible strings
JIRA: https://issues.redhat.com/browse/RHEL-67693
Upstream Status: 2a0091f9419cb6dbbada3a4c8d9e86117b80ead4
commit 2a0091f9419cb6dbbada3a4c8d9e86117b80ead4
Author: Bjorn Helgaas <bhelgaas@google.com>
Date: Mon Sep 2 15:28:59 2024 -0500
PCI: brcmstb: Sort enums, pcie_offsets[], pcie_cfg_data, .compatible strings
Sort enum pcie_soc_base values.
Rename pcie_offsets_bmips_7425[] to pcie_offsets_bcm7425[] to match BCM7425
pcie_soc_base enum, bcm7425_cfg, and "brcm,bcm7425-pcie" .compatible
string.
Rename pcie_offset_bcm7278[] to pcie_offsets_bcm7278[] to match other
"pcie_offsets" names.
Rename pcie_offset_bcm7712[] to pcie_offsets_bcm7712[] to match other
"pcie_offsets" names.
Sort pcie_offsets_*[] by SoC name, move them all together, indent values
for easy reading.
Sort pcie_cfg_data structs by SoC name.
Sort .compatible strings by SoC name.
No functional change intended.
Link: https://lore.kernel.org/r/20240902205456.227409-1-helgaas@kernel.org
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com>
Signed-off-by: Myron Stowe <mstowe@redhat.com>
2025-02-17 19:35:50 +00:00
|
|
|
BCM2711,
|
2020-12-10 18:04:21 +00:00
|
|
|
BCM4908,
|
PCI: brcmstb: Add bcm7278 register info
Add in compatibility strings and code for three Broadcom STB chips. Some
of the register locations, shifts, and masks are different for certain
chips, requiring the use of different constants based on of_id.
We would like to add the following at this time to the match list but we
need to wait until the end of this patchset so that everything works.
{ .compatible = "brcm,bcm7211-pcie", .data = &generic_cfg },
{ .compatible = "brcm,bcm7278-pcie", .data = &bcm7278_cfg },
{ .compatible = "brcm,bcm7216-pcie", .data = &bcm7278_cfg },
{ .compatible = "brcm,bcm7445-pcie", .data = &generic_cfg },
Link: https://lore.kernel.org/r/20200911175232.19016-4-james.quinlan@broadcom.com
Signed-off-by: Jim Quinlan <jquinlan@broadcom.com>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
Acked-by: Rob Herring <robh@kernel.org>
2020-09-11 17:52:23 +00:00
|
|
|
BCM7278,
|
PCI: brcmstb: Sort enums, pcie_offsets[], pcie_cfg_data, .compatible strings
JIRA: https://issues.redhat.com/browse/RHEL-67693
Upstream Status: 2a0091f9419cb6dbbada3a4c8d9e86117b80ead4
commit 2a0091f9419cb6dbbada3a4c8d9e86117b80ead4
Author: Bjorn Helgaas <bhelgaas@google.com>
Date: Mon Sep 2 15:28:59 2024 -0500
PCI: brcmstb: Sort enums, pcie_offsets[], pcie_cfg_data, .compatible strings
Sort enum pcie_soc_base values.
Rename pcie_offsets_bmips_7425[] to pcie_offsets_bcm7425[] to match BCM7425
pcie_soc_base enum, bcm7425_cfg, and "brcm,bcm7425-pcie" .compatible
string.
Rename pcie_offset_bcm7278[] to pcie_offsets_bcm7278[] to match other
"pcie_offsets" names.
Rename pcie_offset_bcm7712[] to pcie_offsets_bcm7712[] to match other
"pcie_offsets" names.
Sort pcie_offsets_*[] by SoC name, move them all together, indent values
for easy reading.
Sort pcie_cfg_data structs by SoC name.
Sort .compatible strings by SoC name.
No functional change intended.
Link: https://lore.kernel.org/r/20240902205456.227409-1-helgaas@kernel.org
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com>
Signed-off-by: Myron Stowe <mstowe@redhat.com>
2025-02-17 19:35:50 +00:00
|
|
|
BCM7425,
|
|
|
|
BCM7435,
|
2025-02-17 19:35:10 +00:00
|
|
|
BCM7712,
|
|
|
|
};
|
|
|
|
|
|
|
|
struct inbound_win {
|
|
|
|
u64 size;
|
|
|
|
u64 pci_offset;
|
|
|
|
u64 cpu_addr;
|
PCI: brcmstb: Add bcm7278 register info
Add in compatibility strings and code for three Broadcom STB chips. Some
of the register locations, shifts, and masks are different for certain
chips, requiring the use of different constants based on of_id.
We would like to add the following at this time to the match list but we
need to wait until the end of this patchset so that everything works.
{ .compatible = "brcm,bcm7211-pcie", .data = &generic_cfg },
{ .compatible = "brcm,bcm7278-pcie", .data = &bcm7278_cfg },
{ .compatible = "brcm,bcm7216-pcie", .data = &bcm7278_cfg },
{ .compatible = "brcm,bcm7445-pcie", .data = &generic_cfg },
Link: https://lore.kernel.org/r/20200911175232.19016-4-james.quinlan@broadcom.com
Signed-off-by: Jim Quinlan <jquinlan@broadcom.com>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
Acked-by: Rob Herring <robh@kernel.org>
2020-09-11 17:52:23 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
struct pcie_cfg_data {
|
|
|
|
const int *offsets;
|
2025-02-17 19:35:32 +00:00
|
|
|
const enum pcie_soc_base soc_base;
|
2025-02-17 19:35:02 +00:00
|
|
|
const bool has_phy;
|
2025-02-17 19:35:10 +00:00
|
|
|
u8 num_inbound_wins;
|
2025-02-17 19:35:19 +00:00
|
|
|
int (*perst_set)(struct brcm_pcie *pcie, u32 val);
|
|
|
|
int (*bridge_sw_init_set)(struct brcm_pcie *pcie, u32 val);
|
PCI: brcmstb: Add bcm7278 register info
Add in compatibility strings and code for three Broadcom STB chips. Some
of the register locations, shifts, and masks are different for certain
chips, requiring the use of different constants based on of_id.
We would like to add the following at this time to the match list but we
need to wait until the end of this patchset so that everything works.
{ .compatible = "brcm,bcm7211-pcie", .data = &generic_cfg },
{ .compatible = "brcm,bcm7278-pcie", .data = &bcm7278_cfg },
{ .compatible = "brcm,bcm7216-pcie", .data = &bcm7278_cfg },
{ .compatible = "brcm,bcm7445-pcie", .data = &generic_cfg },
Link: https://lore.kernel.org/r/20200911175232.19016-4-james.quinlan@broadcom.com
Signed-off-by: Jim Quinlan <jquinlan@broadcom.com>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
Acked-by: Rob Herring <robh@kernel.org>
2020-09-11 17:52:23 +00:00
|
|
|
};
|
|
|
|
|
PCI: brcmstb: Enable child bus device regulators from DT
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2124638
Upstream Status: 9e6be018b26347c26a93e63fb50a37ee2c9311de
commit 9e6be018b26347c26a93e63fb50a37ee2c9311de
Author: Jim Quinlan <jim2101024@gmail.com>
Date: Mon Jul 25 11:12:53 2022 -0400
PCI: brcmstb: Enable child bus device regulators from DT
Some platforms have power regulators for slots or devices below Root Ports.
On platforms like Raspberry Pi 4, these regulators are described in the
Root Port device tree node, since they logically belong to the Root Port,
not to the host bridge itself.
Add an .add_bus() hook (called when pci_alloc_child_bus() allocates the
secondary ("child") bus for a bridge), and look for such regulators. If we
find some, enable them before bringing up the link and enumerating devices
on the child bus.
Similarly, when pci_remove_bus() calls the ops->remove_bus() hook, disable
the regulators.
The regulators that may be described in a Root Port DT device are:
vpcie3v3
vpcie3v3aux
vpcie12v
These control power to the device downstream from the Root Port.
[bhelgaas: commit log, name hooks brcm_pcie_add_bus(), etc, since we only
support one set of subregulator info, save info in struct brcm_pcie instead
of dev->driver_data, move brcm_pcie_start_link() from probe to .add_bus()
(from subsequent patch)]
Link: https://lore.kernel.org/r/20220725151258.42574-5-jim2101024@gmail.com
Signed-off-by: Jim Quinlan <jim2101024@gmail.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Tested-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Myron Stowe <mstowe@redhat.com>
2022-09-13 23:22:17 +00:00
|
|
|
struct subdev_regulators {
|
|
|
|
unsigned int num_supplies;
|
|
|
|
struct regulator_bulk_data supplies[];
|
|
|
|
};
|
|
|
|
|
2019-12-16 11:01:10 +00:00
|
|
|
struct brcm_msi {
|
|
|
|
struct device *dev;
|
|
|
|
void __iomem *base;
|
|
|
|
struct device_node *np;
|
|
|
|
struct irq_domain *msi_domain;
|
|
|
|
struct irq_domain *inner_domain;
|
|
|
|
struct mutex lock; /* guards the alloc/free operations */
|
|
|
|
u64 target_addr;
|
|
|
|
int irq;
|
2022-03-28 22:49:25 +00:00
|
|
|
DECLARE_BITMAP(used, BRCM_INT_PCI_MSI_NR);
|
2020-09-11 17:52:28 +00:00
|
|
|
bool legacy;
|
|
|
|
/* Some chips have MSIs in bits [31..24] of a shared register. */
|
|
|
|
int legacy_shift;
|
|
|
|
int nr; /* No. of MSI available, depends on chip */
|
|
|
|
/* This is the base pointer for interrupt status/set/clr regs */
|
|
|
|
void __iomem *intr_base;
|
2019-12-16 11:01:10 +00:00
|
|
|
};
|
|
|
|
|
2019-12-16 11:01:09 +00:00
|
|
|
/* Internal PCIe Host Controller Information.*/
|
|
|
|
struct brcm_pcie {
|
|
|
|
struct device *dev;
|
|
|
|
void __iomem *base;
|
|
|
|
struct clk *clk;
|
|
|
|
struct device_node *np;
|
|
|
|
bool ssc;
|
|
|
|
int gen;
|
2019-12-16 11:01:10 +00:00
|
|
|
u64 msi_target_addr;
|
|
|
|
struct brcm_msi *msi;
|
PCI: brcmstb: Add bcm7278 register info
Add in compatibility strings and code for three Broadcom STB chips. Some
of the register locations, shifts, and masks are different for certain
chips, requiring the use of different constants based on of_id.
We would like to add the following at this time to the match list but we
need to wait until the end of this patchset so that everything works.
{ .compatible = "brcm,bcm7211-pcie", .data = &generic_cfg },
{ .compatible = "brcm,bcm7278-pcie", .data = &bcm7278_cfg },
{ .compatible = "brcm,bcm7216-pcie", .data = &bcm7278_cfg },
{ .compatible = "brcm,bcm7445-pcie", .data = &generic_cfg },
Link: https://lore.kernel.org/r/20200911175232.19016-4-james.quinlan@broadcom.com
Signed-off-by: Jim Quinlan <jquinlan@broadcom.com>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
Acked-by: Rob Herring <robh@kernel.org>
2020-09-11 17:52:23 +00:00
|
|
|
const int *reg_offsets;
|
2025-02-17 19:35:32 +00:00
|
|
|
enum pcie_soc_base soc_base;
|
2020-09-11 17:52:25 +00:00
|
|
|
struct reset_control *rescal;
|
2020-12-10 18:04:21 +00:00
|
|
|
struct reset_control *perst_reset;
|
2025-02-17 19:34:28 +00:00
|
|
|
struct reset_control *bridge_reset;
|
2025-02-17 19:34:37 +00:00
|
|
|
struct reset_control *swinit_reset;
|
2020-09-11 17:52:25 +00:00
|
|
|
int num_memc;
|
|
|
|
u64 memc_size[PCIE_BRCM_MAX_MEMC];
|
|
|
|
u32 hw_rev;
|
2025-02-17 19:35:19 +00:00
|
|
|
int (*perst_set)(struct brcm_pcie *pcie, u32 val);
|
|
|
|
int (*bridge_sw_init_set)(struct brcm_pcie *pcie, u32 val);
|
PCI: brcmstb: Enable child bus device regulators from DT
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2124638
Upstream Status: 9e6be018b26347c26a93e63fb50a37ee2c9311de
commit 9e6be018b26347c26a93e63fb50a37ee2c9311de
Author: Jim Quinlan <jim2101024@gmail.com>
Date: Mon Jul 25 11:12:53 2022 -0400
PCI: brcmstb: Enable child bus device regulators from DT
Some platforms have power regulators for slots or devices below Root Ports.
On platforms like Raspberry Pi 4, these regulators are described in the
Root Port device tree node, since they logically belong to the Root Port,
not to the host bridge itself.
Add an .add_bus() hook (called when pci_alloc_child_bus() allocates the
secondary ("child") bus for a bridge), and look for such regulators. If we
find some, enable them before bringing up the link and enumerating devices
on the child bus.
Similarly, when pci_remove_bus() calls the ops->remove_bus() hook, disable
the regulators.
The regulators that may be described in a Root Port DT device are:
vpcie3v3
vpcie3v3aux
vpcie12v
These control power to the device downstream from the Root Port.
[bhelgaas: commit log, name hooks brcm_pcie_add_bus(), etc, since we only
support one set of subregulator info, save info in struct brcm_pcie instead
of dev->driver_data, move brcm_pcie_start_link() from probe to .add_bus()
(from subsequent patch)]
Link: https://lore.kernel.org/r/20220725151258.42574-5-jim2101024@gmail.com
Signed-off-by: Jim Quinlan <jim2101024@gmail.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Tested-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Myron Stowe <mstowe@redhat.com>
2022-09-13 23:22:17 +00:00
|
|
|
struct subdev_regulators *sr;
|
2022-09-13 23:23:13 +00:00
|
|
|
bool ep_wakeup_capable;
|
2025-02-17 19:35:02 +00:00
|
|
|
bool has_phy;
|
2025-02-17 19:35:10 +00:00
|
|
|
u8 num_inbound_wins;
|
2019-12-16 11:01:09 +00:00
|
|
|
};
|
|
|
|
|
2022-09-13 23:17:57 +00:00
|
|
|
static inline bool is_bmips(const struct brcm_pcie *pcie)
|
|
|
|
{
|
2025-02-17 19:35:32 +00:00
|
|
|
return pcie->soc_base == BCM7435 || pcie->soc_base == BCM7425;
|
2022-09-13 23:17:57 +00:00
|
|
|
}
|
|
|
|
|
2019-12-16 11:01:09 +00:00
|
|
|
/*
|
|
|
|
* This is to convert the size of the inbound "BAR" region to the
|
|
|
|
* non-linear values of PCIE_X_MISC_RC_BAR[123]_CONFIG_LO.SIZE
|
|
|
|
*/
|
|
|
|
static int brcm_pcie_encode_ibar_size(u64 size)
|
|
|
|
{
|
|
|
|
int log2_in = ilog2(size);
|
|
|
|
|
|
|
|
if (log2_in >= 12 && log2_in <= 15)
|
|
|
|
/* Covers 4KB to 32KB (inclusive) */
|
|
|
|
return (log2_in - 12) + 0x1c;
|
|
|
|
else if (log2_in >= 16 && log2_in <= 35)
|
|
|
|
/* Covers 64KB to 32GB, (inclusive) */
|
|
|
|
return log2_in - 15;
|
|
|
|
/* Something is awry so disable */
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static u32 brcm_pcie_mdio_form_pkt(int port, int regad, int cmd)
|
|
|
|
{
|
|
|
|
u32 pkt = 0;
|
|
|
|
|
|
|
|
pkt |= FIELD_PREP(MDIO_PORT_MASK, port);
|
|
|
|
pkt |= FIELD_PREP(MDIO_REGAD_MASK, regad);
|
|
|
|
pkt |= FIELD_PREP(MDIO_CMD_MASK, cmd);
|
|
|
|
|
|
|
|
return pkt;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* negative return value indicates error */
|
|
|
|
static int brcm_pcie_mdio_read(void __iomem *base, u8 port, u8 regad, u32 *val)
|
|
|
|
{
|
|
|
|
u32 data;
|
2023-02-09 18:25:03 +00:00
|
|
|
int err;
|
2019-12-16 11:01:09 +00:00
|
|
|
|
|
|
|
writel(brcm_pcie_mdio_form_pkt(port, regad, MDIO_CMD_READ),
|
|
|
|
base + PCIE_RC_DL_MDIO_ADDR);
|
|
|
|
readl(base + PCIE_RC_DL_MDIO_ADDR);
|
2023-02-09 18:25:03 +00:00
|
|
|
err = readl_poll_timeout_atomic(base + PCIE_RC_DL_MDIO_RD_DATA, data,
|
|
|
|
MDIO_RD_DONE(data), 10, 100);
|
2019-12-16 11:01:09 +00:00
|
|
|
*val = FIELD_GET(MDIO_DATA_MASK, data);
|
2023-02-09 18:25:03 +00:00
|
|
|
|
|
|
|
return err;
|
2019-12-16 11:01:09 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/* negative return value indicates error */
|
|
|
|
static int brcm_pcie_mdio_write(void __iomem *base, u8 port,
|
|
|
|
u8 regad, u16 wrdata)
|
|
|
|
{
|
|
|
|
u32 data;
|
2023-02-09 18:25:03 +00:00
|
|
|
int err;
|
2019-12-16 11:01:09 +00:00
|
|
|
|
|
|
|
writel(brcm_pcie_mdio_form_pkt(port, regad, MDIO_CMD_WRITE),
|
|
|
|
base + PCIE_RC_DL_MDIO_ADDR);
|
|
|
|
readl(base + PCIE_RC_DL_MDIO_ADDR);
|
|
|
|
writel(MDIO_DATA_DONE_MASK | wrdata, base + PCIE_RC_DL_MDIO_WR_DATA);
|
|
|
|
|
2024-05-05 15:11:37 +00:00
|
|
|
err = readl_poll_timeout_atomic(base + PCIE_RC_DL_MDIO_WR_DATA, data,
|
2023-02-09 18:25:03 +00:00
|
|
|
MDIO_WT_DONE(data), 10, 100);
|
|
|
|
return err;
|
2019-12-16 11:01:09 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Configures device for Spread Spectrum Clocking (SSC) mode; a negative
|
|
|
|
* return value indicates error.
|
|
|
|
*/
|
|
|
|
static int brcm_pcie_set_ssc(struct brcm_pcie *pcie)
|
|
|
|
{
|
|
|
|
int pll, ssc;
|
|
|
|
int ret;
|
|
|
|
u32 tmp;
|
|
|
|
|
|
|
|
ret = brcm_pcie_mdio_write(pcie->base, MDIO_PORT0, SET_ADDR_OFFSET,
|
|
|
|
SSC_REGS_ADDR);
|
|
|
|
if (ret < 0)
|
|
|
|
return ret;
|
|
|
|
|
|
|
|
ret = brcm_pcie_mdio_read(pcie->base, MDIO_PORT0,
|
|
|
|
SSC_CNTL_OFFSET, &tmp);
|
|
|
|
if (ret < 0)
|
|
|
|
return ret;
|
|
|
|
|
|
|
|
u32p_replace_bits(&tmp, 1, SSC_CNTL_OVRD_EN_MASK);
|
|
|
|
u32p_replace_bits(&tmp, 1, SSC_CNTL_OVRD_VAL_MASK);
|
|
|
|
ret = brcm_pcie_mdio_write(pcie->base, MDIO_PORT0,
|
|
|
|
SSC_CNTL_OFFSET, tmp);
|
|
|
|
if (ret < 0)
|
|
|
|
return ret;
|
|
|
|
|
|
|
|
usleep_range(1000, 2000);
|
|
|
|
ret = brcm_pcie_mdio_read(pcie->base, MDIO_PORT0,
|
|
|
|
SSC_STATUS_OFFSET, &tmp);
|
|
|
|
if (ret < 0)
|
|
|
|
return ret;
|
|
|
|
|
|
|
|
ssc = FIELD_GET(SSC_STATUS_SSC_MASK, tmp);
|
|
|
|
pll = FIELD_GET(SSC_STATUS_PLL_LOCK_MASK, tmp);
|
|
|
|
|
|
|
|
return ssc && pll ? 0 : -EIO;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Limits operation to a specific generation (1, 2, or 3) */
|
|
|
|
static void brcm_pcie_set_gen(struct brcm_pcie *pcie, int gen)
|
|
|
|
{
|
|
|
|
u16 lnkctl2 = readw(pcie->base + BRCM_PCIE_CAP_REGS + PCI_EXP_LNKCTL2);
|
|
|
|
u32 lnkcap = readl(pcie->base + BRCM_PCIE_CAP_REGS + PCI_EXP_LNKCAP);
|
|
|
|
|
|
|
|
lnkcap = (lnkcap & ~PCI_EXP_LNKCAP_SLS) | gen;
|
|
|
|
writel(lnkcap, pcie->base + BRCM_PCIE_CAP_REGS + PCI_EXP_LNKCAP);
|
|
|
|
|
|
|
|
lnkctl2 = (lnkctl2 & ~0xf) | gen;
|
|
|
|
writew(lnkctl2, pcie->base + BRCM_PCIE_CAP_REGS + PCI_EXP_LNKCTL2);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void brcm_pcie_set_outbound_win(struct brcm_pcie *pcie,
|
2025-02-17 19:35:10 +00:00
|
|
|
u8 win, u64 cpu_addr,
|
2019-12-16 11:01:09 +00:00
|
|
|
u64 pcie_addr, u64 size)
|
|
|
|
{
|
|
|
|
u32 cpu_addr_mb_high, limit_addr_mb_high;
|
|
|
|
phys_addr_t cpu_addr_mb, limit_addr_mb;
|
|
|
|
int high_addr_shift;
|
|
|
|
u32 tmp;
|
|
|
|
|
|
|
|
/* Set the base of the pcie_addr window */
|
|
|
|
writel(lower_32_bits(pcie_addr), pcie->base + PCIE_MEM_WIN0_LO(win));
|
|
|
|
writel(upper_32_bits(pcie_addr), pcie->base + PCIE_MEM_WIN0_HI(win));
|
|
|
|
|
|
|
|
/* Write the addr base & limit lower bits (in MBs) */
|
|
|
|
cpu_addr_mb = cpu_addr / SZ_1M;
|
|
|
|
limit_addr_mb = (cpu_addr + size - 1) / SZ_1M;
|
|
|
|
|
|
|
|
tmp = readl(pcie->base + PCIE_MEM_WIN0_BASE_LIMIT(win));
|
|
|
|
u32p_replace_bits(&tmp, cpu_addr_mb,
|
|
|
|
PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_LIMIT_BASE_MASK);
|
|
|
|
u32p_replace_bits(&tmp, limit_addr_mb,
|
|
|
|
PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_LIMIT_LIMIT_MASK);
|
|
|
|
writel(tmp, pcie->base + PCIE_MEM_WIN0_BASE_LIMIT(win));
|
|
|
|
|
2022-09-13 23:17:57 +00:00
|
|
|
if (is_bmips(pcie))
|
|
|
|
return;
|
|
|
|
|
2019-12-16 11:01:09 +00:00
|
|
|
/* Write the cpu & limit addr upper bits */
|
|
|
|
high_addr_shift =
|
|
|
|
HWEIGHT32(PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_LIMIT_BASE_MASK);
|
|
|
|
|
|
|
|
cpu_addr_mb_high = cpu_addr_mb >> high_addr_shift;
|
|
|
|
tmp = readl(pcie->base + PCIE_MEM_WIN0_BASE_HI(win));
|
|
|
|
u32p_replace_bits(&tmp, cpu_addr_mb_high,
|
|
|
|
PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_HI_BASE_MASK);
|
|
|
|
writel(tmp, pcie->base + PCIE_MEM_WIN0_BASE_HI(win));
|
|
|
|
|
|
|
|
limit_addr_mb_high = limit_addr_mb >> high_addr_shift;
|
|
|
|
tmp = readl(pcie->base + PCIE_MEM_WIN0_LIMIT_HI(win));
|
|
|
|
u32p_replace_bits(&tmp, limit_addr_mb_high,
|
|
|
|
PCIE_MISC_CPU_2_PCIE_MEM_WIN0_LIMIT_HI_LIMIT_MASK);
|
|
|
|
writel(tmp, pcie->base + PCIE_MEM_WIN0_LIMIT_HI(win));
|
|
|
|
}
|
|
|
|
|
2019-12-16 11:01:10 +00:00
|
|
|
static struct irq_chip brcm_msi_irq_chip = {
|
|
|
|
.name = "BRCM STB PCIe MSI",
|
|
|
|
.irq_ack = irq_chip_ack_parent,
|
|
|
|
.irq_mask = pci_msi_mask_irq,
|
|
|
|
.irq_unmask = pci_msi_unmask_irq,
|
|
|
|
};
|
|
|
|
|
|
|
|
static struct msi_domain_info brcm_msi_domain_info = {
|
2025-02-17 19:30:30 +00:00
|
|
|
.flags = MSI_FLAG_USE_DEF_DOM_OPS | MSI_FLAG_USE_DEF_CHIP_OPS |
|
|
|
|
MSI_FLAG_NO_AFFINITY | MSI_FLAG_MULTI_PCI_MSI,
|
2019-12-16 11:01:10 +00:00
|
|
|
.chip = &brcm_msi_irq_chip,
|
|
|
|
};
|
|
|
|
|
|
|
|
static void brcm_pcie_msi_isr(struct irq_desc *desc)
|
|
|
|
{
|
|
|
|
struct irq_chip *chip = irq_desc_get_chip(desc);
|
2022-01-15 19:59:44 +00:00
|
|
|
unsigned long status;
|
2019-12-16 11:01:10 +00:00
|
|
|
struct brcm_msi *msi;
|
|
|
|
struct device *dev;
|
|
|
|
u32 bit;
|
|
|
|
|
|
|
|
chained_irq_enter(chip, desc);
|
|
|
|
msi = irq_desc_get_handler_data(desc);
|
|
|
|
dev = msi->dev;
|
|
|
|
|
2020-09-11 17:52:28 +00:00
|
|
|
status = readl(msi->intr_base + MSI_INT_STATUS);
|
|
|
|
status >>= msi->legacy_shift;
|
|
|
|
|
|
|
|
for_each_set_bit(bit, &status, msi->nr) {
|
2022-01-15 19:59:44 +00:00
|
|
|
int ret;
|
|
|
|
ret = generic_handle_domain_irq(msi->inner_domain, bit);
|
|
|
|
if (ret)
|
2019-12-16 11:01:10 +00:00
|
|
|
dev_dbg(dev, "unexpected MSI\n");
|
|
|
|
}
|
|
|
|
|
|
|
|
chained_irq_exit(chip, desc);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void brcm_msi_compose_msi_msg(struct irq_data *data, struct msi_msg *msg)
|
|
|
|
{
|
|
|
|
struct brcm_msi *msi = irq_data_get_irq_chip_data(data);
|
|
|
|
|
|
|
|
msg->address_lo = lower_32_bits(msi->target_addr);
|
|
|
|
msg->address_hi = upper_32_bits(msi->target_addr);
|
2020-09-11 17:52:28 +00:00
|
|
|
msg->data = (0xffff & PCIE_MISC_MSI_DATA_CONFIG_VAL_32) | data->hwirq;
|
2019-12-16 11:01:10 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static void brcm_msi_ack_irq(struct irq_data *data)
|
|
|
|
{
|
|
|
|
struct brcm_msi *msi = irq_data_get_irq_chip_data(data);
|
2020-09-11 17:52:28 +00:00
|
|
|
const int shift_amt = data->hwirq + msi->legacy_shift;
|
2019-12-16 11:01:10 +00:00
|
|
|
|
2020-09-11 17:52:28 +00:00
|
|
|
writel(1 << shift_amt, msi->intr_base + MSI_INT_CLR);
|
2019-12-16 11:01:10 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
static struct irq_chip brcm_msi_bottom_irq_chip = {
|
|
|
|
.name = "BRCM STB MSI",
|
|
|
|
.irq_compose_msi_msg = brcm_msi_compose_msi_msg,
|
|
|
|
.irq_ack = brcm_msi_ack_irq,
|
|
|
|
};
|
|
|
|
|
2023-02-09 18:22:27 +00:00
|
|
|
static int brcm_msi_alloc(struct brcm_msi *msi, unsigned int nr_irqs)
|
2019-12-16 11:01:10 +00:00
|
|
|
{
|
|
|
|
int hwirq;
|
|
|
|
|
|
|
|
mutex_lock(&msi->lock);
|
2023-02-09 18:22:27 +00:00
|
|
|
hwirq = bitmap_find_free_region(msi->used, msi->nr,
|
|
|
|
order_base_2(nr_irqs));
|
2019-12-16 11:01:10 +00:00
|
|
|
mutex_unlock(&msi->lock);
|
|
|
|
|
|
|
|
return hwirq;
|
|
|
|
}
|
|
|
|
|
2023-02-09 18:22:27 +00:00
|
|
|
static void brcm_msi_free(struct brcm_msi *msi, unsigned long hwirq,
|
|
|
|
unsigned int nr_irqs)
|
2019-12-16 11:01:10 +00:00
|
|
|
{
|
|
|
|
mutex_lock(&msi->lock);
|
2023-02-09 18:22:27 +00:00
|
|
|
bitmap_release_region(msi->used, hwirq, order_base_2(nr_irqs));
|
2019-12-16 11:01:10 +00:00
|
|
|
mutex_unlock(&msi->lock);
|
|
|
|
}
|
|
|
|
|
|
|
|
static int brcm_irq_domain_alloc(struct irq_domain *domain, unsigned int virq,
|
|
|
|
unsigned int nr_irqs, void *args)
|
|
|
|
{
|
|
|
|
struct brcm_msi *msi = domain->host_data;
|
2023-02-09 18:22:27 +00:00
|
|
|
int hwirq, i;
|
2019-12-16 11:01:10 +00:00
|
|
|
|
2023-02-09 18:22:27 +00:00
|
|
|
hwirq = brcm_msi_alloc(msi, nr_irqs);
|
2019-12-16 11:01:10 +00:00
|
|
|
|
|
|
|
if (hwirq < 0)
|
|
|
|
return hwirq;
|
|
|
|
|
2023-02-09 18:22:27 +00:00
|
|
|
for (i = 0; i < nr_irqs; i++)
|
|
|
|
irq_domain_set_info(domain, virq + i, hwirq + i,
|
|
|
|
&brcm_msi_bottom_irq_chip, domain->host_data,
|
|
|
|
handle_edge_irq, NULL, NULL);
|
2019-12-16 11:01:10 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void brcm_irq_domain_free(struct irq_domain *domain,
|
|
|
|
unsigned int virq, unsigned int nr_irqs)
|
|
|
|
{
|
|
|
|
struct irq_data *d = irq_domain_get_irq_data(domain, virq);
|
|
|
|
struct brcm_msi *msi = irq_data_get_irq_chip_data(d);
|
|
|
|
|
2023-02-09 18:22:27 +00:00
|
|
|
brcm_msi_free(msi, d->hwirq, nr_irqs);
|
2019-12-16 11:01:10 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static const struct irq_domain_ops msi_domain_ops = {
|
|
|
|
.alloc = brcm_irq_domain_alloc,
|
|
|
|
.free = brcm_irq_domain_free,
|
|
|
|
};
|
|
|
|
|
|
|
|
static int brcm_allocate_domains(struct brcm_msi *msi)
|
|
|
|
{
|
|
|
|
struct fwnode_handle *fwnode = of_node_to_fwnode(msi->np);
|
|
|
|
struct device *dev = msi->dev;
|
|
|
|
|
2020-09-11 17:52:28 +00:00
|
|
|
msi->inner_domain = irq_domain_add_linear(NULL, msi->nr, &msi_domain_ops, msi);
|
2019-12-16 11:01:10 +00:00
|
|
|
if (!msi->inner_domain) {
|
|
|
|
dev_err(dev, "failed to create IRQ domain\n");
|
|
|
|
return -ENOMEM;
|
|
|
|
}
|
|
|
|
|
|
|
|
msi->msi_domain = pci_msi_create_irq_domain(fwnode,
|
|
|
|
&brcm_msi_domain_info,
|
|
|
|
msi->inner_domain);
|
|
|
|
if (!msi->msi_domain) {
|
|
|
|
dev_err(dev, "failed to create MSI domain\n");
|
|
|
|
irq_domain_remove(msi->inner_domain);
|
|
|
|
return -ENOMEM;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void brcm_free_domains(struct brcm_msi *msi)
|
|
|
|
{
|
|
|
|
irq_domain_remove(msi->msi_domain);
|
|
|
|
irq_domain_remove(msi->inner_domain);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void brcm_msi_remove(struct brcm_pcie *pcie)
|
|
|
|
{
|
|
|
|
struct brcm_msi *msi = pcie->msi;
|
|
|
|
|
|
|
|
if (!msi)
|
|
|
|
return;
|
2021-01-15 21:15:32 +00:00
|
|
|
irq_set_chained_handler_and_data(msi->irq, NULL, NULL);
|
2019-12-16 11:01:10 +00:00
|
|
|
brcm_free_domains(msi);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void brcm_msi_set_regs(struct brcm_msi *msi)
|
|
|
|
{
|
2022-03-28 22:50:37 +00:00
|
|
|
u32 val = msi->legacy ? BRCM_INT_PCI_MSI_LEGACY_MASK :
|
|
|
|
BRCM_INT_PCI_MSI_MASK;
|
2020-09-11 17:52:28 +00:00
|
|
|
|
|
|
|
writel(val, msi->intr_base + MSI_INT_MASK_CLR);
|
|
|
|
writel(val, msi->intr_base + MSI_INT_CLR);
|
2019-12-16 11:01:10 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* The 0 bit of PCIE_MISC_MSI_BAR_CONFIG_LO is repurposed to MSI
|
|
|
|
* enable, which we set to 1.
|
|
|
|
*/
|
|
|
|
writel(lower_32_bits(msi->target_addr) | 0x1,
|
|
|
|
msi->base + PCIE_MISC_MSI_BAR_CONFIG_LO);
|
|
|
|
writel(upper_32_bits(msi->target_addr),
|
|
|
|
msi->base + PCIE_MISC_MSI_BAR_CONFIG_HI);
|
|
|
|
|
2020-09-11 17:52:28 +00:00
|
|
|
val = msi->legacy ? PCIE_MISC_MSI_DATA_CONFIG_VAL_8 : PCIE_MISC_MSI_DATA_CONFIG_VAL_32;
|
|
|
|
writel(val, msi->base + PCIE_MISC_MSI_DATA_CONFIG);
|
2019-12-16 11:01:10 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static int brcm_pcie_enable_msi(struct brcm_pcie *pcie)
|
|
|
|
{
|
|
|
|
struct brcm_msi *msi;
|
|
|
|
int irq, ret;
|
|
|
|
struct device *dev = pcie->dev;
|
|
|
|
|
|
|
|
irq = irq_of_parse_and_map(dev->of_node, 1);
|
|
|
|
if (irq <= 0) {
|
|
|
|
dev_err(dev, "cannot map MSI interrupt\n");
|
|
|
|
return -ENODEV;
|
|
|
|
}
|
|
|
|
|
|
|
|
msi = devm_kzalloc(dev, sizeof(struct brcm_msi), GFP_KERNEL);
|
|
|
|
if (!msi)
|
|
|
|
return -ENOMEM;
|
|
|
|
|
|
|
|
mutex_init(&msi->lock);
|
|
|
|
msi->dev = dev;
|
|
|
|
msi->base = pcie->base;
|
|
|
|
msi->np = pcie->np;
|
|
|
|
msi->target_addr = pcie->msi_target_addr;
|
|
|
|
msi->irq = irq;
|
2020-09-11 17:52:28 +00:00
|
|
|
msi->legacy = pcie->hw_rev < BRCM_PCIE_HW_REV_33;
|
|
|
|
|
2022-03-28 22:49:25 +00:00
|
|
|
/*
|
|
|
|
* Sanity check to make sure that the 'used' bitmap in struct brcm_msi
|
|
|
|
* is large enough.
|
|
|
|
*/
|
|
|
|
BUILD_BUG_ON(BRCM_INT_PCI_MSI_LEGACY_NR > BRCM_INT_PCI_MSI_NR);
|
|
|
|
|
2020-09-11 17:52:28 +00:00
|
|
|
if (msi->legacy) {
|
2025-02-17 19:34:45 +00:00
|
|
|
msi->intr_base = msi->base + INTR2_CPU_BASE(pcie);
|
2020-09-11 17:52:28 +00:00
|
|
|
msi->nr = BRCM_INT_PCI_MSI_LEGACY_NR;
|
|
|
|
msi->legacy_shift = 24;
|
|
|
|
} else {
|
|
|
|
msi->intr_base = msi->base + PCIE_MSI_INTR2_BASE;
|
|
|
|
msi->nr = BRCM_INT_PCI_MSI_NR;
|
|
|
|
msi->legacy_shift = 0;
|
|
|
|
}
|
2019-12-16 11:01:10 +00:00
|
|
|
|
|
|
|
ret = brcm_allocate_domains(msi);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
|
|
|
|
irq_set_chained_handler_and_data(msi->irq, brcm_pcie_msi_isr, msi);
|
|
|
|
|
|
|
|
brcm_msi_set_regs(msi);
|
|
|
|
pcie->msi = msi;
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2019-12-16 11:01:09 +00:00
|
|
|
/* The controller is capable of serving in both RC and EP roles */
|
|
|
|
static bool brcm_pcie_rc_mode(struct brcm_pcie *pcie)
|
|
|
|
{
|
|
|
|
void __iomem *base = pcie->base;
|
|
|
|
u32 val = readl(base + PCIE_MISC_PCIE_STATUS);
|
|
|
|
|
|
|
|
return !!FIELD_GET(PCIE_MISC_PCIE_STATUS_PCIE_PORT_MASK, val);
|
|
|
|
}
|
|
|
|
|
|
|
|
static bool brcm_pcie_link_up(struct brcm_pcie *pcie)
|
|
|
|
{
|
|
|
|
u32 val = readl(pcie->base + PCIE_MISC_PCIE_STATUS);
|
|
|
|
u32 dla = FIELD_GET(PCIE_MISC_PCIE_STATUS_PCIE_DL_ACTIVE_MASK, val);
|
|
|
|
u32 plu = FIELD_GET(PCIE_MISC_PCIE_STATUS_PCIE_PHYLINKUP_MASK, val);
|
|
|
|
|
|
|
|
return dla && plu;
|
|
|
|
}
|
|
|
|
|
2022-09-13 23:24:04 +00:00
|
|
|
static void __iomem *brcm_pcie_map_bus(struct pci_bus *bus,
|
|
|
|
unsigned int devfn, int where)
|
2019-12-16 11:01:09 +00:00
|
|
|
{
|
|
|
|
struct brcm_pcie *pcie = bus->sysdata;
|
|
|
|
void __iomem *base = pcie->base;
|
|
|
|
int idx;
|
|
|
|
|
2022-09-13 23:20:16 +00:00
|
|
|
/* Accesses to the RC go right to the RC registers if !devfn */
|
2019-12-16 11:01:09 +00:00
|
|
|
if (pci_is_root_bus(bus))
|
2022-09-13 23:20:16 +00:00
|
|
|
return devfn ? NULL : base + PCIE_ECAM_REG(where);
|
|
|
|
|
|
|
|
/* An access to our HW w/o link-up will cause a CPU Abort */
|
|
|
|
if (!brcm_pcie_link_up(pcie))
|
|
|
|
return NULL;
|
2019-12-16 11:01:09 +00:00
|
|
|
|
|
|
|
/* For devices, write to the config space index register */
|
2020-11-29 23:07:39 +00:00
|
|
|
idx = PCIE_ECAM_OFFSET(bus->number, devfn, 0);
|
2019-12-16 11:01:09 +00:00
|
|
|
writel(idx, pcie->base + PCIE_EXT_CFG_INDEX);
|
2022-09-13 23:20:16 +00:00
|
|
|
return base + PCIE_EXT_CFG_DATA + PCIE_ECAM_REG(where);
|
2019-12-16 11:01:09 +00:00
|
|
|
}
|
|
|
|
|
2022-09-13 23:24:04 +00:00
|
|
|
static void __iomem *brcm7425_pcie_map_bus(struct pci_bus *bus,
|
|
|
|
unsigned int devfn, int where)
|
2022-09-13 23:17:57 +00:00
|
|
|
{
|
|
|
|
struct brcm_pcie *pcie = bus->sysdata;
|
|
|
|
void __iomem *base = pcie->base;
|
|
|
|
int idx;
|
|
|
|
|
2022-09-13 23:20:16 +00:00
|
|
|
/* Accesses to the RC go right to the RC registers if !devfn */
|
2022-09-13 23:17:57 +00:00
|
|
|
if (pci_is_root_bus(bus))
|
2022-09-13 23:20:16 +00:00
|
|
|
return devfn ? NULL : base + PCIE_ECAM_REG(where);
|
|
|
|
|
|
|
|
/* An access to our HW w/o link-up will cause a CPU Abort */
|
|
|
|
if (!brcm_pcie_link_up(pcie))
|
|
|
|
return NULL;
|
2022-09-13 23:17:57 +00:00
|
|
|
|
|
|
|
/* For devices, write to the config space index register */
|
2022-09-13 23:20:16 +00:00
|
|
|
idx = PCIE_ECAM_OFFSET(bus->number, devfn, where);
|
2022-09-13 23:17:57 +00:00
|
|
|
writel(idx, base + IDX_ADDR(pcie));
|
|
|
|
return base + DATA_ADDR(pcie);
|
|
|
|
}
|
|
|
|
|
2025-02-17 19:35:19 +00:00
|
|
|
static int brcm_pcie_bridge_sw_init_set_generic(struct brcm_pcie *pcie, u32 val)
|
2019-12-16 11:01:09 +00:00
|
|
|
{
|
2025-02-17 19:34:28 +00:00
|
|
|
u32 tmp, mask = RGR1_SW_INIT_1_INIT_GENERIC_MASK;
|
2020-09-11 17:52:25 +00:00
|
|
|
u32 shift = RGR1_SW_INIT_1_INIT_GENERIC_SHIFT;
|
2025-02-17 19:35:19 +00:00
|
|
|
int ret = 0;
|
2019-12-16 11:01:09 +00:00
|
|
|
|
2025-02-17 19:34:28 +00:00
|
|
|
if (pcie->bridge_reset) {
|
|
|
|
if (val)
|
2025-02-17 19:35:19 +00:00
|
|
|
ret = reset_control_assert(pcie->bridge_reset);
|
2025-02-17 19:34:28 +00:00
|
|
|
else
|
2025-02-17 19:35:19 +00:00
|
|
|
ret = reset_control_deassert(pcie->bridge_reset);
|
2025-02-17 19:34:28 +00:00
|
|
|
|
2025-02-17 19:35:19 +00:00
|
|
|
if (ret)
|
|
|
|
dev_err(pcie->dev, "failed to %s 'bridge' reset, err=%d\n",
|
|
|
|
val ? "assert" : "deassert", ret);
|
|
|
|
|
|
|
|
return ret;
|
2025-02-17 19:34:28 +00:00
|
|
|
}
|
|
|
|
|
PCI: brcmstb: Add bcm7278 register info
Add in compatibility strings and code for three Broadcom STB chips. Some
of the register locations, shifts, and masks are different for certain
chips, requiring the use of different constants based on of_id.
We would like to add the following at this time to the match list but we
need to wait until the end of this patchset so that everything works.
{ .compatible = "brcm,bcm7211-pcie", .data = &generic_cfg },
{ .compatible = "brcm,bcm7278-pcie", .data = &bcm7278_cfg },
{ .compatible = "brcm,bcm7216-pcie", .data = &bcm7278_cfg },
{ .compatible = "brcm,bcm7445-pcie", .data = &generic_cfg },
Link: https://lore.kernel.org/r/20200911175232.19016-4-james.quinlan@broadcom.com
Signed-off-by: Jim Quinlan <jquinlan@broadcom.com>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
Acked-by: Rob Herring <robh@kernel.org>
2020-09-11 17:52:23 +00:00
|
|
|
tmp = readl(pcie->base + PCIE_RGR1_SW_INIT_1(pcie));
|
|
|
|
tmp = (tmp & ~mask) | ((val << shift) & mask);
|
|
|
|
writel(tmp, pcie->base + PCIE_RGR1_SW_INIT_1(pcie));
|
2025-02-17 19:35:19 +00:00
|
|
|
|
|
|
|
return ret;
|
2019-12-16 11:01:09 +00:00
|
|
|
}
|
|
|
|
|
2025-02-17 19:35:19 +00:00
|
|
|
static int brcm_pcie_bridge_sw_init_set_7278(struct brcm_pcie *pcie, u32 val)
|
2020-09-11 17:52:25 +00:00
|
|
|
{
|
|
|
|
u32 tmp, mask = RGR1_SW_INIT_1_INIT_7278_MASK;
|
|
|
|
u32 shift = RGR1_SW_INIT_1_INIT_7278_SHIFT;
|
|
|
|
|
|
|
|
tmp = readl(pcie->base + PCIE_RGR1_SW_INIT_1(pcie));
|
|
|
|
tmp = (tmp & ~mask) | ((val << shift) & mask);
|
|
|
|
writel(tmp, pcie->base + PCIE_RGR1_SW_INIT_1(pcie));
|
2025-02-17 19:35:19 +00:00
|
|
|
|
|
|
|
return 0;
|
2020-09-11 17:52:25 +00:00
|
|
|
}
|
|
|
|
|
2025-02-17 19:35:19 +00:00
|
|
|
static int brcm_pcie_perst_set_4908(struct brcm_pcie *pcie, u32 val)
|
2020-12-10 18:04:21 +00:00
|
|
|
{
|
2025-02-17 19:35:19 +00:00
|
|
|
int ret;
|
|
|
|
|
2020-12-10 18:04:21 +00:00
|
|
|
if (WARN_ONCE(!pcie->perst_reset, "missing PERST# reset controller\n"))
|
2025-02-17 19:35:19 +00:00
|
|
|
return -EINVAL;
|
2020-12-10 18:04:21 +00:00
|
|
|
|
|
|
|
if (val)
|
2025-02-17 19:35:19 +00:00
|
|
|
ret = reset_control_assert(pcie->perst_reset);
|
2020-12-10 18:04:21 +00:00
|
|
|
else
|
2025-02-17 19:35:19 +00:00
|
|
|
ret = reset_control_deassert(pcie->perst_reset);
|
|
|
|
|
|
|
|
if (ret)
|
|
|
|
dev_err(pcie->dev, "failed to %s 'perst' reset, err=%d\n",
|
|
|
|
val ? "assert" : "deassert", ret);
|
|
|
|
return ret;
|
2020-12-10 18:04:21 +00:00
|
|
|
}
|
|
|
|
|
2025-02-17 19:35:19 +00:00
|
|
|
static int brcm_pcie_perst_set_7278(struct brcm_pcie *pcie, u32 val)
|
2019-12-16 11:01:09 +00:00
|
|
|
{
|
|
|
|
u32 tmp;
|
|
|
|
|
2020-09-11 17:52:25 +00:00
|
|
|
/* Perst bit has moved and assert value is 0 */
|
|
|
|
tmp = readl(pcie->base + PCIE_MISC_PCIE_CTRL);
|
|
|
|
u32p_replace_bits(&tmp, !val, PCIE_MISC_PCIE_CTRL_PCIE_PERSTB_MASK);
|
|
|
|
writel(tmp, pcie->base + PCIE_MISC_PCIE_CTRL);
|
2025-02-17 19:35:19 +00:00
|
|
|
|
|
|
|
return 0;
|
2019-12-16 11:01:09 +00:00
|
|
|
}
|
|
|
|
|
2025-02-17 19:35:19 +00:00
|
|
|
static int brcm_pcie_perst_set_generic(struct brcm_pcie *pcie, u32 val)
|
2019-12-16 11:01:09 +00:00
|
|
|
{
|
|
|
|
u32 tmp;
|
|
|
|
|
PCI: brcmstb: Add bcm7278 register info
Add in compatibility strings and code for three Broadcom STB chips. Some
of the register locations, shifts, and masks are different for certain
chips, requiring the use of different constants based on of_id.
We would like to add the following at this time to the match list but we
need to wait until the end of this patchset so that everything works.
{ .compatible = "brcm,bcm7211-pcie", .data = &generic_cfg },
{ .compatible = "brcm,bcm7278-pcie", .data = &bcm7278_cfg },
{ .compatible = "brcm,bcm7216-pcie", .data = &bcm7278_cfg },
{ .compatible = "brcm,bcm7445-pcie", .data = &generic_cfg },
Link: https://lore.kernel.org/r/20200911175232.19016-4-james.quinlan@broadcom.com
Signed-off-by: Jim Quinlan <jquinlan@broadcom.com>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
Acked-by: Rob Herring <robh@kernel.org>
2020-09-11 17:52:23 +00:00
|
|
|
tmp = readl(pcie->base + PCIE_RGR1_SW_INIT_1(pcie));
|
2019-12-16 11:01:09 +00:00
|
|
|
u32p_replace_bits(&tmp, val, PCIE_RGR1_SW_INIT_1_PERST_MASK);
|
PCI: brcmstb: Add bcm7278 register info
Add in compatibility strings and code for three Broadcom STB chips. Some
of the register locations, shifts, and masks are different for certain
chips, requiring the use of different constants based on of_id.
We would like to add the following at this time to the match list but we
need to wait until the end of this patchset so that everything works.
{ .compatible = "brcm,bcm7211-pcie", .data = &generic_cfg },
{ .compatible = "brcm,bcm7278-pcie", .data = &bcm7278_cfg },
{ .compatible = "brcm,bcm7216-pcie", .data = &bcm7278_cfg },
{ .compatible = "brcm,bcm7445-pcie", .data = &generic_cfg },
Link: https://lore.kernel.org/r/20200911175232.19016-4-james.quinlan@broadcom.com
Signed-off-by: Jim Quinlan <jquinlan@broadcom.com>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
Acked-by: Rob Herring <robh@kernel.org>
2020-09-11 17:52:23 +00:00
|
|
|
writel(tmp, pcie->base + PCIE_RGR1_SW_INIT_1(pcie));
|
2025-02-17 19:35:19 +00:00
|
|
|
|
|
|
|
return 0;
|
2019-12-16 11:01:09 +00:00
|
|
|
}
|
|
|
|
|
2025-02-17 19:35:10 +00:00
|
|
|
static void add_inbound_win(struct inbound_win *b, u8 *count, u64 size,
|
|
|
|
u64 cpu_addr, u64 pci_offset)
|
|
|
|
{
|
|
|
|
b->size = size;
|
|
|
|
b->cpu_addr = cpu_addr;
|
|
|
|
b->pci_offset = pci_offset;
|
|
|
|
(*count)++;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int brcm_pcie_get_inbound_wins(struct brcm_pcie *pcie,
|
|
|
|
struct inbound_win inbound_wins[])
|
2019-12-16 11:01:09 +00:00
|
|
|
{
|
|
|
|
struct pci_host_bridge *bridge = pci_host_bridge_from_priv(pcie);
|
2025-02-17 19:35:10 +00:00
|
|
|
u64 pci_offset, cpu_addr, size = 0, tot_size = 0;
|
2019-12-16 11:01:09 +00:00
|
|
|
struct resource_entry *entry;
|
PCI: brcmstb: Set additional internal memory DMA viewport sizes
The Raspberry Pi (RPI) is currently the only chip using this driver
(pcie-brcmstb.c). There, only one memory controller is used, without an
extension region, and the SCB0 viewport size is set to the size of the
first and only dma-range region. Other BrcmSTB SOCs have more complicated
memory configurations that require setting additional viewport sizes.
BrcmSTB PCIe controllers are intimately connected to the memory
controller(s) on the SOC. The SOC may have one to three memory
controllers; they are indicated by the term SCBi. Each controller has a
base region and an optional extension region. In physical memory, the base
and extension regions of a controller are not adjacent, but in PCIe-space
they are.
There is a "viewport" for each memory controller that allows DMA from
endpoint devices. Each viewport's size must be set to a power of two, and
that size must be equal to or larger than the amount of memory each
controller supports which is the sum of base region and its optional
extension. Further, the 1-3 viewports are also adjacent in PCIe-space.
Unfortunately the viewport sizes cannot be ascertained from the
"dma-ranges" property so they have their own property, "brcm,scb-sizes".
This is because dma-range information does not indicate what memory
controller it is associated. For example, consider the following case
where the size of one dma-range is 2GB and the second dma-range is 1GB:
/* Case 1: SCB0 size set to 4GB */
dma-range0: 2GB (from memc0-base)
dma-range1: 1GB (from memc0-extension)
/* Case 2: SCB0 size set to 2GB, SCB1 size set to 1GB */
dma-range0: 2GB (from memc0-base)
dma-range1: 1GB (from memc0-extension)
By just looking at the dma-ranges information, one cannot tell which
situation applies. That is why an additional property is needed. Its
length indicates the number of memory controllers being used and each value
indicates the viewport size.
Note that the RPI DT does not have a "brcm,scb-sizes" property value,
as it is assumed that it only requires one memory controller and no
extension. So the optional use of "brcm,scb-sizes" will be backwards
compatible.
One last layer of complexity exists: all of the viewports sizes must be
added and rounded up to a power of two to determine what the "BAR" size is.
Further, an offset must be given that indicates the base PCIe address of
this "BAR". The use of the term BAR is typically associated with endpoint
devices, and the term is used here because the PCIe HW may be used as an RC
or an EP. In the former case, all of the system memory appears in a single
"BAR" region in PCIe memory. As it turns out, BrcmSTB PCIe HW is rarely
used in the EP role and its system of mapping memory is an artifact that
requires multiple dma-ranges regions.
Link: https://lore.kernel.org/r/20200911175232.19016-8-james.quinlan@broadcom.com
Signed-off-by: Jim Quinlan <james.quinlan@broadcom.com>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
2020-09-11 17:52:27 +00:00
|
|
|
struct device *dev = pcie->dev;
|
|
|
|
u64 lowest_pcie_addr = ~(u64)0;
|
|
|
|
int ret, i = 0;
|
2025-02-17 19:35:10 +00:00
|
|
|
u8 n = 0;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* The HW registers (and PCIe) use order-1 numbering for BARs. As such,
|
|
|
|
* we have inbound_wins[0] unused and BAR1 starts at inbound_wins[1].
|
|
|
|
*/
|
|
|
|
struct inbound_win *b_begin = &inbound_wins[1];
|
|
|
|
struct inbound_win *b = b_begin;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* STB chips beside 7712 disable the first inbound window default.
|
|
|
|
* Rather being mapped to system memory it is mapped to the
|
|
|
|
* internal registers of the SoC. This feature is deprecated, has
|
|
|
|
* security considerations, and is not implemented in our modern
|
|
|
|
* SoCs.
|
|
|
|
*/
|
2025-02-17 19:35:32 +00:00
|
|
|
if (pcie->soc_base != BCM7712)
|
2025-02-17 19:35:10 +00:00
|
|
|
add_inbound_win(b++, &n, 0, 0, 0);
|
2019-12-16 11:01:09 +00:00
|
|
|
|
PCI: brcmstb: Set additional internal memory DMA viewport sizes
The Raspberry Pi (RPI) is currently the only chip using this driver
(pcie-brcmstb.c). There, only one memory controller is used, without an
extension region, and the SCB0 viewport size is set to the size of the
first and only dma-range region. Other BrcmSTB SOCs have more complicated
memory configurations that require setting additional viewport sizes.
BrcmSTB PCIe controllers are intimately connected to the memory
controller(s) on the SOC. The SOC may have one to three memory
controllers; they are indicated by the term SCBi. Each controller has a
base region and an optional extension region. In physical memory, the base
and extension regions of a controller are not adjacent, but in PCIe-space
they are.
There is a "viewport" for each memory controller that allows DMA from
endpoint devices. Each viewport's size must be set to a power of two, and
that size must be equal to or larger than the amount of memory each
controller supports which is the sum of base region and its optional
extension. Further, the 1-3 viewports are also adjacent in PCIe-space.
Unfortunately the viewport sizes cannot be ascertained from the
"dma-ranges" property so they have their own property, "brcm,scb-sizes".
This is because dma-range information does not indicate what memory
controller it is associated. For example, consider the following case
where the size of one dma-range is 2GB and the second dma-range is 1GB:
/* Case 1: SCB0 size set to 4GB */
dma-range0: 2GB (from memc0-base)
dma-range1: 1GB (from memc0-extension)
/* Case 2: SCB0 size set to 2GB, SCB1 size set to 1GB */
dma-range0: 2GB (from memc0-base)
dma-range1: 1GB (from memc0-extension)
By just looking at the dma-ranges information, one cannot tell which
situation applies. That is why an additional property is needed. Its
length indicates the number of memory controllers being used and each value
indicates the viewport size.
Note that the RPI DT does not have a "brcm,scb-sizes" property value,
as it is assumed that it only requires one memory controller and no
extension. So the optional use of "brcm,scb-sizes" will be backwards
compatible.
One last layer of complexity exists: all of the viewports sizes must be
added and rounded up to a power of two to determine what the "BAR" size is.
Further, an offset must be given that indicates the base PCIe address of
this "BAR". The use of the term BAR is typically associated with endpoint
devices, and the term is used here because the PCIe HW may be used as an RC
or an EP. In the former case, all of the system memory appears in a single
"BAR" region in PCIe memory. As it turns out, BrcmSTB PCIe HW is rarely
used in the EP role and its system of mapping memory is an artifact that
requires multiple dma-ranges regions.
Link: https://lore.kernel.org/r/20200911175232.19016-8-james.quinlan@broadcom.com
Signed-off-by: Jim Quinlan <james.quinlan@broadcom.com>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
2020-09-11 17:52:27 +00:00
|
|
|
resource_list_for_each_entry(entry, &bridge->dma_ranges) {
|
2025-02-17 19:35:10 +00:00
|
|
|
u64 pcie_start = entry->res->start - entry->offset;
|
|
|
|
u64 cpu_start = entry->res->start;
|
2019-12-16 11:01:09 +00:00
|
|
|
|
2025-02-17 19:35:10 +00:00
|
|
|
size = resource_size(entry->res);
|
|
|
|
tot_size += size;
|
|
|
|
if (pcie_start < lowest_pcie_addr)
|
|
|
|
lowest_pcie_addr = pcie_start;
|
|
|
|
/*
|
|
|
|
* 7712 and newer chips may have many BARs, with each
|
|
|
|
* offering a non-overlapping viewport to system memory.
|
|
|
|
* That being said, each BARs size must still be a power of
|
|
|
|
* two.
|
|
|
|
*/
|
2025-02-17 19:35:32 +00:00
|
|
|
if (pcie->soc_base == BCM7712)
|
2025-02-17 19:35:10 +00:00
|
|
|
add_inbound_win(b++, &n, size, cpu_start, pcie_start);
|
|
|
|
|
|
|
|
if (n > pcie->num_inbound_wins)
|
|
|
|
break;
|
PCI: brcmstb: Set additional internal memory DMA viewport sizes
The Raspberry Pi (RPI) is currently the only chip using this driver
(pcie-brcmstb.c). There, only one memory controller is used, without an
extension region, and the SCB0 viewport size is set to the size of the
first and only dma-range region. Other BrcmSTB SOCs have more complicated
memory configurations that require setting additional viewport sizes.
BrcmSTB PCIe controllers are intimately connected to the memory
controller(s) on the SOC. The SOC may have one to three memory
controllers; they are indicated by the term SCBi. Each controller has a
base region and an optional extension region. In physical memory, the base
and extension regions of a controller are not adjacent, but in PCIe-space
they are.
There is a "viewport" for each memory controller that allows DMA from
endpoint devices. Each viewport's size must be set to a power of two, and
that size must be equal to or larger than the amount of memory each
controller supports which is the sum of base region and its optional
extension. Further, the 1-3 viewports are also adjacent in PCIe-space.
Unfortunately the viewport sizes cannot be ascertained from the
"dma-ranges" property so they have their own property, "brcm,scb-sizes".
This is because dma-range information does not indicate what memory
controller it is associated. For example, consider the following case
where the size of one dma-range is 2GB and the second dma-range is 1GB:
/* Case 1: SCB0 size set to 4GB */
dma-range0: 2GB (from memc0-base)
dma-range1: 1GB (from memc0-extension)
/* Case 2: SCB0 size set to 2GB, SCB1 size set to 1GB */
dma-range0: 2GB (from memc0-base)
dma-range1: 1GB (from memc0-extension)
By just looking at the dma-ranges information, one cannot tell which
situation applies. That is why an additional property is needed. Its
length indicates the number of memory controllers being used and each value
indicates the viewport size.
Note that the RPI DT does not have a "brcm,scb-sizes" property value,
as it is assumed that it only requires one memory controller and no
extension. So the optional use of "brcm,scb-sizes" will be backwards
compatible.
One last layer of complexity exists: all of the viewports sizes must be
added and rounded up to a power of two to determine what the "BAR" size is.
Further, an offset must be given that indicates the base PCIe address of
this "BAR". The use of the term BAR is typically associated with endpoint
devices, and the term is used here because the PCIe HW may be used as an RC
or an EP. In the former case, all of the system memory appears in a single
"BAR" region in PCIe memory. As it turns out, BrcmSTB PCIe HW is rarely
used in the EP role and its system of mapping memory is an artifact that
requires multiple dma-ranges regions.
Link: https://lore.kernel.org/r/20200911175232.19016-8-james.quinlan@broadcom.com
Signed-off-by: Jim Quinlan <james.quinlan@broadcom.com>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
2020-09-11 17:52:27 +00:00
|
|
|
}
|
2019-12-16 11:01:09 +00:00
|
|
|
|
PCI: brcmstb: Set additional internal memory DMA viewport sizes
The Raspberry Pi (RPI) is currently the only chip using this driver
(pcie-brcmstb.c). There, only one memory controller is used, without an
extension region, and the SCB0 viewport size is set to the size of the
first and only dma-range region. Other BrcmSTB SOCs have more complicated
memory configurations that require setting additional viewport sizes.
BrcmSTB PCIe controllers are intimately connected to the memory
controller(s) on the SOC. The SOC may have one to three memory
controllers; they are indicated by the term SCBi. Each controller has a
base region and an optional extension region. In physical memory, the base
and extension regions of a controller are not adjacent, but in PCIe-space
they are.
There is a "viewport" for each memory controller that allows DMA from
endpoint devices. Each viewport's size must be set to a power of two, and
that size must be equal to or larger than the amount of memory each
controller supports which is the sum of base region and its optional
extension. Further, the 1-3 viewports are also adjacent in PCIe-space.
Unfortunately the viewport sizes cannot be ascertained from the
"dma-ranges" property so they have their own property, "brcm,scb-sizes".
This is because dma-range information does not indicate what memory
controller it is associated. For example, consider the following case
where the size of one dma-range is 2GB and the second dma-range is 1GB:
/* Case 1: SCB0 size set to 4GB */
dma-range0: 2GB (from memc0-base)
dma-range1: 1GB (from memc0-extension)
/* Case 2: SCB0 size set to 2GB, SCB1 size set to 1GB */
dma-range0: 2GB (from memc0-base)
dma-range1: 1GB (from memc0-extension)
By just looking at the dma-ranges information, one cannot tell which
situation applies. That is why an additional property is needed. Its
length indicates the number of memory controllers being used and each value
indicates the viewport size.
Note that the RPI DT does not have a "brcm,scb-sizes" property value,
as it is assumed that it only requires one memory controller and no
extension. So the optional use of "brcm,scb-sizes" will be backwards
compatible.
One last layer of complexity exists: all of the viewports sizes must be
added and rounded up to a power of two to determine what the "BAR" size is.
Further, an offset must be given that indicates the base PCIe address of
this "BAR". The use of the term BAR is typically associated with endpoint
devices, and the term is used here because the PCIe HW may be used as an RC
or an EP. In the former case, all of the system memory appears in a single
"BAR" region in PCIe memory. As it turns out, BrcmSTB PCIe HW is rarely
used in the EP role and its system of mapping memory is an artifact that
requires multiple dma-ranges regions.
Link: https://lore.kernel.org/r/20200911175232.19016-8-james.quinlan@broadcom.com
Signed-off-by: Jim Quinlan <james.quinlan@broadcom.com>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
2020-09-11 17:52:27 +00:00
|
|
|
if (lowest_pcie_addr == ~(u64)0) {
|
|
|
|
dev_err(dev, "DT node has no dma-ranges\n");
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
2025-02-17 19:35:10 +00:00
|
|
|
/*
|
|
|
|
* 7712 and newer chips do not have an internal memory mapping system
|
|
|
|
* that enables multiple memory controllers. As such, it can return
|
|
|
|
* now w/o doing special configuration.
|
|
|
|
*/
|
2025-02-17 19:35:32 +00:00
|
|
|
if (pcie->soc_base == BCM7712)
|
2025-02-17 19:35:10 +00:00
|
|
|
return n;
|
|
|
|
|
PCI: brcmstb: Set additional internal memory DMA viewport sizes
The Raspberry Pi (RPI) is currently the only chip using this driver
(pcie-brcmstb.c). There, only one memory controller is used, without an
extension region, and the SCB0 viewport size is set to the size of the
first and only dma-range region. Other BrcmSTB SOCs have more complicated
memory configurations that require setting additional viewport sizes.
BrcmSTB PCIe controllers are intimately connected to the memory
controller(s) on the SOC. The SOC may have one to three memory
controllers; they are indicated by the term SCBi. Each controller has a
base region and an optional extension region. In physical memory, the base
and extension regions of a controller are not adjacent, but in PCIe-space
they are.
There is a "viewport" for each memory controller that allows DMA from
endpoint devices. Each viewport's size must be set to a power of two, and
that size must be equal to or larger than the amount of memory each
controller supports which is the sum of base region and its optional
extension. Further, the 1-3 viewports are also adjacent in PCIe-space.
Unfortunately the viewport sizes cannot be ascertained from the
"dma-ranges" property so they have their own property, "brcm,scb-sizes".
This is because dma-range information does not indicate what memory
controller it is associated. For example, consider the following case
where the size of one dma-range is 2GB and the second dma-range is 1GB:
/* Case 1: SCB0 size set to 4GB */
dma-range0: 2GB (from memc0-base)
dma-range1: 1GB (from memc0-extension)
/* Case 2: SCB0 size set to 2GB, SCB1 size set to 1GB */
dma-range0: 2GB (from memc0-base)
dma-range1: 1GB (from memc0-extension)
By just looking at the dma-ranges information, one cannot tell which
situation applies. That is why an additional property is needed. Its
length indicates the number of memory controllers being used and each value
indicates the viewport size.
Note that the RPI DT does not have a "brcm,scb-sizes" property value,
as it is assumed that it only requires one memory controller and no
extension. So the optional use of "brcm,scb-sizes" will be backwards
compatible.
One last layer of complexity exists: all of the viewports sizes must be
added and rounded up to a power of two to determine what the "BAR" size is.
Further, an offset must be given that indicates the base PCIe address of
this "BAR". The use of the term BAR is typically associated with endpoint
devices, and the term is used here because the PCIe HW may be used as an RC
or an EP. In the former case, all of the system memory appears in a single
"BAR" region in PCIe memory. As it turns out, BrcmSTB PCIe HW is rarely
used in the EP role and its system of mapping memory is an artifact that
requires multiple dma-ranges regions.
Link: https://lore.kernel.org/r/20200911175232.19016-8-james.quinlan@broadcom.com
Signed-off-by: Jim Quinlan <james.quinlan@broadcom.com>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
2020-09-11 17:52:27 +00:00
|
|
|
ret = of_property_read_variable_u64_array(pcie->np, "brcm,scb-sizes", pcie->memc_size, 1,
|
|
|
|
PCIE_BRCM_MAX_MEMC);
|
|
|
|
if (ret <= 0) {
|
|
|
|
/* Make an educated guess */
|
|
|
|
pcie->num_memc = 1;
|
2025-02-17 19:35:10 +00:00
|
|
|
pcie->memc_size[0] = 1ULL << fls64(tot_size - 1);
|
PCI: brcmstb: Set additional internal memory DMA viewport sizes
The Raspberry Pi (RPI) is currently the only chip using this driver
(pcie-brcmstb.c). There, only one memory controller is used, without an
extension region, and the SCB0 viewport size is set to the size of the
first and only dma-range region. Other BrcmSTB SOCs have more complicated
memory configurations that require setting additional viewport sizes.
BrcmSTB PCIe controllers are intimately connected to the memory
controller(s) on the SOC. The SOC may have one to three memory
controllers; they are indicated by the term SCBi. Each controller has a
base region and an optional extension region. In physical memory, the base
and extension regions of a controller are not adjacent, but in PCIe-space
they are.
There is a "viewport" for each memory controller that allows DMA from
endpoint devices. Each viewport's size must be set to a power of two, and
that size must be equal to or larger than the amount of memory each
controller supports which is the sum of base region and its optional
extension. Further, the 1-3 viewports are also adjacent in PCIe-space.
Unfortunately the viewport sizes cannot be ascertained from the
"dma-ranges" property so they have their own property, "brcm,scb-sizes".
This is because dma-range information does not indicate what memory
controller it is associated. For example, consider the following case
where the size of one dma-range is 2GB and the second dma-range is 1GB:
/* Case 1: SCB0 size set to 4GB */
dma-range0: 2GB (from memc0-base)
dma-range1: 1GB (from memc0-extension)
/* Case 2: SCB0 size set to 2GB, SCB1 size set to 1GB */
dma-range0: 2GB (from memc0-base)
dma-range1: 1GB (from memc0-extension)
By just looking at the dma-ranges information, one cannot tell which
situation applies. That is why an additional property is needed. Its
length indicates the number of memory controllers being used and each value
indicates the viewport size.
Note that the RPI DT does not have a "brcm,scb-sizes" property value,
as it is assumed that it only requires one memory controller and no
extension. So the optional use of "brcm,scb-sizes" will be backwards
compatible.
One last layer of complexity exists: all of the viewports sizes must be
added and rounded up to a power of two to determine what the "BAR" size is.
Further, an offset must be given that indicates the base PCIe address of
this "BAR". The use of the term BAR is typically associated with endpoint
devices, and the term is used here because the PCIe HW may be used as an RC
or an EP. In the former case, all of the system memory appears in a single
"BAR" region in PCIe memory. As it turns out, BrcmSTB PCIe HW is rarely
used in the EP role and its system of mapping memory is an artifact that
requires multiple dma-ranges regions.
Link: https://lore.kernel.org/r/20200911175232.19016-8-james.quinlan@broadcom.com
Signed-off-by: Jim Quinlan <james.quinlan@broadcom.com>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
2020-09-11 17:52:27 +00:00
|
|
|
} else {
|
|
|
|
pcie->num_memc = ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Each memc is viewed through a "port" that is a power of 2 */
|
|
|
|
for (i = 0, size = 0; i < pcie->num_memc; i++)
|
|
|
|
size += pcie->memc_size[i];
|
|
|
|
|
2025-02-17 19:35:10 +00:00
|
|
|
/* Our HW mandates that the window size must be a power of 2 */
|
|
|
|
size = 1ULL << fls64(size - 1);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* For STB chips, the BAR2 cpu_addr is hardwired to the start
|
|
|
|
* of system memory, so we set it to 0.
|
|
|
|
*/
|
|
|
|
cpu_addr = 0;
|
|
|
|
pci_offset = lowest_pcie_addr;
|
2019-12-16 11:01:09 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* We validate the inbound memory view even though we should trust
|
|
|
|
* whatever the device-tree provides. This is because of an HW issue on
|
|
|
|
* early Raspberry Pi 4's revisions (bcm2711). It turns out its
|
|
|
|
* firmware has to dynamically edit dma-ranges due to a bug on the
|
|
|
|
* PCIe controller integration, which prohibits any access above the
|
|
|
|
* lower 3GB of memory. Given this, we decided to keep the dma-ranges
|
|
|
|
* in check, avoiding hard to debug device-tree related issues in the
|
|
|
|
* future:
|
|
|
|
*
|
|
|
|
* The PCIe host controller by design must set the inbound viewport to
|
|
|
|
* be a contiguous arrangement of all of the system's memory. In
|
|
|
|
* addition, its size mut be a power of two. To further complicate
|
|
|
|
* matters, the viewport must start on a pcie-address that is aligned
|
|
|
|
* on a multiple of its size. If a portion of the viewport does not
|
|
|
|
* represent system memory -- e.g. 3GB of memory requires a 4GB
|
|
|
|
* viewport -- we can map the outbound memory in or after 3GB and even
|
|
|
|
* though the viewport will overlap the outbound memory the controller
|
|
|
|
* will know to send outbound memory downstream and everything else
|
|
|
|
* upstream.
|
|
|
|
*
|
|
|
|
* For example:
|
|
|
|
*
|
|
|
|
* - The best-case scenario, memory up to 3GB, is to place the inbound
|
|
|
|
* region in the first 4GB of pcie-space, as some legacy devices can
|
|
|
|
* only address 32bits. We would also like to put the MSI under 4GB
|
|
|
|
* as well, since some devices require a 32bit MSI target address.
|
|
|
|
*
|
|
|
|
* - If the system memory is 4GB or larger we cannot start the inbound
|
|
|
|
* region at location 0 (since we have to allow some space for
|
|
|
|
* outbound memory @ 3GB). So instead it will start at the 1x
|
|
|
|
* multiple of its size
|
|
|
|
*/
|
2025-02-17 19:35:10 +00:00
|
|
|
if (!size || (pci_offset & (size - 1)) ||
|
|
|
|
(pci_offset < SZ_4G && pci_offset > SZ_2G)) {
|
|
|
|
dev_err(dev, "Invalid inbound_win2_offset/size: size 0x%llx, off 0x%llx\n",
|
|
|
|
size, pci_offset);
|
2019-12-16 11:01:09 +00:00
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
2025-02-17 19:35:10 +00:00
|
|
|
/* Enable inbound window 2, the main inbound window for STB chips */
|
|
|
|
add_inbound_win(b++, &n, size, cpu_addr, pci_offset);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Disable inbound window 3. On some chips presents the same
|
|
|
|
* window as #2 but the data appears in a settable endianness.
|
|
|
|
*/
|
|
|
|
add_inbound_win(b++, &n, 0, 0, 0);
|
|
|
|
|
|
|
|
return n;
|
|
|
|
}
|
|
|
|
|
|
|
|
static u32 brcm_bar_reg_offset(int bar)
|
|
|
|
{
|
|
|
|
if (bar <= 3)
|
|
|
|
return PCIE_MISC_RC_BAR1_CONFIG_LO + 8 * (bar - 1);
|
|
|
|
else
|
|
|
|
return PCIE_MISC_RC_BAR4_CONFIG_LO + 8 * (bar - 4);
|
|
|
|
}
|
|
|
|
|
|
|
|
static u32 brcm_ubus_reg_offset(int bar)
|
|
|
|
{
|
|
|
|
if (bar <= 3)
|
|
|
|
return PCIE_MISC_UBUS_BAR1_CONFIG_REMAP + 8 * (bar - 1);
|
|
|
|
else
|
|
|
|
return PCIE_MISC_UBUS_BAR4_CONFIG_REMAP + 8 * (bar - 4);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void set_inbound_win_registers(struct brcm_pcie *pcie,
|
|
|
|
const struct inbound_win *inbound_wins,
|
|
|
|
u8 num_inbound_wins)
|
|
|
|
{
|
|
|
|
void __iomem *base = pcie->base;
|
|
|
|
int i;
|
|
|
|
|
|
|
|
for (i = 1; i <= num_inbound_wins; i++) {
|
|
|
|
u64 pci_offset = inbound_wins[i].pci_offset;
|
|
|
|
u64 cpu_addr = inbound_wins[i].cpu_addr;
|
|
|
|
u64 size = inbound_wins[i].size;
|
|
|
|
u32 reg_offset = brcm_bar_reg_offset(i);
|
|
|
|
u32 tmp = lower_32_bits(pci_offset);
|
|
|
|
|
|
|
|
u32p_replace_bits(&tmp, brcm_pcie_encode_ibar_size(size),
|
|
|
|
PCIE_MISC_RC_BAR1_CONFIG_LO_SIZE_MASK);
|
|
|
|
|
|
|
|
/* Write low */
|
|
|
|
writel_relaxed(tmp, base + reg_offset);
|
|
|
|
/* Write high */
|
|
|
|
writel_relaxed(upper_32_bits(pci_offset), base + reg_offset + 4);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Most STB chips:
|
|
|
|
* Do nothing.
|
|
|
|
* 7712:
|
|
|
|
* All of their BARs need to be set.
|
|
|
|
*/
|
2025-02-17 19:35:32 +00:00
|
|
|
if (pcie->soc_base == BCM7712) {
|
2025-02-17 19:35:10 +00:00
|
|
|
/* BUS remap register settings */
|
|
|
|
reg_offset = brcm_ubus_reg_offset(i);
|
|
|
|
tmp = lower_32_bits(cpu_addr) & ~0xfff;
|
|
|
|
tmp |= PCIE_MISC_UBUS_BAR1_CONFIG_REMAP_ACCESS_EN_MASK;
|
|
|
|
writel_relaxed(tmp, base + reg_offset);
|
|
|
|
tmp = upper_32_bits(cpu_addr);
|
|
|
|
writel_relaxed(tmp, base + reg_offset + 4);
|
|
|
|
}
|
|
|
|
}
|
2019-12-16 11:01:09 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static int brcm_pcie_setup(struct brcm_pcie *pcie)
|
|
|
|
{
|
2025-02-17 19:35:10 +00:00
|
|
|
struct inbound_win inbound_wins[PCIE_BRCM_MAX_INBOUND_WINS];
|
2019-12-16 11:01:09 +00:00
|
|
|
void __iomem *base = pcie->base;
|
2022-09-13 23:21:19 +00:00
|
|
|
struct pci_host_bridge *bridge;
|
2022-08-18 00:03:24 +00:00
|
|
|
struct resource_entry *entry;
|
2020-09-11 17:52:29 +00:00
|
|
|
u32 tmp, burst, aspm_support;
|
2025-02-17 19:35:10 +00:00
|
|
|
u8 num_out_wins = 0;
|
|
|
|
int num_inbound_wins = 0;
|
2025-02-17 19:35:19 +00:00
|
|
|
int memc, ret;
|
2019-12-16 11:01:09 +00:00
|
|
|
|
|
|
|
/* Reset the bridge */
|
2025-02-17 19:35:19 +00:00
|
|
|
ret = pcie->bridge_sw_init_set(pcie, 1);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
2023-11-02 16:02:47 +00:00
|
|
|
|
|
|
|
/* Ensure that PERST# is asserted; some bootloaders may deassert it. */
|
2025-02-17 19:35:32 +00:00
|
|
|
if (pcie->soc_base == BCM2711) {
|
2025-02-17 19:35:19 +00:00
|
|
|
ret = pcie->perst_set(pcie, 1);
|
|
|
|
if (ret) {
|
|
|
|
pcie->bridge_sw_init_set(pcie, 0);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
}
|
2023-11-02 16:02:47 +00:00
|
|
|
|
2019-12-16 11:01:09 +00:00
|
|
|
usleep_range(100, 200);
|
|
|
|
|
|
|
|
/* Take the bridge out of reset */
|
2025-02-17 19:35:19 +00:00
|
|
|
ret = pcie->bridge_sw_init_set(pcie, 0);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
2019-12-16 11:01:09 +00:00
|
|
|
|
2025-02-17 19:34:45 +00:00
|
|
|
tmp = readl(base + HARD_DEBUG(pcie));
|
2022-09-13 23:17:57 +00:00
|
|
|
if (is_bmips(pcie))
|
|
|
|
tmp &= ~PCIE_BMIPS_MISC_HARD_PCIE_HARD_DEBUG_SERDES_IDDQ_MASK;
|
|
|
|
else
|
|
|
|
tmp &= ~PCIE_MISC_HARD_PCIE_HARD_DEBUG_SERDES_IDDQ_MASK;
|
2025-02-17 19:34:45 +00:00
|
|
|
writel(tmp, base + HARD_DEBUG(pcie));
|
2019-12-16 11:01:09 +00:00
|
|
|
/* Wait for SerDes to be stable */
|
|
|
|
usleep_range(100, 200);
|
|
|
|
|
2020-09-11 17:52:29 +00:00
|
|
|
/*
|
|
|
|
* SCB_MAX_BURST_SIZE is a two bit field. For GENERIC chips it
|
|
|
|
* is encoded as 0=128, 1=256, 2=512, 3=Rsvd, for BCM7278 it
|
|
|
|
* is encoded as 0=Rsvd, 1=128, 2=256, 3=512.
|
|
|
|
*/
|
2022-09-13 23:17:57 +00:00
|
|
|
if (is_bmips(pcie))
|
|
|
|
burst = 0x1; /* 256 bytes */
|
2025-02-17 19:35:32 +00:00
|
|
|
else if (pcie->soc_base == BCM2711)
|
2022-09-13 23:17:57 +00:00
|
|
|
burst = 0x0; /* 128 bytes */
|
2025-02-17 19:35:32 +00:00
|
|
|
else if (pcie->soc_base == BCM7278)
|
2020-09-11 17:52:29 +00:00
|
|
|
burst = 0x3; /* 512 bytes */
|
|
|
|
else
|
|
|
|
burst = 0x2; /* 512 bytes */
|
|
|
|
|
2023-02-09 18:27:43 +00:00
|
|
|
/*
|
|
|
|
* Set SCB_MAX_BURST_SIZE, CFG_READ_UR_MODE, SCB_ACCESS_EN,
|
|
|
|
* RCB_MPS_MODE, RCB_64B_MODE
|
|
|
|
*/
|
2020-11-02 20:57:12 +00:00
|
|
|
tmp = readl(base + PCIE_MISC_MISC_CTRL);
|
2019-12-16 11:01:09 +00:00
|
|
|
u32p_replace_bits(&tmp, 1, PCIE_MISC_MISC_CTRL_SCB_ACCESS_EN_MASK);
|
|
|
|
u32p_replace_bits(&tmp, 1, PCIE_MISC_MISC_CTRL_CFG_READ_UR_MODE_MASK);
|
2020-09-11 17:52:29 +00:00
|
|
|
u32p_replace_bits(&tmp, burst, PCIE_MISC_MISC_CTRL_MAX_BURST_SIZE_MASK);
|
2023-02-09 18:27:43 +00:00
|
|
|
u32p_replace_bits(&tmp, 1, PCIE_MISC_MISC_CTRL_PCIE_RCB_MPS_MODE_MASK);
|
|
|
|
u32p_replace_bits(&tmp, 1, PCIE_MISC_MISC_CTRL_PCIE_RCB_64B_MODE_MASK);
|
2019-12-16 11:01:09 +00:00
|
|
|
writel(tmp, base + PCIE_MISC_MISC_CTRL);
|
|
|
|
|
2025-02-17 19:35:10 +00:00
|
|
|
num_inbound_wins = brcm_pcie_get_inbound_wins(pcie, inbound_wins);
|
|
|
|
if (num_inbound_wins < 0)
|
|
|
|
return num_inbound_wins;
|
|
|
|
|
|
|
|
set_inbound_win_registers(pcie, inbound_wins, num_inbound_wins);
|
2019-12-16 11:01:09 +00:00
|
|
|
|
2025-02-17 19:35:10 +00:00
|
|
|
if (!brcm_pcie_rc_mode(pcie)) {
|
|
|
|
dev_err(pcie->dev, "PCIe RC controller misconfigured as Endpoint\n");
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
2019-12-16 11:01:09 +00:00
|
|
|
|
|
|
|
tmp = readl(base + PCIE_MISC_MISC_CTRL);
|
PCI: brcmstb: Set additional internal memory DMA viewport sizes
The Raspberry Pi (RPI) is currently the only chip using this driver
(pcie-brcmstb.c). There, only one memory controller is used, without an
extension region, and the SCB0 viewport size is set to the size of the
first and only dma-range region. Other BrcmSTB SOCs have more complicated
memory configurations that require setting additional viewport sizes.
BrcmSTB PCIe controllers are intimately connected to the memory
controller(s) on the SOC. The SOC may have one to three memory
controllers; they are indicated by the term SCBi. Each controller has a
base region and an optional extension region. In physical memory, the base
and extension regions of a controller are not adjacent, but in PCIe-space
they are.
There is a "viewport" for each memory controller that allows DMA from
endpoint devices. Each viewport's size must be set to a power of two, and
that size must be equal to or larger than the amount of memory each
controller supports which is the sum of base region and its optional
extension. Further, the 1-3 viewports are also adjacent in PCIe-space.
Unfortunately the viewport sizes cannot be ascertained from the
"dma-ranges" property so they have their own property, "brcm,scb-sizes".
This is because dma-range information does not indicate what memory
controller it is associated. For example, consider the following case
where the size of one dma-range is 2GB and the second dma-range is 1GB:
/* Case 1: SCB0 size set to 4GB */
dma-range0: 2GB (from memc0-base)
dma-range1: 1GB (from memc0-extension)
/* Case 2: SCB0 size set to 2GB, SCB1 size set to 1GB */
dma-range0: 2GB (from memc0-base)
dma-range1: 1GB (from memc0-extension)
By just looking at the dma-ranges information, one cannot tell which
situation applies. That is why an additional property is needed. Its
length indicates the number of memory controllers being used and each value
indicates the viewport size.
Note that the RPI DT does not have a "brcm,scb-sizes" property value,
as it is assumed that it only requires one memory controller and no
extension. So the optional use of "brcm,scb-sizes" will be backwards
compatible.
One last layer of complexity exists: all of the viewports sizes must be
added and rounded up to a power of two to determine what the "BAR" size is.
Further, an offset must be given that indicates the base PCIe address of
this "BAR". The use of the term BAR is typically associated with endpoint
devices, and the term is used here because the PCIe HW may be used as an RC
or an EP. In the former case, all of the system memory appears in a single
"BAR" region in PCIe memory. As it turns out, BrcmSTB PCIe HW is rarely
used in the EP role and its system of mapping memory is an artifact that
requires multiple dma-ranges regions.
Link: https://lore.kernel.org/r/20200911175232.19016-8-james.quinlan@broadcom.com
Signed-off-by: Jim Quinlan <james.quinlan@broadcom.com>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
2020-09-11 17:52:27 +00:00
|
|
|
for (memc = 0; memc < pcie->num_memc; memc++) {
|
|
|
|
u32 scb_size_val = ilog2(pcie->memc_size[memc]) - 15;
|
|
|
|
|
|
|
|
if (memc == 0)
|
|
|
|
u32p_replace_bits(&tmp, scb_size_val, SCB_SIZE_MASK(0));
|
|
|
|
else if (memc == 1)
|
|
|
|
u32p_replace_bits(&tmp, scb_size_val, SCB_SIZE_MASK(1));
|
|
|
|
else if (memc == 2)
|
|
|
|
u32p_replace_bits(&tmp, scb_size_val, SCB_SIZE_MASK(2));
|
|
|
|
}
|
2019-12-16 11:01:09 +00:00
|
|
|
writel(tmp, base + PCIE_MISC_MISC_CTRL);
|
|
|
|
|
2019-12-16 11:01:10 +00:00
|
|
|
/*
|
|
|
|
* We ideally want the MSI target address to be located in the 32bit
|
|
|
|
* addressable memory area. Some devices might depend on it. This is
|
|
|
|
* possible either when the inbound window is located above the lower
|
|
|
|
* 4GB or when the inbound area is smaller than 4GB (taking into
|
|
|
|
* account the rounding-up we're forced to perform).
|
|
|
|
*/
|
2025-02-17 19:35:10 +00:00
|
|
|
if (inbound_wins[2].pci_offset >= SZ_4G ||
|
|
|
|
(inbound_wins[2].size + inbound_wins[2].pci_offset) < SZ_4G)
|
2019-12-16 11:01:10 +00:00
|
|
|
pcie->msi_target_addr = BRCM_MSI_TARGET_ADDR_LT_4GB;
|
|
|
|
else
|
|
|
|
pcie->msi_target_addr = BRCM_MSI_TARGET_ADDR_GT_4GB;
|
|
|
|
|
2019-12-16 11:01:09 +00:00
|
|
|
|
2022-09-13 23:21:19 +00:00
|
|
|
/* Don't advertise L0s capability if 'aspm-no-l0s' */
|
|
|
|
aspm_support = PCIE_LINK_STATE_L1;
|
|
|
|
if (!of_property_read_bool(pcie->np, "aspm-no-l0s"))
|
|
|
|
aspm_support |= PCIE_LINK_STATE_L0S;
|
|
|
|
tmp = readl(base + PCIE_RC_CFG_PRIV1_LINK_CAPABILITY);
|
|
|
|
u32p_replace_bits(&tmp, aspm_support,
|
|
|
|
PCIE_RC_CFG_PRIV1_LINK_CAPABILITY_ASPM_SUPPORT_MASK);
|
|
|
|
writel(tmp, base + PCIE_RC_CFG_PRIV1_LINK_CAPABILITY);
|
2019-12-16 11:01:09 +00:00
|
|
|
|
|
|
|
/*
|
2022-09-13 23:21:19 +00:00
|
|
|
* For config space accesses on the RC, show the right class for
|
|
|
|
* a PCIe-PCIe bridge (the default setting is to be EP mode).
|
2019-12-16 11:01:09 +00:00
|
|
|
*/
|
2022-09-13 23:21:19 +00:00
|
|
|
tmp = readl(base + PCIE_RC_CFG_PRIV1_ID_VAL3);
|
|
|
|
u32p_replace_bits(&tmp, 0x060400,
|
|
|
|
PCIE_RC_CFG_PRIV1_ID_VAL3_CLASS_CODE_MASK);
|
|
|
|
writel(tmp, base + PCIE_RC_CFG_PRIV1_ID_VAL3);
|
2019-12-16 11:01:09 +00:00
|
|
|
|
2022-09-13 23:21:19 +00:00
|
|
|
bridge = pci_host_bridge_from_priv(pcie);
|
2019-12-16 11:01:09 +00:00
|
|
|
resource_list_for_each_entry(entry, &bridge->windows) {
|
2022-09-13 23:21:19 +00:00
|
|
|
struct resource *res = entry->res;
|
2019-12-16 11:01:09 +00:00
|
|
|
|
|
|
|
if (resource_type(res) != IORESOURCE_MEM)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
if (num_out_wins >= BRCM_NUM_PCIE_OUT_WINS) {
|
|
|
|
dev_err(pcie->dev, "too many outbound wins\n");
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
2022-09-13 23:17:57 +00:00
|
|
|
if (is_bmips(pcie)) {
|
|
|
|
u64 start = res->start;
|
|
|
|
unsigned int j, nwins = resource_size(res) / SZ_128M;
|
|
|
|
|
|
|
|
/* bmips PCIe outbound windows have a 128MB max size */
|
|
|
|
if (nwins > BRCM_NUM_PCIE_OUT_WINS)
|
|
|
|
nwins = BRCM_NUM_PCIE_OUT_WINS;
|
|
|
|
for (j = 0; j < nwins; j++, start += SZ_128M)
|
|
|
|
brcm_pcie_set_outbound_win(pcie, j, start,
|
|
|
|
start - entry->offset,
|
|
|
|
SZ_128M);
|
|
|
|
break;
|
|
|
|
}
|
2019-12-16 11:01:09 +00:00
|
|
|
brcm_pcie_set_outbound_win(pcie, num_out_wins, res->start,
|
|
|
|
res->start - entry->offset,
|
|
|
|
resource_size(res));
|
|
|
|
num_out_wins++;
|
|
|
|
}
|
|
|
|
|
2025-02-17 19:35:10 +00:00
|
|
|
/* PCIe->SCB endian mode for inbound window */
|
2022-09-13 23:21:19 +00:00
|
|
|
tmp = readl(base + PCIE_RC_CFG_VENDOR_VENDOR_SPECIFIC_REG1);
|
|
|
|
u32p_replace_bits(&tmp, PCIE_RC_CFG_VENDOR_SPCIFIC_REG1_LITTLE_ENDIAN,
|
|
|
|
PCIE_RC_CFG_VENDOR_VENDOR_SPECIFIC_REG1_ENDIAN_MODE_BAR2_MASK);
|
|
|
|
writel(tmp, base + PCIE_RC_CFG_VENDOR_VENDOR_SPECIFIC_REG1);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
PCI: brcmstb: Configure HW CLKREQ# mode appropriate for downstream device
JIRA: https://issues.redhat.com/browse/RHEL-28627
Upstream Status: e2596dcf1e9dfd5904d50f796c19b03c94a3b8b4
commit e2596dcf1e9dfd5904d50f796c19b03c94a3b8b4
Author: Jim Quinlan <james.quinlan@broadcom.com>
Date: Mon Nov 13 13:56:06 2023 -0500
PCI: brcmstb: Configure HW CLKREQ# mode appropriate for downstream device
The Broadcom STB/CM PCIe HW core, which is also used in RPi SOCs, must be
deliberately set by the PCIe RC HW into one of three mutually exclusive
modes:
"safe" -- No CLKREQ# expected or required, refclk is always provided. This
mode should work for all devices but is not be capable of any refclk
power savings.
"no-l1ss" -- CLKREQ# is expected to be driven by the downstream device for
CPM and ASPM L0s and L1. Provides Clock Power Management, L0s, and L1,
but cannot provide L1 substate (L1SS) power savings. If the downstream
device connected to the RC is L1SS capable AND the OS enables L1SS, all
PCIe traffic may abruptly halt, potentially hanging the system.
"default" -- Bidirectional CLKREQ# between the RC and downstream device.
Provides ASPM L0s, L1, and L1SS, but not compliant to provide Clock
Power Management; specifically, may not be able to meet the T_CLRon max
timing of 400ns as specified in "Dynamic Clock Control", section
3.2.5.2.2 of the PCIe Express Mini CEM 2.1 specification. This
situation is atypical and should happen only with older devices.
Previously, this driver always set the mode to "no-l1ss", as almost all
STB/CM boards operate in this mode. But now there is interest in
activating L1SS power savings from STB/CM customers, which requires "aspm"
mode. In addition, a bug was filed for RPi4 CM platform because most
devices did not work in "no-l1ss" mode.
Note that the mode is specified by the DT property "brcm,clkreq-mode". If
this property is omitted, then "default" mode is chosen.
Note: Since L1 substates are now possible, a modification was made
regarding an internal bus timeout: During long periods of the PCIe RC HW
being in an L1SS sleep state, there may be a timeout on an internal bus
access, even though there may not be any PCIe access involved. Such a
timeout will cause a subsequent CPU abort.
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=217276
Link: https://lore.kernel.org/linux-pci/20231113185607.1756-3-james.quinlan@broadcom.com
Tested-by: Cyril Brulebois <cyril@debamax.com>
Tested-by: Florian Fainelli <florian.fainelli@broadcom.com>
Signed-off-by: Jim Quinlan <james.quinlan@broadcom.com>
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Signed-off-by: Myron Stowe <mstowe@redhat.com>
2024-03-14 15:53:58 +00:00
|
|
|
/*
|
|
|
|
* This extends the timeout period for an access to an internal bus. This
|
|
|
|
* access timeout may occur during L1SS sleep periods, even without the
|
|
|
|
* presence of a PCIe access.
|
|
|
|
*/
|
|
|
|
static void brcm_extend_rbus_timeout(struct brcm_pcie *pcie)
|
|
|
|
{
|
|
|
|
/* TIMEOUT register is two registers before RGR1_SW_INIT_1 */
|
|
|
|
const unsigned int REG_OFFSET = PCIE_RGR1_SW_INIT_1(pcie) - 8;
|
|
|
|
u32 timeout_us = 4000000; /* 4 seconds, our setting for L1SS */
|
|
|
|
|
2025-02-17 19:35:41 +00:00
|
|
|
/* 7712 does not have this (RGR1) timer */
|
|
|
|
if (pcie->soc_base == BCM7712)
|
|
|
|
return;
|
|
|
|
|
PCI: brcmstb: Configure HW CLKREQ# mode appropriate for downstream device
JIRA: https://issues.redhat.com/browse/RHEL-28627
Upstream Status: e2596dcf1e9dfd5904d50f796c19b03c94a3b8b4
commit e2596dcf1e9dfd5904d50f796c19b03c94a3b8b4
Author: Jim Quinlan <james.quinlan@broadcom.com>
Date: Mon Nov 13 13:56:06 2023 -0500
PCI: brcmstb: Configure HW CLKREQ# mode appropriate for downstream device
The Broadcom STB/CM PCIe HW core, which is also used in RPi SOCs, must be
deliberately set by the PCIe RC HW into one of three mutually exclusive
modes:
"safe" -- No CLKREQ# expected or required, refclk is always provided. This
mode should work for all devices but is not be capable of any refclk
power savings.
"no-l1ss" -- CLKREQ# is expected to be driven by the downstream device for
CPM and ASPM L0s and L1. Provides Clock Power Management, L0s, and L1,
but cannot provide L1 substate (L1SS) power savings. If the downstream
device connected to the RC is L1SS capable AND the OS enables L1SS, all
PCIe traffic may abruptly halt, potentially hanging the system.
"default" -- Bidirectional CLKREQ# between the RC and downstream device.
Provides ASPM L0s, L1, and L1SS, but not compliant to provide Clock
Power Management; specifically, may not be able to meet the T_CLRon max
timing of 400ns as specified in "Dynamic Clock Control", section
3.2.5.2.2 of the PCIe Express Mini CEM 2.1 specification. This
situation is atypical and should happen only with older devices.
Previously, this driver always set the mode to "no-l1ss", as almost all
STB/CM boards operate in this mode. But now there is interest in
activating L1SS power savings from STB/CM customers, which requires "aspm"
mode. In addition, a bug was filed for RPi4 CM platform because most
devices did not work in "no-l1ss" mode.
Note that the mode is specified by the DT property "brcm,clkreq-mode". If
this property is omitted, then "default" mode is chosen.
Note: Since L1 substates are now possible, a modification was made
regarding an internal bus timeout: During long periods of the PCIe RC HW
being in an L1SS sleep state, there may be a timeout on an internal bus
access, even though there may not be any PCIe access involved. Such a
timeout will cause a subsequent CPU abort.
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=217276
Link: https://lore.kernel.org/linux-pci/20231113185607.1756-3-james.quinlan@broadcom.com
Tested-by: Cyril Brulebois <cyril@debamax.com>
Tested-by: Florian Fainelli <florian.fainelli@broadcom.com>
Signed-off-by: Jim Quinlan <james.quinlan@broadcom.com>
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Signed-off-by: Myron Stowe <mstowe@redhat.com>
2024-03-14 15:53:58 +00:00
|
|
|
/* Each unit in timeout register is 1/216,000,000 seconds */
|
|
|
|
writel(216 * timeout_us, pcie->base + REG_OFFSET);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void brcm_config_clkreq(struct brcm_pcie *pcie)
|
|
|
|
{
|
|
|
|
static const char err_msg[] = "invalid 'brcm,clkreq-mode' DT string\n";
|
|
|
|
const char *mode = "default";
|
|
|
|
u32 clkreq_cntl;
|
|
|
|
int ret, tmp;
|
|
|
|
|
|
|
|
ret = of_property_read_string(pcie->np, "brcm,clkreq-mode", &mode);
|
|
|
|
if (ret && ret != -EINVAL) {
|
|
|
|
dev_err(pcie->dev, err_msg);
|
|
|
|
mode = "safe";
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Start out assuming safe mode (both mode bits cleared) */
|
2025-02-17 19:34:45 +00:00
|
|
|
clkreq_cntl = readl(pcie->base + HARD_DEBUG(pcie));
|
PCI: brcmstb: Configure HW CLKREQ# mode appropriate for downstream device
JIRA: https://issues.redhat.com/browse/RHEL-28627
Upstream Status: e2596dcf1e9dfd5904d50f796c19b03c94a3b8b4
commit e2596dcf1e9dfd5904d50f796c19b03c94a3b8b4
Author: Jim Quinlan <james.quinlan@broadcom.com>
Date: Mon Nov 13 13:56:06 2023 -0500
PCI: brcmstb: Configure HW CLKREQ# mode appropriate for downstream device
The Broadcom STB/CM PCIe HW core, which is also used in RPi SOCs, must be
deliberately set by the PCIe RC HW into one of three mutually exclusive
modes:
"safe" -- No CLKREQ# expected or required, refclk is always provided. This
mode should work for all devices but is not be capable of any refclk
power savings.
"no-l1ss" -- CLKREQ# is expected to be driven by the downstream device for
CPM and ASPM L0s and L1. Provides Clock Power Management, L0s, and L1,
but cannot provide L1 substate (L1SS) power savings. If the downstream
device connected to the RC is L1SS capable AND the OS enables L1SS, all
PCIe traffic may abruptly halt, potentially hanging the system.
"default" -- Bidirectional CLKREQ# between the RC and downstream device.
Provides ASPM L0s, L1, and L1SS, but not compliant to provide Clock
Power Management; specifically, may not be able to meet the T_CLRon max
timing of 400ns as specified in "Dynamic Clock Control", section
3.2.5.2.2 of the PCIe Express Mini CEM 2.1 specification. This
situation is atypical and should happen only with older devices.
Previously, this driver always set the mode to "no-l1ss", as almost all
STB/CM boards operate in this mode. But now there is interest in
activating L1SS power savings from STB/CM customers, which requires "aspm"
mode. In addition, a bug was filed for RPi4 CM platform because most
devices did not work in "no-l1ss" mode.
Note that the mode is specified by the DT property "brcm,clkreq-mode". If
this property is omitted, then "default" mode is chosen.
Note: Since L1 substates are now possible, a modification was made
regarding an internal bus timeout: During long periods of the PCIe RC HW
being in an L1SS sleep state, there may be a timeout on an internal bus
access, even though there may not be any PCIe access involved. Such a
timeout will cause a subsequent CPU abort.
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=217276
Link: https://lore.kernel.org/linux-pci/20231113185607.1756-3-james.quinlan@broadcom.com
Tested-by: Cyril Brulebois <cyril@debamax.com>
Tested-by: Florian Fainelli <florian.fainelli@broadcom.com>
Signed-off-by: Jim Quinlan <james.quinlan@broadcom.com>
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Signed-off-by: Myron Stowe <mstowe@redhat.com>
2024-03-14 15:53:58 +00:00
|
|
|
clkreq_cntl &= ~PCIE_CLKREQ_MASK;
|
|
|
|
|
|
|
|
if (strcmp(mode, "no-l1ss") == 0) {
|
|
|
|
/*
|
|
|
|
* "no-l1ss" -- Provides Clock Power Management, L0s, and
|
|
|
|
* L1, but cannot provide L1 substate (L1SS) power
|
|
|
|
* savings. If the downstream device connected to the RC is
|
|
|
|
* L1SS capable AND the OS enables L1SS, all PCIe traffic
|
|
|
|
* may abruptly halt, potentially hanging the system.
|
|
|
|
*/
|
|
|
|
clkreq_cntl |= PCIE_MISC_HARD_PCIE_HARD_DEBUG_CLKREQ_DEBUG_ENABLE_MASK;
|
|
|
|
/*
|
|
|
|
* We want to un-advertise L1 substates because if the OS
|
|
|
|
* tries to configure the controller into using L1 substate
|
|
|
|
* power savings it may fail or hang when the RC HW is in
|
|
|
|
* "no-l1ss" mode.
|
|
|
|
*/
|
|
|
|
tmp = readl(pcie->base + PCIE_RC_CFG_PRIV1_ROOT_CAP);
|
|
|
|
u32p_replace_bits(&tmp, 2, PCIE_RC_CFG_PRIV1_ROOT_CAP_L1SS_MODE_MASK);
|
|
|
|
writel(tmp, pcie->base + PCIE_RC_CFG_PRIV1_ROOT_CAP);
|
|
|
|
|
|
|
|
} else if (strcmp(mode, "default") == 0) {
|
|
|
|
/*
|
|
|
|
* "default" -- Provides L0s, L1, and L1SS, but not
|
|
|
|
* compliant to provide Clock Power Management;
|
|
|
|
* specifically, may not be able to meet the Tclron max
|
|
|
|
* timing of 400ns as specified in "Dynamic Clock Control",
|
|
|
|
* section 3.2.5.2.2 of the PCIe spec. This situation is
|
|
|
|
* atypical and should happen only with older devices.
|
|
|
|
*/
|
|
|
|
clkreq_cntl |= PCIE_MISC_HARD_PCIE_HARD_DEBUG_L1SS_ENABLE_MASK;
|
|
|
|
brcm_extend_rbus_timeout(pcie);
|
|
|
|
|
|
|
|
} else {
|
|
|
|
/*
|
|
|
|
* "safe" -- No power savings; refclk is driven by RC
|
|
|
|
* unconditionally.
|
|
|
|
*/
|
|
|
|
if (strcmp(mode, "safe") != 0)
|
|
|
|
dev_err(pcie->dev, err_msg);
|
|
|
|
mode = "safe";
|
|
|
|
}
|
2025-02-17 19:34:45 +00:00
|
|
|
writel(clkreq_cntl, pcie->base + HARD_DEBUG(pcie));
|
PCI: brcmstb: Configure HW CLKREQ# mode appropriate for downstream device
JIRA: https://issues.redhat.com/browse/RHEL-28627
Upstream Status: e2596dcf1e9dfd5904d50f796c19b03c94a3b8b4
commit e2596dcf1e9dfd5904d50f796c19b03c94a3b8b4
Author: Jim Quinlan <james.quinlan@broadcom.com>
Date: Mon Nov 13 13:56:06 2023 -0500
PCI: brcmstb: Configure HW CLKREQ# mode appropriate for downstream device
The Broadcom STB/CM PCIe HW core, which is also used in RPi SOCs, must be
deliberately set by the PCIe RC HW into one of three mutually exclusive
modes:
"safe" -- No CLKREQ# expected or required, refclk is always provided. This
mode should work for all devices but is not be capable of any refclk
power savings.
"no-l1ss" -- CLKREQ# is expected to be driven by the downstream device for
CPM and ASPM L0s and L1. Provides Clock Power Management, L0s, and L1,
but cannot provide L1 substate (L1SS) power savings. If the downstream
device connected to the RC is L1SS capable AND the OS enables L1SS, all
PCIe traffic may abruptly halt, potentially hanging the system.
"default" -- Bidirectional CLKREQ# between the RC and downstream device.
Provides ASPM L0s, L1, and L1SS, but not compliant to provide Clock
Power Management; specifically, may not be able to meet the T_CLRon max
timing of 400ns as specified in "Dynamic Clock Control", section
3.2.5.2.2 of the PCIe Express Mini CEM 2.1 specification. This
situation is atypical and should happen only with older devices.
Previously, this driver always set the mode to "no-l1ss", as almost all
STB/CM boards operate in this mode. But now there is interest in
activating L1SS power savings from STB/CM customers, which requires "aspm"
mode. In addition, a bug was filed for RPi4 CM platform because most
devices did not work in "no-l1ss" mode.
Note that the mode is specified by the DT property "brcm,clkreq-mode". If
this property is omitted, then "default" mode is chosen.
Note: Since L1 substates are now possible, a modification was made
regarding an internal bus timeout: During long periods of the PCIe RC HW
being in an L1SS sleep state, there may be a timeout on an internal bus
access, even though there may not be any PCIe access involved. Such a
timeout will cause a subsequent CPU abort.
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=217276
Link: https://lore.kernel.org/linux-pci/20231113185607.1756-3-james.quinlan@broadcom.com
Tested-by: Cyril Brulebois <cyril@debamax.com>
Tested-by: Florian Fainelli <florian.fainelli@broadcom.com>
Signed-off-by: Jim Quinlan <james.quinlan@broadcom.com>
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Signed-off-by: Myron Stowe <mstowe@redhat.com>
2024-03-14 15:53:58 +00:00
|
|
|
|
|
|
|
dev_info(pcie->dev, "clkreq-mode set to %s\n", mode);
|
|
|
|
}
|
|
|
|
|
2022-09-13 23:21:19 +00:00
|
|
|
static int brcm_pcie_start_link(struct brcm_pcie *pcie)
|
|
|
|
{
|
|
|
|
struct device *dev = pcie->dev;
|
|
|
|
void __iomem *base = pcie->base;
|
|
|
|
u16 nlw, cls, lnksta;
|
|
|
|
bool ssc_good = false;
|
|
|
|
int ret, i;
|
|
|
|
|
|
|
|
/* Unassert the fundamental reset */
|
2025-02-17 19:35:19 +00:00
|
|
|
ret = pcie->perst_set(pcie, 0);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
2022-08-18 00:03:24 +00:00
|
|
|
|
|
|
|
/*
|
2023-02-09 18:23:20 +00:00
|
|
|
* Wait for 100ms after PERST# deassertion; see PCIe CEM specification
|
|
|
|
* sections 2.2, PCIe r5.0, 6.6.1.
|
|
|
|
*/
|
|
|
|
msleep(100);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Give the RC/EP even more time to wake up, before trying to
|
|
|
|
* configure RC. Intermittently check status for link-up, up to a
|
|
|
|
* total of 100ms.
|
2022-08-18 00:03:24 +00:00
|
|
|
*/
|
2022-09-13 23:21:19 +00:00
|
|
|
for (i = 0; i < 100 && !brcm_pcie_link_up(pcie); i += 5)
|
|
|
|
msleep(5);
|
|
|
|
|
|
|
|
if (!brcm_pcie_link_up(pcie)) {
|
|
|
|
dev_err(dev, "link down\n");
|
|
|
|
return -ENODEV;
|
|
|
|
}
|
|
|
|
|
PCI: brcmstb: Configure HW CLKREQ# mode appropriate for downstream device
JIRA: https://issues.redhat.com/browse/RHEL-28627
Upstream Status: e2596dcf1e9dfd5904d50f796c19b03c94a3b8b4
commit e2596dcf1e9dfd5904d50f796c19b03c94a3b8b4
Author: Jim Quinlan <james.quinlan@broadcom.com>
Date: Mon Nov 13 13:56:06 2023 -0500
PCI: brcmstb: Configure HW CLKREQ# mode appropriate for downstream device
The Broadcom STB/CM PCIe HW core, which is also used in RPi SOCs, must be
deliberately set by the PCIe RC HW into one of three mutually exclusive
modes:
"safe" -- No CLKREQ# expected or required, refclk is always provided. This
mode should work for all devices but is not be capable of any refclk
power savings.
"no-l1ss" -- CLKREQ# is expected to be driven by the downstream device for
CPM and ASPM L0s and L1. Provides Clock Power Management, L0s, and L1,
but cannot provide L1 substate (L1SS) power savings. If the downstream
device connected to the RC is L1SS capable AND the OS enables L1SS, all
PCIe traffic may abruptly halt, potentially hanging the system.
"default" -- Bidirectional CLKREQ# between the RC and downstream device.
Provides ASPM L0s, L1, and L1SS, but not compliant to provide Clock
Power Management; specifically, may not be able to meet the T_CLRon max
timing of 400ns as specified in "Dynamic Clock Control", section
3.2.5.2.2 of the PCIe Express Mini CEM 2.1 specification. This
situation is atypical and should happen only with older devices.
Previously, this driver always set the mode to "no-l1ss", as almost all
STB/CM boards operate in this mode. But now there is interest in
activating L1SS power savings from STB/CM customers, which requires "aspm"
mode. In addition, a bug was filed for RPi4 CM platform because most
devices did not work in "no-l1ss" mode.
Note that the mode is specified by the DT property "brcm,clkreq-mode". If
this property is omitted, then "default" mode is chosen.
Note: Since L1 substates are now possible, a modification was made
regarding an internal bus timeout: During long periods of the PCIe RC HW
being in an L1SS sleep state, there may be a timeout on an internal bus
access, even though there may not be any PCIe access involved. Such a
timeout will cause a subsequent CPU abort.
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=217276
Link: https://lore.kernel.org/linux-pci/20231113185607.1756-3-james.quinlan@broadcom.com
Tested-by: Cyril Brulebois <cyril@debamax.com>
Tested-by: Florian Fainelli <florian.fainelli@broadcom.com>
Signed-off-by: Jim Quinlan <james.quinlan@broadcom.com>
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Signed-off-by: Myron Stowe <mstowe@redhat.com>
2024-03-14 15:53:58 +00:00
|
|
|
brcm_config_clkreq(pcie);
|
|
|
|
|
2022-09-13 23:21:19 +00:00
|
|
|
if (pcie->gen)
|
|
|
|
brcm_pcie_set_gen(pcie, pcie->gen);
|
2022-08-18 00:03:24 +00:00
|
|
|
|
2019-12-16 11:01:09 +00:00
|
|
|
if (pcie->ssc) {
|
|
|
|
ret = brcm_pcie_set_ssc(pcie);
|
|
|
|
if (ret == 0)
|
|
|
|
ssc_good = true;
|
|
|
|
else
|
|
|
|
dev_err(dev, "failed attempt to enter ssc mode\n");
|
|
|
|
}
|
|
|
|
|
|
|
|
lnksta = readw(base + BRCM_PCIE_CAP_REGS + PCI_EXP_LNKSTA);
|
|
|
|
cls = FIELD_GET(PCI_EXP_LNKSTA_CLS, lnksta);
|
|
|
|
nlw = FIELD_GET(PCI_EXP_LNKSTA_NLW, lnksta);
|
|
|
|
dev_info(dev, "link up, %s x%u %s\n",
|
2020-02-28 21:24:52 +00:00
|
|
|
pci_speed_string(pcie_link_speed[cls]), nlw,
|
|
|
|
ssc_good ? "(SSC)" : "(!SSC)");
|
2019-12-16 11:01:09 +00:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
PCI: brcmstb: Enable child bus device regulators from DT
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2124638
Upstream Status: 9e6be018b26347c26a93e63fb50a37ee2c9311de
commit 9e6be018b26347c26a93e63fb50a37ee2c9311de
Author: Jim Quinlan <jim2101024@gmail.com>
Date: Mon Jul 25 11:12:53 2022 -0400
PCI: brcmstb: Enable child bus device regulators from DT
Some platforms have power regulators for slots or devices below Root Ports.
On platforms like Raspberry Pi 4, these regulators are described in the
Root Port device tree node, since they logically belong to the Root Port,
not to the host bridge itself.
Add an .add_bus() hook (called when pci_alloc_child_bus() allocates the
secondary ("child") bus for a bridge), and look for such regulators. If we
find some, enable them before bringing up the link and enumerating devices
on the child bus.
Similarly, when pci_remove_bus() calls the ops->remove_bus() hook, disable
the regulators.
The regulators that may be described in a Root Port DT device are:
vpcie3v3
vpcie3v3aux
vpcie12v
These control power to the device downstream from the Root Port.
[bhelgaas: commit log, name hooks brcm_pcie_add_bus(), etc, since we only
support one set of subregulator info, save info in struct brcm_pcie instead
of dev->driver_data, move brcm_pcie_start_link() from probe to .add_bus()
(from subsequent patch)]
Link: https://lore.kernel.org/r/20220725151258.42574-5-jim2101024@gmail.com
Signed-off-by: Jim Quinlan <jim2101024@gmail.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Tested-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Myron Stowe <mstowe@redhat.com>
2022-09-13 23:22:17 +00:00
|
|
|
static const char * const supplies[] = {
|
|
|
|
"vpcie3v3",
|
|
|
|
"vpcie3v3aux",
|
|
|
|
"vpcie12v",
|
|
|
|
};
|
|
|
|
|
|
|
|
static void *alloc_subdev_regulators(struct device *dev)
|
|
|
|
{
|
|
|
|
const size_t size = sizeof(struct subdev_regulators) +
|
|
|
|
sizeof(struct regulator_bulk_data) * ARRAY_SIZE(supplies);
|
|
|
|
struct subdev_regulators *sr;
|
|
|
|
int i;
|
|
|
|
|
|
|
|
sr = devm_kzalloc(dev, size, GFP_KERNEL);
|
|
|
|
if (sr) {
|
|
|
|
sr->num_supplies = ARRAY_SIZE(supplies);
|
|
|
|
for (i = 0; i < ARRAY_SIZE(supplies); i++)
|
|
|
|
sr->supplies[i].supply = supplies[i];
|
|
|
|
}
|
|
|
|
|
|
|
|
return sr;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int brcm_pcie_add_bus(struct pci_bus *bus)
|
|
|
|
{
|
|
|
|
struct brcm_pcie *pcie = bus->sysdata;
|
|
|
|
struct device *dev = &bus->dev;
|
|
|
|
struct subdev_regulators *sr;
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
if (!bus->parent || !pci_is_root_bus(bus->parent))
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
if (dev->of_node) {
|
|
|
|
sr = alloc_subdev_regulators(dev);
|
|
|
|
if (!sr) {
|
|
|
|
dev_info(dev, "Can't allocate regulators for downstream device\n");
|
|
|
|
goto no_regulators;
|
|
|
|
}
|
|
|
|
|
|
|
|
pcie->sr = sr;
|
|
|
|
|
|
|
|
ret = regulator_bulk_get(dev, sr->num_supplies, sr->supplies);
|
|
|
|
if (ret) {
|
|
|
|
dev_info(dev, "No regulators for downstream device\n");
|
|
|
|
goto no_regulators;
|
|
|
|
}
|
|
|
|
|
|
|
|
ret = regulator_bulk_enable(sr->num_supplies, sr->supplies);
|
|
|
|
if (ret) {
|
|
|
|
dev_err(dev, "Can't enable regulators for downstream device\n");
|
|
|
|
regulator_bulk_free(sr->num_supplies, sr->supplies);
|
|
|
|
pcie->sr = NULL;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
no_regulators:
|
|
|
|
brcm_pcie_start_link(pcie);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void brcm_pcie_remove_bus(struct pci_bus *bus)
|
|
|
|
{
|
|
|
|
struct brcm_pcie *pcie = bus->sysdata;
|
|
|
|
struct subdev_regulators *sr = pcie->sr;
|
|
|
|
struct device *dev = &bus->dev;
|
|
|
|
|
|
|
|
if (!sr)
|
|
|
|
return;
|
|
|
|
|
|
|
|
if (regulator_bulk_disable(sr->num_supplies, sr->supplies))
|
|
|
|
dev_err(dev, "Failed to disable regulators for downstream device\n");
|
|
|
|
regulator_bulk_free(sr->num_supplies, sr->supplies);
|
|
|
|
pcie->sr = NULL;
|
|
|
|
}
|
|
|
|
|
2019-12-16 11:01:09 +00:00
|
|
|
/* L23 is a low-power PCIe link state */
|
|
|
|
static void brcm_pcie_enter_l23(struct brcm_pcie *pcie)
|
|
|
|
{
|
|
|
|
void __iomem *base = pcie->base;
|
|
|
|
int l23, i;
|
|
|
|
u32 tmp;
|
|
|
|
|
|
|
|
/* Assert request for L23 */
|
|
|
|
tmp = readl(base + PCIE_MISC_PCIE_CTRL);
|
|
|
|
u32p_replace_bits(&tmp, 1, PCIE_MISC_PCIE_CTRL_PCIE_L23_REQUEST_MASK);
|
|
|
|
writel(tmp, base + PCIE_MISC_PCIE_CTRL);
|
|
|
|
|
|
|
|
/* Wait up to 36 msec for L23 */
|
|
|
|
tmp = readl(base + PCIE_MISC_PCIE_STATUS);
|
|
|
|
l23 = FIELD_GET(PCIE_MISC_PCIE_STATUS_PCIE_LINK_IN_L23_MASK, tmp);
|
|
|
|
for (i = 0; i < 15 && !l23; i++) {
|
|
|
|
usleep_range(2000, 2400);
|
|
|
|
tmp = readl(base + PCIE_MISC_PCIE_STATUS);
|
|
|
|
l23 = FIELD_GET(PCIE_MISC_PCIE_STATUS_PCIE_LINK_IN_L23_MASK,
|
|
|
|
tmp);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!l23)
|
|
|
|
dev_err(pcie->dev, "failed to enter low-power link state\n");
|
|
|
|
}
|
|
|
|
|
2020-09-11 17:52:26 +00:00
|
|
|
static int brcm_phy_cntl(struct brcm_pcie *pcie, const int start)
|
|
|
|
{
|
|
|
|
static const u32 shifts[PCIE_DVT_PMU_PCIE_PHY_CTRL_DAST_NFLDS] = {
|
|
|
|
PCIE_DVT_PMU_PCIE_PHY_CTRL_DAST_PWRDN_SHIFT,
|
|
|
|
PCIE_DVT_PMU_PCIE_PHY_CTRL_DAST_RESET_SHIFT,
|
|
|
|
PCIE_DVT_PMU_PCIE_PHY_CTRL_DAST_DIG_RESET_SHIFT,};
|
|
|
|
static const u32 masks[PCIE_DVT_PMU_PCIE_PHY_CTRL_DAST_NFLDS] = {
|
|
|
|
PCIE_DVT_PMU_PCIE_PHY_CTRL_DAST_PWRDN_MASK,
|
|
|
|
PCIE_DVT_PMU_PCIE_PHY_CTRL_DAST_RESET_MASK,
|
|
|
|
PCIE_DVT_PMU_PCIE_PHY_CTRL_DAST_DIG_RESET_MASK,};
|
|
|
|
const int beg = start ? 0 : PCIE_DVT_PMU_PCIE_PHY_CTRL_DAST_NFLDS - 1;
|
|
|
|
const int end = start ? PCIE_DVT_PMU_PCIE_PHY_CTRL_DAST_NFLDS : -1;
|
|
|
|
u32 tmp, combined_mask = 0;
|
|
|
|
u32 val;
|
|
|
|
void __iomem *base = pcie->base;
|
|
|
|
int i, ret;
|
|
|
|
|
|
|
|
for (i = beg; i != end; start ? i++ : i--) {
|
|
|
|
val = start ? BIT_MASK(shifts[i]) : 0;
|
|
|
|
tmp = readl(base + PCIE_DVT_PMU_PCIE_PHY_CTRL);
|
|
|
|
tmp = (tmp & ~masks[i]) | (val & masks[i]);
|
|
|
|
writel(tmp, base + PCIE_DVT_PMU_PCIE_PHY_CTRL);
|
|
|
|
usleep_range(50, 200);
|
|
|
|
combined_mask |= masks[i];
|
|
|
|
}
|
|
|
|
|
|
|
|
tmp = readl(base + PCIE_DVT_PMU_PCIE_PHY_CTRL);
|
|
|
|
val = start ? combined_mask : 0;
|
|
|
|
|
|
|
|
ret = (tmp & combined_mask) == val ? 0 : -EIO;
|
|
|
|
if (ret)
|
|
|
|
dev_err(pcie->dev, "failed to %s phy\n", (start ? "start" : "stop"));
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline int brcm_phy_start(struct brcm_pcie *pcie)
|
|
|
|
{
|
2025-02-17 19:35:02 +00:00
|
|
|
return pcie->has_phy ? brcm_phy_cntl(pcie, 1) : 0;
|
2020-09-11 17:52:26 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static inline int brcm_phy_stop(struct brcm_pcie *pcie)
|
|
|
|
{
|
2025-02-17 19:35:02 +00:00
|
|
|
return pcie->has_phy ? brcm_phy_cntl(pcie, 0) : 0;
|
2020-09-11 17:52:26 +00:00
|
|
|
}
|
|
|
|
|
2025-02-17 19:35:19 +00:00
|
|
|
static int brcm_pcie_turn_off(struct brcm_pcie *pcie)
|
2019-12-16 11:01:09 +00:00
|
|
|
{
|
|
|
|
void __iomem *base = pcie->base;
|
2025-02-17 19:35:19 +00:00
|
|
|
int tmp, ret;
|
2019-12-16 11:01:09 +00:00
|
|
|
|
|
|
|
if (brcm_pcie_link_up(pcie))
|
|
|
|
brcm_pcie_enter_l23(pcie);
|
|
|
|
/* Assert fundamental reset */
|
2025-02-17 19:35:19 +00:00
|
|
|
ret = pcie->perst_set(pcie, 1);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
2019-12-16 11:01:09 +00:00
|
|
|
|
|
|
|
/* Deassert request for L23 in case it was asserted */
|
|
|
|
tmp = readl(base + PCIE_MISC_PCIE_CTRL);
|
|
|
|
u32p_replace_bits(&tmp, 0, PCIE_MISC_PCIE_CTRL_PCIE_L23_REQUEST_MASK);
|
|
|
|
writel(tmp, base + PCIE_MISC_PCIE_CTRL);
|
|
|
|
|
|
|
|
/* Turn off SerDes */
|
2025-02-17 19:34:45 +00:00
|
|
|
tmp = readl(base + HARD_DEBUG(pcie));
|
2019-12-16 11:01:09 +00:00
|
|
|
u32p_replace_bits(&tmp, 1, PCIE_MISC_HARD_PCIE_HARD_DEBUG_SERDES_IDDQ_MASK);
|
2025-02-17 19:34:45 +00:00
|
|
|
writel(tmp, base + HARD_DEBUG(pcie));
|
2019-12-16 11:01:09 +00:00
|
|
|
|
|
|
|
/* Shutdown PCIe bridge */
|
2025-02-17 19:35:19 +00:00
|
|
|
ret = pcie->bridge_sw_init_set(pcie, 1);
|
|
|
|
|
|
|
|
return ret;
|
2019-12-16 11:01:09 +00:00
|
|
|
}
|
|
|
|
|
2022-09-13 23:23:13 +00:00
|
|
|
static int pci_dev_may_wakeup(struct pci_dev *dev, void *data)
|
|
|
|
{
|
|
|
|
bool *ret = data;
|
|
|
|
|
|
|
|
if (device_may_wakeup(&dev->dev)) {
|
|
|
|
*ret = true;
|
|
|
|
dev_info(&dev->dev, "Possible wake-up device; regulators will not be disabled\n");
|
|
|
|
}
|
|
|
|
return (int) *ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int brcm_pcie_suspend_noirq(struct device *dev)
|
2020-09-11 17:52:24 +00:00
|
|
|
{
|
|
|
|
struct brcm_pcie *pcie = dev_get_drvdata(dev);
|
2022-09-13 23:23:13 +00:00
|
|
|
struct pci_host_bridge *bridge = pci_host_bridge_from_priv(pcie);
|
2025-02-17 19:35:19 +00:00
|
|
|
int ret, rret;
|
|
|
|
|
|
|
|
ret = brcm_pcie_turn_off(pcie);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
2020-09-11 17:52:24 +00:00
|
|
|
|
2022-03-28 22:51:27 +00:00
|
|
|
/*
|
|
|
|
* If brcm_phy_stop() returns an error, just dev_err(). If we
|
|
|
|
* return the error it will cause the suspend to fail and this is a
|
|
|
|
* forgivable offense that will probably be erased on resume.
|
|
|
|
*/
|
|
|
|
if (brcm_phy_stop(pcie))
|
|
|
|
dev_err(dev, "Could not stop phy for suspend\n");
|
|
|
|
|
|
|
|
ret = reset_control_rearm(pcie->rescal);
|
|
|
|
if (ret) {
|
|
|
|
dev_err(dev, "Could not rearm rescal reset\n");
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2022-09-13 23:23:13 +00:00
|
|
|
if (pcie->sr) {
|
|
|
|
/*
|
|
|
|
* Now turn off the regulators, but if at least one
|
|
|
|
* downstream device is enabled as a wake-up source, do not
|
|
|
|
* turn off regulators.
|
|
|
|
*/
|
|
|
|
pcie->ep_wakeup_capable = false;
|
|
|
|
pci_walk_bus(bridge->bus, pci_dev_may_wakeup,
|
|
|
|
&pcie->ep_wakeup_capable);
|
|
|
|
if (!pcie->ep_wakeup_capable) {
|
|
|
|
ret = regulator_bulk_disable(pcie->sr->num_supplies,
|
|
|
|
pcie->sr->supplies);
|
|
|
|
if (ret) {
|
|
|
|
dev_err(dev, "Could not turn off regulators\n");
|
2025-02-17 19:35:19 +00:00
|
|
|
rret = reset_control_reset(pcie->rescal);
|
|
|
|
if (rret)
|
|
|
|
dev_err(dev, "failed to reset 'rascal' controller ret=%d\n",
|
|
|
|
rret);
|
2022-09-13 23:23:13 +00:00
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2020-09-11 17:52:24 +00:00
|
|
|
clk_disable_unprepare(pcie->clk);
|
|
|
|
|
2022-03-28 22:51:27 +00:00
|
|
|
return 0;
|
2020-09-11 17:52:24 +00:00
|
|
|
}
|
|
|
|
|
2022-09-13 23:23:13 +00:00
|
|
|
static int brcm_pcie_resume_noirq(struct device *dev)
|
2020-09-11 17:52:24 +00:00
|
|
|
{
|
|
|
|
struct brcm_pcie *pcie = dev_get_drvdata(dev);
|
|
|
|
void __iomem *base;
|
|
|
|
u32 tmp;
|
2025-02-17 19:35:19 +00:00
|
|
|
int ret, rret;
|
2020-09-11 17:52:24 +00:00
|
|
|
|
|
|
|
base = pcie->base;
|
2022-03-28 22:51:27 +00:00
|
|
|
ret = clk_prepare_enable(pcie->clk);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
2020-09-11 17:52:24 +00:00
|
|
|
|
2021-04-30 15:21:56 +00:00
|
|
|
ret = reset_control_reset(pcie->rescal);
|
|
|
|
if (ret)
|
2022-08-18 00:01:24 +00:00
|
|
|
goto err_disable_clk;
|
2021-04-30 15:21:56 +00:00
|
|
|
|
2020-09-11 17:52:26 +00:00
|
|
|
ret = brcm_phy_start(pcie);
|
|
|
|
if (ret)
|
2021-04-30 15:21:56 +00:00
|
|
|
goto err_reset;
|
2020-09-11 17:52:26 +00:00
|
|
|
|
2020-09-11 17:52:24 +00:00
|
|
|
/* Take bridge out of reset so we can access the SERDES reg */
|
2020-09-11 17:52:25 +00:00
|
|
|
pcie->bridge_sw_init_set(pcie, 0);
|
2020-09-11 17:52:24 +00:00
|
|
|
|
|
|
|
/* SERDES_IDDQ = 0 */
|
2025-02-17 19:34:45 +00:00
|
|
|
tmp = readl(base + HARD_DEBUG(pcie));
|
2020-09-11 17:52:24 +00:00
|
|
|
u32p_replace_bits(&tmp, 0, PCIE_MISC_HARD_PCIE_HARD_DEBUG_SERDES_IDDQ_MASK);
|
2025-02-17 19:34:45 +00:00
|
|
|
writel(tmp, base + HARD_DEBUG(pcie));
|
2020-09-11 17:52:24 +00:00
|
|
|
|
|
|
|
/* wait for serdes to be stable */
|
|
|
|
udelay(100);
|
|
|
|
|
|
|
|
ret = brcm_pcie_setup(pcie);
|
|
|
|
if (ret)
|
2021-04-30 15:21:56 +00:00
|
|
|
goto err_reset;
|
2020-09-11 17:52:24 +00:00
|
|
|
|
2022-09-13 23:23:13 +00:00
|
|
|
if (pcie->sr) {
|
|
|
|
if (pcie->ep_wakeup_capable) {
|
|
|
|
/*
|
|
|
|
* We are resuming from a suspend. In the suspend we
|
|
|
|
* did not disable the power supplies, so there is
|
|
|
|
* no need to enable them (and falsely increase their
|
|
|
|
* usage count).
|
|
|
|
*/
|
|
|
|
pcie->ep_wakeup_capable = false;
|
|
|
|
} else {
|
|
|
|
ret = regulator_bulk_enable(pcie->sr->num_supplies,
|
|
|
|
pcie->sr->supplies);
|
|
|
|
if (ret) {
|
|
|
|
dev_err(dev, "Could not turn on regulators\n");
|
|
|
|
goto err_reset;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2022-09-13 23:21:19 +00:00
|
|
|
ret = brcm_pcie_start_link(pcie);
|
|
|
|
if (ret)
|
2022-09-13 23:23:13 +00:00
|
|
|
goto err_regulator;
|
2022-09-13 23:21:19 +00:00
|
|
|
|
2020-09-11 17:52:24 +00:00
|
|
|
if (pcie->msi)
|
|
|
|
brcm_msi_set_regs(pcie->msi);
|
|
|
|
|
|
|
|
return 0;
|
2020-09-11 17:52:26 +00:00
|
|
|
|
2022-09-13 23:23:13 +00:00
|
|
|
err_regulator:
|
|
|
|
if (pcie->sr)
|
|
|
|
regulator_bulk_disable(pcie->sr->num_supplies, pcie->sr->supplies);
|
2021-04-30 15:21:56 +00:00
|
|
|
err_reset:
|
2025-02-17 19:35:19 +00:00
|
|
|
rret = reset_control_rearm(pcie->rescal);
|
|
|
|
if (rret)
|
|
|
|
dev_err(pcie->dev, "failed to rearm 'rescal' reset, err=%d\n", rret);
|
2021-04-30 15:21:56 +00:00
|
|
|
err_disable_clk:
|
2020-09-11 17:52:26 +00:00
|
|
|
clk_disable_unprepare(pcie->clk);
|
|
|
|
return ret;
|
2019-12-16 11:01:09 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static void __brcm_pcie_remove(struct brcm_pcie *pcie)
|
|
|
|
{
|
2019-12-16 11:01:10 +00:00
|
|
|
brcm_msi_remove(pcie);
|
2019-12-16 11:01:09 +00:00
|
|
|
brcm_pcie_turn_off(pcie);
|
2022-03-28 22:51:27 +00:00
|
|
|
if (brcm_phy_stop(pcie))
|
|
|
|
dev_err(pcie->dev, "Could not stop phy\n");
|
|
|
|
if (reset_control_rearm(pcie->rescal))
|
|
|
|
dev_err(pcie->dev, "Could not rearm rescal reset\n");
|
2019-12-16 11:01:09 +00:00
|
|
|
clk_disable_unprepare(pcie->clk);
|
|
|
|
}
|
|
|
|
|
2023-09-18 17:25:32 +00:00
|
|
|
static void brcm_pcie_remove(struct platform_device *pdev)
|
2019-12-16 11:01:09 +00:00
|
|
|
{
|
|
|
|
struct brcm_pcie *pcie = platform_get_drvdata(pdev);
|
2020-05-22 23:48:21 +00:00
|
|
|
struct pci_host_bridge *bridge = pci_host_bridge_from_priv(pcie);
|
2019-12-16 11:01:09 +00:00
|
|
|
|
2020-05-22 23:48:21 +00:00
|
|
|
pci_stop_root_bus(bridge->bus);
|
|
|
|
pci_remove_root_bus(bridge->bus);
|
2019-12-16 11:01:09 +00:00
|
|
|
__brcm_pcie_remove(pcie);
|
|
|
|
}
|
|
|
|
|
2022-09-13 23:18:40 +00:00
|
|
|
static const int pcie_offsets[] = {
|
PCI: brcmstb: Sort enums, pcie_offsets[], pcie_cfg_data, .compatible strings
JIRA: https://issues.redhat.com/browse/RHEL-67693
Upstream Status: 2a0091f9419cb6dbbada3a4c8d9e86117b80ead4
commit 2a0091f9419cb6dbbada3a4c8d9e86117b80ead4
Author: Bjorn Helgaas <bhelgaas@google.com>
Date: Mon Sep 2 15:28:59 2024 -0500
PCI: brcmstb: Sort enums, pcie_offsets[], pcie_cfg_data, .compatible strings
Sort enum pcie_soc_base values.
Rename pcie_offsets_bmips_7425[] to pcie_offsets_bcm7425[] to match BCM7425
pcie_soc_base enum, bcm7425_cfg, and "brcm,bcm7425-pcie" .compatible
string.
Rename pcie_offset_bcm7278[] to pcie_offsets_bcm7278[] to match other
"pcie_offsets" names.
Rename pcie_offset_bcm7712[] to pcie_offsets_bcm7712[] to match other
"pcie_offsets" names.
Sort pcie_offsets_*[] by SoC name, move them all together, indent values
for easy reading.
Sort pcie_cfg_data structs by SoC name.
Sort .compatible strings by SoC name.
No functional change intended.
Link: https://lore.kernel.org/r/20240902205456.227409-1-helgaas@kernel.org
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com>
Signed-off-by: Myron Stowe <mstowe@redhat.com>
2025-02-17 19:35:50 +00:00
|
|
|
[RGR1_SW_INIT_1] = 0x9210,
|
|
|
|
[EXT_CFG_INDEX] = 0x9000,
|
|
|
|
[EXT_CFG_DATA] = 0x9004,
|
|
|
|
[PCIE_HARD_DEBUG] = 0x4204,
|
|
|
|
[PCIE_INTR2_CPU_BASE] = 0x4300,
|
|
|
|
};
|
|
|
|
|
|
|
|
static const int pcie_offsets_bcm7278[] = {
|
|
|
|
[RGR1_SW_INIT_1] = 0xc010,
|
|
|
|
[EXT_CFG_INDEX] = 0x9000,
|
|
|
|
[EXT_CFG_DATA] = 0x9004,
|
|
|
|
[PCIE_HARD_DEBUG] = 0x4204,
|
|
|
|
[PCIE_INTR2_CPU_BASE] = 0x4300,
|
2022-09-13 23:18:40 +00:00
|
|
|
};
|
|
|
|
|
PCI: brcmstb: Sort enums, pcie_offsets[], pcie_cfg_data, .compatible strings
JIRA: https://issues.redhat.com/browse/RHEL-67693
Upstream Status: 2a0091f9419cb6dbbada3a4c8d9e86117b80ead4
commit 2a0091f9419cb6dbbada3a4c8d9e86117b80ead4
Author: Bjorn Helgaas <bhelgaas@google.com>
Date: Mon Sep 2 15:28:59 2024 -0500
PCI: brcmstb: Sort enums, pcie_offsets[], pcie_cfg_data, .compatible strings
Sort enum pcie_soc_base values.
Rename pcie_offsets_bmips_7425[] to pcie_offsets_bcm7425[] to match BCM7425
pcie_soc_base enum, bcm7425_cfg, and "brcm,bcm7425-pcie" .compatible
string.
Rename pcie_offset_bcm7278[] to pcie_offsets_bcm7278[] to match other
"pcie_offsets" names.
Rename pcie_offset_bcm7712[] to pcie_offsets_bcm7712[] to match other
"pcie_offsets" names.
Sort pcie_offsets_*[] by SoC name, move them all together, indent values
for easy reading.
Sort pcie_cfg_data structs by SoC name.
Sort .compatible strings by SoC name.
No functional change intended.
Link: https://lore.kernel.org/r/20240902205456.227409-1-helgaas@kernel.org
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com>
Signed-off-by: Myron Stowe <mstowe@redhat.com>
2025-02-17 19:35:50 +00:00
|
|
|
static const int pcie_offsets_bcm7425[] = {
|
|
|
|
[RGR1_SW_INIT_1] = 0x8010,
|
|
|
|
[EXT_CFG_INDEX] = 0x8300,
|
|
|
|
[EXT_CFG_DATA] = 0x8304,
|
|
|
|
[PCIE_HARD_DEBUG] = 0x4204,
|
|
|
|
[PCIE_INTR2_CPU_BASE] = 0x4300,
|
2022-09-13 23:18:40 +00:00
|
|
|
};
|
|
|
|
|
PCI: brcmstb: Sort enums, pcie_offsets[], pcie_cfg_data, .compatible strings
JIRA: https://issues.redhat.com/browse/RHEL-67693
Upstream Status: 2a0091f9419cb6dbbada3a4c8d9e86117b80ead4
commit 2a0091f9419cb6dbbada3a4c8d9e86117b80ead4
Author: Bjorn Helgaas <bhelgaas@google.com>
Date: Mon Sep 2 15:28:59 2024 -0500
PCI: brcmstb: Sort enums, pcie_offsets[], pcie_cfg_data, .compatible strings
Sort enum pcie_soc_base values.
Rename pcie_offsets_bmips_7425[] to pcie_offsets_bcm7425[] to match BCM7425
pcie_soc_base enum, bcm7425_cfg, and "brcm,bcm7425-pcie" .compatible
string.
Rename pcie_offset_bcm7278[] to pcie_offsets_bcm7278[] to match other
"pcie_offsets" names.
Rename pcie_offset_bcm7712[] to pcie_offsets_bcm7712[] to match other
"pcie_offsets" names.
Sort pcie_offsets_*[] by SoC name, move them all together, indent values
for easy reading.
Sort pcie_cfg_data structs by SoC name.
Sort .compatible strings by SoC name.
No functional change intended.
Link: https://lore.kernel.org/r/20240902205456.227409-1-helgaas@kernel.org
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com>
Signed-off-by: Myron Stowe <mstowe@redhat.com>
2025-02-17 19:35:50 +00:00
|
|
|
static const int pcie_offsets_bcm7712[] = {
|
|
|
|
[EXT_CFG_INDEX] = 0x9000,
|
|
|
|
[EXT_CFG_DATA] = 0x9004,
|
|
|
|
[PCIE_HARD_DEBUG] = 0x4304,
|
|
|
|
[PCIE_INTR2_CPU_BASE] = 0x4400,
|
2025-02-17 19:35:41 +00:00
|
|
|
};
|
|
|
|
|
2022-09-13 23:18:40 +00:00
|
|
|
static const struct pcie_cfg_data generic_cfg = {
|
|
|
|
.offsets = pcie_offsets,
|
2025-02-17 19:35:32 +00:00
|
|
|
.soc_base = GENERIC,
|
2022-09-13 23:18:40 +00:00
|
|
|
.perst_set = brcm_pcie_perst_set_generic,
|
|
|
|
.bridge_sw_init_set = brcm_pcie_bridge_sw_init_set_generic,
|
2025-02-17 19:35:10 +00:00
|
|
|
.num_inbound_wins = 3,
|
2022-09-13 23:18:40 +00:00
|
|
|
};
|
|
|
|
|
PCI: brcmstb: Sort enums, pcie_offsets[], pcie_cfg_data, .compatible strings
JIRA: https://issues.redhat.com/browse/RHEL-67693
Upstream Status: 2a0091f9419cb6dbbada3a4c8d9e86117b80ead4
commit 2a0091f9419cb6dbbada3a4c8d9e86117b80ead4
Author: Bjorn Helgaas <bhelgaas@google.com>
Date: Mon Sep 2 15:28:59 2024 -0500
PCI: brcmstb: Sort enums, pcie_offsets[], pcie_cfg_data, .compatible strings
Sort enum pcie_soc_base values.
Rename pcie_offsets_bmips_7425[] to pcie_offsets_bcm7425[] to match BCM7425
pcie_soc_base enum, bcm7425_cfg, and "brcm,bcm7425-pcie" .compatible
string.
Rename pcie_offset_bcm7278[] to pcie_offsets_bcm7278[] to match other
"pcie_offsets" names.
Rename pcie_offset_bcm7712[] to pcie_offsets_bcm7712[] to match other
"pcie_offsets" names.
Sort pcie_offsets_*[] by SoC name, move them all together, indent values
for easy reading.
Sort pcie_cfg_data structs by SoC name.
Sort .compatible strings by SoC name.
No functional change intended.
Link: https://lore.kernel.org/r/20240902205456.227409-1-helgaas@kernel.org
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com>
Signed-off-by: Myron Stowe <mstowe@redhat.com>
2025-02-17 19:35:50 +00:00
|
|
|
static const struct pcie_cfg_data bcm2711_cfg = {
|
2022-09-13 23:18:40 +00:00
|
|
|
.offsets = pcie_offsets,
|
PCI: brcmstb: Sort enums, pcie_offsets[], pcie_cfg_data, .compatible strings
JIRA: https://issues.redhat.com/browse/RHEL-67693
Upstream Status: 2a0091f9419cb6dbbada3a4c8d9e86117b80ead4
commit 2a0091f9419cb6dbbada3a4c8d9e86117b80ead4
Author: Bjorn Helgaas <bhelgaas@google.com>
Date: Mon Sep 2 15:28:59 2024 -0500
PCI: brcmstb: Sort enums, pcie_offsets[], pcie_cfg_data, .compatible strings
Sort enum pcie_soc_base values.
Rename pcie_offsets_bmips_7425[] to pcie_offsets_bcm7425[] to match BCM7425
pcie_soc_base enum, bcm7425_cfg, and "brcm,bcm7425-pcie" .compatible
string.
Rename pcie_offset_bcm7278[] to pcie_offsets_bcm7278[] to match other
"pcie_offsets" names.
Rename pcie_offset_bcm7712[] to pcie_offsets_bcm7712[] to match other
"pcie_offsets" names.
Sort pcie_offsets_*[] by SoC name, move them all together, indent values
for easy reading.
Sort pcie_cfg_data structs by SoC name.
Sort .compatible strings by SoC name.
No functional change intended.
Link: https://lore.kernel.org/r/20240902205456.227409-1-helgaas@kernel.org
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com>
Signed-off-by: Myron Stowe <mstowe@redhat.com>
2025-02-17 19:35:50 +00:00
|
|
|
.soc_base = BCM2711,
|
2022-09-13 23:18:40 +00:00
|
|
|
.perst_set = brcm_pcie_perst_set_generic,
|
|
|
|
.bridge_sw_init_set = brcm_pcie_bridge_sw_init_set_generic,
|
2025-02-17 19:35:10 +00:00
|
|
|
.num_inbound_wins = 3,
|
2022-09-13 23:18:40 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
static const struct pcie_cfg_data bcm4908_cfg = {
|
|
|
|
.offsets = pcie_offsets,
|
2025-02-17 19:35:32 +00:00
|
|
|
.soc_base = BCM4908,
|
2022-09-13 23:18:40 +00:00
|
|
|
.perst_set = brcm_pcie_perst_set_4908,
|
|
|
|
.bridge_sw_init_set = brcm_pcie_bridge_sw_init_set_generic,
|
2025-02-17 19:35:10 +00:00
|
|
|
.num_inbound_wins = 3,
|
2022-09-13 23:18:40 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
static const struct pcie_cfg_data bcm7278_cfg = {
|
PCI: brcmstb: Sort enums, pcie_offsets[], pcie_cfg_data, .compatible strings
JIRA: https://issues.redhat.com/browse/RHEL-67693
Upstream Status: 2a0091f9419cb6dbbada3a4c8d9e86117b80ead4
commit 2a0091f9419cb6dbbada3a4c8d9e86117b80ead4
Author: Bjorn Helgaas <bhelgaas@google.com>
Date: Mon Sep 2 15:28:59 2024 -0500
PCI: brcmstb: Sort enums, pcie_offsets[], pcie_cfg_data, .compatible strings
Sort enum pcie_soc_base values.
Rename pcie_offsets_bmips_7425[] to pcie_offsets_bcm7425[] to match BCM7425
pcie_soc_base enum, bcm7425_cfg, and "brcm,bcm7425-pcie" .compatible
string.
Rename pcie_offset_bcm7278[] to pcie_offsets_bcm7278[] to match other
"pcie_offsets" names.
Rename pcie_offset_bcm7712[] to pcie_offsets_bcm7712[] to match other
"pcie_offsets" names.
Sort pcie_offsets_*[] by SoC name, move them all together, indent values
for easy reading.
Sort pcie_cfg_data structs by SoC name.
Sort .compatible strings by SoC name.
No functional change intended.
Link: https://lore.kernel.org/r/20240902205456.227409-1-helgaas@kernel.org
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com>
Signed-off-by: Myron Stowe <mstowe@redhat.com>
2025-02-17 19:35:50 +00:00
|
|
|
.offsets = pcie_offsets_bcm7278,
|
2025-02-17 19:35:32 +00:00
|
|
|
.soc_base = BCM7278,
|
2022-09-13 23:18:40 +00:00
|
|
|
.perst_set = brcm_pcie_perst_set_7278,
|
|
|
|
.bridge_sw_init_set = brcm_pcie_bridge_sw_init_set_7278,
|
2025-02-17 19:35:10 +00:00
|
|
|
.num_inbound_wins = 3,
|
2022-09-13 23:18:40 +00:00
|
|
|
};
|
|
|
|
|
PCI: brcmstb: Sort enums, pcie_offsets[], pcie_cfg_data, .compatible strings
JIRA: https://issues.redhat.com/browse/RHEL-67693
Upstream Status: 2a0091f9419cb6dbbada3a4c8d9e86117b80ead4
commit 2a0091f9419cb6dbbada3a4c8d9e86117b80ead4
Author: Bjorn Helgaas <bhelgaas@google.com>
Date: Mon Sep 2 15:28:59 2024 -0500
PCI: brcmstb: Sort enums, pcie_offsets[], pcie_cfg_data, .compatible strings
Sort enum pcie_soc_base values.
Rename pcie_offsets_bmips_7425[] to pcie_offsets_bcm7425[] to match BCM7425
pcie_soc_base enum, bcm7425_cfg, and "brcm,bcm7425-pcie" .compatible
string.
Rename pcie_offset_bcm7278[] to pcie_offsets_bcm7278[] to match other
"pcie_offsets" names.
Rename pcie_offset_bcm7712[] to pcie_offsets_bcm7712[] to match other
"pcie_offsets" names.
Sort pcie_offsets_*[] by SoC name, move them all together, indent values
for easy reading.
Sort pcie_cfg_data structs by SoC name.
Sort .compatible strings by SoC name.
No functional change intended.
Link: https://lore.kernel.org/r/20240902205456.227409-1-helgaas@kernel.org
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com>
Signed-off-by: Myron Stowe <mstowe@redhat.com>
2025-02-17 19:35:50 +00:00
|
|
|
static const struct pcie_cfg_data bcm7425_cfg = {
|
|
|
|
.offsets = pcie_offsets_bcm7425,
|
|
|
|
.soc_base = BCM7425,
|
|
|
|
.perst_set = brcm_pcie_perst_set_generic,
|
|
|
|
.bridge_sw_init_set = brcm_pcie_bridge_sw_init_set_generic,
|
|
|
|
.num_inbound_wins = 3,
|
|
|
|
};
|
|
|
|
|
|
|
|
static const struct pcie_cfg_data bcm7435_cfg = {
|
2022-09-13 23:18:40 +00:00
|
|
|
.offsets = pcie_offsets,
|
PCI: brcmstb: Sort enums, pcie_offsets[], pcie_cfg_data, .compatible strings
JIRA: https://issues.redhat.com/browse/RHEL-67693
Upstream Status: 2a0091f9419cb6dbbada3a4c8d9e86117b80ead4
commit 2a0091f9419cb6dbbada3a4c8d9e86117b80ead4
Author: Bjorn Helgaas <bhelgaas@google.com>
Date: Mon Sep 2 15:28:59 2024 -0500
PCI: brcmstb: Sort enums, pcie_offsets[], pcie_cfg_data, .compatible strings
Sort enum pcie_soc_base values.
Rename pcie_offsets_bmips_7425[] to pcie_offsets_bcm7425[] to match BCM7425
pcie_soc_base enum, bcm7425_cfg, and "brcm,bcm7425-pcie" .compatible
string.
Rename pcie_offset_bcm7278[] to pcie_offsets_bcm7278[] to match other
"pcie_offsets" names.
Rename pcie_offset_bcm7712[] to pcie_offsets_bcm7712[] to match other
"pcie_offsets" names.
Sort pcie_offsets_*[] by SoC name, move them all together, indent values
for easy reading.
Sort pcie_cfg_data structs by SoC name.
Sort .compatible strings by SoC name.
No functional change intended.
Link: https://lore.kernel.org/r/20240902205456.227409-1-helgaas@kernel.org
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com>
Signed-off-by: Myron Stowe <mstowe@redhat.com>
2025-02-17 19:35:50 +00:00
|
|
|
.soc_base = BCM7435,
|
2022-09-13 23:18:40 +00:00
|
|
|
.perst_set = brcm_pcie_perst_set_generic,
|
|
|
|
.bridge_sw_init_set = brcm_pcie_bridge_sw_init_set_generic,
|
2025-02-17 19:35:10 +00:00
|
|
|
.num_inbound_wins = 3,
|
2022-09-13 23:18:40 +00:00
|
|
|
};
|
|
|
|
|
2025-02-17 19:35:02 +00:00
|
|
|
static const struct pcie_cfg_data bcm7216_cfg = {
|
PCI: brcmstb: Sort enums, pcie_offsets[], pcie_cfg_data, .compatible strings
JIRA: https://issues.redhat.com/browse/RHEL-67693
Upstream Status: 2a0091f9419cb6dbbada3a4c8d9e86117b80ead4
commit 2a0091f9419cb6dbbada3a4c8d9e86117b80ead4
Author: Bjorn Helgaas <bhelgaas@google.com>
Date: Mon Sep 2 15:28:59 2024 -0500
PCI: brcmstb: Sort enums, pcie_offsets[], pcie_cfg_data, .compatible strings
Sort enum pcie_soc_base values.
Rename pcie_offsets_bmips_7425[] to pcie_offsets_bcm7425[] to match BCM7425
pcie_soc_base enum, bcm7425_cfg, and "brcm,bcm7425-pcie" .compatible
string.
Rename pcie_offset_bcm7278[] to pcie_offsets_bcm7278[] to match other
"pcie_offsets" names.
Rename pcie_offset_bcm7712[] to pcie_offsets_bcm7712[] to match other
"pcie_offsets" names.
Sort pcie_offsets_*[] by SoC name, move them all together, indent values
for easy reading.
Sort pcie_cfg_data structs by SoC name.
Sort .compatible strings by SoC name.
No functional change intended.
Link: https://lore.kernel.org/r/20240902205456.227409-1-helgaas@kernel.org
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com>
Signed-off-by: Myron Stowe <mstowe@redhat.com>
2025-02-17 19:35:50 +00:00
|
|
|
.offsets = pcie_offsets_bcm7278,
|
2025-02-17 19:35:32 +00:00
|
|
|
.soc_base = BCM7278,
|
2025-02-17 19:35:02 +00:00
|
|
|
.perst_set = brcm_pcie_perst_set_7278,
|
|
|
|
.bridge_sw_init_set = brcm_pcie_bridge_sw_init_set_7278,
|
|
|
|
.has_phy = true,
|
2025-02-17 19:35:10 +00:00
|
|
|
.num_inbound_wins = 3,
|
2025-02-17 19:35:02 +00:00
|
|
|
};
|
|
|
|
|
2025-02-17 19:35:41 +00:00
|
|
|
static const struct pcie_cfg_data bcm7712_cfg = {
|
PCI: brcmstb: Sort enums, pcie_offsets[], pcie_cfg_data, .compatible strings
JIRA: https://issues.redhat.com/browse/RHEL-67693
Upstream Status: 2a0091f9419cb6dbbada3a4c8d9e86117b80ead4
commit 2a0091f9419cb6dbbada3a4c8d9e86117b80ead4
Author: Bjorn Helgaas <bhelgaas@google.com>
Date: Mon Sep 2 15:28:59 2024 -0500
PCI: brcmstb: Sort enums, pcie_offsets[], pcie_cfg_data, .compatible strings
Sort enum pcie_soc_base values.
Rename pcie_offsets_bmips_7425[] to pcie_offsets_bcm7425[] to match BCM7425
pcie_soc_base enum, bcm7425_cfg, and "brcm,bcm7425-pcie" .compatible
string.
Rename pcie_offset_bcm7278[] to pcie_offsets_bcm7278[] to match other
"pcie_offsets" names.
Rename pcie_offset_bcm7712[] to pcie_offsets_bcm7712[] to match other
"pcie_offsets" names.
Sort pcie_offsets_*[] by SoC name, move them all together, indent values
for easy reading.
Sort pcie_cfg_data structs by SoC name.
Sort .compatible strings by SoC name.
No functional change intended.
Link: https://lore.kernel.org/r/20240902205456.227409-1-helgaas@kernel.org
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com>
Signed-off-by: Myron Stowe <mstowe@redhat.com>
2025-02-17 19:35:50 +00:00
|
|
|
.offsets = pcie_offsets_bcm7712,
|
2025-02-17 19:35:41 +00:00
|
|
|
.perst_set = brcm_pcie_perst_set_7278,
|
|
|
|
.bridge_sw_init_set = brcm_pcie_bridge_sw_init_set_generic,
|
|
|
|
.soc_base = BCM7712,
|
|
|
|
.num_inbound_wins = 10,
|
|
|
|
};
|
|
|
|
|
PCI: brcmstb: Add bcm7278 register info
Add in compatibility strings and code for three Broadcom STB chips. Some
of the register locations, shifts, and masks are different for certain
chips, requiring the use of different constants based on of_id.
We would like to add the following at this time to the match list but we
need to wait until the end of this patchset so that everything works.
{ .compatible = "brcm,bcm7211-pcie", .data = &generic_cfg },
{ .compatible = "brcm,bcm7278-pcie", .data = &bcm7278_cfg },
{ .compatible = "brcm,bcm7216-pcie", .data = &bcm7278_cfg },
{ .compatible = "brcm,bcm7445-pcie", .data = &generic_cfg },
Link: https://lore.kernel.org/r/20200911175232.19016-4-james.quinlan@broadcom.com
Signed-off-by: Jim Quinlan <jquinlan@broadcom.com>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
Acked-by: Rob Herring <robh@kernel.org>
2020-09-11 17:52:23 +00:00
|
|
|
static const struct of_device_id brcm_pcie_match[] = {
|
|
|
|
{ .compatible = "brcm,bcm2711-pcie", .data = &bcm2711_cfg },
|
2020-12-10 18:04:21 +00:00
|
|
|
{ .compatible = "brcm,bcm4908-pcie", .data = &bcm4908_cfg },
|
2020-09-11 17:52:30 +00:00
|
|
|
{ .compatible = "brcm,bcm7211-pcie", .data = &generic_cfg },
|
2025-02-17 19:35:02 +00:00
|
|
|
{ .compatible = "brcm,bcm7216-pcie", .data = &bcm7216_cfg },
|
PCI: brcmstb: Sort enums, pcie_offsets[], pcie_cfg_data, .compatible strings
JIRA: https://issues.redhat.com/browse/RHEL-67693
Upstream Status: 2a0091f9419cb6dbbada3a4c8d9e86117b80ead4
commit 2a0091f9419cb6dbbada3a4c8d9e86117b80ead4
Author: Bjorn Helgaas <bhelgaas@google.com>
Date: Mon Sep 2 15:28:59 2024 -0500
PCI: brcmstb: Sort enums, pcie_offsets[], pcie_cfg_data, .compatible strings
Sort enum pcie_soc_base values.
Rename pcie_offsets_bmips_7425[] to pcie_offsets_bcm7425[] to match BCM7425
pcie_soc_base enum, bcm7425_cfg, and "brcm,bcm7425-pcie" .compatible
string.
Rename pcie_offset_bcm7278[] to pcie_offsets_bcm7278[] to match other
"pcie_offsets" names.
Rename pcie_offset_bcm7712[] to pcie_offsets_bcm7712[] to match other
"pcie_offsets" names.
Sort pcie_offsets_*[] by SoC name, move them all together, indent values
for easy reading.
Sort pcie_cfg_data structs by SoC name.
Sort .compatible strings by SoC name.
No functional change intended.
Link: https://lore.kernel.org/r/20240902205456.227409-1-helgaas@kernel.org
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com>
Signed-off-by: Myron Stowe <mstowe@redhat.com>
2025-02-17 19:35:50 +00:00
|
|
|
{ .compatible = "brcm,bcm7278-pcie", .data = &bcm7278_cfg },
|
2022-09-13 23:17:57 +00:00
|
|
|
{ .compatible = "brcm,bcm7425-pcie", .data = &bcm7425_cfg },
|
PCI: brcmstb: Sort enums, pcie_offsets[], pcie_cfg_data, .compatible strings
JIRA: https://issues.redhat.com/browse/RHEL-67693
Upstream Status: 2a0091f9419cb6dbbada3a4c8d9e86117b80ead4
commit 2a0091f9419cb6dbbada3a4c8d9e86117b80ead4
Author: Bjorn Helgaas <bhelgaas@google.com>
Date: Mon Sep 2 15:28:59 2024 -0500
PCI: brcmstb: Sort enums, pcie_offsets[], pcie_cfg_data, .compatible strings
Sort enum pcie_soc_base values.
Rename pcie_offsets_bmips_7425[] to pcie_offsets_bcm7425[] to match BCM7425
pcie_soc_base enum, bcm7425_cfg, and "brcm,bcm7425-pcie" .compatible
string.
Rename pcie_offset_bcm7278[] to pcie_offsets_bcm7278[] to match other
"pcie_offsets" names.
Rename pcie_offset_bcm7712[] to pcie_offsets_bcm7712[] to match other
"pcie_offsets" names.
Sort pcie_offsets_*[] by SoC name, move them all together, indent values
for easy reading.
Sort pcie_cfg_data structs by SoC name.
Sort .compatible strings by SoC name.
No functional change intended.
Link: https://lore.kernel.org/r/20240902205456.227409-1-helgaas@kernel.org
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com>
Signed-off-by: Myron Stowe <mstowe@redhat.com>
2025-02-17 19:35:50 +00:00
|
|
|
{ .compatible = "brcm,bcm7435-pcie", .data = &bcm7435_cfg },
|
|
|
|
{ .compatible = "brcm,bcm7445-pcie", .data = &generic_cfg },
|
2025-02-17 19:35:41 +00:00
|
|
|
{ .compatible = "brcm,bcm7712-pcie", .data = &bcm7712_cfg },
|
PCI: brcmstb: Add bcm7278 register info
Add in compatibility strings and code for three Broadcom STB chips. Some
of the register locations, shifts, and masks are different for certain
chips, requiring the use of different constants based on of_id.
We would like to add the following at this time to the match list but we
need to wait until the end of this patchset so that everything works.
{ .compatible = "brcm,bcm7211-pcie", .data = &generic_cfg },
{ .compatible = "brcm,bcm7278-pcie", .data = &bcm7278_cfg },
{ .compatible = "brcm,bcm7216-pcie", .data = &bcm7278_cfg },
{ .compatible = "brcm,bcm7445-pcie", .data = &generic_cfg },
Link: https://lore.kernel.org/r/20200911175232.19016-4-james.quinlan@broadcom.com
Signed-off-by: Jim Quinlan <jquinlan@broadcom.com>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
Acked-by: Rob Herring <robh@kernel.org>
2020-09-11 17:52:23 +00:00
|
|
|
{},
|
|
|
|
};
|
|
|
|
|
2022-09-13 23:18:40 +00:00
|
|
|
static struct pci_ops brcm_pcie_ops = {
|
2022-09-13 23:24:04 +00:00
|
|
|
.map_bus = brcm_pcie_map_bus,
|
2022-09-13 23:18:40 +00:00
|
|
|
.read = pci_generic_config_read,
|
|
|
|
.write = pci_generic_config_write,
|
PCI: brcmstb: Enable child bus device regulators from DT
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2124638
Upstream Status: 9e6be018b26347c26a93e63fb50a37ee2c9311de
commit 9e6be018b26347c26a93e63fb50a37ee2c9311de
Author: Jim Quinlan <jim2101024@gmail.com>
Date: Mon Jul 25 11:12:53 2022 -0400
PCI: brcmstb: Enable child bus device regulators from DT
Some platforms have power regulators for slots or devices below Root Ports.
On platforms like Raspberry Pi 4, these regulators are described in the
Root Port device tree node, since they logically belong to the Root Port,
not to the host bridge itself.
Add an .add_bus() hook (called when pci_alloc_child_bus() allocates the
secondary ("child") bus for a bridge), and look for such regulators. If we
find some, enable them before bringing up the link and enumerating devices
on the child bus.
Similarly, when pci_remove_bus() calls the ops->remove_bus() hook, disable
the regulators.
The regulators that may be described in a Root Port DT device are:
vpcie3v3
vpcie3v3aux
vpcie12v
These control power to the device downstream from the Root Port.
[bhelgaas: commit log, name hooks brcm_pcie_add_bus(), etc, since we only
support one set of subregulator info, save info in struct brcm_pcie instead
of dev->driver_data, move brcm_pcie_start_link() from probe to .add_bus()
(from subsequent patch)]
Link: https://lore.kernel.org/r/20220725151258.42574-5-jim2101024@gmail.com
Signed-off-by: Jim Quinlan <jim2101024@gmail.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Tested-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Myron Stowe <mstowe@redhat.com>
2022-09-13 23:22:17 +00:00
|
|
|
.add_bus = brcm_pcie_add_bus,
|
|
|
|
.remove_bus = brcm_pcie_remove_bus,
|
2022-09-13 23:18:40 +00:00
|
|
|
};
|
|
|
|
|
2022-09-13 23:24:04 +00:00
|
|
|
static struct pci_ops brcm7425_pcie_ops = {
|
|
|
|
.map_bus = brcm7425_pcie_map_bus,
|
2022-09-13 23:18:40 +00:00
|
|
|
.read = pci_generic_config_read32,
|
|
|
|
.write = pci_generic_config_write32,
|
PCI: brcmstb: Enable child bus device regulators from DT
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2124638
Upstream Status: 9e6be018b26347c26a93e63fb50a37ee2c9311de
commit 9e6be018b26347c26a93e63fb50a37ee2c9311de
Author: Jim Quinlan <jim2101024@gmail.com>
Date: Mon Jul 25 11:12:53 2022 -0400
PCI: brcmstb: Enable child bus device regulators from DT
Some platforms have power regulators for slots or devices below Root Ports.
On platforms like Raspberry Pi 4, these regulators are described in the
Root Port device tree node, since they logically belong to the Root Port,
not to the host bridge itself.
Add an .add_bus() hook (called when pci_alloc_child_bus() allocates the
secondary ("child") bus for a bridge), and look for such regulators. If we
find some, enable them before bringing up the link and enumerating devices
on the child bus.
Similarly, when pci_remove_bus() calls the ops->remove_bus() hook, disable
the regulators.
The regulators that may be described in a Root Port DT device are:
vpcie3v3
vpcie3v3aux
vpcie12v
These control power to the device downstream from the Root Port.
[bhelgaas: commit log, name hooks brcm_pcie_add_bus(), etc, since we only
support one set of subregulator info, save info in struct brcm_pcie instead
of dev->driver_data, move brcm_pcie_start_link() from probe to .add_bus()
(from subsequent patch)]
Link: https://lore.kernel.org/r/20220725151258.42574-5-jim2101024@gmail.com
Signed-off-by: Jim Quinlan <jim2101024@gmail.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Tested-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Myron Stowe <mstowe@redhat.com>
2022-09-13 23:22:17 +00:00
|
|
|
.add_bus = brcm_pcie_add_bus,
|
|
|
|
.remove_bus = brcm_pcie_remove_bus,
|
2022-09-13 23:18:40 +00:00
|
|
|
};
|
|
|
|
|
2019-12-16 11:01:09 +00:00
|
|
|
static int brcm_pcie_probe(struct platform_device *pdev)
|
|
|
|
{
|
2019-12-16 11:01:10 +00:00
|
|
|
struct device_node *np = pdev->dev.of_node, *msi_np;
|
2019-12-16 11:01:09 +00:00
|
|
|
struct pci_host_bridge *bridge;
|
PCI: brcmstb: Add bcm7278 register info
Add in compatibility strings and code for three Broadcom STB chips. Some
of the register locations, shifts, and masks are different for certain
chips, requiring the use of different constants based on of_id.
We would like to add the following at this time to the match list but we
need to wait until the end of this patchset so that everything works.
{ .compatible = "brcm,bcm7211-pcie", .data = &generic_cfg },
{ .compatible = "brcm,bcm7278-pcie", .data = &bcm7278_cfg },
{ .compatible = "brcm,bcm7216-pcie", .data = &bcm7278_cfg },
{ .compatible = "brcm,bcm7445-pcie", .data = &generic_cfg },
Link: https://lore.kernel.org/r/20200911175232.19016-4-james.quinlan@broadcom.com
Signed-off-by: Jim Quinlan <jquinlan@broadcom.com>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
Acked-by: Rob Herring <robh@kernel.org>
2020-09-11 17:52:23 +00:00
|
|
|
const struct pcie_cfg_data *data;
|
2019-12-16 11:01:09 +00:00
|
|
|
struct brcm_pcie *pcie;
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
bridge = devm_pci_alloc_host_bridge(&pdev->dev, sizeof(*pcie));
|
|
|
|
if (!bridge)
|
|
|
|
return -ENOMEM;
|
|
|
|
|
PCI: brcmstb: Add bcm7278 register info
Add in compatibility strings and code for three Broadcom STB chips. Some
of the register locations, shifts, and masks are different for certain
chips, requiring the use of different constants based on of_id.
We would like to add the following at this time to the match list but we
need to wait until the end of this patchset so that everything works.
{ .compatible = "brcm,bcm7211-pcie", .data = &generic_cfg },
{ .compatible = "brcm,bcm7278-pcie", .data = &bcm7278_cfg },
{ .compatible = "brcm,bcm7216-pcie", .data = &bcm7278_cfg },
{ .compatible = "brcm,bcm7445-pcie", .data = &generic_cfg },
Link: https://lore.kernel.org/r/20200911175232.19016-4-james.quinlan@broadcom.com
Signed-off-by: Jim Quinlan <jquinlan@broadcom.com>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
Acked-by: Rob Herring <robh@kernel.org>
2020-09-11 17:52:23 +00:00
|
|
|
data = of_device_get_match_data(&pdev->dev);
|
|
|
|
if (!data) {
|
|
|
|
pr_err("failed to look up compatible string\n");
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
2019-12-16 11:01:09 +00:00
|
|
|
pcie = pci_host_bridge_priv(bridge);
|
|
|
|
pcie->dev = &pdev->dev;
|
|
|
|
pcie->np = np;
|
PCI: brcmstb: Add bcm7278 register info
Add in compatibility strings and code for three Broadcom STB chips. Some
of the register locations, shifts, and masks are different for certain
chips, requiring the use of different constants based on of_id.
We would like to add the following at this time to the match list but we
need to wait until the end of this patchset so that everything works.
{ .compatible = "brcm,bcm7211-pcie", .data = &generic_cfg },
{ .compatible = "brcm,bcm7278-pcie", .data = &bcm7278_cfg },
{ .compatible = "brcm,bcm7216-pcie", .data = &bcm7278_cfg },
{ .compatible = "brcm,bcm7445-pcie", .data = &generic_cfg },
Link: https://lore.kernel.org/r/20200911175232.19016-4-james.quinlan@broadcom.com
Signed-off-by: Jim Quinlan <jquinlan@broadcom.com>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
Acked-by: Rob Herring <robh@kernel.org>
2020-09-11 17:52:23 +00:00
|
|
|
pcie->reg_offsets = data->offsets;
|
2025-02-17 19:35:32 +00:00
|
|
|
pcie->soc_base = data->soc_base;
|
2020-09-11 17:52:25 +00:00
|
|
|
pcie->perst_set = data->perst_set;
|
|
|
|
pcie->bridge_sw_init_set = data->bridge_sw_init_set;
|
2025-02-17 19:35:02 +00:00
|
|
|
pcie->has_phy = data->has_phy;
|
2025-02-17 19:35:10 +00:00
|
|
|
pcie->num_inbound_wins = data->num_inbound_wins;
|
2019-12-16 11:01:09 +00:00
|
|
|
|
2020-07-08 15:56:14 +00:00
|
|
|
pcie->base = devm_platform_ioremap_resource(pdev, 0);
|
2019-12-16 11:01:09 +00:00
|
|
|
if (IS_ERR(pcie->base))
|
|
|
|
return PTR_ERR(pcie->base);
|
|
|
|
|
|
|
|
pcie->clk = devm_clk_get_optional(&pdev->dev, "sw_pcie");
|
|
|
|
if (IS_ERR(pcie->clk))
|
|
|
|
return PTR_ERR(pcie->clk);
|
|
|
|
|
|
|
|
ret = of_pci_get_max_link_speed(np);
|
|
|
|
pcie->gen = (ret < 0) ? 0 : ret;
|
|
|
|
|
|
|
|
pcie->ssc = of_property_read_bool(np, "brcm,enable-ssc");
|
|
|
|
|
2020-09-11 17:52:26 +00:00
|
|
|
pcie->rescal = devm_reset_control_get_optional_shared(&pdev->dev, "rescal");
|
2025-02-17 19:34:20 +00:00
|
|
|
if (IS_ERR(pcie->rescal))
|
2020-09-11 17:52:26 +00:00
|
|
|
return PTR_ERR(pcie->rescal);
|
2025-02-17 19:34:20 +00:00
|
|
|
|
2020-12-10 18:04:21 +00:00
|
|
|
pcie->perst_reset = devm_reset_control_get_optional_exclusive(&pdev->dev, "perst");
|
2025-02-17 19:34:20 +00:00
|
|
|
if (IS_ERR(pcie->perst_reset))
|
2020-12-10 18:04:21 +00:00
|
|
|
return PTR_ERR(pcie->perst_reset);
|
2020-09-11 17:52:26 +00:00
|
|
|
|
2025-02-17 19:34:28 +00:00
|
|
|
pcie->bridge_reset = devm_reset_control_get_optional_exclusive(&pdev->dev, "bridge");
|
|
|
|
if (IS_ERR(pcie->bridge_reset))
|
|
|
|
return PTR_ERR(pcie->bridge_reset);
|
|
|
|
|
2025-02-17 19:34:37 +00:00
|
|
|
pcie->swinit_reset = devm_reset_control_get_optional_exclusive(&pdev->dev, "swinit");
|
|
|
|
if (IS_ERR(pcie->swinit_reset))
|
|
|
|
return PTR_ERR(pcie->swinit_reset);
|
|
|
|
|
2025-02-17 19:34:20 +00:00
|
|
|
ret = clk_prepare_enable(pcie->clk);
|
2020-09-11 17:52:26 +00:00
|
|
|
if (ret)
|
2025-02-17 19:34:20 +00:00
|
|
|
return dev_err_probe(&pdev->dev, ret, "could not enable clock\n");
|
|
|
|
|
2025-02-17 19:34:28 +00:00
|
|
|
pcie->bridge_sw_init_set(pcie, 0);
|
|
|
|
|
2025-02-17 19:34:37 +00:00
|
|
|
if (pcie->swinit_reset) {
|
|
|
|
ret = reset_control_assert(pcie->swinit_reset);
|
|
|
|
if (ret) {
|
|
|
|
clk_disable_unprepare(pcie->clk);
|
|
|
|
return dev_err_probe(&pdev->dev, ret,
|
|
|
|
"could not assert reset 'swinit'\n");
|
|
|
|
}
|
|
|
|
|
|
|
|
/* HW team recommends 1us for proper sync and propagation of reset */
|
|
|
|
udelay(1);
|
|
|
|
|
|
|
|
ret = reset_control_deassert(pcie->swinit_reset);
|
|
|
|
if (ret) {
|
|
|
|
clk_disable_unprepare(pcie->clk);
|
|
|
|
return dev_err_probe(&pdev->dev, ret,
|
|
|
|
"could not de-assert reset 'swinit'\n");
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2025-02-17 19:34:20 +00:00
|
|
|
ret = reset_control_reset(pcie->rescal);
|
|
|
|
if (ret) {
|
|
|
|
clk_disable_unprepare(pcie->clk);
|
|
|
|
return dev_err_probe(&pdev->dev, ret, "failed to deassert 'rescal'\n");
|
|
|
|
}
|
2020-09-11 17:52:26 +00:00
|
|
|
|
|
|
|
ret = brcm_phy_start(pcie);
|
|
|
|
if (ret) {
|
2021-04-30 15:21:56 +00:00
|
|
|
reset_control_rearm(pcie->rescal);
|
2020-09-11 17:52:26 +00:00
|
|
|
clk_disable_unprepare(pcie->clk);
|
|
|
|
return ret;
|
|
|
|
}
|
2019-12-16 11:01:09 +00:00
|
|
|
|
|
|
|
ret = brcm_pcie_setup(pcie);
|
|
|
|
if (ret)
|
|
|
|
goto fail;
|
|
|
|
|
2020-09-11 17:52:28 +00:00
|
|
|
pcie->hw_rev = readl(pcie->base + PCIE_MISC_REVISION);
|
2025-02-17 19:35:32 +00:00
|
|
|
if (pcie->soc_base == BCM4908 && pcie->hw_rev >= BRCM_PCIE_HW_REV_3_20) {
|
2020-12-10 18:04:21 +00:00
|
|
|
dev_err(pcie->dev, "hardware revision with unsupported PERST# setup\n");
|
2021-03-08 13:56:19 +00:00
|
|
|
ret = -ENODEV;
|
2020-12-10 18:04:21 +00:00
|
|
|
goto fail;
|
|
|
|
}
|
2020-09-11 17:52:28 +00:00
|
|
|
|
2019-12-16 11:01:10 +00:00
|
|
|
msi_np = of_parse_phandle(pcie->np, "msi-parent", 0);
|
|
|
|
if (pci_msi_enabled() && msi_np == pcie->np) {
|
|
|
|
ret = brcm_pcie_enable_msi(pcie);
|
|
|
|
if (ret) {
|
|
|
|
dev_err(pcie->dev, "probe of internal MSI failed");
|
|
|
|
goto fail;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2025-02-17 19:35:32 +00:00
|
|
|
bridge->ops = pcie->soc_base == BCM7425 ? &brcm7425_pcie_ops : &brcm_pcie_ops;
|
2019-12-16 11:01:09 +00:00
|
|
|
bridge->sysdata = pcie;
|
|
|
|
|
|
|
|
platform_set_drvdata(pdev, pcie);
|
|
|
|
|
PCI: brcmstb: Enable child bus device regulators from DT
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2124638
Upstream Status: 9e6be018b26347c26a93e63fb50a37ee2c9311de
commit 9e6be018b26347c26a93e63fb50a37ee2c9311de
Author: Jim Quinlan <jim2101024@gmail.com>
Date: Mon Jul 25 11:12:53 2022 -0400
PCI: brcmstb: Enable child bus device regulators from DT
Some platforms have power regulators for slots or devices below Root Ports.
On platforms like Raspberry Pi 4, these regulators are described in the
Root Port device tree node, since they logically belong to the Root Port,
not to the host bridge itself.
Add an .add_bus() hook (called when pci_alloc_child_bus() allocates the
secondary ("child") bus for a bridge), and look for such regulators. If we
find some, enable them before bringing up the link and enumerating devices
on the child bus.
Similarly, when pci_remove_bus() calls the ops->remove_bus() hook, disable
the regulators.
The regulators that may be described in a Root Port DT device are:
vpcie3v3
vpcie3v3aux
vpcie12v
These control power to the device downstream from the Root Port.
[bhelgaas: commit log, name hooks brcm_pcie_add_bus(), etc, since we only
support one set of subregulator info, save info in struct brcm_pcie instead
of dev->driver_data, move brcm_pcie_start_link() from probe to .add_bus()
(from subsequent patch)]
Link: https://lore.kernel.org/r/20220725151258.42574-5-jim2101024@gmail.com
Signed-off-by: Jim Quinlan <jim2101024@gmail.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Tested-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Myron Stowe <mstowe@redhat.com>
2022-09-13 23:22:17 +00:00
|
|
|
ret = pci_host_probe(bridge);
|
|
|
|
if (!ret && !brcm_pcie_link_up(pcie))
|
|
|
|
ret = -ENODEV;
|
|
|
|
|
|
|
|
if (ret) {
|
|
|
|
brcm_pcie_remove(pdev);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
2019-12-16 11:01:09 +00:00
|
|
|
fail:
|
|
|
|
__brcm_pcie_remove(pcie);
|
2025-02-17 19:34:20 +00:00
|
|
|
|
2019-12-16 11:01:09 +00:00
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
MODULE_DEVICE_TABLE(of, brcm_pcie_match);
|
|
|
|
|
2020-09-11 17:52:24 +00:00
|
|
|
static const struct dev_pm_ops brcm_pcie_pm_ops = {
|
2022-09-13 23:23:13 +00:00
|
|
|
.suspend_noirq = brcm_pcie_suspend_noirq,
|
|
|
|
.resume_noirq = brcm_pcie_resume_noirq,
|
2020-09-11 17:52:24 +00:00
|
|
|
};
|
|
|
|
|
2019-12-16 11:01:09 +00:00
|
|
|
static struct platform_driver brcm_pcie_driver = {
|
|
|
|
.probe = brcm_pcie_probe,
|
2023-09-18 17:25:32 +00:00
|
|
|
.remove_new = brcm_pcie_remove,
|
2019-12-16 11:01:09 +00:00
|
|
|
.driver = {
|
|
|
|
.name = "brcm-pcie",
|
|
|
|
.of_match_table = brcm_pcie_match,
|
2020-09-11 17:52:24 +00:00
|
|
|
.pm = &brcm_pcie_pm_ops,
|
2019-12-16 11:01:09 +00:00
|
|
|
},
|
|
|
|
};
|
|
|
|
module_platform_driver(brcm_pcie_driver);
|
|
|
|
|
|
|
|
MODULE_LICENSE("GPL");
|
|
|
|
MODULE_DESCRIPTION("Broadcom STB PCIe RC driver");
|
|
|
|
MODULE_AUTHOR("Broadcom");
|