coreboot-kgpe-d16/src/mainboard/google/gru/mainboard.c

392 lines
11 KiB
C
Raw Normal View History

/*
* This file is part of the coreboot project.
*
* Copyright 2016 Rockchip Inc.
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; version 2 of the License.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
*/
#include <boardid.h>
google/gru: Power-cycle USB ports in developer/recovery modes Gru only uses USB 2.0 in firmware to avoid all the madness associated with Type-C port orientation and USB 3.0 tuning. We do this by isolating the SuperSpeed lines in the Type-C PHY so it looks like they aren't connected to the device. Unfortunately, some devices seem to already get "locked" into SuperSpeed mode as soon as they detect Rx terminations once, and can never snap out again on their own. Since the terminations are already connected during power-on reset we cannot disable them fast enough to prevent this, and the only solution we found to date is to power-cycle the whole USB port. Now, Gru's USB port power is controlled by the EC, and unfortunately we have no direct host command to control it. We do however have a command to force a certain USB PD "role", and forcing our host into "sink" mode makes it stop sourcing power to the port. So for lack of a saner solution we'll use this to work around our problem. BRANCH=gru BUG=chrome-os-partner:59346 TEST=Booted Kevin in recovery mode, confirmed that my "problem stick" gets detected immediately (whereas previously I had to unplug/replug it). Booted Kevin to OS in both developer and normal mode and confirmed that USB still seems to work. Change-Id: Ib3cceba9baa170b13f01bd5c01bd413be5b441ba Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: cd695eda33299e50362f1096c46f2f5260c49036 Original-Change-Id: I2db3d6d3710d18a8b8030e94eb1ac2e931f22638 Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/413031 Reviewed-on: https://review.coreboot.org/17628 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.com>
2016-11-22 05:14:18 +01:00
#include <console/console.h>
#include <delay.h>
#include <device/device.h>
#include <device/i2c.h>
google/gru: Power-cycle USB ports in developer/recovery modes Gru only uses USB 2.0 in firmware to avoid all the madness associated with Type-C port orientation and USB 3.0 tuning. We do this by isolating the SuperSpeed lines in the Type-C PHY so it looks like they aren't connected to the device. Unfortunately, some devices seem to already get "locked" into SuperSpeed mode as soon as they detect Rx terminations once, and can never snap out again on their own. Since the terminations are already connected during power-on reset we cannot disable them fast enough to prevent this, and the only solution we found to date is to power-cycle the whole USB port. Now, Gru's USB port power is controlled by the EC, and unfortunately we have no direct host command to control it. We do however have a command to force a certain USB PD "role", and forcing our host into "sink" mode makes it stop sourcing power to the port. So for lack of a saner solution we'll use this to work around our problem. BRANCH=gru BUG=chrome-os-partner:59346 TEST=Booted Kevin in recovery mode, confirmed that my "problem stick" gets detected immediately (whereas previously I had to unplug/replug it). Booted Kevin to OS in both developer and normal mode and confirmed that USB still seems to work. Change-Id: Ib3cceba9baa170b13f01bd5c01bd413be5b441ba Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: cd695eda33299e50362f1096c46f2f5260c49036 Original-Change-Id: I2db3d6d3710d18a8b8030e94eb1ac2e931f22638 Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/413031 Reviewed-on: https://review.coreboot.org/17628 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.com>
2016-11-22 05:14:18 +01:00
#include <ec/google/chromeec/ec.h>
#include <gpio.h>
#include <soc/bl31_plat_params.h>
#include <soc/clock.h>
#include <soc/display.h>
#include <soc/grf.h>
#include <soc/i2c.h>
#include <soc/usb.h>
#include <vendorcode/google/chromeos/chromeos.h>
#include "board.h"
/*
* Wifi's PDN/RST line is pulled down by its (unpowered) voltage rails, but
* this reset pin is pulled up by default. Let's drive it low as early as we
* can.
*/
static void deassert_wifi_power(void)
{
gpio_output(GPIO(1, B, 3), 0); /* Assert WLAN_MODULE_RST# */
}
static void configure_emmc(void)
{
/* Host controller does not support programmable clock generator.
* If we don't do this setting, when we use phy to control the
* emmc clock(when clock exceed 50MHz), it will get wrong clock.
*
* Refer to TRM V0.3 Part 1 Chapter 15 PAGE 782 for this register.
* Please search "_CON11[7:0]" to locate register description.
*/
write32(&rk3399_grf->emmccore_con[11], RK_CLRSETBITS(0xff, 0));
rkclk_configure_emmc();
}
static void register_apio_suspend(void)
{
static struct bl31_apio_param param_apio = {
.h = {
.type = PARAM_SUSPEND_APIO,
},
.apio = {
.apio1 = 1,
.apio2 = 1,
.apio3 = 1,
.apio4 = 1,
.apio5 = 1,
},
};
register_bl31_param(&param_apio.h);
}
static void register_gpio_suspend(void)
{
/*
* These three GPIO params are used to shut down the 1.5V, 1.8V and
* 3.3V power rails, which need to be shut down ordered by voltage,
* with highest voltage first.
* Since register_bl31() appends to the front of the list, we need to
* register them backwards, with 1.5V coming first.
*/
static struct bl31_gpio_param param_p15_en = {
.h = {
.type = PARAM_SUSPEND_GPIO,
},
.gpio = {
.polarity = BL31_GPIO_LEVEL_LOW,
},
};
param_p15_en.gpio.index = GET_GPIO_NUM(GPIO_P15V_EN);
register_bl31_param(&param_p15_en.h);
static struct bl31_gpio_param param_p18_audio_en = {
.h = {
.type = PARAM_SUSPEND_GPIO,
},
.gpio = {
.polarity = BL31_GPIO_LEVEL_LOW,
},
};
param_p18_audio_en.gpio.index = GET_GPIO_NUM(GPIO_P18V_AUDIO_PWREN);
register_bl31_param(&param_p18_audio_en.h);
static struct bl31_gpio_param param_p30_en = {
.h = {
.type = PARAM_SUSPEND_GPIO,
},
.gpio = {
.polarity = BL31_GPIO_LEVEL_LOW,
},
};
param_p30_en.gpio.index = GET_GPIO_NUM(GPIO_P30V_EN);
register_bl31_param(&param_p30_en.h);
}
static void register_reset_to_bl31(void)
{
static struct bl31_gpio_param param_reset = {
.h = {
.type = PARAM_RESET,
},
.gpio = {
.polarity = 1,
},
};
/* gru/kevin reset pin: gpio0b3 */
param_reset.gpio.index = GET_GPIO_NUM(GPIO_RESET),
register_bl31_param(&param_reset.h);
}
static void register_poweroff_to_bl31(void)
{
static struct bl31_gpio_param param_poweroff = {
.h = {
.type = PARAM_POWEROFF,
},
.gpio = {
.polarity = 1,
},
};
/*
* gru/kevin power off pin: gpio1a6,
* reuse with tsadc int pin, so iomux need set back to
* gpio in BL31 and depthcharge before you setting this gpio
*/
param_poweroff.gpio.index = GET_GPIO_NUM(GPIO_POWEROFF),
register_bl31_param(&param_poweroff.h);
}
static void configure_sdmmc(void)
{
gpio_output(GPIO(4, D, 5), 1); /* SDMMC_PWR_EN */
gpio_output(GPIO(2, A, 2), 1); /* SDMMC_SDIO_PWR_EN */
/* SDMMC_DET_L is different on Kevin board revision 0. */
if (IS_ENABLED(CONFIG_BOARD_GOOGLE_KEVIN) && (board_id() == 0))
gpio_input(GPIO(4, D, 2));
else
gpio_input(GPIO(4, D, 0));
gpio_output(GPIO(2, D, 4), 0); /* Keep the max voltage */
gpio_input(GPIO(4, B, 0)); /* SDMMC0_D0 remove pull-up */
gpio_input(GPIO(4, B, 1)); /* SDMMC0_D1 remove pull-up */
gpio_input(GPIO(4, B, 2)); /* SDMMC0_D2 remove pull-up */
gpio_input(GPIO(4, B, 3)); /* SDMMC0_D3 remove pull-up */
gpio_input(GPIO(4, B, 4)); /* SDMMC0_CLK remove pull-down */
gpio_input(GPIO(4, B, 5)); /* SDMMC0_CMD remove pull-up */
write32(&rk3399_grf->gpio2_p[2][1], RK_CLRSETBITS(0xfff, 0));
/*
* Set all outputs' drive strength to 8 mA. Group 4 bank B driver
* strength requires three bits per pin. Value of 2 written in that
* three bit field means '8 mA', as deduced from the kernel code.
*
* Thus the six pins involved in SDMMC interface require 18 bits to
* configure drive strength, but each 32 bit register provides only 16
* bits for this setting, this covers 5 pins fully and one bit from
* the 6th pin. Two more bits spill over to the next register. This is
* described on page 378 of rk3399 TRM Version 0.3 Part 1.
*/
write32(&rk3399_grf->gpio4b_e01,
RK_CLRSETBITS(0xffff,
(2 << 0) | (2 << 3) |
(2 << 6) | (2 << 9) | (2 << 12)));
write32(&rk3399_grf->gpio4b_e2, RK_CLRSETBITS(3, 1));
/* And now set the multiplexor to enable SDMMC0. */
write32(&rk3399_grf->iomux_sdmmc, IOMUX_SDMMC);
}
static void configure_codec(void)
{
gpio_input(GPIO(3, D, 0)); /* I2S0_SCLK remove pull-up */
gpio_input(GPIO(3, D, 1)); /* I2S0_RX remove pull-up */
gpio_input(GPIO(3, D, 2)); /* I2S0_TX remove pull-up */
gpio_input(GPIO(3, D, 3)); /* I2S0_SDI0 remove pull-up */
gpio_input(GPIO(3, D, 4)); /* I2S0_SDI1 remove pull-up */
/* GPIO3_D5 (I2S0_SDI2SDO2) not connected */
gpio_input(GPIO(3, D, 6)); /* I2S0_SDO1 remove pull-up */
gpio_input(GPIO(3, D, 7)); /* I2S0_SDO0 remove pull-up */
gpio_input(GPIO(4, A, 0)); /* I2S0_MCLK remove pull-up */
write32(&rk3399_grf->iomux_i2s0, IOMUX_I2S0);
write32(&rk3399_grf->iomux_i2sclk, IOMUX_I2SCLK);
/* AUDIO IO domain 1.8V voltage selection */
write32(&rk3399_grf->io_vsel, RK_SETBITS(1 << 1));
/* CPU1_P1.8V_AUDIO_PWREN for P1.8_AUDIO */
gpio_output(GPIO(0, A, 2), 1);
/* set CPU1_SPK_PA_EN output */
gpio_output(GPIO(1, A, 2), 0);
rkclk_configure_i2s(12288000);
}
static void configure_display(void)
{
/* set pinmux for edp HPD*/
gpio_input_pulldown(GPIO(4, C, 7));
write32(&rk3399_grf->iomux_edp_hotplug, IOMUX_EDP_HOTPLUG);
gpio_output(GPIO(4, D, 3), 1); /* CPU3_EDP_VDDEN for P3.3V_DISP */
}
google/gru: Power-cycle USB ports in developer/recovery modes Gru only uses USB 2.0 in firmware to avoid all the madness associated with Type-C port orientation and USB 3.0 tuning. We do this by isolating the SuperSpeed lines in the Type-C PHY so it looks like they aren't connected to the device. Unfortunately, some devices seem to already get "locked" into SuperSpeed mode as soon as they detect Rx terminations once, and can never snap out again on their own. Since the terminations are already connected during power-on reset we cannot disable them fast enough to prevent this, and the only solution we found to date is to power-cycle the whole USB port. Now, Gru's USB port power is controlled by the EC, and unfortunately we have no direct host command to control it. We do however have a command to force a certain USB PD "role", and forcing our host into "sink" mode makes it stop sourcing power to the port. So for lack of a saner solution we'll use this to work around our problem. BRANCH=gru BUG=chrome-os-partner:59346 TEST=Booted Kevin in recovery mode, confirmed that my "problem stick" gets detected immediately (whereas previously I had to unplug/replug it). Booted Kevin to OS in both developer and normal mode and confirmed that USB still seems to work. Change-Id: Ib3cceba9baa170b13f01bd5c01bd413be5b441ba Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: cd695eda33299e50362f1096c46f2f5260c49036 Original-Change-Id: I2db3d6d3710d18a8b8030e94eb1ac2e931f22638 Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/413031 Reviewed-on: https://review.coreboot.org/17628 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.com>
2016-11-22 05:14:18 +01:00
static void usb_power_cycle(int port)
{
if (google_chromeec_set_usb_pd_role(port, USB_PD_CTRL_ROLE_FORCE_SINK))
printk(BIOS_ERR, "ERROR: Cannot force USB%d PD sink\n", port);
mdelay(10); /* Make sure USB stick is fully depowered. */
if (google_chromeec_set_usb_pd_role(port, USB_PD_CTRL_ROLE_TOGGLE_ON))
printk(BIOS_ERR, "ERROR: Cannot restore USB%d PD mode\n", port);
}
static void setup_usb(void)
{
gru: Tuning USB 2.0 PHY0 and PHY1 host-port The commit 0ba3b2593b0c ("gru: Tuning USB 2.0 PHY to increase compatibility") bypass ODT to set the max driver strength for the Type-C otg-port, it works well on otg-port when connected with USB2.0 devices. Unfortunately, because the Type-C otg-port and host-port are consisted in one USB2 PHY, so bypass ODT will have an effect on both host-port and otg-port. I have tested the host-port eye-diagram, the result shows that if we bypass ODT, the host- port eye-diagram height will become to high, more than 500mv, this may cause USB 2.0 high-speed enumeration failure. This patch bypass ODT for host-port separately, and then we can reduce the host-port driver strength without affecting the otg-port driver strength. BRANCH=gru BUG=chrome-os-partner:60727 TEST=Boot system, run 'lsusb' command and check if the usb camera and usb bluetooth are on usb 2.0 hub or usb 1.1 hub. If they are on usb 1.1 hub, the issue happens. If not, try to run camera app and then close camera app, repeat until find that the usb camera is on the usb 1.1 hub. Change-Id: Ib693e2a6f2113c06692a7bfee22d85b67ee3b165 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 5ea7660b7b05080b76fc5ca5af3fa18552a03491 Original-Change-Id: Ia1f12182929673c5726df9f77f0903469b5c957a Original-Signed-off-by: William wu <wulf@rock-chips.com> Original-Reviewed-on: https://chromium-review.googlesource.com/425739 Original-Commit-Ready: Douglas Anderson <dianders@chromium.org> Original-Tested-by: Douglas Anderson <dianders@chromium.org> Original-Tested-by: Inno Park <ih.yoo.park@samsung.com> Original-Reviewed-by: Douglas Anderson <dianders@chromium.org> Reviewed-on: https://review.coreboot.org/18126 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.com>
2017-01-09 12:02:39 +01:00
/*
* A few magic PHY tuning values that improve eye diagram amplitude
* and make it extra sure we get reliable communication in firmware
* Set max ODT compensation voltage and current tuning reference.
*/
google/gru: Tune USB 2.0 PHY to increase compatibility When testing USB 2.0 compatibility with different kinds of USB 2.0 devices on Kevin board, we find that some USB HDDs (e.g. seagate SRD00F1 1TB HDD) and some smart phones (e.g. galaxy A5 smart phone) can't be detected. And according to the error log, this issue is related to USB 2.0 PHY signal problem. For the USB HDD, error log is: [ 592.557724] usb 5-1: new high-speed USB device number 2 using xhci-hcd [ 592.847735] usb 5-1: new high-speed USB device number 3 using xhci-hcd [ 593.473720] usb 5-1: new high-speed USB device number 6 using xhci-hcd [ 594.187717] usb 5-1: new high-speed USB device number 9 using xhci-hcd [ 595.020717] usb 5-1: new high-speed USB device number 13 using xhci-hcd [ 595.284730] usb 5-1: new high-speed USB device number 14 using xhci-hcd [ 595.574816] usb 5-1: new high-speed USB device number 15 using xhci-hcd The log shows that HDD failed to high-speed handshake. For the smart phone, error log is: [ 1145.661625] usb 5-1: new high-speed USB device number 2 using xhci-hcd [ 1145.771674] usb 5-1: device descriptor read/64, error -71 [ 1145.979752] usb 5-1: device descriptor read/64, error -71 [ 1146.187721] usb 5-1: new high-speed USB device number 3 using xhci-hcd [ 1146.301754] usb 5-1: device descriptor read/64, error -71 [ 1146.509750] usb 5-1: device descriptor read/64, error -71 [ 1146.717722] usb 5-1: new high-speed USB device number 4 using xhci-hcd [ 1146.724393] usb 5-1: Device not responding to setup address. [ 1146.930795] usb 5-1: Device not responding to setup address. [ 1147.137720] usb 5-1: device not accepting address 4, error -71 [ 1147.246644] usb 5-1: new high-speed USB device number 5 using xhci-hcd [ 1147.253336] usb 5-1: Device not responding to setup address. [ 1147.459786] usb 5-1: Device not responding to setup address. [ 1147.665712] usb 5-1: device not accepting address 5, error -71 [ 1147.671789] usb usb5-port1: unable to enumerate USB device The log shows that smart phone failed to read device descriptor, error -71 may be caused by PHY signal problem. This patch aims to tune USB 2.0 PHY with the following parameters to support USB HDD, smart phone and some other potential USB 2.0 devices. 1. Disable the pre-emphasize in chirp state to avoid high-speed handshake failure. 2. Bypass ODT auto compensation to enable set max driver strength manually. (Bit[42] of usbphy_ctrl register is 1'b1 for bypass, and Bit[41:37] of usbphy_ctrl register is 5'b10000 for max driver strength). 3. Bypass ODT auto refresh, and set the max bias current tuning reference. (Bit[57] of usbphy_ctrl register is 1'b1 for bypass, and Bit[52:50] of usbphy_ctrl register is 3b'100 for max bias current tuning reference). We have done the USB 2.0 compliance test and compatibility test with this patch, it works well. BRANCH=gru BUG=chrome-os-partner:59623 TEST=plug/unplug USB HDD or smart phone in Type-C port, check if they can be detected successfully. Change-Id: I275c2236b8e469bfd04e9184d007eb095657225e Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 7735c514d4136978133c2299f2f58da8320bb89f Original-Change-Id: I4e6c10faa1c03af9880a89afe4731a7065eb1e4e Original-Signed-off-by: William wu <wulf@rock-chips.com> Original-Reviewed-on: https://chromium-review.googlesource.com/409856 Original-Commit-Ready: Eddie Cai <eddie.cai.rk@gmail.com> Original-Tested-by: Cindy Han <cindy.han@samsung.com> Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/17566 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.com>
2016-11-10 12:34:45 +01:00
write32(&rk3399_grf->usbphy0_ctrl[3], RK_CLRSETBITS(0xfff, 0x2e3));
write32(&rk3399_grf->usbphy1_ctrl[3], RK_CLRSETBITS(0xfff, 0x2e3));
/* Set max pre-emphasis level on PHY0 and PHY1. */
write32(&rk3399_grf->usbphy0_ctrl[12],
RK_CLRSETBITS(0xffff, 0xa7));
write32(&rk3399_grf->usbphy1_ctrl[12],
RK_CLRSETBITS(0xffff, 0xa7));
/*
google/gru: Tuning USB 2.0 PHY0 and PHY1 squelch detection threshold According to USB 2.0 Spec Table 7-7, the High-speed squelch detection threshold Min 100mV and Max 150mV, and we set USB 2.0 PHY0 and PHY1 squelch detection threshold to 150mV by default, so if the amplitude of differential voltage envelope is < 150 mV, the USB 2.0 PHYs envelope detector will indicate it as squelch. On Kevin board, if we connect usb device with Samsung U2 cable, we can see that the impedance of U2 cable is too big according to the eye-diagram test report, and this cause serious signal attenuation at the end of receiver, the amplitude of differential voltage falls below 150mV. This patch aims to reduce the PHY0 and PHY1 otg-ports squelch detection threshold to 125mV (host-ports still use 150mV by default), this is helpful to increase USB 2.0 PHY compatibility. BRANCH=gru BUG=chrome-os-partner:62320 TEST=Plug Samsung U2 cable + SEC P3 HDD 500GB/Galaxy S3 into Type-C port, check if the USB device can be detected. Change-Id: Ia0a2d354781c2ac757938409490f7c4eecdffe61 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 7d74311c25762668386061234df0562f84b7203e Original-Change-Id: Ib20772f8fc2484d34c69f5938818aaa81ded7ed8 Original-Signed-off-by: William wu <wulf@rock-chips.com> Original-Reviewed-on: https://chromium-review.googlesource.com/431015 Original-Commit-Ready: Caesar Wang <wxt@rock-chips.com> Original-Tested-by: Inno Park <ih.yoo.park@samsung.com> Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/18462 Reviewed-by: Martin Roth <martinroth@google.com> Tested-by: build bot (Jenkins)
2017-01-23 13:54:22 +01:00
* 1. Disable the pre-emphasize in eop state and chirp
* state to avoid mis-trigger the disconnect detection
* and also avoid high-speed handshake fail for PHY0
* and PHY1 consist of otg-port and host-port.
google/gru: Tuning USB 2.0 PHY0 and PHY1 squelch detection threshold According to USB 2.0 Spec Table 7-7, the High-speed squelch detection threshold Min 100mV and Max 150mV, and we set USB 2.0 PHY0 and PHY1 squelch detection threshold to 150mV by default, so if the amplitude of differential voltage envelope is < 150 mV, the USB 2.0 PHYs envelope detector will indicate it as squelch. On Kevin board, if we connect usb device with Samsung U2 cable, we can see that the impedance of U2 cable is too big according to the eye-diagram test report, and this cause serious signal attenuation at the end of receiver, the amplitude of differential voltage falls below 150mV. This patch aims to reduce the PHY0 and PHY1 otg-ports squelch detection threshold to 125mV (host-ports still use 150mV by default), this is helpful to increase USB 2.0 PHY compatibility. BRANCH=gru BUG=chrome-os-partner:62320 TEST=Plug Samsung U2 cable + SEC P3 HDD 500GB/Galaxy S3 into Type-C port, check if the USB device can be detected. Change-Id: Ia0a2d354781c2ac757938409490f7c4eecdffe61 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 7d74311c25762668386061234df0562f84b7203e Original-Change-Id: Ib20772f8fc2484d34c69f5938818aaa81ded7ed8 Original-Signed-off-by: William wu <wulf@rock-chips.com> Original-Reviewed-on: https://chromium-review.googlesource.com/431015 Original-Commit-Ready: Caesar Wang <wxt@rock-chips.com> Original-Tested-by: Inno Park <ih.yoo.park@samsung.com> Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/18462 Reviewed-by: Martin Roth <martinroth@google.com> Tested-by: build bot (Jenkins)
2017-01-23 13:54:22 +01:00
*
* 2. Configure PHY0 and PHY1 otg-ports squelch detection
* threshold to 125mV (default is 150mV).
*/
google/gru: Tuning USB 2.0 PHY0 and PHY1 squelch detection threshold According to USB 2.0 Spec Table 7-7, the High-speed squelch detection threshold Min 100mV and Max 150mV, and we set USB 2.0 PHY0 and PHY1 squelch detection threshold to 150mV by default, so if the amplitude of differential voltage envelope is < 150 mV, the USB 2.0 PHYs envelope detector will indicate it as squelch. On Kevin board, if we connect usb device with Samsung U2 cable, we can see that the impedance of U2 cable is too big according to the eye-diagram test report, and this cause serious signal attenuation at the end of receiver, the amplitude of differential voltage falls below 150mV. This patch aims to reduce the PHY0 and PHY1 otg-ports squelch detection threshold to 125mV (host-ports still use 150mV by default), this is helpful to increase USB 2.0 PHY compatibility. BRANCH=gru BUG=chrome-os-partner:62320 TEST=Plug Samsung U2 cable + SEC P3 HDD 500GB/Galaxy S3 into Type-C port, check if the USB device can be detected. Change-Id: Ia0a2d354781c2ac757938409490f7c4eecdffe61 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 7d74311c25762668386061234df0562f84b7203e Original-Change-Id: Ib20772f8fc2484d34c69f5938818aaa81ded7ed8 Original-Signed-off-by: William wu <wulf@rock-chips.com> Original-Reviewed-on: https://chromium-review.googlesource.com/431015 Original-Commit-Ready: Caesar Wang <wxt@rock-chips.com> Original-Tested-by: Inno Park <ih.yoo.park@samsung.com> Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/18462 Reviewed-by: Martin Roth <martinroth@google.com> Tested-by: build bot (Jenkins)
2017-01-23 13:54:22 +01:00
write32(&rk3399_grf->usbphy0_ctrl[0],
RK_CLRSETBITS(7 << 13 | 3 << 0, 6 << 13));
write32(&rk3399_grf->usbphy1_ctrl[0],
RK_CLRSETBITS(7 << 13 | 3 << 0, 6 << 13));
write32(&rk3399_grf->usbphy0_ctrl[13], RK_CLRBITS(3 << 0));
write32(&rk3399_grf->usbphy1_ctrl[13], RK_CLRBITS(3 << 0));
/*
* ODT auto compensation bypass, and set max driver
* strength only for PHY0 and PHY1 otg-port.
*/
write32(&rk3399_grf->usbphy0_ctrl[2],
RK_CLRSETBITS(0x7e << 4, 0x60 << 4));
write32(&rk3399_grf->usbphy1_ctrl[2],
RK_CLRSETBITS(0x7e << 4, 0x60 << 4));
/*
* ODT auto refresh bypass, and set the max bias current
* tuning reference only for PHY0 and PHY1 otg-port.
*/
write32(&rk3399_grf->usbphy0_ctrl[3],
RK_CLRSETBITS(0x21c, 1 << 4));
write32(&rk3399_grf->usbphy1_ctrl[3],
RK_CLRSETBITS(0x21c, 1 << 4));
/*
* ODT auto compensation bypass, and set default driver
* strength only for PHY0 and PHY1 host-port.
*/
write32(&rk3399_grf->usbphy0_ctrl[15], RK_SETBITS(1 << 10));
write32(&rk3399_grf->usbphy1_ctrl[15], RK_SETBITS(1 << 10));
/* ODT auto refresh bypass only for PHY0 and PHY1 host-port. */
write32(&rk3399_grf->usbphy0_ctrl[16], RK_CLRBITS(1 << 9));
write32(&rk3399_grf->usbphy1_ctrl[16], RK_CLRBITS(1 << 9));
rockchip/rk3399: Add code to neuter Type-C PHY for firmware USB The Rockchip RK3399 integrates a USB Type-C PHY in charge of things like SuperSpeed line muxing for rotated cable orientations in the SoC. While fancy, this is very complicated and we don't want to implement support for the whole thing in firmware. The USB Type-C standard has intentionally been designed in a way that the USB 2.0 (HighSpeed) lines always "just work" in any orientation (by just shorting different pins in the connector together) so that simple use cases like ours can get basic USB functionality without much hassle. However, a semi-configured Type-C PHY can confuse USB 3.0 capable devices into thinking we're actually supporting SuperSpeed, and fail at that rather than establishing a reliable HighSpeed connection. This patch sets enough bits in the Type-C PHY to electrically isolate the SuperSpeed lines from the connector so that the connected device isn't going to get any fancy ideas and reliably falls back to USB 2.0. Also clean up the rest of the USB code while we're at it: avoid writing a few bits that are already in the right state from their reset values anyway, or reading values whose content we already know for this SoC. Rename the USB controllers to the name actually used in the Rockchip documentation (USB OTGx) rather than the name blindly copied from Exynos code (USB DRDx). BRANCH=None BUG=chrome-os-partner:54621 TEST=Plug a USB 3.0 Patriot Memory stick into both ports in all orientations, observe how it gets reliably detected now (safe for some known hardware issues on my board). Change-Id: Ifce6bcddd69f2e8f2e2a2f48faf65551e084da1e Signed-off-by: Martin Roth <martinroth@chromium.org> Original-Commit-Id: c526906f998bf66067d3addb8b3d3a126c188b1e Original-Change-Id: Ie80a201a58764c4d851fe4a5098a5acfc4bcebdf Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/366160 Original-Reviewed-by: liangfeng wu <wulf@rock-chips.com> Original-Reviewed-by: Shelley Chen <shchen@chromium.org> Original-Reviewed-by: <515506667@qq.com> Reviewed-on: https://review.coreboot.org/16125 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2016-08-04 04:18:39 +02:00
setup_usb_otg0();
setup_usb_otg1();
google/gru: Power-cycle USB ports in developer/recovery modes Gru only uses USB 2.0 in firmware to avoid all the madness associated with Type-C port orientation and USB 3.0 tuning. We do this by isolating the SuperSpeed lines in the Type-C PHY so it looks like they aren't connected to the device. Unfortunately, some devices seem to already get "locked" into SuperSpeed mode as soon as they detect Rx terminations once, and can never snap out again on their own. Since the terminations are already connected during power-on reset we cannot disable them fast enough to prevent this, and the only solution we found to date is to power-cycle the whole USB port. Now, Gru's USB port power is controlled by the EC, and unfortunately we have no direct host command to control it. We do however have a command to force a certain USB PD "role", and forcing our host into "sink" mode makes it stop sourcing power to the port. So for lack of a saner solution we'll use this to work around our problem. BRANCH=gru BUG=chrome-os-partner:59346 TEST=Booted Kevin in recovery mode, confirmed that my "problem stick" gets detected immediately (whereas previously I had to unplug/replug it). Booted Kevin to OS in both developer and normal mode and confirmed that USB still seems to work. Change-Id: Ib3cceba9baa170b13f01bd5c01bd413be5b441ba Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: cd695eda33299e50362f1096c46f2f5260c49036 Original-Change-Id: I2db3d6d3710d18a8b8030e94eb1ac2e931f22638 Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/413031 Reviewed-on: https://review.coreboot.org/17628 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.com>
2016-11-22 05:14:18 +01:00
/*
* Need to power-cycle USB ports for use in firmware, since some devices
* can't fall back to USB 2.0 after they saw SuperSpeed terminations.
* This takes about a dozen milliseconds, so only do it in boot modes
* that have firmware UI (which one could select USB boot from).
*/
if (display_init_required()) {
usb_power_cycle(0);
usb_power_cycle(1);
}
}
static void mainboard_init(device_t dev)
{
deassert_wifi_power();
configure_sdmmc();
configure_emmc();
configure_codec();
configure_display();
setup_usb();
register_reset_to_bl31();
register_poweroff_to_bl31();
register_gpio_suspend();
register_apio_suspend();
}
static void enable_backlight_booster(void)
{
const struct {
uint8_t reg;
uint8_t value;
} i2c_writes[] = {
{1, 0x84},
{1, 0x85},
{0, 0x26}
};
int i;
const int booster_i2c_port = 0;
uint8_t i2c_buf[2];
struct i2c_seg i2c_command = { .read = 0, .chip = 0x2c,
.buf = i2c_buf, .len = sizeof(i2c_buf)
};
/*
* This function is called on Gru right after BL_EN is asserted. It
* takes time for the switcher chip to come online, let's wait a bit
* to let the voltage settle, so that the chip can be accessed.
*/
udelay(1000);
gpio_input(GPIO(1, B, 7)); /* I2C0_SDA remove pull_up */
gpio_input(GPIO(1, C, 0)); /* I2C0_SCL remove pull_up */
i2c_init(0, 100*KHz);
write32(&rk3399_pmugrf->iomux_i2c0_sda, IOMUX_I2C0_SDA);
write32(&rk3399_pmugrf->iomux_i2c0_scl, IOMUX_I2C0_SCL);
for (i = 0; i < ARRAY_SIZE(i2c_writes); i++) {
i2c_buf[0] = i2c_writes[i].reg;
i2c_buf[1] = i2c_writes[i].value;
i2c_transfer(booster_i2c_port, &i2c_command, 1);
}
}
void mainboard_power_on_backlight(void)
{
gpio_output(GPIO_BACKLIGHT, 1); /* BL_EN */
if (IS_ENABLED(CONFIG_BOARD_GOOGLE_GRU) && board_id() == 0)
enable_backlight_booster();
}
static void mainboard_enable(device_t dev)
{
dev->ops->init = &mainboard_init;
}
struct chip_operations mainboard_ops = {
.name = CONFIG_MAINBOARD_PART_NUMBER,
.enable_dev = mainboard_enable,
};