GNUBoot
/
coreboot-kgpe-d16
2
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

google/gru: Fix pmu1833_volsel handling 

RK3399 has a pin that can decide whether GPIO port 1 is driven with 1.8V
or 3.0V. We thought this mechanism was disabled by default, but it turns
out it wasn't. We want to use that pin as an output GPIO on Scarlet so
we need to reconfigure the respective SoC controls before we do that. It
seems that we also need to explicitly pinmux the pin away from that
special function (to normal GPIO) or weird things happen on some boards.

BUG=b:66534913
TEST=Sprinkled several long udelays, poked test points with a
multi-meter on Scarlet.

Change-Id: Ia02cbb4f3b2f14b0d958b84adcddb0c5f4259efa
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/21727
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This commit is contained in:
Julius Werner 2017-09-27 16:36:01 -07:00
parent cf20c90430
commit e0459c78e4
1 changed files with 6 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
src/mainboard/google/gru/bootblock.c
View File

@ -48,6 +48,12 @@ void bootblock_mainboard_early_init(void)
if (IS_ENABLED(CONFIG_BOARD_GOOGLE_SCARLET))
write32(&rk3399_grf->io_vsel, RK_SETBITS(1 << 3));
/* Reconfigure GPIO1 from dynamic voltage selection through GPIO0_B1 to
hardcoded 1.8V, and change that pin to a normal GPIO. The TRM says
this is already the power-on reset, but we all know that TRMs lie. */
write32(&rk3399_pmugrf->soc_con0, RK_SETBITS(1 << 9 | 1 << 8));
write32(&rk3399_pmugrf->gpio0b_iomux, RK_CLRBITS(3 << 2));
/* Enable rails powering GPIO blocks, among other things. */
gpio_output(GPIO_P30V_EN, 1);
if (!IS_ENABLED(CONFIG_BOARD_GOOGLE_SCARLET))