Age | Commit message (Collapse) | Author | Files | Lines |
|
Signed-off-by: Joel Stanley <joel@jms.id.au>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
Reviewed-by: Vaidyanathan Srinivasan <svaidy@linux.vnet.ibm.com>
|
|
Currently the reserved PE is set to NPU_NUM_OF_PES, which is one
greater than the maximum PE resulting in the following kernel errors
at boot:
[ 0.000000] pnv_ioda_reserve_pe: Invalid PE 4 on PHB#4
[ 0.000000] pnv_ioda_reserve_pe: Invalid PE 4 on PHB#5
Due to a HW errata PE#0 is already reserved in the kernel, so update
the opal-reserved-pe device-tree property to match this.
Signed-off-by: Alistair Popple <alistair@popple.id.au>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
We still register dump, but only to in memory console buffer by default.
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
This avoids spamming the logs when the centaur is dead and PRD
constantly tries to access it
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Instead of mapping them to just 3 different codes, define an OPAL
error code for all known HMER error status, as different recovery
path might be needed at the call site, and it allows for more
informative logging.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
In case of error, don't leave the data random. It helps debugging when
the user fails to check the error code. This happens due to a bug in the
PRD wrapper app.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
The bdfn of the emulated/fake nvlink PCIe devices is allocated based
on the topology of GPU connections. Nvlinks going to the same GPU are
allocated to unique functions within the same device number.
In the device-tree every collection of nvlinks going to the same GPU
are given a unique group number which is currently also used as the
device number. To allocate a sequentially unique function number the
code should find the maximum previously allocated function.
However currently the code only checks for a single previously
allocated function number. This works fine on Garrison systems which
only have two links per GPU, but other systems may have more links per
GPU which will result in several links being assigned an identical
function number, resulting boot failure.
Signed-off-by: Alistair Popple <alistair@popple.id.au>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
NPUs have 4 PEs which are zero indexed, so {0, 1, 2, 3}. A bad PE number
check in npu_err_inject checks if the PE number is greater than 4 as a
fail case, so it would wrongly perform operations on a non-existant PE 4.
Reported-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
Cc: stable
Signed-off-by: Russell Currey <ruscur@russell.cc>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
This rmoves the codes for emulated PCI config space as it can be
supported by generic PCI virtual device:
* The PCI virtual device and NPU device are created at same time.
* Uses PCI virtual device and filter to access NPU (PCI) device's
config space.
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 improves PCI config register filter so that it can be reused
by PCI virtual device in subsequent patch:
* First argument to pci_cfg_reg_func() is changed to "void *".
It allows to accept variable data types including PCI virtual
device in future.
* Return value from pci_cfg_reg_func() to be used by PCI virtual
device in future.
* Shortened name of function phb3_pcicfg_filter_rc_pref_window().
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>
|
|
The hardware enforces the buid range is on a 16 irsn boundary
even though there are only 8 irqs. Enforce that here and show
where the value comes from when programming the lsi source id
field in the npu register block.
Signed-off-by: Milton Miller <miltonm@us.ibm.com>
Signed-off-by: Alistair Popple <alistair@popple.id.au>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
The NPU BUID register was incorrectly programmed resulting in npu
interrupt level 0 causing a PB_CENT_CRESP_ADDR_ERROR checkstop,
and irqs from npus in odd chips being aliased to and processed
as the interrupts from the corresponding npu on the even chips.
The documentation for the BUID register is confusing, describing
required values of some bits and bits of differing meaning within
contained within one field.
This patch seperates the per-irq-level irq enable mask from the
documented buid base field, leaving the buid base as the part that
is directly compared. It documents the buid as the boundary of a
block of 16 sources (in the form of a 4 bit shift), and documents
that some bits are sourced from another register and are always
compared to that register, so they are not required to be set in
the base and mask fields.
Fixes: cc61799 Nvlink: Add NPU PHB functions
Signed-off-by: Milton Miller <miltonm@us.ibm.com>
Signed-off-by: Alistair Popple <alistair@popple.id.au>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Throughout skiboot (and the kernel) PE numbers are named "pe_no",
"pe_num" and "pe_number", and sized as 16, 32 and 64bit uints depending
on where you look. This is annoying and potentially misleading in cases
such as the OPAL API, where different calls have different int sizes
even though the PE number they want is the same.
Fix this by making *everything* uint64_t pe_number. In doing this, there
are some whitespace fixes and mve_number gets dragged into this as well
for cases like set_msi_{32/64} where they essentially mean the same thing.
Signed-off-by: Russell Currey <ruscur@russell.cc>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Signed-off-by: Russell Currey <ruscur@russell.cc>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Presently we set timeout value as soon as we add elog to queue. If
we have multiple elogs to write, it doesn't consider queue wait time.
Instead set timeout value when we are actually sending elog to FSP.
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
OPAL gets elog notification from service processor which contains log
information. Once we get notification we start reading log data and
change elog state to ELOG_STATE_FETCHING.
Hence we don't need ELOG_STATE_FETCHED_INFO state. Lets remove this
variable.
Also in some places we have used this state after sending event information
to host. Replace such usage with better state (ELOG_STATE_HOST_INFO).
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
There are chances where another interrupt can wake a CPU in 0x100
vector just when HMI for TOD error is also pending. In such a rare race
condition if CPU has woken up with tb_loss power saving mode, it will
invoke opal call to resync the TB. Since TOD is already in error state,
resync TB will timeout leaving TFMR bit 18 set to '1'. (TFMR[18]=1 means
TB is prepared to receive new value from TOD. Once the new value is
received this bit gets reset to '0', otherwise TB would stay in waiting
state). When HMI is delivered, it may find all TFMR errors are already
cleared but would fail to restore TB since TFMR bit 18 is already set.
This leads to HMI recovery failure causing a kernel crash.
This patch fixes this by clearing of TB errors if TFMR[18] is set to 1.
This makes sure that TB is in clean state before TB restore process starts.
Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
High volume of SYNC errors onto LPC bus cause degraded system
performance and are likely due to bad hardware present onto system.
Thus once LPC SYNC errors cross a certain threshold, OPAL should log
them onto BMC as unrecoverable errors in manufacturing mode. This
will help manufacturing screen bad parts, causing such errors.
Cc: stable
Signed-off-by: Vipin K Parashar <vipin@linux.vnet.ibm.com>
[stewart@linux.vnet.ibm.com: s/mfg/manufacturing/]
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
The capi initialization sequence was revised in a circumvention
document when a 'link down' error was converted from fatal to Endpoint
Recoverable. Other, non-capi, register setup was corrected even before
the initial open-source release of skiboot, but a few capi-related
registers were not updated then, so this patch fixes it.
The point is that a link-down error detected by the UTL logic will
lead to an AIB fence, so that the CAPP unit can detect the error.
Signed-off-by: Frederic Barrat <fbarrat@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Move them to the C code so that rvwinkle_restore() is more generic
and suitable for use for nap mode wakeup as well
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
The patch code itself is unchanged (for now...). Install it during
boot so we will be able to use power management instructions. We
can't just have a proper exception code built at 0x100 as this is
otherwise one of our entry points.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
And add an argument to specify whether to enter nap or rvwinkle
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
If we had XSCOM/FSI errors accessing a centaur, we assert later
on when trying to create it's i2c bus. Don't, just file an error log
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
The checks validate pointers sent in using
opal_addr_valid() in opal_call API's provided
via the console, cpu, fdt, flash, i2c, interrupts,
nvram, opal-msg, opal, opal-pci, xscom and
cec modules
Signed-off-by: Balbir Singh <bsingharora@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
We keep a mask for which SerIRQ is associated with which of the 4
PSI IRQs and we only dispatch the ones that correspond to the
PSI interrupt that fired.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
We can route them to any of 4 PSI interrupts. We use the device-tree
to determine the default routing
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Take them out of struct proc_chip and into a private struct lpcm
that's local to lpc.c
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
This will provide the global IRQ numbers for all 16 PSI inputs (though
we don't really care about 0 here). We can then express them in the
device-tree as relative to the PSI bridge. Among others, that allows
us to express the external interrupt and the LPC interrupt using a
fixed numbering scheme.
The example device-tree is updated to route them all to the LPC0
input which corresponds to what the LPC code does at the moment.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Instantiate if if it's in the device-tree...
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Also fix an error path that can dereference a NULL PSI pointer
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
I was only ever set to true
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
We currently don't exploit the new MUX that allow to spread them
around different PSI interrupts, they all go to LPC#0
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
There's hardly any difference between P8 and P9, except the PIB_MASTER
addressing being expanded to 5 bits with the PIR.
We can now look at the TOD->CAPP sync to use new functionality.
Signed-off-by: Jack Miller <jack@codezen.org>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
This reworks interrupt handling a bit and adds support for XIVE
based interrupts and the new sources available on POWER9.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
All the source controllers use the standard XIVE mechanism for
masking/unmasking and EOI, so there is no point having that
logic duplicated. There are a few variations on how they are
implemented but that can be handled using a few flags.
So let's create a wrapper around irq_sources for a xive source
and provide a new API for things like PHB4 to instanciate them
This patch while at it also fixes the calculation of the source
offset when setting up targetting information in the PHB4.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
This allows a given source to provide per-interrupt attributes
such as whether it targets OPAL or Linux and it's estimated
frequency.
The former allows to get rid of the double set of ops used to
decide which interrupts go where on some modules like the PHBs
and the latter will be eventually used to implement smart
caching of the source lookups.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
This issue is one of the corner case, which is related to recent change
went upstream and only observed in the petitboot prompt, where we see
only one error log instead of getting all error log in
/sys/firmware/opal/elog.
Below is snippet of the code, where elog module in the kernel
initialised.
{
..
...
rc = request_threaded_irq(irq, NULL, elog_event, =<=======
IRQF_TRIGGER_HIGH | IRQF_ONESHOT, "opal-elog", NULL); |
if (rc) { |
pr_err("%s: Can't request OPAL event irq (%d)\n", |
__func__, rc); |
return rc; |
} |
/* We are now ready to pull error logs from opal. */ |
if (opal_check_token(OPAL_ELOG_RESEND)) |
opal_resend_pending_logs(); =<=======
}
Scenario:
While elog_enabled is true, OPAL_EVENT_ERROR_LOG_AVAIL will be set from
OPAL, whenever it has error logs that are waiting to be fetched from the
kernel.
Race occurs between the code arrowed above, as soon as kernel registers
error log handler, it sees OPAL_EVENT_ERROR_LOG_AVAIL is set, so it
schedule the handler. Which makes 'opal_get_elog_size'(kernel) call on
the error log set the state from ELOG_STATE_FETCHED_DATA to
ELOG_STATE_FETCHED_INFO and clears OPAL_EVENT_ERROR_LOG_AVAIL. During
the same time 'opal_resend_pending_logs'(kernel) call which will set the
state machine from ELOG_STATE_FETCHED_INFO to ELOG_STATE_NONE in OPAL.
Because of that, read call from the kernel, which was to be made after
the 'opal_get_elog_size' ends up failing. But, the elog kobject was
created for the particular error log.
Further in the resend routine in the OPAL, we make opal_commit_elog_in_host()
call that sets OPAL_EVENT_ERROR_LOG_AVAIL. So, Kernel again makes
'opal_get_elog_size' which results in getting the error log info of the
same error log which was fetched earlier. It also changes the state
machine to ELOG_STATE_FETCHED_INFO and clears OPAL_EVENT_ERROR_LOG_AVAIL.
Below is the snippet from the elog_event registered handler call
{
...
...
/* we may get notified twice, let's handle
* that gracefully and not create two conflicting
* entries.
*/
if (kset_find_obj(elog_kset, name))
return IRQ_HANDLED;
...
...
}
In the kernel, we search kobject for the error log whether it already
exist. So kobject is found and it returns without reading error log
data.
So, this patch makes the flag which was true during initialisation
to false. And that solves the race.
Signed-off-by: Mukesh Ojha <mukesh02@linux.vnet.ibm.com>
Reviewed-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Confirmed with Alistair on IRC, and earlier discussions with Russell.
Basically, I was a bit of an idiot and didn't think hard enough before
adding the FWTS annotation.
Without this patch, you get spurious FirmWare Test Suite (FWTS) warnings
about NVLink not working on machines that aren't fully populated with
GPUs.
Fixes: 00e3e275344a42f6a682be72c88c015df87a0e28
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
We have used TCE_MASK value (4095) instead of TCE_PSIZE (4096) to align memory
source address. In some corner cases (like source memory size = 4097) we may
endup doing wrong mapping and corrupting part of SYSDUMP.
This patch uses ALIGN_UP macro with TCE_PSIZE value for alignining memory.
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
It was left uninitialized which could cause issues later on
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
When enabling CAPI in DMA mode, set the AIB TX command credits for channel
2 (DMA read) to 28, rather than 1. This significantly improves DMA read
performance in CAPI DMA mode.
Fixes: 5477148a439f ("phb3: Add support for CAPP DMA mode")
Reported-by: John Walthour <jwalthour@us.ibm.com>
Reported-by: Ricardo Mata <ricmata@us.ibm.com>
Reported-by: Michael Perez <perezma@us.ibm.com>
Cc: Ian Munsie <imunsie@au1.ibm.com>
Signed-off-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Fix resend logic in opal_resend_pending_logs, so that it actually
restarts sending remaining logs.
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
In some corner cases host may send acknowledgement without
reading actual data (fsp_opal_elog_info -> fsp_opal_elog_ack).
Because of this elog_read_from_fsp_head_state may be stuck in
wrong state (ELOG_STATE_HOST_INFO) and not able to send remaining
ELOG's to host. Hence reset ELOG state and start sending remaining
ELOG's.
Also in normal case we will ACK the logs which are already processed
(elog_read_processed). Hence rearrange the code such that we go
through elog_read_processed first.
Finally return OPAL_PARAMETER if we are not able to find ELOG ID.
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
[stewart@linux.vnet.ibm.com: spelling fix]
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Chances of elog_read_pending inconsistent state is very very
less. Just to be on safer side, disable notification if list
is not in consistent state.
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Reviewed-by: Mukesh Ojha <mukesh02@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
ELOG enables event notification once new log is available. And this
will be disabled after host completes reading logs (it has to complete
both fsp_opal_elog_info and fsp_opal_elog_read).
Ideally we should disable notification as soon as host consumes event
(after fsp_opal_elog_info). Also if host fails to call fsp_opal_elog_read
(ex: situations like duplicate event), then we endup keeping notification
forever.
This patch introduces new ELOG state (ELOG_STATE_HOST_INFO). As soon
as host consumes event elog will move to this new state so that event
notification is disabled.
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|