Change in coreboot[master]: google/gru: Fix pmu1833_volsel handling

[Julius Werner (Code Review)]

Hello Lin Huang, David Schneider, Philip Chen,

I'd like you to do a code review. Please visit

https://review.coreboot.org/21727

to review the following change.

Change subject: google/gru: Fix pmu1833_volsel handling
......................................................................

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.

Change-Id: Ia02cbb4f3b2f14b0d958b84adcddb0c5f4259efa
Signed-off-by: Julius Werner 
---
M src/mainboard/google/gru/bootblock.c
1 file changed, 6 insertions(+), 0 deletions(-)

git pull ssh://review.coreboot.org:29418/coreboot refs/changes/27/21727/1

diff --git a/src/mainboard/google/gru/bootblock.c b/src/mainboard/google/gru/bootblock.c
index a3d3121..162a7e5 100644
--- a/src/mainboard/google/gru/bootblock.c
+++ b/src/mainboard/google/gru/bootblock.c
@@ -48,6 +48,12 @@
    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))