This is necessary to support generic gpio interface in src/lib. This
file will be later populated with more GPIO definitions.
BRANCH=none
BUG=chrome-os-partner:31438
TEST=none
Change-Id: I68c9c3a28fcc747575436b502cb25b31afed8700
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/226181
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
In the case of an EC wake event that is pending but not cleared
it is possible for the EC wake pin (i.e. GPIO27) to be asserted
after the kernel triggers the sleep SMI but before the system
goes to sleep.
If this happens then the GPE will be reported as a wake source
when the system wakes up again.
BUG=chrome-os-partner:33218
BRANCH=samus,auron
TEST=build and boot on samus, use the keyboard to enter suspend
with suspend_stress_test and ensure that only the RTC is listed
as a wake source upon resume.
Change-Id: I319dc22e21126a3086415f8f8b2b35eaec66fd50
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/225540
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
- Add the Whirlwind board ID to the enum
- Replace comparisons of the board ID with 0 to the proto0 constant
TEST=Booted Storm with this coreboot version
BUG=none
BRANCH=none
Change-Id: I75c7c98732c3d4569611de54d7aa149dd3b0fb7d
Signed-off-by: Dan Ehrenberg <dehrenberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/225460
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
This patch runs basic NAND initialization code on Proto 0.2 boards which
have been reworked for NAND. It makes sense to do this in coreboot for
two reasons:
- In general, it is reasonable for coreboot to initialize clocks and such
in preparation for depthcharge's use. Waiting times can be pooled, and
the initialization itself here is very fast.
- There is a kernel bug which requires that the clock already be initialized
before the kernel loads NAND support. Coreboot is a more sensible place
to put a workaround than depthcharge because depthcharge initializes
things lazily, but when booting from USB, depthcharge won't need to look
at NAND. Partner bug 33270
This change involves bringing in an additional header file, ebi2.h, from uBoot.
TEST=Booted a kernel from USB and verified that NAND came up without any
depthcharge hacks, whereas previously a USB-booted kernel would be unable
to access NAND even with the same drivers compiled in due to an initialization
failure.
BUG=chromium:403432
BRANCH=none
Signed-off-by: Dan Ehrenberg <dehrenberg@chromium.org>
Change-Id: I1760ecb4e47438311d80e34326e45578c608481c
Reviewed-on: https://chromium-review.googlesource.com/225277
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
We've had gpiolib.h which defines a few common GPIO access functions for
a while, but it wasn't really complete. This patch adds the missing
gpio_output() function, and also renames the unwieldy
gpio_get_in_value() and gpio_set_out_value() to the much easier to
handle gpio_get() and gpio_set(). The header is renamed to the simpler
gpio.h while we're at it (there was never really anything "lib" about
it, and it was presumably just chosen due to the IPQ806x include/
conflict problem that is now resolved).
It also moves the definition of gpio_t into SoC-specific code, so that
different implementations are free to encode their platform-specific
GPIO parameters in those 4 bytes in the most convenient way (such as the
rk3288 with a bitfield struct). Every SoC intending to use this common
API should supply a <soc/gpio.h> that typedefs gpio_t to a type at most
4 bytes in length. Files accessing the API only need to include <gpio.h>
which may pull in additional things (like a gpio_t creation macro) from
<soc/gpio.h> on its own.
For now the API is still only used on non-x86 SoCs. Whether it makes
sense to expand it to x86 as well should be separately evaluated at a
later point (by someone who understands those systems better). Also,
Exynos retains its old, incompatible GPIO API even though it would be a
prime candidate, because it's currently just not worth the effort.
BUG=None
TEST=Compiled on Daisy, Peach_Pit, Nyan_Blaze, Rush_Ryu, Storm and
Veyron_Pinky.
Change-Id: I6c1e7d1e154d9b02288aabedb397e21e1aadfa15
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/220975
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This patch aligns baytrail to the new SoC header include scheme.
BUG=None
TEST=Tested with whole series. Compiled Rambi.
Change-Id: If5d2a609354b3d773aa3d482e682ab97422fd9d5
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/222026
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This patch aligns broadwell to the new SoC header include scheme.
BUG=None
TEST=Tested with whole series. Compiled Auron and Samus.
Change-Id: I613ec0e2b970c75d1f8f7d9bb454bcf11abc78f0
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/224507
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This patch aligns bg4cd to the new SoC header include scheme.
Also alphabetized headers in affected files since we touch them anyway.
BUG=None
TEST=Tested with whole series. Compiled Cosmos.
Change-Id: Ia5299659ad186f2e7d698adfa7562396e747473f
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/224506
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This patch aligns tegra132 to the new SoC header include scheme.
Also alphabetized headers in affected files since we touch them anyway.
BUG=None
TEST=Tested with whole series. Compiled Rush_Ryu.
Change-Id: Ifafd4d42d4fb04a1c37e8a5f23877c2b550cf44c
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/224505
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This patch aligns tegra124 to the new SoC header include scheme.
Also alphabetized headers in affected files since we touch them anyway.
BUG=None
TEST=Tested with whole series. Compiled Nyan, Nyan_Big and Nyan_Blaze.
Change-Id: Ia126cff8590117788d1872e50608c257d2659c1f
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/224504
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This patch aligns pistachio to the new SoC header include scheme.
Also alphabetized headers in affected files since we touch them anyway.
BUG=None
TEST=Tested with whole series. Compiled Urara.
Change-Id: I3ed405a3efdeec28965538d19a22f2b5b8204f01
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/224503
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This patch aligns ipq806x to the new SoC header include scheme.
Also alphabetized headers in affected files since we touch them anyway.
BUG=None
TEST=Tested with whole series. Compiled Storm.
Change-Id: I283cc7e6094be977d67ed4146f376cebcea6774a
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/224502
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This patch aligns exynos5420 to the new SoC header include scheme.
Also alphabetized headers in affected files since we touch them anyway.
BUG=None
TEST=Tested with whole series. Compiled Peach_Pit.
Change-Id: I338559564e57bdc5202d34c7173ce0d075ad2afc
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/224501
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This patch aligns exynos5250 to the new SoC header include scheme.
Also alphabetized headers in affected files since we touch them anyway.
BUG=None
TEST=Tested with whole series. Compiled Daisy.
Change-Id: Ic358061ddcbbe7d83a95ca11247b8b505b20491d
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/224500
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This patch is the start of a series to change all non-x86 SoC-specific
headers to be included as <soc/header.h> instead of the old
<soc/vendor/chip/header.h> or "header.h". It will add an include/soc/
directory under every src/soc/vendor/chip/ and append the .../include/
part of that to the global include path.
This matches the usage of <arch/header.h> for architecture-specific
headers and had already been done for some headers on Tegra. It has the
advantage that a source file which does not know the specific SoC used
(e.g. Tegra files common for multiple chips, or a global include file)
can still include SoC-specific headers and access macros/types defined
there. It also makes the includes for mainboard files more readable, and
reduces the chance to pull in a wrong header when copying mainboard
sources to use a different-related SoC (e.g. using a Tegra124 mainboard
as template for a Tegra132 one).
For easier maintainability, every SoC family is modified individually.
This patch starts out by changing Rk3288. Also alphabetized headers in
affected files since we touch them anyway.
BUG=None
TEST=Whole series: compared binary images for Daisy, Nyan_Blaze,
Rush_Ryu, Storm, Urara and Veyron_Pinky. Confirmed that they are
byte-for-byte identical except for timestamps, hashes, and __LINE__
macro replacements. Compile-tested individual patches.
Change-Id: I415b8dbe735e572d4ae2cb1df62d66bcce386fff
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/222025
check the cpu and gpu temperature in romstage,
if over 120 degrees celsius,shut down the device.
BUG=None
Test=Boot on veyron_pinky rev2, write value
3421(125 celsius) to grf_tsadc_testbitl register,
the device will be shut down
Change-Id: If406d6a4f6201150f52ea7fc64cd50b45778d7aa
Signed-off-by: huang lin <hl@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/223259
Reviewed-by: Julius Werner <jwerner@chromium.org>
Commit-Queue: Julius Werner <jwerner@chromium.org>
As per NV SysEng, setting PINMUX_CLAMP_INPUTS=1 is now
considered a bad thing. It clamps _all_ tristated inputs
to zero, and isn't really the panacea for duplicated pinmux
mappings as was stated previously.
BUG=None
BRANCH=None
TEST=Built both Rush and Ryu OK. Tested on Rush, booted kernel
OK.
Change-Id: I566c4516b34686b744a47a2b0c18c4b801456727
Signed-off-by: Tom Warren <twarren@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/224032
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Solving the DACR bug will mean that XN bits suddenly become enforced on
non-LPAE systems, and we will no longer be able to execute out of a
region mapped DCACHE_OFF. When we enable the MMU in romstage we are
still executing out of SRAM, so we would instantly kill ourselves.
Solve this issue by enabling the MMU earlier (in the bootblock) and
mapping the SRAM regions as DCACHE_WRITETHROUGH. They should really be
DCACHE_WRITEBACK, but it looks like there might be hardware limitations
in the Cortex-A12 cache architecture that prevent us from doing so.
Write-through mappings are equivalent to normal non-cacheable on the A12
anyway, and by using this attribute we don't need to introduce a new
DCACHE_OFF_BUT_WITHOUT_XN_BIT type in our API. (Also, using normal
non-cacheable might still have a slight speed advantage over strongly
ordered since it should fetch whole cache lines at once if the processor
finds enough accesses it can combine.)
CQ-DEPEND=CL:223783
BUG=chrome-os-partner:32118
TEST=None (depends on follow-up CL)
Change-Id: I53e827d95acc2db909f1251de78d65e295eceaa7
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/223782
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The SOC code should include the SPI controller driver when configured.
With the upcoming configuration change media.c is not needed anymore.
BRANCH=none
BUG=chrome-os-partner:32631
TEST=the driver compiles when the upcoming patches are applied
Change-Id: If7e12e2fb04e63c36d9696d13e08397b91a77a8c
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/223750
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This file provides the SOC specific SPI driver API, it needs to be
filled up with code. Function descriptions can be found in
src/include/spi-generic.h.
BRANCH=none
BUG=chrome-os-partner:32631
TEST=compiles with the upcoming patches applied.
Change-Id: I0ee04ca17874a13403007bba80d5e8a7708bc625
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/223719
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Add necessary configuration to enable the inclusion of the UART driver
into the image when serial console is enabled.
BRANCH=none
BUG=chrome-os-partner:32631
TEST=building with serial console enabled includes the skeleton uart
driver into the build
Change-Id: I6cbd110f600169021901b3f864d596404587fbcc
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/223598
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This adds the file to be filled up with the uart driver implementation
for bg4cd.
The console driver structure when required is provided by
src/console/uart_wrapper.c.
BRANCH=none
BUG=chrome-os-partner:32772
TEST=none yet, this file is not event being compiled
Change-Id: I73c12ddcd6f5099cc2196820452e714eeb736cdc
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/223595
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
MEI PCI device has internal logic to flush out the posted writes
before returning completion for non-posted request. When doing a RCBA
write to function disable and then using the PCI CFG RD cycle, need
to do RCBA posting read after writing to it to make sure the write
went through.
As Aaron sugegsted, abstracted function disable path to a common
function.
BUG=chrome-os-partner:33048
TEST=run warm and cold reboot testing
Change-Id: I87aa8ccd604446263fc3621c9a01839a5a75b644
Signed-off-by: Wenkai Du <wenkai.du@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/223715
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
before the rkclk_init(), we must set rk808
buck1 voltage up to 1300mv
BUG=chrome-os-partner:32716, chrome-os-partner:31896
TEST=Boot on veyron_pinky rev2,check the rk808 buck1 voltage 1300mv
and check the cpu frequency up to 1.8GHz
Change-Id: I6a8c6e35bd7cc6017f2def72876a9170977f206e
Signed-off-by: huang lin <hl@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/222957
Reviewed-by: Doug Anderson <dianders@chromium.org>
change i2c clock low period and high perid propoton to 7:3
guarantee the low period more than 1.3us
BUG=None
TEST=Boot on veyron_pinky rev2,check the i2c clock frequency
Change-Id: I235e9e3ff54ab3b9cabad36bab58a8409f7005a0
Signed-off-by: huang lin <hl@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/223002
Reviewed-by: Julius Werner <jwerner@chromium.org>
BUG=None
BRANCH=None
TEST=Verified by reading back the value of SMMU_CONFIG register that enable bit
is set to 1
Change-Id: Iccc870141f9b9729971bf12119f9f3dae8181a43
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://chromium-review.googlesource.com/222770
Reviewed-by: Olof Johansson <olofj@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Since the E0 and F0 stepping parts have the same CPUID it is
necessary to use the MCH PCI device revision to determine what
the actual stepping is.
Add this decode table so the early output gives proper identification
of the installed CPU type.
BUG=chrome-os-partner:32359
BRANCH=samus,auron
TEST=build and boot on samus with E0 and F0 parts
Change-Id: I1bc127badd75ecc34d3d2dbae5d272bd4d9f9082
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/223158
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The F0 stepping has the same CPUID as E0 stepping so report
it as either stepping to avoid confusion.
BUG=chrome-os-partner:32359
BRANCH=samus,auron
TEST=build and boot on samus
Change-Id: Ia4955f346ceb9be92e06ecea5b7a8fe2db84cabc
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/223097
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
It's been a while since SBL blob size was reduced. As CBFS area by
definition includes the bootblock, storm configuration needs to be
updated to address the changes in layout.
Incidentally, it looks like CBFS_SIZE configuration setting is not
used on ARM platforms, this will have to be addressed separately.
BRANCH=storm
BUG=chromium:422501
TEST=storm firmware does not report the failure to find payload anymore
Change-Id: I37abf76a9d8884b3431633f57f64896c3a5fb135
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/222898
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
In able to do earlyprintk spew on LP0 resume, the kernel needs to
know the board UART. ODMDATA (in bct/odmdata.cfg) contains this info,
and the kernel looks for it in PMC_SCRATCH20. Fetch the ODMDATA word
from the BCT copy stored in IRAM by the BootROM.
BUG=chrome-os-partner:32015
BRANCH=none
TEST=Built for Rush and Ryu OK. Dumped PMC_SCRATCH20 in TegraShell
on Rush and confirmed value is what's in odmdata.cfg.
Change-Id: I63f33558ee8b00bd6c1e313efcd531e1d5fc67eb
Signed-off-by: Tom Warren <twarren@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/222402
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This patch does some general cleanup in the Rockchip clock code, and
adds some more assertions regarding the PLL VCO and output frequency
ranges. It changes all PLL divisors to use the lowest values that can
still hit the target frequency, since higher NR values lead to higher
jitter and higher NO values increase power draw.
Also change DDR3 frequency code to hardcode the optimal divisors for
certail frequencies. As a little hack we will interpret 666000000 to
actually mean 666666666.6P (and analogous for 533MHz), since that's what
you usually want for memory.
BUG=chrome-os-partner:32139
TEST=Boot on veyron_pinky rev2, check that dpll_is shown as 666666666 in
/sys/kernel/debug/clk/clk_summary.
Change-Id: I4f3c39641955a95c6dfbe9334035eb670b138bf0
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/221801
This change re-writes the spi_xfer() function to support full-duplex
transfers.
Even though the code looks much different, the same basic algorithm
for setting up the transfer is used. The main difference is that
reads from rxdr and writes to txdr occur simultaneously and accounting
is more complicated, so I separated the higher-level accounting
portion from the low-level FIFO handling portion to simplify things.
BUG=chrome-os-partner:31850
BRANCH=none
TEST=Loaded content from SPI ROM fine, needs testing w/ EC
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: I33d2f5179360baf94627c86b57d12f032897caf5
Reviewed-on: https://chromium-review.googlesource.com/218881
Reviewed-by: Julius Werner <jwerner@chromium.org>
Fix the typo of sate to state and add uKernel phase to just
output the current state byte.
BUG=chrome-os-partner:28234
BRANCH=samus,auron
TEST=build and boot on samus
Change-Id: I520a4cc75faffa5feeb6113ffd7b07a48c4e6f28
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/222677
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The first 64 bytes of the framebuffer contain garbage after running
the option rom and after calling the VBE mode set with the flag to
clear the framebuffer.
Work around this issue by clearing the first 64 bytes in the framebuffer
in the broadwell graphics setup code after it executes the VBIOS.
BUG=chrome-os-partner:32771
BRANCH=samus,auron
TEST=build and boot on samus in dev mode, check for graphical corruption
Change-Id: I072bc913f7daea16e4861a7549e1b4ec85cde4cd
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/222676
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
BUG=chrome-os-partner:31424
TEST=Build a image and run on Samus proto boards to confirm if the
settings are applied correctly.
Signed-off-by: Kenji Chen <kenji.chen@intel.com>
Change-Id: I8138507506771148420a585fd12897a3bfe91916
Reviewed-on: https://chromium-review.googlesource.com/221387
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
There's no need to reserve the framebuffer within corebot. If the
payloads need a framebuffer they can allocate one themselves.
BUG=chrome-os-partner:31355
BRANCH=None
TEST=Built and booted on ryu.
Change-Id: I8d8b159e7fdd877e392193c5474a7518e9b3ad21
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/221726
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
DDI-A should not need re-enabled in the resume path, just
the resume path when we did not execute VBIOS.
BUG=chrome-os-partner:28234
BRANCH=samus,auron
TEST=build and boot on samus, test suspend+resume
Change-Id: Iaf7d083c5c92c42b7a117e2d2c9546ada6bf5f76
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/221988
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This is the latest available microcode.
BUG=chrome-os-partner:28234
BRANCH=samus,auron
TEST=build and boot on samus
Change-Id: I3fdc93d834a43c97cf6f404f0f465902781ad9e4
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/221987
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This patch adds some simple constants to more easily write and do math
with frequencies, analogous to the existing KiB, MiB and GiB constants
for sizes. They are exemplary added to the Veyron_Pinky/Rk3288 code for
now and will hopefully be adopted by other parts of the codebase in the
future.
BUG=None
TEST=Compiled Veyron_Pinky.
Change-Id: I4a1927fd423eb96d3f76f7e44b451192038b02e0
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/221800
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Provide a weak implemenation of usb_setup_utmip function for those stages that
do not include usb.c.
BUG=chrome-os-partner:32684
BRANCH=None
TEST=Compiles successfully
Change-Id: Ib235cf039a17204ef7e06d545a3c86b75aff5b4c
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://chromium-review.googlesource.com/221575
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
This function needs to be available in different LOGLEVELs.
BUG=chrome-os-partner:28234
BRANCH=samus
TEST=USE=quiet-cb emerge-samus coreboot
Change-Id: Ia8f0d05af24c9070c8c9241a3a7e137f845d1cab
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/221540
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
A higher drive setting is used for fast link training, once the
link training succeeds, a known-good drive setting will be used
for the main stream transactions.
For full link training sequence, the sink devices may ask for a
preferred drive setting, thus this drive setting should be used
for the main stream transactions too.
BUG=chrome-os-partner:32129
TEST=all panels on blaze/big devices work fine.
Change-Id: Icc540650dc1329af07fd9ee4661eb7fad435fde4
Signed-off-by: Neil Chen <neilc@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/219544
Reviewed-by: Julius Werner <jwerner@chromium.org>
The original dp driver supports only fast link training and a
special drive setting is used for the link training sequence.
This might not be accepted by all panels. The better way is to
go through full link training sequence to negotiate for a best
drive setting.
With the change, dp driver will try fast link training first,
this is same as before. If it fails in fast link training, will
try full link training.
BUG=chrome-os-partner:32129
TEST=all panels on blaze/big devices work fine.
Change-Id: I6f3402c4c5993a156c965c7f52b011d336a2946f
Signed-off-by: Neil Chen <neilc@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/219543
Reviewed-by: Jimmy Zhang <jimmzhang@nvidia.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
rockchip_spi_slave has a fifo_size member which doesn't change.
This just replaces the struct member with a #define.
BUG=none
BRANCH=none
TEST=built and booted on Pinky
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: I9ea5cdad49ee10c5f32304d0909c4a7e74a261f9
Reviewed-on: https://chromium-review.googlesource.com/220471
Reviewed-by: Julius Werner <jwerner@chromium.org>
