2018-11-09 00:05:22 +03:00
Kernel driver occ-hwmon
=======================
Supported chips:
2019-04-17 12:46:28 +03:00
2018-11-09 00:05:22 +03:00
* POWER8
* POWER9
Author: Eddie James <eajames@linux.ibm.com>
Description
-----------
This driver supports hardware monitoring for the On-Chip Controller (OCC)
embedded on POWER processors. The OCC is a device that collects and aggregates
sensor data from the processor and the system. The OCC can provide the raw
sensor data as well as perform thermal and power management on the system.
The P8 version of this driver is a client driver of I2C. It may be probed
manually if an "ibm,p8-occ-hwmon" compatible device is found under the
appropriate I2C bus node in the device-tree.
The P9 version of this driver is a client driver of the FSI-based OCC driver.
It will be probed automatically by the FSI-based OCC driver.
Sysfs entries
-------------
The following attributes are supported. All attributes are read-only unless
specified.
The OCC sensor ID is an integer that represents the unique identifier of the
sensor with respect to the OCC. For example, a temperature sensor for the third
DIMM slot in the system may have a sensor ID of 7. This mapping is unavailable
to the device driver, which must therefore export the sensor ID as-is.
Some entries are only present with certain OCC sensor versions or only on
certain OCCs in the system. The version number is not exported to the user
but can be inferred.
2019-04-17 12:46:28 +03:00
temp[1-n]_ label
OCC sensor ID.
2018-11-09 00:05:22 +03:00
[with temperature sensor version 1]
2019-04-17 12:46:28 +03:00
temp[1-n]_ input
Measured temperature of the component in millidegrees
2018-11-09 00:05:22 +03:00
Celsius.
2019-04-17 12:46:28 +03:00
2018-11-09 00:05:22 +03:00
[with temperature sensor version >= 2]
2019-04-17 12:46:28 +03:00
temp[1-n]_ type
The FRU (Field Replaceable Unit) type
2018-11-09 00:05:22 +03:00
(represented by an integer) for the component
that this sensor measures.
2019-04-17 12:46:28 +03:00
temp[1-n]_ fault
Temperature sensor fault boolean; 1 to indicate
2018-11-09 00:05:22 +03:00
that a fault is present or 0 to indicate that
no fault is present.
2019-04-17 12:46:28 +03:00
2018-11-09 00:05:22 +03:00
[with type == 3 (FRU type is VRM)]
2019-04-17 12:46:28 +03:00
temp[1-n]_ alarm
VRM temperature alarm boolean; 1 to indicate
2018-11-09 00:05:22 +03:00
alarm, 0 to indicate no alarm
2019-04-17 12:46:28 +03:00
2018-11-09 00:05:22 +03:00
[else]
2019-04-17 12:46:28 +03:00
temp[1-n]_ input
Measured temperature of the component in
millidegrees Celsius.
2018-11-09 00:05:22 +03:00
2019-04-17 12:46:28 +03:00
freq[1-n]_ label
OCC sensor ID.
freq[1-n]_ input
Measured frequency of the component in MHz.
power[1-n]_ input
Latest measured power reading of the component in
2018-11-09 00:05:22 +03:00
microwatts.
2019-04-17 12:46:28 +03:00
power[1-n]_ average
Average power of the component in microwatts.
power[1-n]_ average_interval
The amount of time over which the power average
2018-11-09 00:05:22 +03:00
was taken in microseconds.
2019-04-17 12:46:28 +03:00
2018-11-09 00:05:22 +03:00
[with power sensor version < 2]
2019-04-17 12:46:28 +03:00
power[1-n]_ label
OCC sensor ID.
2018-11-09 00:05:22 +03:00
[with power sensor version >= 2]
2019-04-17 12:46:28 +03:00
power[1-n]_ label
OCC sensor ID + function ID + channel in the form
2018-11-09 00:05:22 +03:00
of a string, delimited by underscores, i.e. "0_15_1".
Both the function ID and channel are integers that
further identify the power sensor.
2019-04-17 12:46:28 +03:00
2018-11-09 00:05:22 +03:00
[with power sensor version 0xa0]
2019-04-17 12:46:28 +03:00
power[1-n]_ label
OCC sensor ID + sensor type in the form of a string,
2018-11-09 00:05:22 +03:00
delimited by an underscore, i.e. "0_system". Sensor
type will be one of "system", "proc", "vdd" or "vdn".
For this sensor version, OCC sensor ID will be the same
for all power sensors.
2019-04-17 12:46:28 +03:00
2018-11-09 00:05:22 +03:00
[present only on "master" OCC; represents the whole system power; only one of
2019-04-17 12:46:28 +03:00
this type of power sensor will be present]
power[1-n]_ label
"system"
power[1-n]_ input
Latest system output power in microwatts.
power[1-n]_ cap
Current system power cap in microwatts.
power[1-n]_ cap_not_redundant
System power cap in microwatts when
there is not redundant power.
power[1-n]_ cap_max
Maximum power cap that the OCC can enforce in
2018-11-09 00:05:22 +03:00
microwatts.
power[1-n]_ cap_min Minimum power cap that the OCC can enforce in
microwatts.
power[1-n]_ cap_user The power cap set by the user, in microwatts.
This attribute will return 0 if no user power
cap has been set. This attribute is read-write,
but writing any precision below watts will be
ignored, i.e. requesting a power cap of
500900000 microwatts will result in a power cap
request of 500 watts.
2019-04-17 12:46:28 +03:00
2018-11-09 00:05:22 +03:00
[with caps sensor version > 1]
2019-04-17 12:46:28 +03:00
power[1-n]_ cap_user_source
Indicates how the user power cap was
2018-11-09 00:05:22 +03:00
set. This is an integer that maps to
system or firmware components that can
set the user power cap.
The following "extn" sensors are exported as a way for the OCC to provide data
that doesn't fit anywhere else. The meaning of these sensors is entirely
dependent on their data, and cannot be statically defined.
2019-04-17 12:46:28 +03:00
extn[1-n]_ label
ASCII ID or OCC sensor ID.
extn[1-n]_ flags
This is one byte hexadecimal value. Bit 7 indicates the
2018-11-09 00:05:22 +03:00
type of the label attribute; 1 for sensor ID, 0 for
ASCII ID. Other bits are reserved.
2019-04-17 12:46:28 +03:00
extn[1-n]_ input
6 bytes of hexadecimal data, with a meaning defined by
2018-11-09 00:05:22 +03:00
the sensor ID.