aboutsummaryrefslogtreecommitdiff
path: root/hw/xive.c
diff options
context:
space:
mode:
authorStewart Smith <stewart@linux.vnet.ibm.com>2016-12-02 13:29:26 +1100
committerStewart Smith <stewart@linux.vnet.ibm.com>2016-12-02 14:25:06 +1100
commitcf6ec98fe79c59fd5de5c5a77917913af8d2cede (patch)
treefe3597b7f7f0f9585e53e7ddcbd600dbcbb17cfd /hw/xive.c
parent61784acd026820b711efd6a263a6db43b86bd289 (diff)
downloadskiboot-cf6ec98fe79c59fd5de5c5a77917913af8d2cede.zip
skiboot-cf6ec98fe79c59fd5de5c5a77917913af8d2cede.tar.gz
skiboot-cf6ec98fe79c59fd5de5c5a77917913af8d2cede.tar.bz2
p8-i2c reset things manually in some error conditions
It appears that our reset code wasn't entirely correct, and what we're meant to do is reset each port and wait for command complete. In the event where that fails, we can then bitbang things to recover to a state where at least the i2c engine isn't in a weird state. Practically, this means that "i2cdetect -y 10; i2cdetect -y 10" (where 10 is the bus where a TPM is attached, typically p8e1p2) doesn't hard lock the machine (things are still bad and you won't reboot successfully, but it's *better*). one downside to this patch is that we spend a *long* time in OPAL (tens of ms) when doing the reset. This is something that we really need to fix, as it's not at all nice. The full fix for this though will involve changing a decent chunk of the p8-i2c code, as we don't want to write *any* registers while doing this extended reset (while existing code checks status a bit later). Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
Diffstat (limited to 'hw/xive.c')
0 files changed, 0 insertions, 0 deletions