diff options
author | Felix Held <felix-coreboot@felixheld.de> | 2021-08-02 19:48:40 +0200 |
---|---|---|
committer | Felix Held <felix-coreboot@felixheld.de> | 2021-09-08 00:14:35 +0000 |
commit | 96c4882d257c611bb1a3d18ad2f1b60041582022 (patch) | |
tree | 7ff7b02c9b322c5b6c5215da894bc639e34c0518 /3rdparty/opensbi | |
parent | 916cd50edc90bc9edd134d6a37911174cc0ff944 (diff) |
soc/amd/common/block/i2c: use common GPIO API in drive_scl
No need to do raw GPIO MMIO accesses when basically the same
functionality can be achieved by using existing APIs. Using the existing
GPIO API instead of raw GPIO MMIO register accesses allows containing
all direct GPIO MMIO accesses inside the common AMD GPIO code which will
be done in subsequent patches. Since the value parameter of gpio_set is
int, change the type of the val parameter of drive_scl to int as well
even though I'm not sure why a signed integer was used for this in the
common GPIO API. Since program_gpios already configures the SCL GPIOs as
outputs, gpio_set can be used in drive_scl which only sets the output
value, but doesn't configure the direction.
TEST=The waveform on the SCL pin of I2C3 on a barla/careena Chromebook
looks similar to the same as before during the reset_i2c_peripherals
call, but due to the additional overhead of the read-modify-write to the
GPIO register instead of just a write, the pulse width gets about 50%
longer. Since the udelay call in drive_scl still has an open TODO to
make this configurable and the pulses being longer is in the safe side,
this side-effect can be addressed in a follow-up patch.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ic323cebc1c83ecd6f0e1fbab419c69489d77face
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56777
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Diffstat (limited to '3rdparty/opensbi')
0 files changed, 0 insertions, 0 deletions