| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
I'm going to defer training to this state soon, so move the tracing
first.
Signed-off-by: Michael Neuling <mikey@neuling.org>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
We want to get through this as fast as possible so minimise by
removing msecs_to_tb() call. Changes number passed from 512 -> 1.
Signed-off-by: Michael Neuling <mikey@neuling.org>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
The transport control register needs to be loaded in two steps: Once
the register values have been set, we have to write bit 63 to a '1',
which loads the register values into the ci store buffer logic.
Bit 63 always reads back as a zero but to load the ci store buffer
values in capp the transition of 0 to 1 of bit 63 must be seen.
A new comment is added in the code to avoid confusion and to precise
the feature of this register.
Signed-off-by: Christophe Lombard <clombard@linux.vnet.ibm.com>
Reviewed-by: Frederic Barrat <fbarrat@linux.vnet.ibm.com>
Reviewed-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
Acked-by: Vaibhav Jain <vaibhav@linux.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
Without the WOF registers it's hard to figure out what went wrong first,
so print those when we print the FIRs when a fence is detected.
Suggested-by: Mike Perez <perezma@us.ibm.com>
Signed-off-by: Russell Currey <ruscur@russell.cc>
Reviewed-by: Vaibhav Jain <vaibhav@linux.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
CFG Write Request Timeout was incorrectly set to informational and not
fatal for both non-CAPI and CAPI, so set it to fatal. This was a
mistake in the specification. Correcting this fixes a niche bug in
escalation (which is necessary on pre-DD2.2) that can cause a checkstop
due to a NCU timeout.
In addition, set the values in the timeout control registers to match.
This fixes an extremely rare and unreproducible bug, though the current
timings don't make sense since they're higher than the NCU timeout (16)
which will checkstop the machine anyway.
Signed-off-by: Russell Currey <ruscur@russell.cc>
Reviewed-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com> # CAPI
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
Currently we restore PCIe bus numbers right after the link is
up. Unfortunately as this point we haven't done CRS so config space
may not be accessible.
This moves the bus number restore till after CRS has happened.
Signed-off-by: Michael Neuling <mikey@neuling.org>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
Enables reporting of slot status information, etc in the config space of
the root complex. Currently this is only used to set the slot power
limit in our generic PCI code, but we might use it for other things
later on.
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
Deprecate the old "opal-interrupts", it's still there, but the new
property follows the standard and allow us to specify whether an
interrupt is level or edge sensitive.
Similarly create "interrupt-names" whose content is identical to
"opal-interrupts-names".
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
When the phb is used as a CAPI interface, the current mmio windows list
is cleaned before adding the capi and the prefetchable memory (M64)
windows, which implies that the non-prefetchable BAR is no more
configured.
This patch allows to set only the mbt bar to pass capi mmio window and
to keep, as defined, the other mmio values (M32 and M64).
Signed-off-by: Christophe Lombard <clombard@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
The cxl driver will set the capi value, like other drivers already do.
Signed-off-by: Philippe Bergheaud <felix@linux.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
This happens normally if a slot doesn't have a working HW presence
detect and relies instead of inband presence detect.
The message we display is scary and not very useful unless ou
are debugging, so quiten it up and change it to something more
meaningful.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Acked-By: Michael Neuling <mikey@neuling.org>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
The ASN indication is used for tunneled operations (as_notify and
atomics). Tunneled operation messages can be sent in PCI mode as
well as CAPI mode.
The address field of as_notify messages is hijacked to encode the
LPID/PID/TID of the target thread, so those messages should not go
through address translation. Therefore bit 59 is part of the ASN
indication.
This patch sets TVT#1 in bypass mode when capi mode is enabled,
to prevent as_notify messages from being dropped.
Signed-off-by: Philippe Bergheaud <felix@linux.ibm.com>
Reviewed-by: Christophe Lombard <clombard@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
Hardware has limitations which would require to put a sync after each
store EOI to make sure the MMIO operations that change the ESB state
are ordered. This is a killer for performance and the PHBs do not
support the sync. So remove the store EOI for the moment, until
hardware is improved.
Also, while we are at changing the XIVE source flags, let's fix the
settings for the PHB4s which should follow these rules :
- SHIFT_BUG for DD10
- STORE_EOI for DD20 and if enabled
- TRIGGER_PAGE for DDx0 and if not STORE_EOI
Signed-off-by: Cédric Le Goater <clg@kaod.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
The function phb4_probe_stack() resets "ETU Reset Register" to
unfreeze the PHB before it performs mmio access on the PHB. However in
case the FIR/NFIR registers are set while entering this function,
the reset of "ETU Reset Register" wont unfreeze the PHB and it will
remain fenced. This leads to failure during initial CRESET of the PHB
as mmio access is still not enabled and an error message of the form
below is logged:
PHB#0000[0:0]: Initializing PHB4...
PHB#0000[0:0]: Default system config: 0xffffffffffffffff
PHB#0000[0:0]: New system config : 0xffffffffffffffff
PHB#0000[0:0]: Initial PHB CRESET is 0xffffffffffffffff
PHB#0000[0:0]: Waiting for DLP PG reset to complete...
<snip>
PHB#0000[0:0]: Timeout waiting for DLP PG reset !
PHB#0000[0:0]: Initialization failed
This is especially seen happening during the MPIPL flow where SBE
would quiesces and fence the PHB so that it doesn't stomp on the main
memory. However when skiboot enters phb4_probe_stack() after MPIPL,
the FIR/NFIR registers are set forcing PHB to re-enter fence after ETU
reset is done.
So to fix this issue the patch introduces new xscom writes to
phb4_probe_stack() to reset the FIR/NFIR registers before performing
ETU reset to enable mmio access to the PHB.
Signed-off-by: Vaibhav Jain <vaibhav@linux.vnet.ibm.com>
Tested-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Reviewed-by: Russell Currey <ruscur@russell.cc>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
This patch updates do_capp_recovery_scoms() to poll the CAPP
Err/Status control register, check for CAPP-Recovery to complete/fail
based on indications of BITS-1,5,9 and then proceed with the
CAPP-Recovery scoms iif recovery completed successfully. This would
prevent cases where we bring-up the PCIe link while recovery sequencer
on CAPP is still busy with casting out cache lines.
In case CAPP-Recovery didn't complete successfully an error is returned
from do_capp_recovery_scoms() asking phb4_creset() to keep the phb4
fenced and mark it as broken.
The loop that implements polling of Err/Status register will also log
an error on the PHB when it continues for more than 168ms which is the
max time to failure for CAPP-Recovery.
Signed-off-by: Vaibhav Jain <vaibhav@linux.vnet.ibm.com>
Reviewed-by: Alastair D'Silva <alastair@d-silva.org>
Acked-by: Christophe Lombard <clombard@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
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>
|
|
This patch updates phb4_set_capi_mode() to disable fast-reboot
whenever enable_capi_mode() is called, irrespective to its return
value. This should prevent against a possibility of not disabling
fast-reboot when some changes to enable_capi_mode() causing return of
an error and leaving CAPP in enabled mode.
Suggested-by: Frederic Barrat <fbarrat@linux.vnet.ibm.com>
Signed-off-by: Vaibhav Jain <vaibhav@linux.vnet.ibm.com>
Reviewed-by: Frederic Barrat <fbarrat@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Presently when we encounter an error while synchronizing capp timebase
with chip-tod at the end of enable_capi_mode() we return an
error. This has an to unintended consequences. First this will prevent
disabling of fast-reboot even though CAPP is already enabled by this
point. Secondly, failure during timebase sync is a non fatal error or
capp initialization as CAPP/PSL can continue working after this and an
AFU will only see an error when it tries to read the timebase value
from PSL.
So this patch updates enable_capi_mode() to not return an error in
case call to chiptod_capp_timebase_sync() fails. The function will now
just log an error and continue further with capp init sequence. This
make the current implementation align with the one in kernel 'cxl'
driver which also assumes the PSL timebase sync errors as non-fatal
init error.
Signed-off-by: Vaibhav Jain <vaibhav@linux.vnet.ibm.com>
Reviewed-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
P9 supports PCI tunneled operations (atomics and as_notify) that are
initiated by devices.
A subset of the tunneled operations require a response, that must be
sent back from the host to the device. For example, an atomic compare
and swap will return the compare status, as swap will only performed
in case of success. Similarly, as_notify reports if the target thread
has been woken up or not, because the operation may fail.
To enable tunneled operations, a device driver must tell the host where
it expects tunneled operation responses, by setting the PBCQ Tunnel BAR
Response register with a specific value within the range of its BARs.
This register is currently initialized by enable_capi_mode(). But, as
tunneled operations may also operate in PCI mode, a new API is required
to set the PBCQ Tunnel BAR Response register, without switching to CAPI
mode.
This patch provides two new OPAL calls to get/set the PBCQ Tunnel
BAR Response register.
Note: as there is only one PBCQ Tunnel BAR register, shared between
all the devices connected to the same PHB, only one of these devices
will be able to use tunneled operations, at any time.
Signed-off-by: Philippe Bergheaud <felix@linux.vnet.ibm.com>
Reviewed-by: Frederic Barrat <fbarrat@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
P9 supports PCI tunneled operations (atomics and as_notify) that require
setting the PHB ASN Compare/Mask register with a 16-bit indication.
This register is currently initialized by enable_capi_mode(). But, as
tunneled operations may also work in PCI mode, the ASN Compare/Mask
register should rather be initialized in phb4_init_ioda3().
This patch also adds "ibm,phb-indications" to the device tree, to tell
Linux the values of CAPI, ASN, and NBW indications, when supported.
Tunneled operations tested by IBM in CAPI mode, by Mellanox Technologies
in PCI mode.
Signed-off-by: Philippe Bergheaud <felix@linux.vnet.ibm.com>
Reviewed-by: Frederic Barrat <fbarrat@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Ref[1] enables fast-reboot by default for POWER9. Presently
fast-reboot for CAPP is not yet supported. Hence this patch disables
fast-reboot in case the CAPP is enabled after reboot until its
support is merged.
References: [1] https://patchwork.ozlabs.org/patch/878879/
Suggested-by: Frederic Barrat <fbarrat@linux.vnet.ibm.com>
Signed-off-by: Vaibhav Jain <vaibhav@linux.vnet.ibm.com>
Acked-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
This fixes these nvidia cards training at only GEN2 spends rather than
GEN3 by disabling PCIe lane equalisation.
Firstly we check if the card is in a whitelist. If it is and the link
has not trained optimally, retry with lane equalisation off. We do
this on all POWER9 chip revisions since this is a device issue, not
a POWER9 chip issue.
Signed-off-by: Michael Neuling <mikey@neuling.org>
Reviewed-by: Russell Currey <ruscur@russell.cc>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Add a new property, "ibm,supported-tce-sizes", to advertise to Linux how
big the available TCE sizes are. Each value is a bit shift, from
smallest to largest.
Signed-off-by: Russell Currey <ruscur@russell.cc>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
The page sizes for TCEs on P9 were inaccurate and just copied from PHB3,
so correct them.
Signed-off-by: Russell Currey <ruscur@russell.cc>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
In order to work around a hardware issue, MMIO load freezes were
escalated to fences on every chip. Now that hardware no longer requires
this, restrict escalation to the chips that actually need it.
Signed-off-by: Russell Currey <ruscur@russell.cc>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
We re-enable channel tag streaming for PHB in CAPP mode as without it
PEC was waiting for cresp for each DMA write command before sending a
new DMA write command on the Powerbus. This resulted in much lower DMA
write performance than expected.
The patch updates enable_capi_mode() to remove the masking of
channel_streaming_en bit in PBCQ Hardware Configuration Register. Also
does some re-factoring of the code that updates this register to use
xscom_write_mask instead of xscom_read followed by a xscom_write.
Cc: stable
Signed-off-by: Vaibhav Jain <vaibhav@linux.vnet.ibm.com>
Reviewed-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
Reviewed-by: Christophe Lombard clombard@linux.vnet.ibm.com
Acked-by: Christophe Lombard <clombard@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Switch to 512KB mode (directory size) as we don’t use bit 48 of the tag
in addressing the array. This mode is controlled by the Snoop CAPI
Configuration Register.
Set the maximum of the number of data polls received before signaling
TLBI hang detect timer expired. The value of '0000' is equal to 16.
Signed-off-by: Christophe Lombard <clombard@linux.vnet.ibm.com>
Reviewed-by: Vaibhav Jain <vaibhav@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
When exercising more than one CAPI accelerators simultaneously in
cache coherency mode, the verification team is seeing a deadlock. To
fix this a workaround of disabling CAPP virtual machines is
suggested. These 'virtual machines' let PSL queue multiple CAPP
commands for servicing by CAPP there by increasing
throughput. Below is the error scenario described by the h/w team:
" With virtual machines enabled we had a deadlock scenario where with 2
or more CAPI's in a system you could get in a deadlock scenario due to
cast-outs that are required break the deadlock (evict lines that
another CAPI is requesting) get stuck in the virtual machine queue by
a command ahead of it that is being retried by the same scenario in
the other CAPI. "
So this patch updates CAPP APC Master Powerbus control
register during CAPP init to also set Bit(12) that disables CAPP
virtual machines. This forces processing of CAPP commands from PSL one
at a time and thereby preventing above mentioned deadlock scenario.
Signed-off-by: Vaibhav Jain <vaibhav@linux.vnet.ibm.com>
Reviewed-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Presently during a CRESET the CAPP recovery sequence can be executed
multiple times in case PBCQ on the PEC is still busy processing in/out
bound inflight transactions.
This patch updates phb4_creset() to perform capp-recovery sequence via
do_capp_recovery_scoms() only when PBCQ General Status Register
reports no pending transactions.
Signed-off-by: Vaibhav Jain <vaibhav@linux.vnet.ibm.com>
Reviewed-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
Reviewed-by: Christophe Lombard clombard@linux.vnet.ibm.com
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
This patch introduces a new function phb4_dump_app_err_regs() that
dumps CAPP error registers in case the PEC nestfir register indicates
that the fence was due to a CAPP error (BIT-24).
Contents of these registers are helpful in diagnosing CAPP
issues. Registers that are dumped in phb4_dump_app_err_regs() are:
* CAPP FIR Register
* CAPP APC Master Error Report Register
* CAPP Snoop Error Report Register
* CAPP Transport Error Report Register
* CAPP TLBI Error Report Register
* CAPP Error Status and Control Register
Signed-off-by: Vaibhav Jain <vaibhav@linux.vnet.ibm.com>
Reviewed-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
Reviewed-by: Christophe Lombard<clombard@linux.vnet.ibm.com>
Acked-by: Russell Currey <ruscur@russell.cc>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Currently we have a mismatch between the NCU and PCI timers for MMIO
accesses. The PCI timers must be lower than the NCU timers otherwise
it may cause checkstops.
This changes PCI timeouts controlled by skiboot to 33-50ms. It should
be forwards and backwards compatible with expected hostboot changes to
the NCU timer.
Signed-off-by: Michael Neuling <mikey@neuling.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Currently our GEN3 lane equalisation settings are set to 0x77. Change
this to 0x54. This change will allow us to train at GEN3 in a shorter
time and more consistently.
This setting gives us a TX preset 0x4 and RX hint 0x5. This gives a
boost in gain for high frequency signaling. It allows the most optimal
continuous time linear equalizers (CTLE) for the remote receiver port
and de-emphasis and pre-shoot for the remote transmitter port.
Machine Readable Workbooks (MRW) are moving to this new value also.
Signed-off-by: Michael Neuling <mikey@neuling.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
These init changes for phb4 from the HW team.
Link down are now endpoint recoverable (ERC) rather than PHB fatal
errors.
BLIF Completion Timeout Error now generate an interrupt rather than
causing freeze events.
Signed-off-by: Michael Neuling <mikey@neuling.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Fix cut and paste from phb3. The sizes have changes now we have GEN4,
so the check here needs to change also
Without this we end up with the default settings (all '7') rather
than what's in HDAT.
Signed-off-by: Michael Neuling <mikey@neuling.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
The M32 BAR is the PHB4 region used to map all the non-prefetchable
or 32-bit device BARs. It's supposed to have its segments remapped
via the MDT and Linux relies on that to assign them individual PE#.
However, we weren't configuring that properly and instead used the
mode where PE# == segment#, thus causing EEH to freeze the wrong
device or PE#.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
A PE number can be up to 9 bits, using a uint8_t won't fly..
That was causing error on config accesses to freeze the
wrong PE.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
New init value from HW folks for the fence enable register.
This clears bit 17 (CFG Write Error CA or UR response) and bit 22 (MMIO Write
DAT_ERR Indication) and sets bit 21 (MMIO CFG Pending Error)
Signed-off-by: Michael Neuling <mikey@neuling.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
We need to acknowledge an eventual HMI initiated by the previous forced
fence on the PHB to work around a non-existent PE in the phb4_creset()
function.
For this reason do_capp_recovery_scoms() is called now at the
beginning of the step: PHB4_SLOT_CRESET_WAIT_CQ
Signed-off-by: Christophe Lombard <clombard@linux.vnet.ibm.com>
Acked-by: Vaibhav Jain <vaibhav@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
The number of read (APC type traffic) and mmio store (MSG type traffic)
resources assigned to the CAPP is controlled by the CAPP control
register.
According to the type of CAPI cards present on the server, we have to
configure differently the CAPP messages and the DMA read engines given
to the CAPP for use.
Signed-off-by: Christophe Lombard <clombard@linux.vnet.ibm.com>
Acked-by: Vaibhav Jain <vaibhav@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Freeze events such as MMIO loads can cause the PHB to lose it's
limited powerbus credits. If all credits are used and a further MMIO
will cause a checkstop.
To work around this, we escalate the troublesome freeze events to a
fence. The fence will cause a full PHB reset which resets the powerbus
credits and avoids the checkstop.
Signed-off-by: Michael Neuling <mikey@neuling.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
We are going to reuse this so move it earlier. No functional change
Signed-off-by: Michael Neuling <mikey@neuling.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
New inits based on next PHB4 workbook. Increases some timeouts to
avoid some spurious error conditions.
Signed-off-by: Michael Neuling <mikey@neuling.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Linux EEH flow is somewhat broken. It saves the PCIe config space of
the PHB on boot, which it then uses to restore on EEH recovery. It
does this to restore MMIO bars and some other pieces.
Unfortunately this save is done before any drivers are bound to
devices under the PHB. A number of other things are configured in the
PHB after drivers start, hence some configuration space settings
aren't saved correctly. These include bus master and MMIO bits in the
command register.
Linux tried to hack around this in this linux commit
bf898ec5cb powerpc/eeh: Enable PCI_COMMAND_MASTER for PCI bridges
This sets the bus master bit but ignores the MMIO bit.
Hence we lose MMIO after a full PHB reset. This causes the next MMIO
access to the device to fail and for us to perform a PE freeze
recovery, which still doesn't set the MMIO bit and hence we still
fail.
This works around this by forcing MMIO on during
phb4_root_port_init().
With this we can recovery from a PHB fence event on POWER9.
Signed-off-by: Michael Neuling <mikey@neuling.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Use phb4_ioda_sel() in phb4_read_phb_status() rather than re-implementing it.
Signed-off-by: Michael Neuling <mikey@neuling.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Log root complex accesses and print BFDN on device access
Signed-off-by: Michael Neuling <mikey@neuling.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
This is old unused code from phb3 so just remove it.
No functional change
Signed-off-by: Michael Neuling <mikey@neuling.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
No functional change.
Signed-off-by: Michael Neuling <mikey@neuling.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
No functional change.
Signed-off-by: Michael Neuling <mikey@neuling.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
If we hit this message we'll retry and fix the problem. If we run out
of retries and can't fix the problem, we'll still print a log message
at error level indicating a problem.
Signed-off-by: Michael Neuling <mikey@neuling.org>
Reported-by: Pridhiviraj Paidipeddi <ppaidipe@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
In this fix:
62ac7631ae phb4: Fix PCIe GEN4 on DD2.1 and above
We fixed DD2.1 GEN4 but broke DD2.00 as GEN3.
This fixes DD2.00 back to GEN3. This time for sure!
Signed-off-by: Michael Neuling <mikey@neuling.org>
Tested-by: Pridhiviraj Paidipeddi <ppaidipe@linux.vnet.ibm.com>
|
