| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
We've been carting around this field since the original p7ioc-phb code.
As far as I can tell we never actually use it for anything other than
checking if the PHB has been marked as broken or not. The _FENCED
state is set in a few places, but we never use it in favour of just
checking the MMIO register.
This patch just replaces it with a boolean that indicates if
the PHB has been marked as broken and removes the giant, mostly
wrong, comment explaining it's usage that is copied and pasted
into each phb header file.
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
The issue was reported by Mark: the Samsung NVMe adapter is lost
when it's connected to PMC 8546 PCIe switch, until ECRC is disabled
on the root port. Actually, we found similar issue prevously when
Broadcom adapter is connected to same part of PCIe switch and it
was fixed by commit 60ce59ccd0e9 ("hw/phb3: Disable ECRC on Broadcom
adapter behind PMC switch"). Unfortunately, the commit doesn't fix
the Samsung NVMe adapter lost issue.
This fixes the issues by disable ECRC generation/check on root port
when PMC 8546 PCIe switch ports are found. This can be extended for
other PCIe switches or endpoints in future: Each PHB maintains the
count of PCI devices (PMC 8546 PCIe switch ports currently) which
require to disable ECRC on root port. The ECRC functionality is
enabled when first PMC 8546 switch port is probed and disabled when
last PMC 8546 switch port is destroyed (in PCI hot remove scenario).
Except PHB's reinitialization after complete reset, the ECRC on
root port is untouched.
Reported-by: Mark E Schreiter <markes@us.ibm.com>
Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
Tested-by: Mark E Schreiter <markes@us.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
When fast rebooting or kexec-ing a system with a PHB in CAPI mode, we need
to return the PHB to regular PCIe mode.
In order to do this, we have to reset a bunch of registers to their
pre-CAPI-mode state. However, doing this while there is traffic going over
the PCI link is dangerous and will generally cause a checkstop.
As such, we want to do this while the PHB is fenced. Conveniently, during a
complete reset we force a PHB fence, so this is a good opportunity to
disable CAPI mode.
When doing a complete reset, if the PHB is in CAPI mode, execute a sequence
of SCOMs to reset PHB-related registers back to their regular, PCIe mode
values.
Signed-off-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
PCI slot pfreset() operation is obsoleted as nobody uses it. This
removes it and the related PCI slot states. No functional changes
introduced.
Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
Acked-by: Russell Currey <ruscur@russell.cc>
Reviewed-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Various backends define their own PCI slot states for flexibility
with numbers [A]. PCI core also defines its PCI slot states [B].
For one specific PCI slot state, the major number of [A] and [B]
should be same so that the corresponding operation can be found.
It means [A] and [B] are relevant to some extent, but the code
where defines the PCI slots in backends doesn't reflect it.
This makes the major PCI slot state defined in backend same to
the corresponding one defined in PCI core. The minor PCI slot
states are made to be incremental to their base number (major
PCI slot state). No functional changes introduced.
Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
Acked-by: Russell Currey <ruscur@russell.cc>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
The patch refactors functions used for PHB slot management for
PHB3. Also, PHB slots are created before platform's PHB setup
hook (platform.pci_setup_phb()). That means the platforms can
override the properties or methods of the PHB slot if necessary.
Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
Reviewed-by: Russell Currey <ruscur@russell.cc>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
This removes the useless comments as the I2C based power managment
is covered by this series of patches and the left items in the FIXUP
aren't needed any more.
Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
Reviewed-by: Russell Currey <ruscur@russell.cc>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
All kinds of PHBs are maintaining a spinlock. At mean while, the
spinlock is acquired or released by backends for phb_ops->lock()
or phb_ops->unlock(). There're no difference of the logic on all
kinds of PHBs. So it's reasonable to maintain the lock in the
generic layer (struct phb).
This moves lock from specific PHB to generic one. The spinlock is
initialized when the generic PHB is registered in pci_register_phb().
Also, two inline functions phb_{lock, unlock}() are introduced to
acquire/release it. No logical changes introduced.
Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Venice and Murano have only one capp unit, that can be mapped to phb0,
phb1 or phb2. Naples has two capp units, that are statically mapped,
capp unit 0 on phb0 and capp unit 1 on phb1. The capp ucode must be
loaded once onto each capp unit.
This patch replaces the boolean chip->capp_ucode_loaded by a bitmap,
and sets the bit corresponding to the phb index to indicate that ucode
has been loaded. The macro CAPP_UCODE_LOADED(chip, phb) returns the value
of the phb index bit.
The xscom register addresses of capp unit 0 are identical to the register
addresses of the single capp unit of Venice and Murano. The addresses of
the Naples capp unit 1 are equal to the addresses of capp unit 0 + 0x180.
This patch introduces the macro PHB3_CAPP_REG_OFFSET(p), that returns the
following xscom register address offsets:
0x0 for the Venice capp unit
0x0 for the Murano capp unit
0x0 for Naples capp unit 0
0x180 for Naples capp unit 1
The offset is added to the register address at each xscom_write, in order
to operate on the right capp unit.
Signed-off-by: Philippe Bergheaud <felix@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Interrupts on P8 are currently hard-coded using macros in
include/interrupts.h. The new P8NVL processor has an extra PHB meaning
it supports 4 PHBs in total which leads to the following assert fail
when booting P8NVL based systems:
[6614913194,3] register IRQ source overlap !
[6620562844,3] new: 2000..27f7 old: 2000..27f7
[6870377440,0] Assert fail: core/interrupts.c:67:0
This patch converts the existing macros to function calls so that
different platforms can support extra PHBs at the expense of a reduced
maximum number of chips.
Signed-off-by: Alistair Popple <alistair@popple.id.au>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
When issuing fundamental reset on below IPR adapter that seats
behind root complex, there is 50% possibility that the link
fails to come up after the reset. In that case, the adapter's
config space is blocked and it's not usable.
host# lspci -ns 0004:01:00.0
0004:01:00.0 0104: 1014:034a (rev 01)
host# lspci -s 0004:01:00.0
0004:01:00.0 RAID bus controller: IBM PCI-E IPR SAS Adapter
(ASIC) (rev 01)
This introduces another PHB3 state (PHB3_STATE_FRESET_START)
allowing to redo fundamental reset if the link doesn't come up
in time at the first attempt, to improve the robustness of PHB's
fundamental reset. If the link comes up after the first reset,
the 2nd reset won't be issued at all.
Reported-by: Paul Nguyen <nguyenp@us.ibm.com>
Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Nobody is using it except calculating the RTE table size. The
patch removes it.
Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Currently, we have reserved PE#0 to which all RIDs are mapped prior
to PE assignment request from kernel. The last M64 BAR is configured
to have shared mode. So we have to cut off the first M64 segment,
which corresponds to reserved PE#0 in kernel. If the first BAR
(for example PF's IOV BAR) requires huge alignment in kernel, we
have to waste huge M64 space to accomodate the alignment. If we
have reserved PE#256, the waste of M64 space will be avoided.
Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
We have problem with some Mellanox cards
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
|
|
The presence detect bit in the standard root complex config space is
not properly implemented on some IBM PHBs. Using it during probe is
incorrect.
We already have a workaround using the hotplug override "AB" detect
bits in the PHB3 code but it somewhat relies on the standard presence
detect bit returning false positives, which happened on Venice/Murano
but no longer happens in Naples.
Similarly, all the slot control stuff in the generic pci_enable_bridge()
isn't going to work properly on the PHB root complex and is unnecessary
as this code is only called after the upper layers have verified the
presence of a valid link on the PHB (the slot power control for the PHB
is handled separately).
This fixes it all by removing the AB detect flag, and unconditionally
using those bits in PHB3 presence detect along with making sure the
code in pci_enable_bridge() that manipulates the slot controls is
only executed on downstream ports.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
This detects the new PHB revision and does the appropriate updates
to the init sequence.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
This reworks the CAPP microcode flash download and CAPP upload.
We now use load_resource() to download microcode from flash rather than
assuming we are on an FSP. This means we can download the microcode on PNOR
based systems.
Also, currently the code associates the microcode upload with the PHB. This
means we store one copy of the microcode for every PHB in the system. This
patch changes this so that we only save one copy of the microcode for the whole
system. We mark if the microcode as been uploaded in the CAPP unit based on
the chip, rather than the PHB. We add a check in case the system has two
different chip ECs in the one system but such a Frankenmachine should never be
built!
We keep the microcode around in case we need it for a recovery event.
It also harmonises the CAPP printks to look the same.
Signed-off-by: Michael Neuling <mikey@neuling.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Add a flag indicating the CAPP unit is in recovery. When a capp recoverable
malfunction HMI comes in, the HMI handler will call into
phb3_set_capp_recovery, which will put set the flag and send the event to
Linux.
EEH will call phb3_next_error which will tell it the phb is fenced.
EEH will then call into sapphire to reinitialize the phb which contains steps
3-5 of capp recovery procedure. The code increases wait time of PERST to 1s to
ensure fpga download is complete before polling linkup.
EEH will then rebind the cxl driver and it will complete recovery once it
initializes and turns snoops on, steps 7-8, completing capp recovery procedure.
Signed-off-by: Ryan Grimm <grimm@linux.vnet.ibm.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
|
|
The complete reset could be issued by kdump kernel to remove pending
PCI traffic in order to avoid EEH errors in kdump scenario. However,
the bus numbers configured into PCI bridges would be lost after the
reset and it would cause that some of PCI devices (e.g. IPR) can't
be probed by kdump kernel successfully.
The patch fixes above issue by restoring bus numbers after complete
reset. It's responsing to bug#113210
Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
|
|
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
|
