| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
commit c789772 introduced an asynchronous mechanism to load LID resource for
FSP systems. But after this change some of the FSP based system failed
to load/boot petitboot kernel.
While fetching LID resource in multiple chunks, we depend on return
status from FSP whether there is more data available to fetch or not.
As per FSP mailbox documentation, fetch cmd returns status=2 which means,
there is more data pending, and status=0 means we have reached end-of-file.
But in reality FSP don't behave as per the document. It looks like we
always get status=0 irrespective of whether end of file is reached or not.
The old implementation (fsp_sync_msg) used to rely on (wlen < chunk) check
to decide whether we reached end of file or not.
Ideally, FSP folks should be fix their code as per documentation. But until
they do, adding the old check back here again.
Without this patch some system won't be able to boot into petitboot kernel.
Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Simplify the NX 842 config logic by using the global proc_gen to
conditionally apply P8-specific configuration values, instead of
passing the proc gen in a function parameter.
No functional change here, it just simplifies the code.
Signed-off-by: Dan Streetman <ddstreet@ieee.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Remove the counters for each NX engine that are used to assign a unique
Coprocessor Instance (CI) to each engine, and instead just use the chip
id for the CI.
Originally I created the counter to avoid the possibility of assigning
a CI that was out of the defined range for each engine's CI, but I did
not check then what the max chip id was. Since MAX_CHIPS is 64, which
is less than all the engine's max CI value, the chip id can be safely
used for the engine CI.
Additionally, add a BUILD_ASSERT in each engine's setup to verify that
MAX_CHIPS is <= the engine's max CI.
While this changes the CI numbers that are visible to the kernel driver,
the CI values can't be relied on by the kernel to be any specific number,
so this has no effect from an API perspective. The kernel will simply
use whatever CI values are provided (technically, the current kernel
driver uses the special "0" CI value to allow the hw to select which
instance to use for each request, and it does nothing with the actual
CI values).
Signed-off-by: Dan Streetman <ddstreet@ieee.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Set the NX crb input queues to be used by 842 only, by not reserving any input
queue slots for the sym or asym engines. This allows the maximum number of
842 crb requests to be queued up, to (hopefully) improve 842 performance.
This patch isn't critical, as the default is no extra input queue locations
for asym, and only 1 extra input queue location for sym, so this only takes
sym's extra location for use by 842.
There is 1 each dedicated input queue location for asym and sym (and 842), so
this patch won't prevent them from working if support is ever added for them.
Signed-off-by: Dan Streetman <ddstreet@ieee.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
This is an attempt to make it clearer how to use the sensor set ipmi
command, and to do the correct thing to our BMC.
The boot count was using the incorrect set mask and type. It now confirms
to what the AMI BMC expects.
Signed-off-by: Joel Stanley <joel@jms.id.au>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
If FSP messes up SLCA data then attention location code points
to some other location code and its possible that we may endup
in duplicate LED location code :-(
Better to continue with partial LED list than crashing OPAL because
of duplicate node in device tree.
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
[stewart@linux.vnet.ibm.com: prlog(PR_WARNING) on duplicate found]
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Presently if fsp_msg_set_led_state() fails then we don't continue
processing remaining LED update request...which is not correct.
Also free spcn_cmd in one place rather than freeing at every failure
block.
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
memboot uses bmc system memory instead of a real flash chip. This
patch adds a flash backend for bmc system memory to allow use of the
memboot tool (in external/memboot) to boot the system.
Signed-off-by: Alistair Popple <alistair@popple.id.au>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
In case of split core, some of the Timer facility errors needs cleanup to be
done before we proceed with the error recovery.
Certain TB/HDEC errors leaves dirty data in timebase and HDEC registers,
which need to cleared before we initiate clear_tb_errors through TFMR[24].
The cleanup has to be done by any one thread from core or subcore.
In split core mode, it is required to clear the dirty data from TB/HDEC
register by all subcores (active partitions) before we clear tb errors
through TFMR[24]. The HMI recovery would fail even if one subcore do
not cleanup the respective TB/HDEC register. Dirty data can be cleaned by
writing zero's to TB/HDEC register.
For un-split core, any one thread can do the cleanup.
For split core, any one thread from each subcore can do the cleanup.
Errors that required pre-recovery cleanup:
- SPR_TFMR_TB_RESIDUE_ERR
- SPR_TFMR_HDEC_PARITY_ERROR
This patch implements pre-recovery steps to clean dirty data from TB/HDEC
register for above mentioned timer facility errors.
Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Recovery process for SPURR/PURR parity error:
- Set SPURR/PURR Register with valid value or zero
- Reset TFMR SPURR/PURR parity error bit.
To inject TFMR PURR parity error issue:
$ putscom pu.ex 10013281 0004080000000000 -all
To inject TFMR SPURR parity error issue:
$ putscom pu.ex 10013281 0005080000000000 -all
Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Recovery process for TFMR DEC parity error:
- Set DEC Register with all ones.
- Reset TFMR DEC parity error bit.
To inject TFMR DEC parity error issue:
$ putscom pu.ex 10013281 0006080000000000 -all
Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Recovery process for HDEC parity error:
- Reset HDEC Register.
- Reset TFMR HDEC parity error bit.
To inject HDEC parity error issue:
$ putscom pu.ex 10013281 0002080000000000 -all
Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Handle TFMR parity errors reported through HMER[bit 5] and TFMR bit 60
i.e tx_tfmr_corrupt. For recovery, write '1' to TFMR bit 60 to clear it.
Once we clear this error, check for timebase machine state in TFMR [28:31]
and clear TB errors if timebase machine state is in error (9) state. Once
we reset the timebase machine state continue loading TOD into core TB.
To inject TFMR parity error issue:
$ putscom pu.ex 10013281 0001080000000000 -all
Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Handle TFMR firmware control error reported through HMER[bit 5] and TFMR bit
46 and 27. There are three reason for this error:
1. TFMR command was received but the state machine was in the wrong state
for that command. e.g. TFMR move_chip_tod_to_tb command was received
while in state 0 (RESET state).
2. Two tfmr commands were set which should be mutually exclusive.
e.g. move_chip_tod_to_tb and load_tod_mod
3. Cycle counter used by the PURR overflows due to missing TB59 step.
When we get this error TB is in not-valid state (corrupted - TFMR bit 27)
and has stopped running. To recover, clear tb errors by writing 1 to TFMR
bit 46, 27 and 24. This will reset the time machine state. And then
fall through existing code which takes TB through correct states and
reloads it with valid TOD value.
To inject TFMR firmware control error set TFMR bit 16 and 18 at the same
time.
Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Handle TB residue error reported through HMER[bit 5] and TFMR bit 45
i.e tb_residu_err. For recovery, reset TB register with all zeros and
then clear tb errors by writing 1 to TFMR bit 45 and 24. Clearing TB error
bits from TFMR would set the time state machine to RESET state and then
fall through existing code path which reloads the TB with TOD value and
get TB running.
To inject TB parity error issue:
$ putscom pu.ex 10013281 0003080000000000 -all
Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
The current implementation invokes chiptod_reset_tb_errors() function that
force write 1 to all the TB errors irrespective of whether those error
occurred or not. Refactor this code to detect individual TB error and reset
them. This change does not affect the recovery of tb errors that we handle as
of today and has been verified by running regression tests. Instead this
change introduces a better way to handle individual TB errors that we handle
currently and in subsequent patches.
The subsequent patches will recover from more TB and non-TB errors.
Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
This reverts commit 699c433a8c736f44b13b7ba28cc0f9e0ac55840c.
The rest of the patches in this series refactors the code that reset TB
errors for better handling/recovery of individual TB errors. Hence Reverting
old patch that claimed to handle more TFAC errors, but did not.
Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Signed-off-by: Cédric Le Goater <clg@fr.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
The memory buffer chips (Centaur) have DTS very similar to the
ones we find on the cores.
Only available on open power machines for the moment.
Signed-off-by: Cédric Le Goater <clg@fr.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
This patch adds a couple of properties in the device tree for the core
temperatures nodes. It helps the Linux driver to identify the core and
have a "pretty" sensors output, something like the following :
Core 8: +46.0°C
Core 16: +47.0°C
Core 24: +45.0°C
...
Core 112: +42.0°C
Core 120: +44.0°C
Signed-off-by: Cédric Le Goater <clg@fr.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
The hwmon framework in Linux needs a type for the sensors it exposes
in userspace through the sysfs interface. This patch gives Linux a hand
on what is dealing with when parsing the sensor device tree.
Signed-off-by: Cédric Le Goater <clg@fr.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
The Linux driver should use this property to reflect the status as
a hwmon *_alarm or *_fault attribute.
The temperature sensors trip bits are currently always set, so we
brutaly assign the value to nil until we know why.
Signed-off-by: Cédric Le Goater <clg@fr.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
This patch simply adds sensors nodes for the core temperatures. It
uses the core PIR as a resource identifier to fit in the sensor model.
The device tree nodes use the new layout.
Signed-off-by: Cédric Le Goater <clg@fr.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
This patch adds a new sensor family for Digital Temperature Sensors
and a new resource class to capture the core temperatures.
Each core has four DTS located in different zones (LSU, ISU, FXU, L3).
The max of the four temperatures is computed and returned for the core
as well as a global trip point value. This is based on the meltbox tool.
Signed-off-by: Cédric Le Goater <clg@fr.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
This patch introduces an initial framework to define a sensor_read
operation per platform. It also proposes a few helper routines to
work on the sensor 'handler' which identifies a sensor and attribute
in the OPAL_SENSOR_READ call.
Signed-off-by: Cédric Le Goater <clg@fr.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
This moves away from using fsp_sync_msg in fsp_fetch_data and instead
using the platform hooks for start_preload_resource() to actually queue
up a load and having the plumbing for checking if a resource is loaded yet.
This gets rid of the "pollers called with locks held" warning we got
heaps of previously. You can now boot some FSP systems without getting
this warning at all.
This also sets the stage for starting load of LIDs much earlier to when
they're needed, improving boot time.
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
No functional changes in what happens, just have two calls, one for
queueing preload the other for waiting until it has loaded.
future patches will introduce platform specific queueing.
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Presently we update enclosure exclusive bit before making LED update
SPCN passthrough command and not reverting if this command fails. So
we endup having wrong state if SPCN passthrough command fails.
This patch fixes above described issue.
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
This patch adds and registers the following two new OPAL interfaces
for the LED subsystem. With the help of these new OPAL calls, the
host will be able to set or query the state of various LEDs on the
system at any given location code (as passed in the device tree).
As of now, it supports two kinds of LEDs on the same location code
one is "Identify LED" and the other being the "Fault LED".
(1) OPAL_LEDS_GET_INDICATOR fsp_opal_leds_get_ind
(2) OPAL_LEDS_SET_INDICATOR fsp_opal_leds_set_ind
The signtaure of these OPAL interfaces are like the following
(1) fsp_opal_leds_get_ind(loc_code, led_mask, led_value, led_max_type)
The host will pass the location code of the LED (loc_code) and
maximum number of LED types it understands (led_max_type). Sapphire
updates the led_mask with set bits pointing to LED types whose status
is availbale and updates the led_value with actual status. Sapphire
checks the led_max_type to understand whether host is newer or older
compared to itself. In the case where the Sapphire is newer compared
to host (Sapphire's led_max_type > host's led_max_type), it will update
led_mask and led_value according to led_max_type requested by the host.
When the host is newer compared to the Sapphire (host's led_max_type >
Sapphire's led_max_type), Sapphire updates led_max_type to the maximum
number of LED type it understands and updates led_mask, led_value based
on that maximum value.
(2) fsp_opal_leds_set_ind(loc_code, led_mask, led_value, led_max_type)
The host will pass the location code of the LED types, mask,
value and maximum number of LED types it understands. Sapphire will
update LED status for all the LED types mentioned in the mask with
their value mentioned. Sapphire checks the 'led_max_type' to understand
whether the host is newer or older compared to itself. In case where
the Sapphire is newer compared to the host (Sapphire's led_max_type >
host's led_max_type), it updates LED status based on led_max_type
requested from the host. When the host is newer compared to the Sapphire
(host's led_max_type > Sapphire's led_max_type), Sapphire updates
'led_max_type' to the maximum number of LED type it understands and
then it updates LED status based on that updated maximum value of LED
types. Host needs to check the returned updated value of led_max_type
to figure out which part of it's request got served and which ones got
ignored.
Signed-off-by: Anshuman Khandual <khandual@linux.vnet.ibm.com>
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
If set LED mbox command fails then we have to respond to FSP
with apropriate status code.
Moved MBOX response code to separate function so that we can
just call that with different status code.
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
The LED local state gets updated before queuing the FSP command.
If the command returns in error state, the state gets rolled back
in the function callback. But in case where the FSP command queue
it self fails, it does not get rolled back. This patch fixes this
scenario by rolling back the state change in case the FSP command
queuing itself fails.
Signed-off-by: Anshuman Khandual <khandual@linux.vnet.ibm.com>
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
This patch increase the scope of the lock to cover all data structure
manipulation and SPCN command queuing to change the LED state. It also
locks the corresponding sections in the function callback.
Signed-off-by: Anshuman Khandual <khandual@linux.vnet.ibm.com>
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
OPAL queues up asynchronous SPCN command to change the state of any
given LED with a function call back. After receiving the call back, it
sends acknowledgement message to the FSP for the previous command. But
in case of OPAL interface initiated LED state changes, no ack message
needs to be sent to the FSP, instead we might want to enable some flags
for OPAL indicating the success of the previous LED request thus making
the OPAL interface ready for subsequent commands from the host. This
creates a need to distinguish between SPCN based LED commands generated
because of FSP async interface compared to that of OPAL interface. This
patch achieves the classification and other needfull changes in this
regard. These changes will be necessary and used by OPAL interface in
subsequent patches in this series.
Signed-off-by: Anshuman Khandual <khandual@linux.vnet.ibm.com>
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
"fsp_led_data" structure contains ckpt_status variable which keeps
current LED state before updating and if LED update fails then we
use this to revert the LED state.
We have introduced new structure (led_set_cmd) to queue up LED update
requests. It make sense to move checkpoint status variable to this
new structure.
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
This patch creates a parent LED device node called 'led' under the root
'opal' device node. This also creates child device nodes under 'led'
corresponding to all individual LEDs on the system whether it is an enclosure
type or a descendant type with their location code as name. The location code
information will be used by the host to enlist and access all the individual
LEDs present on the system. The child LED device nodes also have the properties
'led-types' and 'led-loc' representing what kind of LEDs present on the same
loation code and whether it is an enclosure type LED or a descendant type LED.
Sample device tree output:
ibm,opal {
..
..
led {
compatible = "ibm,opal-v3-led";
phandle = <0x1000006b>;
linux,phandle = <0x1000006b>;
U78C9.001.RST0027-P1-C1 {
led-types = "identify", "fault";
led-loc = "descendent";
phandle = <0x1000006f>;
linux,phandle = <0x1000006f>;
};
<snip>
};
};
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Signed-off-by: Anshuman Khandual <khandual@linux.vnet.ibm.com>
[stewart@linux.vnet.ibm.com: Move create_led_device_nodes to FSP platform.exit]
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
During Reset/Reload, we currently enable FSP interrupts on PSIHBCR
even before the DISR handshake is complete. Fix that.
Signed-off-by: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Add NX config register values for P7+. Remove "P8" from all register
defines, where the define is common to P7+ and P8. For values new to P8
(specifically 842 prefeching), only enable on P8.
This should correctly setup the NX coprocessors on P7+ systems.
Signed-off-by: Dan Streetman <ddstreet@ieee.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
..which will result lock error in OPAL.
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
We don't actually need to use a separate node for the nx-842
details, so move its information nodes (for CT and CI) under
each main nx node for each coprocessor.
Part of the reason for this is the kernel driver will need to
read/write xscom registers, for coprocessor monitoring and
error recovery, and locating the CT and CI nodes under the
main nx node allows the nx-842 driver to easily get more
information about the coprocessor, like its base xscom
address, and the processor version (p7, p8, etc).
Signed-off-by: Dan Streetman <ddstreet@ieee.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Check for TOD state before returning cached time in
fsp_opal_rtc_read. Also improve error handling.
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
cc: Neelesh Gupta <neelegup@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Similar to rtc read requests, have a state machine to handle the
write transitions.
Signed-off-by: Neelesh Gupta <neelegup@linux.vnet.ibm.com>
Reviewed-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
The rtc_request_state handles the state transition for rtc read requests
only, so rtc_read_request_state is more appropriate name.
Signed-off-by: Neelesh Gupta <neelegup@linux.vnet.ibm.com>
Reviewed-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Commit 4db0c1e4f introduced occ_load_req queue. With that changes we queue
the occ load request if hostservice LID load is not complete. And we have
callback function (occ_poke_load_queue)...which takes care of calling
__occ_do_load().
But current code proceeds and calls __occ_do_load() after queueing....which
is not correct. So just return if we queue the occ load request.
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
cc: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
Reviewed-by: Vaidyanathan Srinivasan <svaidy@linux.vnet.ibm.com>
Acked-by: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
We introduce simple state machine, have liberal assert()s and very
clearly indicate what's protected by the lock (everything).
We also stop waiting for the initial RTC response on boot, which
will ever so slightly speed up booting.
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Rather than doing the last disable in the interrupt path, do it on final
reset. This is a temporary workaround for incorrect pretimeout
behaviour.
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
|
|
Signed-off-by: Cédric Le Goater <clg@fr.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
