| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The PCI-PCI bridge spec says that bridges that implement an IO window
should hardcode the IO base and limit registers to zero.
Unfortunately, these registers only define the upper bits of the IO
window and the low bits are assumed to be 0 for the base and 1 for the
limit address. As a result, setting both to zero can be mis-interpreted
as a 4K IO window.
This patch fixes the problem the same way PHB3 does. It sets the IO base
and limit values to 0xf000 and 0x1000 respectively which most software
interprets as a disabled window.
lspci before patch:
0000:00:00.0 PCI bridge: IBM Device 04c1 (prog-if 00 [Normal decode])
I/O behind bridge: 00000000-00000fff
lspci after patch:
0000:00:00.0 PCI bridge: IBM Device 04c1 (prog-if 00 [Normal decode])
I/O behind bridge: None
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
| |
The delay between the ASSERT_DELAY and DEASSERT_DELAY states is set to
one timebase tick. This state seems to have been a hold over from PHB3
where it was used to add a 1s delay between de-asserting PERST and
polling the link for the CAPI FPGA. There's no requirement for that here
since the link polling on PHB4 is a bit smarter so we should be fine.
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Some time ago Mikey added some code work around a bug we found where a
certain RAID card wouldn't come back again after a fast-reboot. The
workaround is setting the Link Disable bit before asserting PERST and
clear it after de-asserting PERST.
Currently we do this in the FRESET path, but not in the CRESET path.
This patch moves the PERST control into its own function to reduce
duplication and to the workaround is applied in all circumstances.
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When we do an freset the first step is to check if a card is present in
the slot. However, this only occurs when we enter phb4_freset() with the
slot state set to SLOT_NORMAL. This occurs in:
a) The creset path, and
b) When the OS manually requests an FRESET via an OPAL call.
a) is problematic because in the boot path the generic code will put the
slot into FRESET_START manually before calling into phb4_freset(). This
can result in a situation where a device is detected on boot, but not
after a CRESET.
I've noticed this occurring on systems where the PHB's slot presence
detect signal is not wired to an adapter. In this situation we can rely
on the in-band presence mechanism, but the presence check will make
us exit before that has a chance to work.
Additionally, if we enter from the CRESET path this early exit leaves
the slot's PERST signal being left asserted. This isn't currently an issue,
but if we want to support hotplug of devices into the root port it will
be.
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
PERST is asserted at the beginning of the CRESET process to prevent
the downstream device from interacting with the host while the PHB logic
is being reset and re-initialised. There is at least a 100ms wait during
the CRESET processing so it's not necessary to wait this time again
in the FRESET handler.
This patch extends the delay after re-setting the PHB logic to extend
to the 250ms PERST wait period that we typically use and sets the
skip_perst flag so that we don't wait this time again in the FRESET
handler.
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
|
|
|
|
|
|
|
|
| |
The hub-id is stored in the PBCQ node rather than the stack node so we
never add it to the PHB node. This breaks the lxvpd slot lookup code
since the hub-id is encoded in the VPD record that we need to find the
slot information.
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
|
|
|
|
|
| |
Come on bridge control register. You're letting the team down.
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
repeatedly failed
Certain older PCIe 1.0 devices will not train unless the training process starts at GEN1 speeds.
As a last resort when a device will not train, fall back to GEN1 speed for the last training attempt.
This is verified to fix devices based on the Conexant CX23888 on the Talos II platform.
Signed-off-by: Timothy Pearson <tpearson@raptorengineering.com>
[stewart: cut P9NDD1.0 support, fixup dt_max_link_speed]
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The OPAL_PCI_EEH_FREEZE_STATUS call takes a bunch of parameters, one of
them is @phb_status. It is defined as __be64* and always NULL in
the current Linux upstream but if anyone ever decides to read that status,
then the PHB3's handler will assume it is struct OpalIoPhb3ErrorData*
(which is a lot bigger than 8 bytes) and zero it causing the stack
corruption; p7ioc-phb has the same issue.
This removes @phb_status from all eeh_freeze_status() hooks and moves
the error message from PHB4 to the affected OPAL handlers.
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Reviewed-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
Reviewed-By: Oliver O'Halloran <oohall@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I now know what an IODA cache is and I'm not happy about it. With
the power of Comments™ you too can share the misery.
Remove the big WARNING about the P8 specific hardware bug while
we're here. That seems to have been copied over from phb3.c and
no one thought about it too hard.
Reviewed-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
|
|
|
|
|
|
|
|
| |
The PELT-V is also an in-memory table and there is no reason to have two
copies of it. Removing the cache shaves another 128KB off the size of
each struct phb4.
Reviewed-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In ancient times we added a caches to struct phb3 for some of the IODA
tables which can only be accessed in-directly via XSCOM. A cache for the
Requester Translation Table (RTT) was also added even though this is an
in-memory table. This was carried over to PHB4 when Ben did the initial
copy and paste, but it's still largely pointless.
There's no real need to have a second copy of the table. This patch
removes the "cache" and changes all the users to reference the RTT
directly if we need to. This reduces the size of the struct phb4 by
128KB.
Reviewed-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
|
|
|
|
|
|
|
|
| |
When we allocate the various in-memory tables we assert() on the
allocation. There's no point in checking if the table pointer is NULL
or not at runtime.
Reviewed-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
|
|
|
|
|
|
|
|
| |
General cleanup. For a function that does nothing more than a
mask-and-compare the current implementation is way more convoluted
than it has any right to be.
Reviewed-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
|
|
|
|
|
|
| |
This is not a shipping product and is no longer supported by Linux
or other firmware components.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
|
|
|
| |
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
|
|
| |
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
While disabling CAPP an HMI gets triggered as soon as ETU is put in
reset mode. This is caused as before we can disabled CAPP, it detects
PHB link going down and triggers an HMI requesting Opal to perform
CAPP recovery. This has an un-intended side effect of spamming the
Opal logs with malfunction alert messages and may also confuse the
user.
To prevent this we mask the CAPP FIR error 'PHB Link Down' Bit(31)
when we are disabling CAPP just before we put ETU in reset in
phb4_creset(). Also now since bringing down the PHB link now wont
trigger an HMI and CAPP recovery, hence we manually set the
PHB4_CAPP_RECOVERY flag on the phb to force recovery during creset.
Reviewed-by: Frederic Barrat <fbarrat@linux.ibm.com>
Reviewed-by: Christophe Lombard <clombard@linux.vnet.ibm.com>
Reviewed-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
Signed-off-by: Vaibhav Jain <vaibhav@linux.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We implement h/w sequence to disable CAPP in disable_capi_mode() and
with it also enable fast-reset for CAPI mode in phb4_set_capi_mode().
Sequence to disable CAPP is executed in three phases. The first two
phase is implemented in disable_capi_mode() where we reset the CAPP
registers followed by PEC registers to their init values. The final
third final phase is to reset the PHB CAPI Compare/Mask Register and
is done in phb4_init_ioda3(). The reason to move the PHB reset to
phb4_init_ioda3() is because by the time Opal PCI reset state machine
reaches this function the PHB is already un-fenced and its
configuration registers accessible via mmio.
Reviewed-by: Frederic Barrat <fbarrat@linux.ibm.com>
Reviewed-by: Christophe Lombard <clombard@linux.vnet.ibm.com>
Reviewed-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
Signed-off-by: Vaibhav Jain <vaibhav@linux.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch introduces a PHB4 flag PHB4_CAPP_DISABLE and scaffolding
necessary to handle it during CRESET flow. The flag is set when CAPP
is request to switch to PCIe mode via call to phb4_set_capi_mode()
with mode OPAL_PHB_CAPI_MODE_PCIE. This starts the below sequence that
ultimately ends in newly introduced phb4_slot_sm_run_completed()
1. Set PHB4_CAPP_DISABLE to phb4->flags.
2. Start a CRESET on the phb slot. This also starts the opal pci reset
state machine.
3. Wait for slot state to be PHB4_SLOT_CRESET_WAIT_CQ.
4. Perform CAPP recovery as PHB is still fenced, by calling
do_capp_recovery_scoms().
5. Call newly introduced 'disable_capi_mode()' to disable CAPP.
6. Wait for slot reset to complete while it transitions to
PHB4_SLOT_FRESET and optionally to PHB4_SLOT_LINK_START.
7. Once slot reset is complete opal pci-core state machine will call
slot->ops.completed_sm_run().
8. For PHB4 this branches newly introduced 'phb4_slot_sm_run_completed()'.
9. Inside this function we mark the CAPP as disabled and un-register
the opal syncer phb4_host_sync_reset().
10. Optionally if the slot reset was unsuccessful disable
fast-reboot.
****************************
Notes:
****************************
a. Function 'disable_capi_mode()' performs various sanity tests on CAPP to
to determine if its ok to disable it and perform necessary xscoms
to disable it. However the current implementation proposed in this
patch is a skeleton one that just does sanity tests. A followup patch
will be proposed that implements the xscoms necessary to disable CAPP.
b. The sequence expects that Opal PCI reset state machine makes
forward progress hence needs someone to call slot->ops.run_sm(). This
can be either from phb4_host_sync_reset() or opal_pci_poll().
Reviewed-by: Frederic Barrat <fbarrat@linux.ibm.com>
Reviewed-by: Christophe Lombard <clombard@linux.vnet.ibm.com>
Reviewed-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
Signed-off-by: Vaibhav Jain <vaibhav@linux.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch introduces a new opal syncer for PHB4 named
phb4_host_sync_reset(). We register this opal syncer when CAPP is
activated successfully in phb4_set_capi_mode() so that it will be
called at kernel shutdown during fast-reset.
During kernel shutdown the function will then repeatedly call
phb->ops->set_capi_mode() to switch switch CAPP to PCIe mode. In case
set_capi_mode() indicates its OPAL_BUSY, which indicates that CAPP is
still transitioning to new state; it calls slot->ops.run_sm() to
ensure that Opal slot reset state machine makes forward progress.
Reviewed-by: Frederic Barrat <fbarrat@linux.ibm.com>
Reviewed-by: Christophe Lombard <clombard@linux.vnet.ibm.com>
Signed-off-by: Vaibhav Jain <vaibhav@linux.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Presently phb4_set_capi_mode() performs certain CAPP checks
like, checking of CAPP ucode loaded or checks if CAPP is still in
recovery, even when the requested mode is to switch to PCI mode.
Hence this patch updates and re-factors phb4_set_capi_mode() to make
sure CAPP related checks are only performed when request to enable
CAPP is made by mode==OPAL_PHB_CAPI_MODE_CAPI/DMA_TVT1. We also update
other possible modes requests to return a more appropriate status code
based on if CAPP is activated or not.
Reviewed-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
Reviewed-by: Christophe Lombard <clombard@linux.vnet.ibm.com>
Signed-off-by: Vaibhav Jain <vaibhav@linux.ibm.com>
Reviewed-by: Frederic Barrat <fbarrat@linux.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously struct proc_chip member 'capp_phb3_attached_mask' was used
for Power-8 to keep track of PHB attached to the single CAPP on the
chip. CAPP on that chip supported a flexible PHB assignment
scheme. However since then new chips only support a static assignment
i.e a CAPP can only be attached to a specific PEC.
Hence instead of using 'proc_chip.capp_phb4_attached_mask' to manage
CAPP <-> PEC assignments which needs a global lock (capi_lock) to be
updated, we introduce a new struct named 'capp' a pointer to which
resides inside struct 'phb4'. Since updates to struct 'phb4' already
happen in context of phb_lock; this eliminates the
need to use mutex 'capi_lock' while updating
'capp_phb4_attached_mask'.
This struct is also used to hold CAPP specific variables such as
pointer to the 'struct phb' to which the CAPP is attached,
'capp_xscom_offset' which is the xscom offset to be added to CAPP
registers in case there are more than 1 on the chip, 'capp_index'
which is the index of the CAPP on the chip, and attached_pe' which is
the process endpoint index to which CAPP is attached. Finally member
'chip_id' holds the chip-id thats used for performing xscom
read/writes.
Also new helpers named capp_xscom_read()/write() are introduced to
make access to CAPP xscom registers easier.
Signed-off-by: Vaibhav Jain <vaibhav@linux.ibm.com>
Reviewed-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
Reviewed-by: Christophe Lombard <clombard@linux.vnet.ibm.com>
Reviewed-by: Frederic Barrat <fbarrat@linux.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
During CAPP recovery do_capp_recovery_scoms() will reset the CAPP Fir
register just after CAPP recovery is completed. This has an
unintentional side effect of preventing PRD from analyzing and
reporting this error. If PRD tries to read the CAPP FIR after opal has
already reset it, then it logs a critical error complaining "No active
error bits found".
To prevent this from happening we update do_capp_recovery_scoms() to
only reset fir bits that cause CAPP machine check (local xstop). This
is done by reading the CAPP Fir Action0/1 & Mask registers and
generating a mask which is then written on CAPP_FIR_CLEAR register.
Cc: stable
Signed-off-by: Vaibhav Jain <vaibhav@linux.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Some PHB4 PHYs can get stuck in a bad state where they are constantly
retraining the link. This happens transparently to skiboot and Linux
but will causes PCIe to be slow. Resetting the PHB4 clears the
problem.
We can detect this case by looking at the RX errors count where we
check for link stability. This patch does this by modifying the link
optimal code to check for RX errors. If errors are occurring we
retrain the link irrespective of the chip rev or card.
Normally when this problem occurs, the RX error count is maxed out at
255. When there is no problem, the count is 0. We chose 8 as the max
rx errors value to give us some margin for a few errors. There is also
a knob that can be used to set the error threshold for when we should
retrain the link. ie
nvram -p ibm,skiboot --update-config phb-rx-err-max=8
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
Signed-off-by: Michael Neuling <mikey@neuling.org>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Presently phb4_probe_stack() will always enable PHB MMIO0/1 windows
even if they doesn't exist in phy_map. Hence we do some minor shuffling
in the phb4_probe_stack() so that MMIO-0/1 Bars are only enabled if
there corresponding MMIO window exists in the phy_map. In case phy_map
for an mmio window is '0' we set the corresponding BAR register to
'0'.
Signed-off-by: Vaibhav Jain <vaibhav@linux.ibm.com>
Reviewed-by: Oliver O'Halloran <oohall@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently on a FSP based P9 system load_capp_code() expects CAPP ucode
lid header to have eye-catcher magic of 'CAPPPSLL'. However skiboot
currently supports CAPP ucode only lids that have a eye-catcher magic
of 'CAPPLIDH'. This prevents skiboot from loading the ucode with this
error message:
CAPP: ucode header invalid
We fix this issue by updating load_capp_ucode() to use the eye-catcher
value of 'CAPPLIDH' instead of 'CAPPPSLL'.
Cc: stable
Fixes: e50764d4f2b1("capi: Load capp microcode")
Signed-off-by: Vaibhav Jain <vaibhav@linux.ibm.com>
Acked-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
Reviewed-by: Christophe Lombard <clombard@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Update phb4_init_capp_regs() to allocates STQ Engines to CAPP/PEC2
based on link width instead of always assuming it to x8.
Also re-factor the function slightly to evaluate the link-width only
once and cache it so that it can also be used to allocate DMA read
engines.
Cc: stable
Fixes: 47c09cdfe7a3("phb4/capp: Calculate STQ/DMA read engines based on link-width for PEC")
Signed-off-by: Vaibhav Jain <vaibhav@linux.ibm.com>
Reviewed-by: Frederic Barrat <fbarrat@linux.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On DD2.0 parts, PCIe ECC protection is not warranted in the response
data path. Thus, for these parts, we need to flag any ECC errors
detected from the adjacent AIB RX Data path so the part can be
replaced.
This patch configures the FIRs so that we escalate these AIB ECC
errors to a checkstop so the parts can be replaced.
Signed-off-by: Michael Neuling <mikey@neuling.org>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
| |
Couple of places in 'phb4.c' where we may want to dump the PEC's error
registers. Hence we introduce a phb4_dump_pec_err_regs() that dumps
all the PEC error registers and also update phb4->nfir_cache &
phb4->pfir_cache for later use.
Signed-off-by: Vaibhav Jain <vaibhav@linux.ibm.com>
Reviewed-by: Oliver O'Halloran <oohall@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
During fast-reboot new PEC errors can be latched even after ETU-Reset
is asserted. This will result in values of variables nfir_cache and
pfir_cache to be out of sync.
During step-2 of CRESET nfir_cache and pfir_cache values are used to
bring the PHB out of reset state. However if these variables are out
as noted above of date the nfir/pfir registers are never reset
completely and ETU still remains frozen.
Hence this patch updates step-2 of phb4_creset to re-read the values of
nfir/pfir registers to check if any new errors were reported after
ETU-reset was asserted, report these new errors and reset the
nfir/pfir registers. This should bring the ETU out of reset
successfully.
Signed-off-by: Vaibhav Jain <vaibhav@linux.ibm.com>
Tested-By: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Reviewed-by: Oliver O'Halloran <oohall@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In this commit
commit 737c0ba3d72b8aab05a765a9fc111a48faac0f75
Author: Michael Neuling <mikey@neuling.org>
Date: Thu Feb 22 10:52:18 2018 +1100
phb4: Disable lane eq when retrying some nvidia GEN3 devices
We made a typo and set PH2 twice. This fixes it.
It worked previously as if only phase 2 (PH2) is set it, skips phase 2
and phase 3 (PH3).
Reported-by: Meng Li <shlimeng@cn.ibm.com>
Signed-off-by: Michael Neuling <mikey@neuling.org>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Presently phb4_probe_stack() causes an exception while trying to probe
a PHB if its garded. This causes skiboot to go into a reboot loop with
following exception log:
***********************************************
Fatal MCE at 000000003006ecd4 .probe_phb4+0x570
CFAR : 00000000300b98a0
<snip>
Aborting!
CPU 0018 Backtrace:
S: 0000000031cc37e0 R: 000000003001a51c ._abort+0x4c
S: 0000000031cc3860 R: 0000000030028170 .exception_entry+0x180
S: 0000000031cc3a40 R: 0000000000001f10 *
S: 0000000031cc3c20 R: 000000003006ecb0 .probe_phb4+0x54c
S: 0000000031cc3e30 R: 0000000030014ca4 .main_cpu_entry+0x5b0
S: 0000000031cc3f00 R: 0000000030002700 boot_entry+0x1b8
This is caused as phb4_probe_stack() will ignore all xscom read/write
errors to enable PHB Bars and then tries to perform an mmio to read
PHB Version registers that cause the fatal MCE.
We fix this by ignoring the PHB probe if the first xscom_write() to
populate the PHB Bar register fails, which indicates that there is
something wrong with the PHB.
Cc: stable
Fixes: dc21b4db3a2e('hw/phb4: Add initial support')
Reviewed-by: Oliver O'Halloran <oohall@gmail.com>
Signed-off-by: Vaibhav Jain <vaibhav@linux.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If the PHB encounters a UR or CA status on a CFG write, it will
incorrectly freeze the wrong PE. Instead of using the PE# specified
in the CONFIG_ADDRESS register, it will use the PE# of whatever
MMIO occurred last.
Work around this disabling freeze on such errors
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Tested-By: Oliver O'Halloran <oohall@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
|
|
| |
If the zalloc fails (and it can be a rather large allocation),
we will overwite memory at 0 instead of failing.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In a POWER9 chip, some PHB4s have 256 PEs, some have 512.
Currently, the diagnostics code retrieves 512 unconditionally,
which is wrong and causes us to incorrectly report bogus values
for the "high" PEs on the small PHBs.
Use the actual number of implemented PEs instead
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If a capi device does a DMA write targeting an address lower than 4GB,
it does so through a 32-bit operation, per the PCI spec. In capi mode,
the first TVE entry is configured in bypass mode, so the address is
valid. But with any (bad) luck, the address could be 0xFFFFxxxx, thus
looking like a 32-bit MSI.
We currently enable both 32-bit and 64-bit MSIs, so the PHB will
interpret the DMA write as a MSI, which very likely results in an EEH
(MSI with a bad payload size).
We can fix it by disabling 32-bit MSI when switching the PHB to capi
mode. Capi devices are 64-bit.
Cc: stable
Signed-off-by: Frederic Barrat <fbarrat@linux.ibm.com>
Reviewed-by: Christophe Lombard <clombard@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The current capp recovery timeout control loop in
do_capp_recovery_scoms() uses a wrong comparison for return value of
tb_compare(). This may cause do_capp_recovery_scoms() to report an
timeout earlier than the 168ms stipulated time.
The patch fixes this by updating the loop timeout control branch in
do_capp_recovery_scoms() to use the correct enum tb_cmpval.
Cc: Stable #6.0+
Fixes: 09b853cae0aa0("capi: Poll Err/Status register during CAPP
recovery")
Reported-by: Frederic Barrat <fbarrat@linux.vnet.ibm.com>
Signed-off-by: Vaibhav Jain <vaibhav@linux.ibm.com>
Reviewed-by: Frederic Barrat <fbarrat@linux.vnet.ibm.com>
Reviewed-by: Christophe Lombard <clombard@linux.vnet.ibm.com>
Reviewed-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Commit 47c09cdfe7a3("phb4/capp: Calculate STQ/DMA read engines based
on link-width for PEC") update the CAPP init sequence by calculating
the needed STQ/DMA-read engines based on link width and populating it
in XPEC_NEST_CAPP_CNTL register. This however needs to be synchronized
with the value set in CAPP APC FSM Read Machine Mask Register.
Hence this patch update phb4_init_capp_regs() to calculate the link
width of the stack on PEC2 and populate the same values as previously
populated in PEC CAPP_CNTL register.
Cc: stable # v5.7+
Fixes: 47c09cdfe7a3("phb4/capp: Calculate STQ/DMA read engines based on link-width for PEC")
Signed-off-by: Vaibhav Jain <vaibhav@linux.ibm.com>
Reviewed-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
Reviewed-by: Frederic Barrat <fbarrat@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
| |
phb4_get_diag_data() checks the flags for the PHB4_AIB_FENCED after
having called phb4_fenced(). This information is returned by
phb4_fenced().
This patch was prompted by an unused return value warning in Coverity.
Fixes: CID 163734
Signed-off-by: Cyril Bur <cyril.bur@au1.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
| |
Knowing the PEC index is going to be important when we enable relaxed
ordering, so store this value for later use.
Signed-off-by: Alistair Popple <alistair@popple.id.au>
[arbab@linux.ibm.com: Rebase/refactor original changes]
Signed-off-by: Reza Arbab <arbab@linux.ibm.com>
Reviewed-By: Alistair Popple <alistair@popple.id.au>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Struct phb4 is fairly heavyweight at 283664 bytes. On systems with
6x PHBs per socket this results in using 3.2MB of heap space the PHB
structures alone. This is a fairly large chunk of our 12MB heap and
on systems with particularly large PCIe topologies, or additional
PHBs we can fail to boot because we cannot allocate space for the
FDT blob.
This patch switches to using local_alloc() for the PHB structures
so they don't consume too large a portion of our 12MB heap space.
Signed-off-by: Ryan Grimm <grimm@linux.vnet.ibm.com>
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
|
|
|
|
|
|
| |
Remove the phb4.c-specific CFLAGS that disable the unused value and unused
parameter warnings, and cleanup the ensuing warnings.
Signed-off-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
| |
The IODA tables are stored inside the PHB itself rather than in memory.
This makes accessing them slightly tedious, but the process is more or
less the same for every table. This patch adds a helper function for
dumping the contents of the IODA tables to help with debugging PHB
issues.
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
| |
The "Partitionable Endpoint Lookup Table (Vector)" is used by the PHB
when processing EEH events. The PELT-V defines which PEs should be
additionally frozen in the event of an error being flagged on a
given PE. Knowing the state of the PELT-V is sometimes useful for
debugging PHB issues so this patch adds a helper to dump it.
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
|
|
|
|
|
|
|
|
| |
Linux always displays the PE number in hexidecimal while skiboot
displays the PEST index (PE number) in decimal. This makes correlating
errors between Skiboot and Linux more annoying than it should be so
this patch makes Skiboot print the PEST number in hex.
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We reallocate additional 16/8 DMA-Read engines allocated to stack0/1
on PEC2 respectively. This is needed to improve bandwidth available to
the Mellanox CX5 adapter when trying to read GPU memory (GPU-Direct).
If kernel cxl driver indicates a request to allocate maximum possible
DMA read engines when calling enable_capi_mode() and card is attached
to PEC2/stack0 slot then we assume its a Mellanox CX5 adapter. We then
allocate additional 16/8 extra DMA read engines to stack0 and stack1
respectively on PEC2. This is done by populating the
XPEC_PCI_PRDSTKOVR and XPEC_NEST_READ_STACK_OVERRIDE as suggested by
the h/w team.
Signed-off-by: Christophe Lombard <clombard@linux.vnet.ibm.com>
Signed-off-by: Vaibhav Jain <vaibhav@linux.ibm.com>
Reviewed-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
By default when a PCIe device issues a read request via the PHB it is first
issued with nodal scope. When accessing GPU memory the NPU does not know at the
time of response if the requested memory page is off node or not. Therefore
every read of GPU memory by a PHB is retried with larger scope which introduces
bandwidth and latency issues.
On smaller boxes which have pump mode enabled nodal and group scoped reads are
treated the same and both types of request are broadcast to one chip. Therefore
we can avoid the retry by disabling nodal scope on the PHB for these boxes. On
larger boxes nodal (single chip) and group (multiple chip) scoped reads are
treated differently. Therefore we avoid disabling nodal scope on large boxes
which have pump mode disabled to avoid all PHB requests being broadcast to
multiple chips.
Signed-off-by: Alistair Popple <alistair@popple.id.au>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
With the current code, the capi mmio window is not correctly configured
in the IODA table entry. The first entry (generally the non-prefetchable
BAR) is overwrriten.
This patch sets the capi window bar at the right place.
Signed-off-by: Christophe Lombard <clombard@linux.vnet.ibm.com>
Reviewed-by: Vaibhav Jain <vaibhav@linux.ibm.com>
Reviewed-by: Frederic Barrat <fbarrat@linux.vnet.ibm.com>
Acked-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Presently in CAPI mode the number of STQ/DMA-read engines allocated on
PEC2 for CAPP is fixed to 6 and 0-30 respectively irrespective of the
PCI link width. These values are only suitable for x8 cards and
quickly run out if a x16 card is plugged to a PEC2 attached slot. This
usually manifests as CAPP reporting TLBI timeout due to these messages
getting stalled due to insufficient STQs.
To fix this we update enable_capi_mode() to check if PEC2 chiplet is
in x16 mode and if yes then we allocate 4/0-47 STQ/DMA-read engines
for the CAPP traffic.
Cc: stable # v5.7+
Fixes: 37ea3cfdc852("capi: Enable capi mode for PHB4")
Reviewed-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
Signed-off-by: Vaibhav Jain <vaibhav@linux.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|