| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
We added led-loc property.. which contains LED location information.
But this property was never used. Also we can make out LED location
(enclosure/component) based on location code (if location code doesn't
contain "-" means its enclosure location code).
As Ben suggested [1], removing this property.
Present code is included in skiboot skiboot-5.0 release..But we don't
have any consumer yet. Hence I think its fine to make this changes.
[1] https://lists.ozlabs.org/pipermail/linuxppc-dev/2015-June/130433.html
Suggested-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Add a new class of message definition OPAL_MSG_OCC to
opal_message_type to notify the following OCC events to host:
1) OCC Reset
2) OCC Load
3) OCC Throttle Status Change
Add an opal poller to periodically read throttle status updated by OCC
for each chip and notify any change in throttle status to host. The
throttle status indicates the reason why OCC may have limited the max
Pstate of the chip.
Signed-off-by: Shilpasri G Bhat <shilpa.bhat@linux.vnet.ibm.com>
Reviewed-by: Preeti U Murthy <preeti@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Presently we are creating '/ibm,opal/led' node and populating all LED
related information there. Ben [1] suggested to rename this as 'leds'.
Present code is included in skiboot skiboot-5.0 release..But we don't
have any consumer yet. Hence I think its fine to make this changes.
Finally updated node name in doc file.
[1] https://lists.ozlabs.org/pipermail/linuxppc-dev/2015-June/130433.html
Suggested-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Reviewed-by: Stewart Smith <stewart@linux.vnet.ibm.com>
[stewart@linux.vnet.ibm.com: We're *lucky* that no FSP based system shipped
with skiboot with /led/ rather than /leds/, in future, as the OpenPower ecosystem
grows, we will unlikly be able to make this kind of assumption that nobody
else went and used this layout. This is likely the last of this kind of change.]
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Updated opal-messages.txt with description of OPAL EPOW and DPO messages
Signed-off-by: Vipin K Parashar <vipin@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Most of the PCI docs come from old documents and thus come with appropriate
warnings about accuracy. Much of this is designed to be a *starting point*
for real documentation.
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Fetch the memory bus frequency present in PCIA area and add this
information to the memory node.
ms-dimm@d000 {
[...]
description = "32GB CDIMM";
ibm,loc-code = "U78C9.001.WZS03HU-P1-C16";
ibm,memory-bus-frequency = <0x0 0x5f5e1000>;
serial-number = "YH10M147C1L1";
fru-type = [4d 53];
[...]
};
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>
|
|
Mention that the vpd document is applicable for FSP-based systems.
Signed-off-by: Neelesh Gupta <neelegup@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
No longer need to parse the skiboot log to find out where data structures
are.
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Suggested-by: Andrei Warkenti <andrey.warkentin@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
Currently, the prd reserved ranges are present in the reserved-ranges
nodes in the device tree. While this works, it's difficult to filter the
actual PRD ranges from general reserved memory.
This change links the prd ranges into the /reserved-memory nodes, by
adding ibm,prd-label properties to those used for PRD.
This change adds a prd node to the ibm,opal node too, to giver kernel &
userspace information about the prd infrastructure provided by OPAL.
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Linux supports a newer memory reservation layout in the device-tree,
where each reservation is represented by a subnode under a top-level
"reserved-memory" node.
This change adds these nodes, using the mem_region names as the property
names (minus any cell addresses). The reserved-memory node looks like
this:
/ {
name = "reserved-memory";
ranges;
#address-cells = <0x2>;
#size-cells = <0x2>;
ibm,firmware-code@30000000 {
reg = <0x0 0x30000000 0x0 0x200000>;
};
ibm,firmware-data@30e00000 {
reg = <0x0 0x30e00000 0x0 0xc00000>;
};
ibm,firmware-stacks@31a00000 {
reg = <0x0 0x31a00000 0x0 0x8000000>;
};
ibm,firmware-allocs-memory@39a00000 {
reg = <0x0 0x39a00000 0x0 0x1c0200>;
};
ibm,firmware-heap@30200000 {
reg = <0x0 0x30200000 0x0 0xc00000>;
};
};
We also store a pointer to the reservation nodes in struct mem_region,
so they can be used by other skiboot code.
We keep the property-style reservation information (reserved-names and
reserved-ranges) unchanged.
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
OpenPower ABI mentions (2.2.1.1 Register Roles) that r11 is not used for
parameter passing, and again in 2.2.3 (Parameter Passing in Registers)
that only 8 registers are available, with the rest spilling to stack.
Incorrectly, we had documented that we use r11 for a 9th parameter
and we were storing and loading r11 as part of OPAL_TRACE_ENTRY.
Github-issue: https://github.com/open-power/skiboot/issues/12
Reported-by: Andrei Warkentin <andrey.warkentin@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
Reviewed-by: Andrei Warkentin <andrey.warkentin@gmail.com>
|
|
SAI is controlled by FSP. This patch adds support to get/set
this indicator. Also update OPAL interface so that playload
can read/set this indicator.
During init, we read this indicator state using MBOX command.
OPAL uses MBOX interface to update this SAI.
FSP sends update notification whenever there is change in SAI
state (except for OPAL initiates updates). We use the notification
to update cached SAI state.
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
FSP based machine supports two different LED modes:
- Light Path : Both identify and fault LEDs are supported
- Guiding Light: Only identify LEDs are supported
And this information is passed to OPAL via HDAT. Lets parse this
and populate the device tree. Later LED driver uses this information
to populate indivisual LED node.
Device Tree property:
/ibm,opal/led/led-mode : lightpath/guidinglight
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Add documentation for FSP based machine code update API.
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Lets document the firmware version related device tree properties.
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
The OPAL_SENSOR_READ call in Linux currently only tests for
OPAL_ASYNC_COMPLETION value. It is safe to change this return value to
give some extra information on the platform sensor support.
Signed-off-by: Cédric Le Goater <clg@fr.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>
|
|
Let's document what has been done so far for DTS sensors in the device
tree under node ibm,opal/sensors/
Signed-off-by: Cédric Le Goater <clg@fr.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>
|
|
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>
|
|
I think the device tree doc update for the new NX node location
got lost from the last patch; this updates the nx device node doc
with the right information.
Signed-off-by: Dan Streetman <ddstreet@ieee.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Intentionally lazy as lazy docs are better than no docs.
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Update doc/opal-api/opal-messages.txt to add more documentation on the HMI
event structure.
Signed-off-by: Mahesh Salgaonkar <mahesh@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>
|
|
This change adds Processor Recovery Diagnostics (PRD) code to skiboot
firmware. This allows certain hardware RAS events to be handled by a
userspace application.
The core of the PRD code is a messaging interface to the kernel (and
onwards to userspace). PRD events are logged with the prd.c code, and
sent to the kernel as opal_msg messages. For responses to these
messages, the kernel will reply using a new OPAL call, opal_prd_msg.
Only one message is outstanding at a time; we collect events from
hardware interrupts (hooked up by subsequent patches), and set
per-processor event bits. Once an event has been consumed by the
kernel, we clear that event from out pending set, and send any further
pending events.
Certain events (hardware attentions from the psi layer) need to be
masked at interrupt time. For these, we have an acknowledgement facility
to clear the mask once the userspace PRD application has cleared the
source of the error.
Includes multiple contributions from:
Neelesh Gupta <neelegup@linux.vnet.ibm.com>
Vaidyanathan Srinivasan <svaidy@linux.vnet.ibm.com>
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
Signed-off-by: Neelesh Gupta <neelegup@linux.vnet.ibm.com>
Signed-off-by: Vaidyanathan Srinivasan <svaidy@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Add support for the 842 hw memory compression engine in the NX Coprocessor.
This moves the existing RNG support into its own nx-rng.c file, adds 842
support in a nx-842.c file, and creates a nx-crypto.c file to configure and
disable the crypto engines (which are not supported yet).
New nodes are created for each 842 engine found. This does not actually
process any of the data or drive the 842 engines, it only configures
registers to set up and enable/disable the engines appropriately, and
creates new nodes so the OS can drive the 842 engines.
Signed-off-by: Dan Streetman <ddstreet@ieee.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
We'd like to enable access to the system PNOR, on platforms where its
present. This change introduces an API for global flash operations:
opal_flash_read
opal_flash_erase
opal_flash_write
- plus device-tree bindings to expose the flash details.
Since there are other components of the system that use the PNOR (NVRAM
and pnor_load_resource), upcoming changes will port this these over to
use the new interface.
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
Reviewed-by: Joel Stanley <joel@jms.id.au>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
We now consistently use msg as abbreviation for message in OPAL API.
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
It turns out that MESSAGE vs MSG in places is already confusing
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
especially around backwards compatibility and what a host OS
should/should not do.
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Signed-off-by: Neelesh Gupta <neelegup@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
This sends the previously unused OPAL_MSG_SHUTDOWN using opal_queue_msg
to initiate a graceful shutdown.
The message provides a single parameter indicating weather the shutdown
is will result in a power-off, or a reboot.
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>
|
|
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
