This patch adds support for an alternative ternary number system in
which group of GPIOs can be interpreted. In this system, the digit
combinations that would form a binary number (i.e. that contain no 'Z'
state) are used to represent the lower values in the way they're used in
the normal binary system, and all the combinations that do contain a 'Z'
are used to represent values above those. We can use this for boards
that originally get strapped with binary board IDs but eventually
require more revisions than that representation allows. We can switch
their code to binary_first base3 and all old revisions with already
produced boards will still get read as the correct numbers.
Credit for the algorithm idea goes to Haran Talmon.
BRANCH=None
BUG=None
TEST=Stubbed out the actual GPIO reading and simulated all combinations
of 4 ternary digits for both number systems.
Change-Id: Ib5127656455f97f890ce2999ba5ac5f58a20cf93
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/14116
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/412365
Commit-Queue: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
Initialize the gpio for buzzer which would be used in depthcharge.
BUG=chrome-os-partner:59202
BRANCH=veyron
TEST=tested with CL:406773
Change-Id: Ie17fb5959d572b4ba284ff86c3a1fa5527d4526e
Signed-off-by: ZhengShunQian <zhengsq@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/407127
Reviewed-by: Julius Werner <jwerner@chromium.org>
There are two configs sdram-lpddr3-hynix-2GB.inc and
sdram-lpddr3-samsung-2GB-24EB.inc use .ddrconfig = 14 now.
Changing .ddrconfig from 14 to 3 could help improving performance
especially when accessing to contiguous memory. Comparing the .ddrconfig:
- if .ddrconfig = 3,
C RDRR RRRR RRRR RRRR RBBB CCCC CCCC C---
- if .ddrconfig = 14,
C DRBB BRRR RRRR RRRR RRRR CCCC CCCC C---
where
- R: indicates Row bits
- B: indicates Bank bits
- C: indicates Column bits
- D: indicates Chip selects bits
Because with .ddrconfig = 3, there are multi banks switching and saving
DDR timing.
BUG=chrome-os-partner:57321
TEST=Boot from fievel and play video
BRANCH=veyron
Change-Id: Ic98ebae48609a7604ec678b6bd14dd2b29b669c4
Signed-off-by: ZhengShunQian <zhengsq@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/402809
Reviewed-by: Julius Werner <jwerner@chromium.org>
Add lpddr3-K4E6E304EB-2GB-1CH memory configuration for rialto.
BUG=chrome-os-partner:56759
BRANCH=none
TEST=Build
Change-Id: I7dae9fd822abeff5b08de0ab9262e1817ac58531
Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/381801
Commit-Queue: Alexandru Stan <amstan@chromium.org>
Tested-by: Alexandru Stan <amstan@chromium.org>
Trybot-Ready: Alexandru Stan <amstan@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
An RC circuit will be added on Tiger/Fievel to solve the S3 blinking.
The new GPIO7_A3 behavior is the following:
- in S0, GPIO7_A3(low) -> LED on.
- in S3, GPIO7_A3(high)-> LED blinking.
BUG=chrome-os-partner:55306
TEST=power on fievel with rework RC circuit, LED on in S0.
BRANCH=None
Change-Id: I52ec6c9608868bb784469edcbfb74e53a30393bf
Signed-off-by: Pan Sheng-Liang <Sheng-Liang.Pan@quantatw.com>
Reviewed-on: https://chromium-review.googlesource.com/365251
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Ren Kuo <ren.kuo@quantatw.com>
Trybot-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Ren Kuo <ren.kuo@quantatw.com>
Commit-Queue: Ren Kuo <ren.kuo@quantatw.com>
Reads the MAC address from the VPD ethernet_mac0 if it exists,
stores it the coreboot table for depthcharge consumption.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=veyron
BUG=chrome-os-partner:53191 chrome-os-partner:53964
TEST=along with the matching depthcharge change, provision a MAC address
on a Tiger device by doing 'vpd -s ethernet_mac0=0a1f9c9bfada' and
ensure that it is properly set in the MAC hardware after reboot by
running 'ifconfig' and checking
'/proc/device-tree/ethernet\@ff290000/mac-address'.
Change-Id: I0a7bb25cd6b094261dda2be25aa89b38b4707868
Reviewed-on: https://chromium-review.googlesource.com/348831
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Enable 5v_drv for usb and hdmi.
For tiger(chromebase with eDP), set the vop mode to
VOP_MODE_AUTO_DECTECT so it would fall through
to hdmi if there is not edp(or edp initialized failed).
For fievel(chromebox without eDP), set vop mode to VOP_MODE_HDMI.
BRANCH=veyron
BUG=none
TEST=check usb/hdmi function
Change-Id: I4bce8fb35a108a590608b3f7084e6be7b200aa5c
Signed-off-by: ZhengShunQian <zhengsq@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/345747
Commit-Queue: Ren Kuo <ren.kuo@quantatw.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Adapt the files copied from veyron_romy to veyron_tiger
BUG=None
TEST=emerge-veyron_tiger coreboot chromeos-bootimage
BRANCH=firmware-veyron-6588.B
Change-Id: I8a2dd74126d2322ed227e0eb6e2fbdae1325bc76
Signed-off-by: philipchen <philipchen@google.com>
Reviewed-on: https://chromium-review.googlesource.com/338194
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: Philip Chen <philipchen@chromium.org>
Commit-Queue: Philip Chen <philipchen@chromium.org>
The developer mode gpio switch on rialto is always hardcoded (through a
resistor) as developer mode. We need to ignore it to allow transitions to
verified mode with the virtual developer mode stuff.
This was not needed in master due to CL:261588, but this is a more semantic
way to do it.
BRANCH=veyron
BUG=chrome-os-partner:46150, chrome-os-partner:43022
TEST=We can now exit dev mode on rialto
Change-Id: If11d752d58a5f26fc270ef01b529dad18b4cce46
Signed-off-by: Alexandru M Stan <amstan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/325546
Reviewed-by: Julius Werner <jwerner@chromium.org>
This is a follow-up to CL:320623 to make veyron DRAM configs
uniform (except for Rialto).
As discussed in chrome-os-partner:43626, the mr[3] value and ODT
are set diffently for Mickey, thus the .inc files for other boards
have mr[3] = 1 and ODT disabled.
For cherry-picking, the change was applied for all Chromebook
platforms individually rather than just src/mainboard/veyron/.
BUG=none
BRANCH=veyron
TEST=compile tested for veyron
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: Iacf821645a2dcceaed1c1c42e3e1b1c312b31eab
Reviewed-on: https://chromium-review.googlesource.com/322487
Updating Hynix memory configuration for mickey so that it can boot on Hynix board.
BUG=chrome-os-partner:48637
BRANCH=master
TEST=Boot on mickey hynix board
Change-Id: Id63d74cac36b9fd84bdb88969291982e14fa7d01
Signed-off-by: Lang Zhang <kingsley_zhang@asus.com>
Reviewed-on: https://chromium-review.googlesource.com/320623
Commit-Ready: lang zhang <kingsley_zhang@asus.com>
Tested-by: lang zhang <kingsley_zhang@asus.com>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/322633
Commit-Queue: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
This makes the same changes to the LPDDR3 configuration that
were made for Samsung modules:
- Enable ODT function
- Change DS to 40 Ω from 34.3 Ω
BUG=chrome-os-partner:47416
BRANCH=firmware-veyron-6588.B
TEST=Boot on mickey elpida board
Change-Id: I2d54d3087ecd3536469866f30e4eb2d8b1acd5c1
Signed-off-by: jiazi Yang <Tomato_Yang@asus.com>
Reviewed-on: https://chromium-review.googlesource.com/311153
Reviewed-by: Julius Werner <jwerner@chromium.org>
Right now our EDID logic isn't very smart. It always just picks the
first detailed mode and ignores the rest. It's possible that this
detailed mode might be too fast for us, so let's allow some filtering.
We'll use this filtering to filter out modes > 165 MHz on the rk3288
HDMI port.
We choose 165 MHz for HDMI because this is the fasest you can go over
single link DVI. We could try to be smart and allow faster speeds if we
detect that we're on HDMI, but this is unlikely to work anyway because >
165 MHz we start getting really jittery without a lot more work on HDMI
clocks.
This happens to make the HP ZR30w show the BIOS dev screen now.
BRANCH=none
BUG=chrome-os-partner:47008
TEST=HP ZR30w works
Change-Id: I1d20090b8ad84717ecc56a27ffe4ab0ee312628a
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/309568
Reviewed-by: David Hendricks <dhendrix@chromium.org>
When booting, you see:
EDID version: %hd.%hd
Let's fix it to print the actual version.
BRANCH=none
BUG=none
TEST=No longer see wrong printout
Change-Id: Id954856538938961678027d5fdc881d9ea270e26
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/309599
The detailed_cvt_descriptor() function takes a parameter "out" for no
good reason. Remove it.
BRANCH=none
BUG=chrome-os-partner:46998
TEST=Build and boot
Change-Id: I4d695a6dba6606d2132578ce0ab4cb612c83d0f4
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/309598
The EDID parsing code continued to update _some_ fields of the output
edid but not others if "did_detailed_timing" was already set. It also
then went on to print out this halfway mix of modes each time, despite
the fact that it didn't really update everything.
Let's fix that. We'll reduce code changes by using a temporary copy of
data in detailed_block() and then we'll copy it back if we decide we
should update.
BRANCH=none
BUG=chrome-os-partner:46998
TEST=No more bogus printouts
Change-Id: Ia72cac7fda2772f26477e43237678fa30feca584
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/309541
The set to say that a standard timing was supported was not properly in
the "if" test. That meant that even when standard timings weren't
supported, we thought that they were. That had the side effect of never
using the detailed mode.
BRANCH=none
BUG=chrome-os-partner:46998
TEST=Adafruit panel works now
Change-Id: Ib67735219fd28516857d9b63f1ba156573f1bea3
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/309521
The hardcoded clock value for 640x480 was 25.175 MHz. That's a valid
clock to use, but is quite hard to make a non-jittery clock from PLLs.
It's much easier to make 25.200 MHz, so let's do that.
The difference between the two modes is 59.9 Hz vs. 60 Hz and it seems
better to make a non-jittery 60 Hz rather than a very jittery 59.9 Hz.
BRANCH=none
BUG=chrome-os-partner:46256
TEST=Insignia monitor works, so do others
Change-Id: Ia9804afe8011a915e4bec306e863d34ad7e27be5
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/309540
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Previously if we tried to read the HDMI EDID several times and failed
each time then we're return from hdmi_read_edid() with no error. Then
we'd interpret whatever happened to be in memory at the time as an
EDID--not so great.
Let's actually look at the error.
BRANCH=none
BUG=chrome-os-partner:46256
TEST=Monitor that can't read EDID not shows that in the log
Change-Id: I9089755b75118499bec37bdb96d1635f66252e65
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/309316
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Yakir Yang <ykk@rock-chips.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Commit-Queue: Julius Werner <jwerner@chromium.org>
Tested-by: Julius Werner <jwerner@chromium.org>
HDMI soft reset happens when you write 0, not 1. ...not that I've ever
seen the soft reset do something, but if we're going to try it we should
probably try to do it correctly.
BRANCH=none
BUG=chrome-os-partner:46256
TEST=Doesn't break anything
Change-Id: I0f4ab869b1e1a2d4a38f0eacfd01b01760069f58
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/309317
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Yakir Yang <ykk@rock-chips.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Commit-Queue: Julius Werner <jwerner@chromium.org>
Tested-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Agnes Cheng <agnescheng@google.com>
Commit-Queue: Agnes Cheng <agnescheng@google.com>
Trybot-Ready: Agnes Cheng <agnescheng@google.com>
Tested-by: Agnes Cheng <agnescheng@google.com>
vboot handoff should look at flags in struct vb2_shared_data when
translating flags to VBSD_BOOT_REC_SWITCH_ON because
VBSD_BOOT_REC_SWITCH_ON is supposed to indicate whether manual recovery was
triggered or not while vb2_sd->recovery_reason will be able to provide
that information only in some cases after CL:307586 is checked in.
For example, this fixes a recovery loop problem: Without this fix,
vb2_sd->recovery_reason won't be set to VB2_RECOVERY_RO_MANUAL when user
hits esc+refresh+power at 'broken' screen. In the next boot,
recovery_reason will be set to whatever reason which caused 'broken'
screen. So, if we check recovery_reason == VB2_RECOVERY_RO_MANUAL, we
won't set vb_sd->flags to VBSD_BOOT_REC_SWITCH_ON. That'll cause a
recovery loop because VbBootRecovery traps us again in the 'broken'
screen after not seeing VBSD_BOOT_REC_SWITCH_ON.
BUG=chromium:501060
BRANCH=tot
TEST=test_that -b veyron_jerry suite:faft_bios
Change-Id: I3da642ff2d05c097d10db303fc8ab3358e10a5c7
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/307946
Reviewed-by: Randall Spangler <rspangler@chromium.org>
(cherry picked from commit d9679b02f6d21ed903bb02e107badb0fbf7da46c)
Reviewed-on: https://chromium-review.googlesource.com/309247
Commit-Queue: Julius Werner <jwerner@chromium.org>
Tested-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
On one particular TV the TV was holding SDA low when it came up. It
would release the SDA when the SCL went low the first time.
Unfortunately the HDMI i2c port wouldn't transmit until the SDA was
released.
Let's detect this case and insert a bogus clock pulse to try to get the
other side to release SDA.
It's unclear why the kernel doesn't have this problem.
BRANCH=none
BUG=chrome-os-partner:46256
TEST=Insignia TV works now
Change-Id: I4b6361877e0576cc4ea2f643f073f1aab660e434
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/309258
Reviewed-by: Agnes Cheng <agnescheng@google.com>
Commit-Queue: Agnes Cheng <agnescheng@google.com>
Trybot-Ready: Agnes Cheng <agnescheng@google.com>
Tested-by: Agnes Cheng <agnescheng@google.com>
HDMI driver need to know whether the monitor is DVI
or HDMI interface, so this commit just introduce a
new number 'hdmi_monitor_detected' to struct edid.
There were four bits to indicate the monitor interfaces,
it's better to take use of that. But those bits only
existed in EDID 1.4 version, but didn't persented in
the previous EDID version, so I decided to detect the
hdmi cea block.
BRANCH=none
BUG=chrome-os-partner:43789
TEST=When mickey connect with HDMI monitor, see 'hdmi_monitor_detected' is 'true'.
When mickey connect with DVI monitor, see 'hdmi_monitor_detected' is 'false'.
Change-Id: Ife770898b0f2b4f58b8259711101a0cab4a5e4ac
Signed-off-by: Yakir Yang <ykk@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/309275
Reviewed-by: Agnes Cheng <agnescheng@google.com>
Commit-Queue: Agnes Cheng <agnescheng@google.com>
Trybot-Ready: Agnes Cheng <agnescheng@google.com>
Tested-by: Agnes Cheng <agnescheng@google.com>
'edid->hdmi_monitor_detected' would indicate whether the monitor
interface is HDMI or DVI.
BRANCH=none
BUG=chrome-os-partner:43789
TEST=Previously, my LG monitor couldn't show dev screen. But now I can see
dev screen have been posted normally.
Change-Id: I157861d327926b834e1e8606b0b676f413491c70
Signed-off-by: Yakir Yang <ykk@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/309370
Reviewed-by: Agnes Cheng <agnescheng@google.com>
Commit-Queue: Agnes Cheng <agnescheng@google.com>
Trybot-Ready: Agnes Cheng <agnescheng@google.com>
Tested-by: Agnes Cheng <agnescheng@google.com>
This patch does a few things:
- write32() -> writel()
- Adds config files for Rialto
- No program_loading.h in FW branch
- No run_ramstage in FW branch, use older stage_exit() instead
- Kconfig stuff:
CONSOLE_SERIAL_UART -> DRIVERS_UART
BOARD_ID_SUPPORT -> BOARD_ID_AUTO
MAINBOARD_HAS_CHROMEOS -> MAINBOARD_HAS_BOOTBLOCK_INIT
Added RETURN_FROM_VERSTAGE - selected with rk3288 in toT
Added ELOG - selected along with CHROMEOS in ToT
Set VBOOT_*_INDEX - Set in .config files in ToT
Except for the actual board differences, this should look a lot
like other non-laptop veyrons in the firmware branch.
BUG=chrome-os-partner:46150
BRANCH=firmware-veyron
TEST=built and booted on Rialto
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: I446bde4f074ffe943a78ddcb0e979c0ffa5a1036
Reviewed-on: https://chromium-review.googlesource.com/304108
Reviewed-by: Alexandru Stan <amstan@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
This is a straight copy of src/mainboard/google/veyron_rialto from
ToT. The next patch in the series will show differences necessary
to get it to build in the firmware branch.
The reason for doing it this way is because a lot of changes from ToT
have already been applied to other non-laptop Veyron boards. So it
doesn't make a whole lot of sense to re-apply them individually just
for Rialto. And since Rialto has been in the tree for a long
time and has accumulated a lot of history, things would be quite
broken up until the later patches if we tried.
Coreboot for Rialto will not compile with this. The follow-up patch
must be applied for it to build successfully.
CQ-DEPEND=CL:304108
BUG=chrome-os-partner:46150
BRANCH=firmware-veyron
TEST=built and booted on Rialto w/ follow-up patch
Change-Id: I90eb9af3b4f31b656ecdded20e0a556fef2609d0
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/304107
Reviewed-by: Alexandru Stan <amstan@chromium.org>
If recovery mode is detected, throttle down APLL frequency to 600MHz
and VDD_ARM to 900mV. This is intended to mitigate the possibility
of thermal shutdown if the system is left at the recovery screen for
a long period of time.
Experimentally, going lower than 600MHz didn't help decrease
temperature significantly and added a few seconds to recovery
boot time.
BUG=chrome-os-partner:41201
BRANCH=firmware-veyron
TEST=built and booted on mickey, normal mode boot time was normal (~1.8s)
and RK808 temperature remained steady at recovery screen for ~14 hours.
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: I82cbc1f591cbfae5ccf4e99e468f2b053c835639
Reviewed-on: https://chromium-review.googlesource.com/299718
Reviewed-by: Julius Werner <jwerner@chromium.org>
Commit-Queue: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
BUG=chrome-os-partner:41201
BRANCH=firmware-veyron
TEST=tested with subsequent patch on mickey
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: I3ce0f7b2772c8c652b7f461749d01cc7b669b6cf
Reviewed-on: https://chromium-review.googlesource.com/300786
Reviewed-by: Julius Werner <jwerner@chromium.org>
Commit-Queue: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
This changes the API to rkclk_configure_cpu() such that we can pass
in the desired APLL frequency in each veyron board's bootblock.c.
Devices with a constrainted form facter (rialto and possibly mickey)
will use this to run firmware at a slower speed to mitigate risk
of thermal issues (due to the RK808, not the RK3288).
BUG=chrome-os-partner:42054
BRANCH=firmware-veyron
TEST=amstan says rialto is noticably cooler (and slower)
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/297190
Reviewed-by: Julius Werner <jwerner@chromium.org>
Change-Id: I960cb6ff512c058e72032aa2cbadedde97510631
Reviewed-on: https://chromium-review.googlesource.com/299714
I don't quite remember when we decided to add Danger to the firmware
branch in the first place, but it looks like we did and we didn't bring
all of its SDRAM configs with us from ToT. This patch syncs them back to
where Jerry is, since they should be 100% identical.
Also, this whole copy&pasting when cherry-picking SDRAM CLs makes me
anxious... one line too few or too many removed could have very ugly
consequences. Let's add another assertion to try to catch that should it
ever happen.
BRANCH=veyron
BUG=None
TEST=None
Change-Id: I7c142b7d329733e3e5af7aac1e623437224a315e
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/295443
Reviewed-by: David Hendricks <dhendrix@chromium.org>
BRANCH=None
TEST=Boot from veyron
BUG=None
Change-Id: I68b105aa4bc3e82ef6a2421b127391e319c34d6e
Signed-off-by: jinkun.hong <jinkun.hong@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/294660
Reviewed-by: Julius Werner <jwerner@chromium.org>
(cherry picked from commit c115d9a3ea2ca1cb62b2a1ee75996d8adb991d5d)
jwerner: Added Minnie
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/294763
(cherry picked from commit 6fe83821013954f0f2069598fd90a2d49de81101)
jwerner: Removed Danger and Shark, added Gus, Jaq, Nicky and Thea
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/295442
only modify the MR3 value, there will always be some mickey not working properly.
After enable ODT, we use many mickey do tests, now functioning properly.
BRANCH=None
BUG=chrome-os-partner:43626
TEST=My mickey now boots up
Change-Id: Ieb2b8a56054f91b6be81260e4c574425fb72fed3
Signed-off-by: jinkun.hong <jinkun.hong@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/293324
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Commit-Queue: Douglas Anderson <dianders@chromium.org>
Trybot-Ready: Douglas Anderson <dianders@chromium.org>
Tested-by: Douglas Anderson <dianders@chromium.org>
(cherry picked from commit 5397c2f32f5851b9f514b0bd2ae68999a77cabbf)
Reviewed-on: https://chromium-review.googlesource.com/294270
If an HDMI display is detected (EDID can be read), set the
display mode to 480p. If for some reason 480p is not supported
then we'll fall back to the automatically detected display mode.
BUG=chrome-os-partner:42946
BRANCH=firmware-veyron
TEST=dev mode screen shows up on Mickey at 480p resolution
Change-Id: I90dea37daa2d78628230d7d47f7ef0e917cbd7bb
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/290554
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/293883
Due to HDMI need to set dclk_rate to 27Mhz, and we can't
caclu a suitable config paramters for this rate, so we
need to multiple rate unless the vco larger then VCO_MAX.
When NPLL rate multiple to 54MHz, pll_para_config could
caclu a right paramters, and I have verify the clock jitter
is okay to HDMI output.
Jitter Reports:
Dclk Rate NPLL Rate nr/no/nf jitter Margin
27MHz 54MHz 2/10/45 449.0ps +51.0%
Note for cherry-picking: Fixed writel()/write32() conflicts.
BRANCH=None
BUG=chrome-os-partner:42946
TEST=Mickey board, show right recovery picture on TV,
and 480p clock jitter test passed
Signed-off-by: Yakir Yang <ykk@rock-chips.com>
Change-Id: Iab274b41f163d2d61332df13e5091f0b605cb65c
Reviewed-on: https://chromium-review.googlesource.com/288416
Commit-Queue: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/293882
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Assume that HDMI implies usage of an external display, and that we
want to try bringing up display if we can read an EDID.
BUG=chrome-os-partner:42946
BRANCH=firmware-veyron
TEST=none; need a display with corrupt EDID to test with
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: I9e22984a98b1a5f8cd9645b92dc9b87e8d968f01
Reviewed-on: https://chromium-review.googlesource.com/293608
This ensures the output buffer is initialized before exiting
decode_edid() so that if the return value is ignored in higher-level
logic (like when dealing with external displays) we don't leave
the struct filled with garbage.
BUG=chrome-os-partner:42946
BRANCH=firmware-veyron
TEST=none
Change-Id: I697436fffadc7dd3af239436061975165a97ec8c
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/293607
This patch will let you to choose a favourite mode to
display, while not just taking the edid detail timing.
But not all modes are able to set, only modes that
are in established or standard timing, and we only
support a few common common resolutions for now.
BUG=chrome-os-partner:42946
BRANCH=firmware-veyron
TEST=tested dev mode on Mickey at 640x480@60Hz
Change-Id: Iaa8c9a6fad106ee792f7cd1a0ac77e3dcbadf481
Signed-off-by: Yakir Yang <ykk@rock-chips.com>
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/293606
This replaces various timing mode parameters parameters with
an edid_mode struct within the edid struct.
Notes for cherry-picking: Reverted ToT's changes to
src/soc/nvidia/tegra132/dp.c. Most of that file wasn't implemented
in the firmware-veyron branch, so pretty much the whole file showed
up as a diff. For src/soc/rockchip/rk3288/hdmi.c, there were some
simple conflicts caused by the writel/write32 transition.
BUG=none
BRANCH=firmware-veyron
TEST=built and booted on Mickey, saw display come up, also
compiled for link,falco,peppy,rambi,nyan_big,rush,smaug
Change-Id: I1bfba5b06a708d042286db56b37f67302f61fff6
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/289964
Reviewed-by: Yakir Yang <ykk@rock-chips.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/293605
There are serveral members of the edid struct which are never used
outside of the EDID parsing code itself. This patch moves them to a
struct in edid.c. They might be useful some day but until then we can
just pretty print them and not pollute the more general API.
Note for cherry-picking: There seem to be some formatting patches for
edid.c that never made it into the firmware branch, so for this patch
conflicts were resolved by just taking the newer (more correct)
version that was tested in ToT.
BUG=none
BRANCH=firmware-veyron
TEST=compiled for veyron_mickey, peppy, link, nyan_big, rush, smaug
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: I7fb8674619c0b780cc64f3ab786286225a3fe0e2
Reviewed-on: https://chromium-review.googlesource.com/290333
Reviewed-by: Yakir Yang <ykk@rock-chips.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Commit-Queue: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/293604
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Struct edid defien pvsync & phsync as an character,
like '+' or '-', so we need to check sync polarity
by comparing with characters '+' and '-' instead of
treating as boolean.
BRANCH=None
BUG=chrome-os-partner:42946
TEST=Mickey board, light monitor normally
Change-Id: I14c72aa8994227092a1059d2b25c1dd2249b9db1
Signed-off-by: Yakir Yang <ykk@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/289963
Reviewed-by: Julius Werner <jwerner@chromium.org>
Commit-Queue: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/293603
Reviewed-by: David Hendricks <dhendrix@chromium.org>
This avoids any ambiguity or breakage in case the vop_modes get
shuffled around or changed in some future patch or copy+paste job.
Brain and Rialto need some more work done so their devicetree.cb
files will be updated in follow-up patches.
BUG=none
BRANCH=none
TEST=compiled only (for danger, jerry, mickey, romy, speedy)
Change-Id: I4fd549c82c8a5c31525c4e485fa8df73f33f2049
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: bd88973b53949058331613c7582650fbd4ea48db
Original-Change-Id: I47da45c5fd9648544392de8d76f86af812de9093
Original-Signed-off-by: David Hendricks <dhendrix@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/282610
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/10776
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: https://chromium-review.googlesource.com/293008
Reviewed-by: Julius Werner <jwerner@chromium.org>
Commit-Queue: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
The value of 0x4 (60 Ohm) apperas to be causing lots of problems.
Since 0x1 (34.3 Ohm) was _almost_ right, let's try 0x2 (40 Ohm) and
hope it's the sweet spot.
BRANCH=None
BUG=chrome-os-partner:43626
TEST=My mickey now boots up
Change-Id: If8b7d51d058ae000c0af189a648c62fa38a872ac
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/291121
Reviewed-by: Julius Werner <jwerner@chromium.org>
