summaryrefslogtreecommitdiff
path: root/util/uio_usbdebug/include/device
diff options
context:
space:
mode:
authorFelix Held <felix-coreboot@felixheld.de>2021-08-02 19:48:40 +0200
committerFelix Held <felix-coreboot@felixheld.de>2021-09-08 00:14:35 +0000
commit96c4882d257c611bb1a3d18ad2f1b60041582022 (patch)
tree7ff7b02c9b322c5b6c5215da894bc639e34c0518 /util/uio_usbdebug/include/device
parent916cd50edc90bc9edd134d6a37911174cc0ff944 (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 'util/uio_usbdebug/include/device')
0 files changed, 0 insertions, 0 deletions