diff options
author | Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com> | 2017-12-08 16:19:42 +0530 |
---|---|---|
committer | Stewart Smith <stewart@linux.vnet.ibm.com> | 2017-12-11 19:30:46 -0600 |
commit | 10f0a09239ddfd4faf47d792f04d3124fb347f88 (patch) | |
tree | bbf6652baf6b769dc33498810c7c2f60e8537c1d /libxz/Makefile.inc | |
parent | 363f328fbc597a5996fc3b28e509c09f2869888f (diff) | |
download | talos-skiboot-10f0a09239ddfd4faf47d792f04d3124fb347f88.tar.gz talos-skiboot-10f0a09239ddfd4faf47d792f04d3124fb347f88.zip |
opal/xscom: Add recovery for lost core wakeup scom failures.
Due to a hardware issue where core responding to scom was delayed due to
thread reconfiguration, leaves the SCOM logic in a state where the
subsequent scom to that core can get errors. This is affected for Core
PC scom registers in the range of 20010A80-20010ABF
The solution is if a xscom timeout occurs to one of Core PC scom registers
in the range of 20010A80-20010ABF, a clearing scom write is done to
0x20010800 with data of '0x00000000' which will also get a timeout but
clears the scom logic errors. After the clearing write is done the original
scom operation can be retried.
The scom timeout is reported as status 0x4 (Invalid address) in HMER[21-23].
Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
Reviewed-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
Diffstat (limited to 'libxz/Makefile.inc')
0 files changed, 0 insertions, 0 deletions