occ.rst 4.7 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153
  1. Kernel driver occ-hwmon
  2. =======================
  3. Supported chips:
  4. * POWER8
  5. * POWER9
  6. Author: Eddie James <eajames@linux.ibm.com>
  7. Description
  8. -----------
  9. This driver supports hardware monitoring for the On-Chip Controller (OCC)
  10. embedded on POWER processors. The OCC is a device that collects and aggregates
  11. sensor data from the processor and the system. The OCC can provide the raw
  12. sensor data as well as perform thermal and power management on the system.
  13. The P8 version of this driver is a client driver of I2C. It may be probed
  14. manually if an "ibm,p8-occ-hwmon" compatible device is found under the
  15. appropriate I2C bus node in the device-tree.
  16. The P9 version of this driver is a client driver of the FSI-based OCC driver.
  17. It will be probed automatically by the FSI-based OCC driver.
  18. Sysfs entries
  19. -------------
  20. The following attributes are supported. All attributes are read-only unless
  21. specified.
  22. The OCC sensor ID is an integer that represents the unique identifier of the
  23. sensor with respect to the OCC. For example, a temperature sensor for the third
  24. DIMM slot in the system may have a sensor ID of 7. This mapping is unavailable
  25. to the device driver, which must therefore export the sensor ID as-is.
  26. Some entries are only present with certain OCC sensor versions or only on
  27. certain OCCs in the system. The version number is not exported to the user
  28. but can be inferred.
  29. temp[1-n]_label
  30. OCC sensor ID.
  31. [with temperature sensor version 1]
  32. temp[1-n]_input
  33. Measured temperature of the component in millidegrees
  34. Celsius.
  35. [with temperature sensor version >= 2]
  36. temp[1-n]_type
  37. The FRU (Field Replaceable Unit) type
  38. (represented by an integer) for the component
  39. that this sensor measures.
  40. temp[1-n]_fault
  41. Temperature sensor fault boolean; 1 to indicate
  42. that a fault is present or 0 to indicate that
  43. no fault is present.
  44. [with type == 3 (FRU type is VRM)]
  45. temp[1-n]_alarm
  46. VRM temperature alarm boolean; 1 to indicate
  47. alarm, 0 to indicate no alarm
  48. [else]
  49. temp[1-n]_input
  50. Measured temperature of the component in
  51. millidegrees Celsius.
  52. freq[1-n]_label
  53. OCC sensor ID.
  54. freq[1-n]_input
  55. Measured frequency of the component in MHz.
  56. power[1-n]_input
  57. Latest measured power reading of the component in
  58. microwatts.
  59. power[1-n]_average
  60. Average power of the component in microwatts.
  61. power[1-n]_average_interval
  62. The amount of time over which the power average
  63. was taken in microseconds.
  64. [with power sensor version < 2]
  65. power[1-n]_label
  66. OCC sensor ID.
  67. [with power sensor version >= 2]
  68. power[1-n]_label
  69. OCC sensor ID + function ID + channel in the form
  70. of a string, delimited by underscores, i.e. "0_15_1".
  71. Both the function ID and channel are integers that
  72. further identify the power sensor.
  73. [with power sensor version 0xa0]
  74. power[1-n]_label
  75. OCC sensor ID + sensor type in the form of a string,
  76. delimited by an underscore, i.e. "0_system". Sensor
  77. type will be one of "system", "proc", "vdd" or "vdn".
  78. For this sensor version, OCC sensor ID will be the same
  79. for all power sensors.
  80. [present only on "master" OCC; represents the whole system power; only one of
  81. this type of power sensor will be present]
  82. power[1-n]_label
  83. "system"
  84. power[1-n]_input
  85. Latest system output power in microwatts.
  86. power[1-n]_cap
  87. Current system power cap in microwatts.
  88. power[1-n]_cap_not_redundant
  89. System power cap in microwatts when
  90. there is not redundant power.
  91. power[1-n]_cap_max
  92. Maximum power cap that the OCC can enforce in
  93. microwatts.
  94. power[1-n]_cap_min Minimum power cap that the OCC can enforce in
  95. microwatts.
  96. power[1-n]_cap_user The power cap set by the user, in microwatts.
  97. This attribute will return 0 if no user power
  98. cap has been set. This attribute is read-write,
  99. but writing any precision below watts will be
  100. ignored, i.e. requesting a power cap of
  101. 500900000 microwatts will result in a power cap
  102. request of 500 watts.
  103. [with caps sensor version > 1]
  104. power[1-n]_cap_user_source
  105. Indicates how the user power cap was
  106. set. This is an integer that maps to
  107. system or firmware components that can
  108. set the user power cap.
  109. The following "extn" sensors are exported as a way for the OCC to provide data
  110. that doesn't fit anywhere else. The meaning of these sensors is entirely
  111. dependent on their data, and cannot be statically defined.
  112. extn[1-n]_label
  113. ASCII ID or OCC sensor ID.
  114. extn[1-n]_flags
  115. This is one byte hexadecimal value. Bit 7 indicates the
  116. type of the label attribute; 1 for sensor ID, 0 for
  117. ASCII ID. Other bits are reserved.
  118. extn[1-n]_input
  119. 6 bytes of hexadecimal data, with a meaning defined by
  120. the sensor ID.