| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |\ |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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>
|
| | |
| |
| |
| | |
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 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 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>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
| |
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>
|
|
|
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
