diff options
| author | Richard Spiegel <richard.spiegel@amd.corp-partner.google.com> | 2018-09-11 11:36:38 -0700 |
|---|---|---|
| committer | Martin Roth <martinroth@google.com> | 2018-10-10 16:29:20 +0000 |
| commit | 5401aa207cf67a222f8685faedcd97e856fe857e (patch) | |
| tree | 81631c407db440147a269abb376788fbfb7e2131 /src/soc/amd/stoneyridge/bootblock | |
| parent | 309210c98054652bccd28b10ef427266b1363831 (diff) | |
| download | coreboot-5401aa207cf67a222f8685faedcd97e856fe857e.tar.xz | |
soc/amd/stoneyridge/gpio.c: Create I2C slave reset code
AMD's SOC do not wait for I2C transactions to complete before executing
a reset. Because of this, it's possible for the reset to happen in the
middle of a transaction, resulting on a slave hang. There are 2 possible
solutions:
If the slave has a reset pin connected to a GPIO pin, it can be used to
reset the slave, else the only solution is to bang SCL 9 times. Create
code that makes it easy to implement SCL bang, using a devicetree
register to define which I2C SCL lines needs to be reset.
BUG=b:114479395
TEST=Build and boot grunt. Look at transactions on a scope.
Change-Id: I7f74b7e45c509044825355874753969f074e2382
Signed-off-by: Richard Spiegel <richard.spiegel@silverbackltd.com>
Reviewed-on: https://review.coreboot.org/28574
Reviewed-by: Daniel Kurtz <djkurtz@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Diffstat (limited to 'src/soc/amd/stoneyridge/bootblock')
| -rw-r--r-- | src/soc/amd/stoneyridge/bootblock/bootblock.c | 9 |
1 files changed, 9 insertions, 0 deletions
diff --git a/src/soc/amd/stoneyridge/bootblock/bootblock.c b/src/soc/amd/stoneyridge/bootblock/bootblock.c index c2440b0eb1..479e0fc9f2 100644 --- a/src/soc/amd/stoneyridge/bootblock/bootblock.c +++ b/src/soc/amd/stoneyridge/bootblock/bootblock.c @@ -93,6 +93,15 @@ asmlinkage void bootblock_c_entry(uint64_t base_timestamp) void bootblock_soc_early_init(void) { + /* + * This call (sb_reset_i2c_slaves) was originally early at + * bootblock_c_entry, but had to be moved here. There was an + * unexplained delay in the middle of the i2c transaction when + * we had it in bootblock_c_entry. Moving it to this point + * (or adding delays) fixes the issue. It seems like the processor + * just pauses but we don't know why. + */ + sb_reset_i2c_slaves(); bootblock_fch_early_init(); post_code(0x90); } |