| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
While performing presence detection on the PMIC targets we need
to first read the parent OCMB's SPD to see what device address
the PMIC is on. There was a bug where we were attempting to read
the parent OCMB's spd without first checking if the OCMB is
present itself. This commit adds a check to ensure we dont attempt
i2c reads on devices that are not present. Also this commit adds
a check to make sure we do not attempt presence detection on GEMINI
ocmbs
Change-Id: I999189b3b97210bb37b7ba1fdb2d86658d770e36
CQ: SW480414
Reviewed-on: http://rchgit01.rchland.ibm.com/gerrit1/86564
Reviewed-by: Ilya Smirnov <ismirno@us.ibm.com>
Tested-by: Jenkins Server <pfd-jenkins+hostboot@us.ibm.com>
Tested-by: Jenkins OP Build CI <op-jenkins+hostboot@us.ibm.com>
Tested-by: Jenkins OP HW <op-hw-jenkins+hostboot@us.ibm.com>
Tested-by: FSP CI Jenkins <fsp-CI-jenkins+hostboot@us.ibm.com>
Reviewed-by: Daniel M Crowell <dcrowell@us.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Depending on which vendor made a given OCMB the i2c device address
of the PMIC targets on the OCMB will be different. To account for this
we have added a new DYNAMIC_DEVICE_ADDRESS attribute. This attribute
is filled out on the PMIC target by looking at the SPD on parent
OCMB chip. This means that we must do presence detection on the OCMB
prior to the the PMIC targets. While doing i2c operations if a given
target has the DYNAMIC_DEVICE_ADDRESS we will use that over the devAddr
in the any complex i2c attribute for that target.
Change-Id: I22a185a65c064a1514751dd5828547c57af98df1
RTC: 209714
Reviewed-on: http://rchgit01.rchland.ibm.com/gerrit1/85394
Tested-by: Jenkins Server <pfd-jenkins+hostboot@us.ibm.com>
Tested-by: Jenkins OP Build CI <op-jenkins+hostboot@us.ibm.com>
Tested-by: Jenkins OP HW <op-hw-jenkins+hostboot@us.ibm.com>
Tested-by: FSP CI Jenkins <fsp-CI-jenkins+hostboot@us.ibm.com>
Reviewed-by: Daniel M Crowell <dcrowell@us.ibm.com>
Reviewed-by: Roland Veloz <rveloz@us.ibm.com>
Reviewed-by: William G Hoffa <wghoffa@us.ibm.com>
|
|
There has been a trend to create more HWPs that process raw data.
This allows Hostboot and Cronus to share more code. The trick is
that we generally want to call these HWPs inside traditionally
hostboot-only code. This new fapiwrap directory will help encapsulate
all of the calls to ekb code in one place. That way if we ever need
to remove HWPs/EKB code it will be easier to stub out the calls. In the
past we have contaminated a lot of Hostboot-only code with calls out
to EKB code. This new new directory should help avoid this issue.
Change-Id: I2b2d0d1e62c97f0976c9c9ede3fe2eac30c7a40f
RTC: 214627
Reviewed-on: http://rchgit01.rchland.ibm.com/gerrit1/83029
Tested-by: Jenkins Server <pfd-jenkins+hostboot@us.ibm.com>
Tested-by: Jenkins OP Build CI <op-jenkins+hostboot@us.ibm.com>
Tested-by: Jenkins OP HW <op-hw-jenkins+hostboot@us.ibm.com>
Tested-by: FSP CI Jenkins <fsp-CI-jenkins+hostboot@us.ibm.com>
Reviewed-by: Ilya Smirnov <ismirno@us.ibm.com>
Reviewed-by: Daniel M Crowell <dcrowell@us.ibm.com>
|