summaryrefslogtreecommitdiff
path: root/src/mainboard/google/gru/mainboard.c
AgeCommit message (Collapse)Author
2018-02-02google/gru: Use newer version of Innolux P097PFG panel init codeLin Huang
There is a line artifact in the lower third of the display with the current initialization code. So update it with code provided by Innolux to fix this issue. BUG=b:69689064, b:72191820 TEST=boot on dru with an Innolux panel and artifact line disappear. Change-Id: I9679c4f7f706fd6cd2e1dba7ec79e772fe3f227a Signed-off-by: Lin Huang <hl@rock-chips.com> Reviewed-on: https://review.coreboot.org/23561 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Matthias Kaehlcke <mka@chromium.org> Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2018-01-29google/scarlet: Add initialization sequence for Innolux P097PFG panelLin Huang
Innolux didn't deliver a working init sequence yet for devices without OTP programming. The sequence in this change has been derived from a register dump of a mostly working panel with OTP. It is not meant to be final, but to make devices with unprogrammed OTP work, while Innolux is figuring out a proper sequence. There is a known issue with an artifact line in the lower third of the display. Change-Id: I7096506208e4cb29c5f31a7ac502231a6c23ac92 Signed-off-by: Lin Huang <hl@rock-chips.com> Reviewed-on: https://review.coreboot.org/23311 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Matthias Kaehlcke <mka@chromium.org> Reviewed-by: Julius Werner <jwerner@chromium.org>
2018-01-29rockchip/rk3399: Support LONG_WRITE type in MIPI DSILin Huang
Some panels need to transfer initial code, and some of them will be over 3 bytes, so support LONG_WRITE type in driver. Refactor mipi dsi transfer function to support it. Change-Id: I212c14165e074c40a4a1a25140d9e8dfdfba465f Signed-off-by: Lin Huang <hl@rock-chips.com> Reviewed-on: https://review.coreboot.org/23299 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org>
2017-12-12google/scarlet: support INNOLUX P097PFG panelLin Huang
Add INNOLUX P097PFG panel timing. According to Scalet schematic, if GPIO3_D4 get low status, it will use INNOLUX P097PFG panel; if GPIO3_D4 get high status, it will use KD097d04 panel. Change-Id: I43fa5d859a9a529a84c58a953b37d03953ce648a Signed-off-by: Lin Huang <hl@rock-chips.com> Reviewed-on: https://review.coreboot.org/22780 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2017-12-11google/gru: Stop mucking with unused I2S0 pins in codec configJulius Werner
Due to a schematic error, our code was written to configure more I2S0 pins than are actually used. We're also pinmuxing the whole bank of pins over to the I2S controller even though we don't need them all. Restrict the GPIO initialization and pinmuxing to the pins we really need so the other ones can be correctly used as SKU ID pins on Scarlet. Also, move the "audio" IO voltage domain selection to the other such selections in the bootblock, since that covers two whole banks of GPIOs and there's no guarantee that they're all used for audio (and thus not needed before ramstage). BUG=b:69373077 TEST=Booted Scarlet, confirmed correct SKU ID (7) was detected on rev2. Change-Id: I9314617e725fe83d254984529f269d4442e736f1 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/22791 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: David Schneider <dnschneid@chromium.org>
2017-12-07google/scarlet: update Kingdisplay kd097d04 timingLin Huang
With the old timing, the hblank time isn't large enough, it may cause display artifacts. So fix it. BUG=b:70160653 TEST=panel work on Scarlet rev2 board Change-Id: Ib061f5e215611d20f59e3f24cfe3c7fbc507ebed Signed-off-by: Lin Huang <hl@rock-chips.com> Reviewed-on: https://review.coreboot.org/22746 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org>
2017-11-28google/scarlet: support kd097d04 panelLin Huang
Support kd097d04 dual mipi panel on Scarlet. Change-Id: Ie8bc0cbb79840f1924a8cc111f2511292203731f Signed-off-by: Lin Huang <hl@rock-chips.com> Reviewed-on: https://review.coreboot.org/22472 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org>
2017-11-28google/gru: correct backlight gpioLin Huang
it uses backlight enable pin as backlight gpio currently, correct it and define the right backlight gpio. Change-Id: I7c5abfd5bbbae015b899f3edc8892ea32bf82463 Signed-off-by: Lin Huang <hl@rock-chips.com> Reviewed-on: https://review.coreboot.org/22529 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org>
2017-11-28rockchip/rk3399: support dual mipi dsiLin Huang
Refactor the mipi driver, so we can support dual mipi panel. And pass the panel data from mainboard.c, that we can support different panel with different board. Change-Id: Id1286c0ccbe50c89514c8daee66439116d3f1ca4 Signed-off-by: Lin Huang <hl@rock-chips.com> Reviewed-on: https://review.coreboot.org/22471 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Brian Norris <briannorris@chromium.org> Reviewed-by: Julius Werner <jwerner@chromium.org>
2017-11-22google/gru: Add support for rainierEge Mihmanli
Rainier is a scarlet-derived board but uses eDP as opposed to MIPI. Using GRU_BASEBOARD_SCARLET is enough, except for display related logic. In those cases, use board specific logic instead of baseboard. Change-Id: I596f7ca6bc26312ecaeb261c96cebd46974c2cdf Signed-off-by: Ege Mihmanli <egemih@google.com> Reviewed-on: https://review.coreboot.org/22542 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org>
2017-11-20google/gru: Add config for scarlet-derived boardsEge Mihmanli
There is merit in having new boards use the pinouts and controls in scarlet. This adds a config so new scarlet-derived boards can easily use scarlet structure without going through every file and adding new logic. TEST=Run "emerge-scarlet coreboot" Signed-off-by: egemih@chromium.org Change-Id: I5808f93f4563033ce93050e1eedb6eac2b52c3b3 Reviewed-on: https://review.coreboot.org/22517 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org>
2017-11-06gru: Fix and export SPK_PA_EN GPIO for ScarletJulius Werner
On older Grus, GPIO0_A2 was an audio voltage rail enable line. On Scarlet, we instead moved the audio codec enable (previously on GPIO1_A2) there. Unfortunately the code still had some hardcoded leftovers that were overlooked in the initial port and make our speakers smell weird. This patch fixes the incorrect GPIO settings and adds the speaker enable pin to the GPIOs passed through the coreboot table, so that depthcharge doesn't have to keep its own definition of the pin which may go out of sync. Change-Id: I1ac70ee47ebf04b8b92ff17a46cbf5d839421a61 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/22323 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: David Schneider <dnschneid@chromium.org> Reviewed-by: Alexandru Stan <amstan@chromium.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2017-09-06google/gru: Re-enable 3V rail GPIO on ScarletJulius Werner
We've decided to move control for the 3.0V rail (technically 3.3V on Scarlet, but who cares about millivolts) back to a GPIO on the AP for Scarlet rev2. This patch adds the necessary code to enable it and make ARM TF aware of its existence. Since the pin had previously not been connected to anything, we shouldn't really need to guard this by board ID... older Scarlets will just be twiddling an empty pin. Change-Id: I6037aa486b50119f2c7b859b966cadc3686e3459 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/21328 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: David Schneider <dnschneid@chromium.org>
2017-08-31google/gru: Support Nefario rev0Philip Chen
Do not assert GPIO1_B3 otherwise BT would be disabled on Nefario. Also, remove DVS support for CENTERLOGIC. BUG=b:64702054, b:63537905 TEST=build coreboot Change-Id: I350db2c080f2e41ae56413f5f895557978ef0ba8 Signed-off-by: Philip Chen <philipchen@google.com> Reviewed-on: https://review.coreboot.org/21176 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org>
2017-08-18include/device: Split i2c.h into threeNico Huber
Split `i2c.h` into three pieces to ease reuse of the generic defi- nitions. No code is changed. * `i2c.h` - keeps the generic definitions * `i2c_simple.h` - holds the current, limited to one controller driver per board, devicetree independent I2C interface * `i2c_bus.h` - will become the devicetree compatible interface for native I2C (e.g. non-SMBus) controllers Change-Id: I382d45c70f9314588663e1284f264f877469c74d Signed-off-by: Nico Huber <nico.huber@secunet.com> Reviewed-on: https://review.coreboot.org/20845 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2017-08-01google/gru: Correct the Sdcard control gpio setting for ScarletLin Huang
in Scarlet the Sdcard control gpio differs from other board variants, So set the GPIO to high on Scarlet. Change-Id: I5fa19b212a716213462eea58b6242392d32a2c5c Signed-off-by: Lin Huang <hl@rock-chips.com> Reviewed-on: https://review.coreboot.org/20803 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2017-07-19google/gru: Add support for Scarlet rev1Julius Werner
This patch adds the necessary changes to support Scarlet revision 1. Since the differences to revision 0 are so deep, we have decided not to continue support for it in the same image. Therefore, this patch will break Scarlet rev0. All the deviations from other Gru boards are currently guarded by CONFIG_BOARD_GOOGLE_SCARLET. This should be changed later if we introduce more variants based on the newer Scarlet board design. Change-Id: I7a7cc11d9387ac1d856663326e35cfa5371e0af2 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/20587 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: David Schneider <dnschneid@chromium.org>
2017-07-19rockchip/rk3399: Adjust gpio_t format to match ARM TFJulius Werner
Our structure packing for Rockchip's gpio_t was chosen arbitrarily. ARM Trusted Firmware has since become a thing and chosen a slightly different way to represent GPIOs in a 32-bit word. Let's align our format to them so we don't need to remember to convert the values every time we pass them through. CQ-DEPEND=CL:572228 Change-Id: I9ce33da28ee8a34d2d944bee010d8bfc06fe879b Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/20586 Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2017-06-15google/gru: drive the stronger pull-up for touchpadCaesar Wang
As the hardware designed on gru, the AP_I2C_TP_PU_EN (gpio3_b4) controlled the SCL/SDA status to avoid leakage. And the gpio3_b4 of rk3399 pull resistor is 26k~71k and 3.3v for supply power, and gpio3_b4 pin connected 2.2k resistor to i2c of TP device. The default of this gpio status is pulled up during the start to bootup, it's very weak drive for the TP device that maybe cause to trigger the recovery process of elan's firmware. Also, the Elan updated its firmware(102.0.5.0) to delay checking the i2c of touchpad is greater than 1 second. So we have to drive the stronger pull-up within 1 second of powering up the touchpad to prevent its firmware from falling into recovery. Change-Id: I9a67d1c041afafde24ed9f00716ba41a9b41a8da Signed-off-by: Caesar Wang <wxt@rock-chips.com> Reviewed-on: https://review.coreboot.org/19863 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Julius Werner <jwerner@chromium.org>
2017-05-03google/gru: skip usbphy1 setup for Scarletphilipchen
Board Scarlet doesn't use usbphy1. BUG=b:37685249 TEST=boot Scarlet, check the firmware log, and confirm no errors about USB1 Change-Id: I66e0d8a235cc9057964f7abca32bc692d41e88fd Signed-off-by: Philip Chen <philipchen@google.com> Reviewed-on: https://review.coreboot.org/19489 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org>
2017-04-25google/gru: change the sd power sequenceCaesar Wang
In the safety considerations, we should make sure the slot of SD is enabled first, since we want to the power switch of corresponding is powered up. The different boards have the different power switch for sdmmc. Some power switch IC need turn on delay for long time. let's move the slot power of SD to romstage and avoid explicit delays or per-board. BRANCH=none BUG=b:35813418, b:35573103 TEST=check the signal for children of gru, and boot up from sd card. Change-Id: Id164e4c4c900c6b1ca0251fc27db4cd36c56f6ff Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: ea1b01cc13628033b85251dbb44407f075efdc85 Original-Change-Id: I48ab543143d3de9be46608fc12d78e09decf8d79 Original-Signed-off-by: Caesar Wang <wxt@rock-chips.com> Original-Reviewed-on: https://chromium-review.googlesource.com/447076 Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/19430 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.com>
2017-04-06gru: Initialize I2C bus for ARC2C0608Philip Chen
BUG=b:35583511 TEST=check i2c bus 0 initializes from ap console log Change-Id: Ibb6709159f5ed28ad0b62397d2ddb504dec55167 Signed-off-by: Philip Chen <philipchen@google.com> Reviewed-on: https://review.coreboot.org/19105 Tested-by: build bot (Jenkins) Reviewed-by: Julius Werner <jwerner@chromium.org>
2017-02-23google/gru: Tuning USB 2.0 PHY0 and PHY1 squelch detection thresholdWilliam wu
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-02-23google/gru: improve eye diagram for passing the testCaesar Wang
The children of Gru should share the benefits. In the real world, Bob can't pass the eye diagram tests. BUG=chrome-os-partner:62714 BRANCH=firmware-gru-8785.B TEST=build coreboot Change-Id: I2470bbc81acdaf2458d660dca5dc307cc3038f83 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: d0cb3e718a7571f602a00c08a42019851634e7fd Original-Change-Id: I0ccb48bb52eb770ccc9c8c265b07df46b0308dd3 Original-Signed-off-by: Caesar Wang <wxt@rock-chips.com> Original-Reviewed-on: https://chromium-review.googlesource.com/440745 Original-Reviewed-by: Douglas Anderson <dianders@chromium.org> Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/441468 Reviewed-on: https://review.coreboot.org/18461 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.com>
2017-01-22gru: kevin: define GPIOs used on both platformsVadim Bendebury
The same GPIOs are used on both platforms, definitions are added an a new .h to make it easier to re-use them across the code. BRANCH=none BUG=chrome-os-partner:51537 TEST=panel backlight still enabled on Gru as before. The rest of the GPIOs are used in the upcoming patches. Change-Id: I54ef3e8dd79670bdb037baeec91430113d11bcc1 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: c58788026f28af52c650da0159b93d97269ca4a9 Original-Change-Id: I1a6c5b5beb82ffcc5fea397e8e9ec2f183f4a7e0 Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/346219 Original-Tested-by: Shunqian Zheng <zhengsq@rock-chips.com> Reviewed-on: https://review.coreboot.org/18176 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.com>
2017-01-13gru: Tuning USB 2.0 PHY0 and PHY1 host-portWilliam wu
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>
2016-12-06Bob: Update the memory ramid of bobShasha Zhao
Update the memory ramid. Move to one CA training pattern. BUG=chrome-os-partner:59454 BRANCH=firmware-gru-8785.B TEST=Build firmware passed Change-Id: Ic05cbc1700a13e372f63d5202459add0e984f9d8 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 1030a78af3d489d13508f17a79df1e65bd5afa3b Original-Change-Id: Ibe8acb5b698cec1adcdddbb13d35a5e20a5b8c0d Original-Reviewed-on: https://chromium-review.googlesource.com/414664 Original-Commit-Ready: Shasha Zhao <Sarah_Zhao@asus.com> Original-Tested-by: Shasha Zhao <Sarah_Zhao@asus.com> Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Original-Change-Id: I0ae46e496cd18492a2b6c7167081798c2f2479b1 Original-Signed-off-by: Shasha Zhao <Sarah_Zhao@asus.com> Original-Reviewed-on: https://chromium-review.googlesource.com/411645 Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/17679 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.com>
2016-12-06Bob: add bob in corebootShasha Zhao
Add bob in coreboot and update as necessary. 1. Add bob HWID 2. Add supported memory source BUG=chrome-os-partner:59454 BRANCH=firmware-gru-8785.B TEST=Build firmware passed Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Change-Id: Iad03a293bdbbb89450f0fea0822e34a4be7064bf Original-Commit-Id: bff788c71a43403bff2c23b38e69cc27fb869559 Original-Change-Id: I0dcf47eb911337b176f73759a2c70a9dbf4dc68b Original-Signed-off-by: Shasha Zhao <Sarah_Zhao@asus.com> Original-Reviewed-on: https://chromium-review.googlesource.com/411083 Original-Reviewed-by: Philip Chen <philipchen@chromium.org> Original-(cherry picked from commit c5925dfcf59ac755a26182744b2bde59e41a37cf) Original-Reviewed-on: https://chromium-review.googlesource.com/413744 Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/17678 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.com>
2016-12-06google/gru: Power-cycle USB ports in developer/recovery modesJulius Werner
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-29google/gru: Tune USB 2.0 PHY to increase compatibilityWilliam wu
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-10-08google/gru: Add USB 2.0 PHY tuning for Kevin PHY0 and PHY1William wu
We found that Kevin board PHY0 and PHY1 eye-diagram margin is not enough to make compliance test pass, and the PHY0 USB SI is worse than PHY1, because of the higher PCB impedance. For PHY0, we can't improve the eye-diagram by SW PHY tuning, so we need to reduce the RBIAS resistance from 133 ohm to 115 ohm, it can help to increase the eye-height. For PHY1, we can improve the eye-diagram by setting the max pre-emphasis level. And after the above change, the USB2 signal amplitude will become larger at the test point near to SOC USB2 PHY, in order to avoid mis-trigger the disconnect detection (650mV), we need to disable pre-emphasize in eop state. BRANCH=None BUG=chrome-os-partner:53863 TEST=do USB 2.0 compliance test for Kevin C0 and C1 port. Change-Id: I95c0acd79623aeca9a0ae077b1dd3836d91fe561 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: de3cdef128966d76e7d8e2ebd641763b911c3ad5 Original-Change-Id: I00cb325b9938e4276cc77b5d6f5faa7023379608 Original-Signed-off-by: William wu <wulf@rock-chips.com> Original-Reviewed-on: https://chromium-review.googlesource.com/390615 Original-Commit-Ready: Julius Werner <jwerner@chromium.org> Original-Tested-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/16911 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.com>
2016-10-07google/gru: drive WLAN_MODULE_RST# low as early as possibleBrian Norris
GPIO1_B3 (WLAN_MODULE_RST#) defaults as a pull-up input, but it is also "pulled up" by 1.8V_WLAN. However, 1.8V_WLAN remains low for some time during early boot. This leaves the signal floating somewhere in the middle. This has two potential issues: (1) we're leaking some power for some (hopefully) short period of time (2) we are possibly screwing with the Wifi power sequence; we aren't supposed to deassert PDn (i.e., MODULE_RST#) until all the rails have fully ramped for some period of time Neither of the above issues are likely to be significant, but it is nice to fix, I expect. BRANCH=gru BUG=chrome-os-partner:54026 TEST=measure WLAN_MODULE_RST# on scope at boot time Change-Id: Ia6af9ad6954ad8feeda33015e3f205842380939e Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 0e890a2787bf034d3358a33fc88c2dd8078593ab Original-Change-Id: I120e26ad0ca486a326874986e142dcaee965b62d Original-Signed-off-by: Brian Norris <briannorris@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/388009 Original-Reviewed-by: Douglas Anderson <dianders@chromium.org> Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/16882 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Martin Roth <martinroth@google.com>
2016-10-07google/gru: pass apio number to arm-trust-firmwareLin Huang
To save power when entering suspend, gpios 2 to 4 need to be set to input and 'pull none' mode. Pass the APIO configuration to ATF so it can do a proper job here. BRANCH=None BUG=chrome-os-partner:56423 TEST=run suspend_stress_test on kevin board Change-Id: Id57fe8f622ae3f9c2bc7e58be89518b2b846cd37 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 9c42082d1ca9a6baa735821382d3e83c1f8dc9ad Original-Change-Id: Iaf441e8e34c5591ffe7c65f6533fcf0b733ff5ac Original-Signed-off-by: Lin Huang <hl@rock-chips.com> Original-Reviewed-on: https://chromium-review.googlesource.com/378475 Original-Commit-Ready: Caesar Wang <wxt@rock-chips.com> Original-Tested-by: Caesar Wang <wxt@rock-chips.com> Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/16720 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.com>
2016-10-07google/gru: pass the gpio power supply enable pin to bl31Lin Huang
We need to disable some regulators when the device goes into suspend. This means that we need to pass some gpios to bl31, and disable these gpios when bl31 runs the suspend function. BRANCH=None BUG=chrome-os-partner:56423 TEST=enter suspend, measure suspend gpio go to low [pg: also update arm-trusted-firmware to match] Change-Id: Ia0835e16f7e65de6dd24a892241f0af542ec5b4b Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 0f3332ef2136fd93f7faad579386ba5af003cf70 Original-Change-Id: I03d0407e0ef035823519a997534dcfea078a7ccd Original-Signed-off-by: Lin Huang <hl@rock-chips.com> Original-Reviewed-on: https://chromium-review.googlesource.com/374046 Original-Commit-Ready: Caesar Wang <wxt@rock-chips.com> Original-Tested-by: Caesar Wang <wxt@rock-chips.com> Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/16719 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.com>
2016-10-04google/gru: Ensure correct pull resistors for special-function pinsJulius Werner
Several of the special function pins we're using in firmware have a pre-assigned pull-up or pull-down on power-on reset. We don't want those to interfere with any of the signaling we're trying to do on those pins, so this patch disables them. Also do some house-cleaning to group the bootblock code better, and change the setup code for all SPI and I2C buses to first initialize the controller and then mux the pins... I assume this might be a little safer (in case the controller peripheral has some pins in a weird state before it gets fully initialized, we don't want to mux it through too early). BRANCH=None BUG=chrome-os-partner:52526 TEST=Booted Kevin. Change-Id: I4d5bd3f7657b8113d90b65d9571583142ba10a27 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: f8f7fd56e945987eb0b1124b699f676bc68d0560 Original-Change-Id: I6bcf2b9a5dc686f2b6f82bd80fc9a1a245661c47 Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/382532 Reviewed-on: https://review.coreboot.org/16711 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.com>
2016-09-20gru: Add USB 2.0 PHY tuning for KevinJulius Werner
This patch sets some magic number in magic undocumented registers that are rumored to make USB 2.0 signal integrity better on Kevin. I don't see any difference (unfortunately it doesn't solve the problems with long cables on my board), but I guess it doesn't hurt either way. BRANCH=None BUG=chrome-os-partner:56108,chrome-os-partner:54788 TEST=Booted Kevin with USB connected through Servo. Seems to have roughly the same failure rate as before. Change-Id: If31fb49f1ed7218b50f24e251e54c9400db72720 Signed-off-by: Martin Roth <martinroth@chromium.org> Original-Commit-Id: 0c5c8f0f80ea1ebb042bcb91506a6100833e7e84 Original-Change-Id: Ifbd47bf6adb63a2ca5371c0b05c5ec27a0fe3195 Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/370900 Original-Reviewed-by: Guenter Roeck <groeck@chromium.org> Original-Reviewed-by: David Schneider <dnschneid@chromium.org> Reviewed-on: https://review.coreboot.org/16265 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2016-08-16Revert "rockchip: rk3399: enable sdhci clk for emmc"Shunqian Zheng
This reverts commit 462e1413 ("rockchip: rk3399: enable sdhci clk for emmc") Enabling this clock in coreboot is no longer needed as it's handled in the kernel driver now. BUG=chrome-os-partner:52873 TEST=boot from usb/sdcard and check there is /dev/mmcblk0 BRANCH=none Change-Id: I92cf51f175fe56a09ab9329b29a27c77ef4328e1 Signed-off-by: Martin Roth <martinroth@chromium.org> Original-Commit-Id: 5707d1269a253dabf825be120d1f9348ffaab6d0 Original-Change-Id: I8bca870c663d8ce8fac5daaaaf8225489f22ed13 Original-Signed-off-by: Shunqian Zheng <zhengsq@rock-chips.com> Original-Reviewed-on: https://chromium-review.googlesource.com/367421 Original-Commit-Ready: Brian Norris <briannorris@chromium.org> Original-Reviewed-by: Douglas Anderson <dianders@chromium.org> Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/16152 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2016-08-13Revert "gru: Show the current time on start-up"Julius Werner
This reverts commit 850e45f19f498eedd80da4a97a5ce641e2cec6d5. google_chromeec_init() is a weird function that can lead to confusing behavior. I'm not sure how it's meant to work on the boards that use it, but it causes problems on Kevin and other non-x86 boards have never used it either. It doesn't really do anything anyway (the EC works fine without an initial HELLO), so at best it's just a waste of time... let's take it back out. There's also no need to display the current time on every boot... other boards don't do that and the eventlog already fills the same purpose. Cut it out to avoid one extra host command overhead. BRANCH=None BUG=chrome-os-partner:55995 TEST=Recovery reasons now get correctly propagated across the EC reboot. Change-Id: Ic3b772780d4d05e362c269969e6e4e7069482bb6 Signed-off-by: Martin Roth <martinroth@chromium.org> Original-Commit-Id: 103d86e68cd164bea39aa1edc8668d80358edbde Original-Change-Id: I58fd5e6094e1c8cb6368e7a4569ab9231375fbc9 Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/367351 Original-Reviewed-by: Simon Glass <sjg@chromium.org> Original-Reviewed-by: Shelley Chen <shchen@chromium.org> Reviewed-on: https://review.coreboot.org/16153 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2016-08-11rockchip/rk3399: Add code to neuter Type-C PHY for firmware USBJulius Werner
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-03google/gru: Add support for Gru rev1Julius Werner
This patch adds support for the Gru rev1 board. This board differs from rev0 by no longer relying on the I2C backlight booster and requiring the same ODT SDRAM settings as newer Kevin boards. BRANCH=None BUG=chrome-os-partner:55087 TEST=None Change-Id: I1428760540a0aaaa0c02c6cb5b0981294ba4df33 Signed-off-by: Martin Roth <martinroth@chromium.org> Original-Commit-Id: 8de7bcc78c6c48c251c85185e238cea7812f7a28 Original-Change-Id: I3cb49bc644190f35300e6c618b2934956fa88e5b Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/364624 Original-Reviewed-by: Douglas Anderson <dianders@chromium.org> Reviewed-on: https://review.coreboot.org/16028 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2016-07-28chromeos: Clean up elog handlingFurquan Shaikh
1. Currenty, boot reason is being added to elog only for some ARM32/ARM64 platforms. Change this so that boot reason is logged by default in elog for all devices which have CHROMEOS selected. 2. Add a new option to select ELOG_WATCHDOG_RESET for the devices that want to add details about watchdog reset in elog. This requires a special region WATCHDOG to be present in the memlayout. 3. Remove calls to elog add boot reason and watchdog reset from mainboards. BUG=chrome-os-partner:55639 Change-Id: I91ff5b158cfd2a0749e7fefc498d8659f7e6aa91 Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: https://review.coreboot.org/15897 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins)
2016-06-24gru: Add elog supportSimon Glass
Add code to start up elog. This uses the EC RTC to obtain the timestamp. BUG=chrome-os-partner:52220 BRANCH=none TEST=boot on gru with CONFIG_ELOG_DEBUG enabled and see elog messages Change-Id: I4971d661b267ae8b7e3befeff482ca703b741743 Signed-off-by: Martin Roth <martinroth@chromium.org> Original-Commit-Id: e4e9823d8cecbf9873e78b048e389c7a737ff512 Original-Change-Id: I0fcf55b3feccf9a0ad915deb6d323b65bf2e9811 Original-Signed-off-by: Simon Glass <sjg@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/353822 Original-Commit-Ready: Vadim Bendebury <vbendeb@chromium.org> Original-Tested-by: Vadim Bendebury <vbendeb@chromium.org> Original-Reviewed-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: https://review.coreboot.org/15306 Tested-by: build bot (Jenkins) Reviewed-by: Furquan Shaikh <furquan@google.com>
2016-06-24gru: Show the current time on start-upSimon Glass
Display the current time from the EC. BUG=chrome-os-partner:52220 BRANCH=none TEST=(partial) boot on gru and see output: Date: 1970-01-17 (Saturday) Time: 1:42:44 Then reboot ~10 seconds later and see output: Date: 1970-01-17 (Saturday) Time: 1:42:53 Change-Id: I4288efc56f00e47f7575d0379a44871351da6200 Signed-off-by: Martin Roth <martinroth@chromium.org> Original-Commit-Id: d0361193e0ec135e21f0611d7fa6e5c02f2b2bfc Original-Change-Id: I04a072c788ba3fc915e6d73703f966955bbd3e7e Original-Signed-off-by: Simon Glass <sjg@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/351783 Original-Commit-Ready: Vadim Bendebury <vbendeb@chromium.org> Original-Tested-by: Vadim Bendebury <vbendeb@chromium.org> Original-Reviewed-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: https://review.coreboot.org/15304 Tested-by: build bot (Jenkins) Reviewed-by: Furquan Shaikh <furquan@google.com>
2016-06-21rockchip: gru: pass poweroff gpio parameter to BL31Lin Huang
To support gpio power off SOC, we need to pass the power off gpio parameter to BL31. Gru reuse tsadc overtemp pin as power off gpio, so need to iomux to gpio function when use gpio power off function, either in bl31 or depthcharge. BRANCH=None BUG=chrome-os-partner:53448 TEST=Build gru Change-Id: Ibfe64042f39f6df1b87536b50fe432859bf74426 Signed-off-by: Martin Roth <martinroth@chromium.org> Original-Commit-Id: Original-Change-Id: Ie7a1bbea4a12753f0abac7a9142f2e032686ce31 Original-Signed-off-by: Lin Huang <hl@rock-chips.com> Original-Signed-off-by: Douglas Anderson <dianders@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/349703 Original-Reviewed-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: https://review.coreboot.org/15119 Tested-by: build bot (Jenkins) Reviewed-by: Furquan Shaikh <furquan@google.com>
2016-06-21rockchip: gru: pass reset gpio parameter to BL31Lin Huang
To support gpio reset SOC, we need to pass the reset gpio parameter to BL31. Note: request BL31 have supported this function. BRANCH=None BUG=chrome-os-partner:51924 TEST=Build gru Change-Id: I182cff11ce6f5dc3354db0dc053c128b813acf9f Signed-off-by: Martin Roth <martinroth@chromium.org> Original-Commit-Id: Original-Change-Id: I8283596565d552b1f3db31c28621a1601c226999 Original-Signed-off-by: Lin Huang <hl@rock-chips.com> Original-Signed-off-by: Douglas Anderson <dianders@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/349702 Original-Reviewed-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: https://review.coreboot.org/15118 Reviewed-by: Furquan Shaikh <furquan@google.com> Tested-by: build bot (Jenkins)
2016-06-12rockchip: gru: Add USB DRD DWC3 controller supportLiangfeng Wu
This patch adds code to initialize the two DWC3 USB host controllers, and uses them to initialize USB3.0 on the gru rk3399 board. BRANCH=none BUG=chrome-os-partner:52684 TEST=boot from USB3.0 on gru/kevin rk3399 platform Change-Id: If6a6e56f3a7c7ce8e8b098634cfc2f250a91810d Signed-off-by: Martin Roth <martinroth@chromium.org> Original-Commit-Id: 0306a9e Original-Change-Id: I796fa1133510876f75873d134ea752e1b52e40a8 Original-Signed-off-by: Liangfeng Wu <wulf@rock-chips.com> Original-Signed-off-by: Douglas Anderson <dianders@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/347524 Original-Commit-Ready: Brian Norris <briannorris@chromium.org> Original-Reviewed-by: Vadim Bendebury <vbendeb@chromium.org> Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/15112 Tested-by: build bot (Jenkins) Reviewed-by: Furquan Shaikh <furquan@google.com>
2016-06-08rockchip: rk3399: Add support i2sXing Zheng
This patch enable and configure the clocks and IOMUX for i2s audio path, and the i2s0 clock is from CPLL. Please refer to TRM V0.3 Part 1 Chapter 3 CRU, P126/P128/P144/P154/P155 for the i2s clock div and gate setting. BRANCH=none BUG=chrome-os-partner:52172 TEST=boot kevin rev1, press ctrl+u and hear the beep voice. Change-Id: Id00baac965c8b9213270ba5516e1ca684e4304a6 Signed-off-by: Martin Roth <martinroth@chromium.org> Original-Commit-Id: 9c58fa7 Original-Change-Id: I130a874a0400712317e5e7a8b3b10a6f04586f68 Original-Signed-off-by: Xing Zheng <zhengxing@rock-chips.com> Original-Reviewed-on: https://chromium-review.googlesource.com/347526 Original-Commit-Ready: Wonjoon Lee <woojoo.lee@samsung.com> Original-Reviewed-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: https://review.coreboot.org/15034 Tested-by: build bot (Jenkins) Reviewed-by: Furquan Shaikh <furquan@google.com>
2016-06-08gru: kevin: define GPIOs used on both platformsVadim Bendebury
The same GPIOs are used on both platforms, definitions are added an a new .h to make it easier to re-use them across the code. BRANCH=none BUG=chrome-os-partner:51537 TEST=panel backlight still enabled on Gru as before. The rest of the GPIOs are used in the upcoming patches. Change-Id: If06f4b33720ab4bf098d23fb91322bba23fe6e90 Signed-off-by: Martin Roth <martinroth@chromium.org> Original-Commit-Id: c587880 Original-Change-Id: I1a6c5b5beb82ffcc5fea397e8e9ec2f183f4a7e0 Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/346219 Original-Tested-by: Shunqian Zheng <zhengsq@rock-chips.com> Reviewed-on: https://review.coreboot.org/15029 Tested-by: build bot (Jenkins) Reviewed-by: Furquan Shaikh <furquan@google.com>
2016-06-03rockchip: gru: enable eDP displayLin Huang
This patch enables eDP display by: o. setting HPD pinmux, backlight, vdd for eDP o. setting vop mode o. enabling VGA configs for edid BRANCH=none BUG=chrome-os-partner:51537 TEST=The dev screen is shown on kevin board Change-Id: If8b07307454daa88727d317cc208d6c97de07ad7 Signed-off-by: Martin Roth <martinroth@google.com> Original-Commit-Id: b1ad9337510f5437f691153dc68883edf273e4c7 Original-Change-Id: Id7006619b5be638b286a5402d892a5361ac1e430 Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/340026 Original-Reviewed-by: Shunqian Zheng <zhengsq@rock-chips.com> Reviewed-on: https://review.coreboot.org/14858 Tested-by: build bot (Jenkins) Reviewed-by: Furquan Shaikh <furquan@google.com>
2016-05-18rockchip: rk3399: enable sdhci clk for emmcShunqian Zheng
If booting from sdcard/usb, kernel can't recognize the /dev/mmcblk0. Before kernel find it's root cause, we add this workaround patch to enable clk for emmc. BRANCH=none BUG=chrome-os-partner:52873 TEST=boot from sdcard and check the /dev/mmcblk0 exists Change-Id: Ie36cc6fdbc24db8c30984c02ccfe2f8aaaf30cd2 Signed-off-by: Martin Roth <martinroth@google.com> Original-Commit-Id: 39b87ec3c73d6f56efc8c3f52b7ed759e548ee85 Original-Change-Id: I88a9cc2e3ea5a56aadfdbd94ef910daaf92a7eb7 Original-Signed-off-by: Shunqian Zheng <zhengsq@rock-chips.com> Original-Reviewed-on: https://chromium-review.googlesource.com/341632 Original-Commit-Ready: Vadim Bendebury <vbendeb@chromium.org> Original-Tested-by: Vadim Bendebury <vbendeb@chromium.org> Original-Reviewed-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: https://review.coreboot.org/14856 Tested-by: build bot (Jenkins) Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
2016-05-18rockchip: rk3399: configure emmc clkLin Huang
Select aclk_emmc and clk_emmc source from GPLL, and both to 198MHz, that is GPLL(594MHz) divided by 3. BRANCH=none BUG=chrome-os-partner:51537 TEST=boot kevin rev1 to chromeos prompt from both emmc and sdcard TEST=LoadKernel faster, more than twice as I measured manually. Change-Id: I2580c43b8c79049c3fe16bbf60bfa1a8e0559948 Signed-off-by: Martin Roth <martinroth@google.com> Original-Commit-Id: 5fd37b66dcce77354e1cafab0d6e806d832c08d2 Original-Change-Id: Id22815b302af3204e0e5537af99c1577b09b0877 Original-Signed-off-by: Lin Huang <hl@rock-chips.com> Original-Signed-off-by: Shunqian Zheng <zhengsq@rock-chips.com> Original-Reviewed-on: https://chromium-review.googlesource.com/339152 Original-Commit-Ready: Vadim Bendebury <vbendeb@chromium.org> Original-Tested-by: Vadim Bendebury <vbendeb@chromium.org> Original-Reviewed-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: https://review.coreboot.org/14855 Tested-by: build bot (Jenkins) Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
2016-05-18rk3399: set proper configuration of SDMMC interfaceVadim Bendebury
For proper interface operation the drive strength on all pins is set to 8 mA and all pull ups/pull downs disabled, this matches the current kernel configuration. BRANCH=none BUG=chrome-os-partner:53257 TEST=it is possible to boot Chrome OS on Gru from various micro SD cards which were failing to boot before. Change-Id: Ie43e52a52cd0513d48d0ecc8ac02fbb100baf9a4 Signed-off-by: Martin Roth <martinroth@google.com> Original-Commit-Id: 6bb0549ed728ac3c5faab6cbe16e2487400e67ed Original-Change-Id: I5180537d3ceb74a9a2f7b3982ca94d3e2daf0369 Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/344491 Original-Reviewed-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: https://review.coreboot.org/14853 Tested-by: build bot (Jenkins) Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
2016-05-18gru: set correct gpio for SD card detectVadim Bendebury
The only outlier at this time is Kevin rev 0, treat it specially, the rest of the targets use the same GPIO. BRANCH=none BUG=none TEST=gru still boots off SD card just fine Change-Id: Ic603093a990d27166b16175db3303f155b4775aa Signed-off-by: Martin Roth <martinroth@google.com> Original-Commit-Id: 5788c5add1d1f803e7b22fb53215b6003ac04d03 Original-Change-Id: Ic5183f08dd1119f9588f243bd9e9c080d84687f9 Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/344151 Original-Reviewed-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: https://review.coreboot.org/14851 Tested-by: build bot (Jenkins) Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
2016-05-09google/gru: kevin: use board version specific SD detect GPIO pinVadim Bendebury
This change reflects Kevin schematics differences, Gru will have to be addressed separately. BRANCH=None BUG=None TEST=the code still works fine on Kevin proto 1. Change-Id: Iecae0e82e6bd4d185b49587b6053dcef8ad2162d Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: e821bbebe902a293b1e78cdd868f6bf3548ddd30 Original-Change-Id: Icd606285aeca1e19189f5e3d24c09b376942708b Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/340429 Original-Reviewed-by: Patrick Georgi <patrick@georgi-clan.de> Reviewed-on: https://review.coreboot.org/14728 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2016-05-09google/gru: power up SD cardVadim Bendebury
Make sure SD card is powered up properly. Please refer to TRM V0.3 Part1 Page 324 for sdmmc pinmux. BRANCH=none BUG=chrome-os-partner:51537 TEST=With other patches, boot into chromeos prompt Change-Id: Ib53b05c1fce851ca7cbcc2207fce2dce3b1bfe9a Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: d37e688a458749e331a50c2ebf2018cba6629823 Original-Change-Id: I9f67c0bc16ddefa5ebe52a10c6d9e54194828a89 Original-Signed-off-by: Lin Huang <hl@rock-chips.com> Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/337192 Reviewed-on: https://review.coreboot.org/14718 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2016-04-16google/gru: Incorporate feedback to #14279Patrick Georgi
To avoid diverging too much on an actively developed code base, keep the changes to a separate commit that can be downstreamed more easily: - removed unused includes - gave kevin board a "Kevin" part number - marked RW_LEGACY as CBFS region (to follow up upstream changes) - moved romstage entry point to SoC code (instead of encouraging per-board copy pasta) Change-Id: Ief0c8db3c4af96fe2be2e2397d8874ad06fb6f1f Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: https://review.coreboot.org/14362 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2016-04-16google/gru: Add a stub rk3399 mainboardhuang lin
Most things still need to be filled in, but this will allow us to build boards which use this SOC. [pg: separated out from the combined commit that added both SoC and board. Added board_info.txt that will be added downstream, too.] Change-Id: I7facce7b98a5d19fb77746b1aee67fff74da8150 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 27dfc39efe95025be2271e2e00e9df93b7907840 Original-Change-Id: I6f2407ff578dcd3d0daed86dd03d8f5f4edcac53 Original-Signed-off-by: huang lin <hl@rock-chips.com> Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/332385 Reviewed-on: https://review.coreboot.org/14279 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.com> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
generated by cgit v1.2.3 (git 2.25.1) at 2024-10-30 01:21:47 +0000