| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
| |
The OCC present count returns the number of OCCs in the system. Before
we have bound the second OCC, this will be greater than the number of
OCCs the Manager has counted as Active, resulting in a mismatch, causing
an error.
Resolves openbmc/openbmc#2733
Change-Id: Ia37a6b152fb073cf3044c601501903bcdfe9d3fe
Signed-off-by: Eddie James <eajames@us.ibm.com>
|
|
|
|
|
|
|
|
|
|
| |
Driver and OCC application should now correctly report errors from the
OCC with no false positives.
Resolves openbmc/openbmc#2285
Change-Id: Ifc4668ab75f26529f071317ead6ab4f77c3a0e7c
Signed-off-by: Edward A. James <eajames@us.ibm.com>
|
|
|
|
|
|
|
|
|
|
| |
P8 uses i2c-occ and powercap is not created.
Add P8 support by creating powercap object with i2c device name.
Fixes openbmc/openbmc#2688
Change-Id: Ia63070d63f4392cc4b084ab628cdbdcf4206c883
Signed-off-by: Lei YU <mine260309@gmail.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously OCC objects would be created either in response (D-Bus
signals) to CPU inventory objects being created, or if the CPU objects
were already present when the openpower-occ-control app starts. We've
had few issues where it has seemed like the OCC objects never got
created, or did not get created in time; the CPU objects were created
though. This is suggestive of either a race, or the D-Bus signal being
missed altogether.
Simplify by creating OCC objects when the app starts (we know how many
OCC objects to create based on system specific config), instead of doing
it reactively. The OCC objects will be marked active only when we're
sent a sensor from the host asking to do so. That's not changing.
Change-Id: I782ea4f120292542e3c7b32b1e0acfa8efb5e8e6
Signed-off-by: Deepak Kodihalli <dkodihal@in.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add a Presence child class of Error to handle detecting the number of
OCCs available. Add an instance of this Presence class if the Device
detects that it is the master OCC, since the number of present OCCs is
only reported by the master OCC. When a change to the number of OCCs
reported is detected, compare with the number of OCCs determined to be
active by the Manager, and if there is a mismatch, follow the usual
error path (reset OCC, etc).
Partially resolves openbmc/openbmc#2285
See https://gerrit.openbmc-project.xyz/#/c/7843/
Change-Id: Idbaca52b307992d9b01fe15439ab746ef6d64397
Signed-off-by: Edward A. James <eajames@us.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I2c occ dbus objects path were their i2c addresses, e.g. 3_0050.
This does not indicate it's occ objects, and it does not work with
op-occ-disable/enable services, which searches "occ" key words in object
path.
So add "occ_" prefix for i2c occ dbus objects, e.g. occ_3_0050, to
indicate it's occ objects and work well with op-occ-disable/enable
services.
Change-Id: I21712f2fb7cf6138248f6986b84f99c90c3fa3a2
Signed-off-by: Lei YU <mine260309@gmail.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously the app would watch for CPU inventory being created (in
order to create OCC objects) only if no CPU inventory existed when the
app starts. This logic breaks when some of the CPUs exist out of the max
possible, because we would never watch for those missing CPU objects
being potentially created in the next boot.
Instead, always watch for CPU inventory being created via the d-bus
InterfacesAdded signal. This is safe in case a persisted CPU object
existed in the inventory, because the signal would not fire on that
object.
Resolves openbmc/openbmc#2515.
Change-Id: I0b7ae84d98cd05fe355d4ff56ebaa14da3a3098a
Signed-off-by: Deepak Kodihalli <dkodihal@in.ibm.com>
|
|
occ_manager.hpp is growing and hence this commit splits
into header and source files
Change-Id: I3203520c50910d39055fea98b770de55796bb074
Signed-off-by: Vishwanatha Subbanna <vishwa@linux.vnet.ibm.com>
|