diff options
author | Stewart Smith <stewart@linux.vnet.ibm.com> | 2016-12-02 13:29:26 +1100 |
---|---|---|
committer | Stewart Smith <stewart@linux.vnet.ibm.com> | 2016-12-02 14:25:06 +1100 |
commit | cf6ec98fe79c59fd5de5c5a77917913af8d2cede (patch) | |
tree | fe3597b7f7f0f9585e53e7ddcbd600dbcbb17cfd /hw/xive.c | |
parent | 61784acd026820b711efd6a263a6db43b86bd289 (diff) | |
download | skiboot-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