The drivers are designed to work with an edge triggered interrupt.
BUG=chrome-os-partner:20811
BRANCH=none
TEST=manual: ensure trackpad still works and cyapa interrupt
rate when holding a finger on the trackpad is lower.
Change-Id: I35a121ecfb6409bb9049f4d1e034185bb3bb7557
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/61664
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
BUG=None
TEST=Built and booted on Snow.
BRANCH=None
Change-Id: I0f27bca119a248e22b06b7343ddc6a4cb85f68a0
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/61532
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
The 5250 DRAM code is *really* chatty. That's not a great
idea in time critical code, and DRAM init is generally
very sensitive about such things.
Finally, for those things that are errors, print them
at an error level, not a debug level.
BUG=chrome-os-partner:19420
BRANCH=none
TEST=not yet
Change-Id: Ifa86b019dfd5f8ae6c8a1da2a35b5d0808dc3623
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/60100
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Commit-Queue: Ronald G. Minnich <rminnich@chromium.org>
Tested-by: Ronald G. Minnich <rminnich@chromium.org>
When the board is in S3 and S5 the WLAN_DISABLE_L signal
can leak power into the WLAN power well since the GPIO
controlling WLAN_DISABLE_L is in the suspend well. Therefore,
drive WLAN_DISABLE_L low to avoid the power leak.
BUG=chrome-os-partner:20793
BRANCH=None
TEST=Manual. Checked the WLAN_DISABLE_L signal on wlan connector in both S3 and
S5. It is driven to ground. WLAN continues to work in S0.
Change-Id: I1a0df80dd47fdbd535aca7a9d49253794c480606
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/61421
The name "LPDDR3PHY_CTRL_PHY_RESET_OFF" is not appropriate because the real
phy-reset is a low-active pin, so "off(0)" will trigger "start to reset".
To prevent confusion, we should rename the constants to "RESET_ENABLE" and
"RESET_DISABLE".
BUG=none
TEST=emerge-daisy chromeos-coreboot-snow
BRANCH=none
Change-Id: Iccba5ef3a2e992f877dea90741f0308c161758c9
Reviewed-on: https://gerrit.chromium.org/gerrit/61081
Tested-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Commit-Queue: Hung-Te Lin <hungte@chromium.org>
These are needed to enable workarounds/features on specific
CPU types and stepping. The older northbridge function and
defines from sandybridge/ivybridge are removed.
BUG=chrome-os-partner:20772
BRANCH=none
TEST=emerge-falco chromeos-coreboot-falco
Change-Id: I80370f53590a5caa914ec8cf0095c3177a8b5c89
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/61333
Commit-Queue: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
To configure source clocks on Exynos 5420 for MMC drivers.
Some registers are different from the 5250. FSYS now has two parts
and MMC uses FSYS2. The MMC block uses MPLL as the clock source.
The "high-speed" MMC interface runs as 52MHz, so divider is set
accordingly.
Also, the MMC driver has changed from MSHCI (Mobile Storage Host Controller
Interface) to DWMCI (DesignWare MMC Controller Interface).
BUG=chrome-os-partner:19420
BRANCH=none
TEST=emerge-peach_pit chromeos-coreboot-peach_pit
Change-Id: I9ba9cf43e2f2dcd9da747888c0c7676bd545177b
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/60858
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Make use of google_chromeec_get_board_version to determine board
version, and apply proper RAM_ID table to load correct SPD.
BUG=chrome-os-partner:20295.
TEST=Manual. Verify correct SPD files are loaded for 2 GB and 4 GB
boards on PROTO and EVT (simulated) boards.
BRANCH=None.
Change-Id: I6a2d54759cf2ce98bf53df0db396c6e09368c714
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/61192
Reviewed-by: Dave Parker <dparker@chromium.org>
Update peppy's verb tables for the Realtek ALC283 Audio Codec.
ALC283 Configuration:
Digital Mic - NID 12h: Disabled
Speakers - NID 14h: Enabled
Mono out - NID 17h: Disabled
Mic 1 - NID 18h: Disabled
Mic 2 - NID 19h: Headphone Jack
Line1 - NID 1Ah: Internal Mic
Line2 - NID 1Bh: Disabled
PCBEEP - NID 1Dh: Enabled
SPDIF - NID 1Eh: Disabled
HP-OUT - NID 21h: Headphone Jack
Mic 1 doesn't seem to really be available, but the documentation
refers to NID 18h as MIC1, so it's being disabled as it's not
being used. The onboard microphone has been moved to line 1.
I had my peppy modified to attach the mic to line1 and mic1 now
works with this patch. Mic2 looks harder to rework, so I think
that will have to wait for the DVT boards.
BUG=chrome-os-partner:20180
TEST=Play audio through system speakers and headphones.
Verify PC Beep at boot time through system speakers
Record audio through system Mic & external Mic connector.
Change-Id: I7d6ce6b428806b6aed1d36e7e25302fa5ae14b21
Signed-off-by: Martin Roth <martin.roth@se-eng.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/58880
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
We will soon need to call google_chromeec_get_board_version to determine
correct DDR SPD. We must do so before DDR is initialized, so allow this
function to be called from romstage.
BUG=chrome-os-partner:20295.
TEST=Manual. Verify google_chromeec_get_board_version works when called
from romstage on Peppy.
BRANCH=None.
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I882d84e38d11bf66067193a6f408f941f2cf8a81
Reviewed-on: https://gerrit.chromium.org/gerrit/61191
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: Shawn Nematbakhsh <shawnn@chromium.org>
Commit-Queue: Shawn Nematbakhsh <shawnn@chromium.org>
USB2 Port A set to 6.4" and Back Panel
USB2 Port B set to 5.2" and Back Panel
USB2 Port C set to 12.3" and Internal
Other devices all set to Internal.
BUG=chrome-os-partner:20759
BRANCH=none
TEST=manual: build and boot on falco and check settings.
Based on the config settings all ports end up with
tuning param 1 == 5 and param 2 == 2
U2ECR[0] = 0x00059501
U2ECR[1] = 0x00059501
U2ECR[2] = 0x00059501
U2ECR[3] = 0x00059501
U2ECR[4] = 0x00059501
U2ECR[5] = 0x00059501
U2ECR[6] = 0x00059501
U2ECR[7] = 0x00059e01
Change-Id: I6b9e6df2679036a501355e6b389a486a6f178f99
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/61297
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Systems are hanging in dev_configure() without a log to
indicate which device is being processed. Add some logging
points to save the device path before talking to the device
so we can narrow in on which device is the problem.
BUG=chrome-os-partner:20680
BRANCH=none
TEST=manual: emerge-falco chromeos-coreboot-falco
Change-Id: I3751c19a1ea68cdccbc33e4f6b2eeddd1bd9f2e4
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/61296
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This CPU does not support Configurable TDP and so far does
not need to use Controllable TDP.
BUG=chrome-os-partner:20604
BRANCH=none
TEST=manual: emerge-falco chromeos-coreboot-falco
Change-Id: I15599cd4e6890dd5c9d9f99bc4e95307a8dcc827
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/60657
Taken directly from parrot with only string changes
TEST=emerge-* chromeos-coreboot-* succeeds
BUG=chromium:254183
Change-Id: Ia801ee82f9c7d41a47a8cb0b095e8502d7794dc5
Reviewed-on: https://gerrit.chromium.org/gerrit/61201
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-by: Mohammed Habibulla <moch@chromium.org>
Tested-by: Mohammed Habibulla <moch@chromium.org>
Commit-Queue: Mohammed Habibulla <moch@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@google.com>
BUG=None
TEST=Built for falco, snow, link.
BRANCH=None
Change-Id: I7252925ef5c4efb69cad6b6fa179031162cf8e74
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/61058
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
When dealing with DMA, we need a function to invalidate cache without corrupting
contents on main memory (clean).
BUG=none
TEST=emerge-peach_pit libpayload
BRANC=NONE
Change-Id: I28e632ae57a7b7ed1accee74e76045b92f92a699
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/61078
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
The OP assigned by dcache_clean_by_mva must be handled in
dcache_op_mva.
BUG=none
TEST=emerge-peach_pit libpayload
BRANCH=none
Change-Id: Ib32262f0419453b2690d7c1a1c6602380b46a37f
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/61077
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
The OP assigned by dcache_clean_by_mva must be handled in dcache_op_mva.
BUG=none
TEST=emerge-peach_pit chromeos-coreboot-peach_pit
BRANCH=none
Change-Id: Ia7631a08be6afacb13dfff406ac4db20efc98926
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/61076
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
The is_resume comment is wrong for this board. It only applies
to the older 5250 cpu. In fact, the is_resume parameter
is not needed for ddr init and will likely be removed soon.
BUG=None
TEST=Still builds.
BRANCH=None
Change-Id: I4e3c92fcaaa75d3c9223d90acccf053f61406307
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/60103
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Commit-Queue: Ronald G. Minnich <rminnich@chromium.org>
Tested-by: Ronald G. Minnich <rminnich@chromium.org>
Some new fields were added to the edid data structure, and the edid code was
changed to put estimated values into those fields which were ultimately passed
into depthcharge or other payloads. On snow we do things different and just
declare an edid structure statically which didn't have those members. The rows
and columns of the graphics console were 0, and that confused the framebuffer
driver and made it loop forever.
BUG=None
TEST=Built and booted into recovery mode on Snow. Before this change, it would
hang trying to display the recovery screen. After this change, it could show
the screen and also continue into the recovery image.
BRANCH=None
Change-Id: I6ca3bd948482b347a6a981e83b82b10dca995e5e
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/61057
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
This reverts commit e7e9b874e1
Let's revert this change. Quanta will change their BOM according to the original order. Without changing the schematic labels it will cause more confusion later. We will follow correct PC industry notation.
Change-Id: Idc08f76f511e2e00b8d75afce1573da3fe4dd62e
Reviewed-on: https://gerrit.chromium.org/gerrit/61083
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
Commit-Queue: Jay Kim <yongjaek@chromium.org>
Tested-by: Jay Kim <yongjaek@chromium.org>
This version is taken from arch/arm/lib/memmove.S in the Linux kernel.
BUG=None
TEST=Built and booted on Snow with memmove used for CBFS loading.
BRANCH=None
Change-Id: If2631172eef7517e669affba066a65ce4ca16151
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/61075
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
This is from memcpy_32.c in the Linux kernel. There was no copyright header
in the original file either.
BUG=None
TEST=Built and booted on Link using memmove for CBFS load. Checked that
firmware boot time was at least as good.
BRANCH=None
Change-Id: Id1d026e191bad5f021fb3499a9f4ae1f71f89747
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/61074
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
BUG=None
TEST=Built and booted on Link and Snow.
BRANCH=None
Change-Id: I0b05e2d128f3da0f4c9a6ee32de4ed359bf93ccd
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/61073
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
The options that keep track of whether there are arch versions of the standard
string functions shouldn't be in the arch/x86 directory since they apply to
all architectures. Move them into the higher level, shared Kconfig defaulting
to off. Then, in each applicable arch (currently all of them) they can be
selected to on.
BUG=None
TEST=Built and booted on Link and Snow.
BRANCH=None
Change-Id: I1711efa699ddf31d29ebc672bd3728b472c26bb7
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/61072
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Some kernel assembly code uses a W macro to optionally add a .w to
instructions that need to be 32 bit thumb. The gnu assembler doesn't seem to
need the .w and won't assemble if it's provided.
BUG=None
TEST=Built for snow with the kernel's implementation of memmove (which uses
W()), and used memmove successfully when loading from CBFS.
BRANCH=None
Change-Id: I3871217b1fcbc81de159c18eb718867b17dea6cb
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/61071
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
- Update RAM_ID table.
- Add DEVSLP0 signal to NGFF SATA port.
Note: After this change, old Micron 2GB boards will no longer boot.
BUG=chrome-os-partner:20295, chrome-os-partner:20308.
TEST=None.
BRANCH=None.
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: Id68a1d6ace2702cca9c37305726cd55a0bde5005
Reviewed-on: https://gerrit.chromium.org/gerrit/60167
Tested-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-by: Dave Parker <dparker@chromium.org>
Commit-Queue: Dave Parker <dparker@chromium.org>
RAM_ID0 was used as the table MSB, and RAM_ID2 as the LSB. This is the
opposite of expected. Reverse these two GPIOS to make current boards
work. For future boards, we will change the signal names on the
schematic to be consistent.
TEST=Manual. Build image, verify Hynix board loads correct SPD.
BUG=chrome-os-partner:19636.
BRANCH=None.
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I044e7ee696f19fe6fd5911e17317190832f675c5
Reviewed-on: https://gerrit.chromium.org/gerrit/60162
Tested-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-by: Dave Parker <dparker@chromium.org>
Commit-Queue: Dave Parker <dparker@chromium.org>
The display port bridge on pit is different from the one on snow and needs to
be initialized differently. Instead of waiting for the chip to come up on its
own and assert the hotplug detect, we need to access it over i2c and get it up
and running ourselves.
BUG=chrome-os-partner:19420
TEST=Built and booted into depthcharge on pit and saw that the video
initialization code in coreboot worked better, successfully training the link
but then failing elsewhere later on.
BRANCH=None
Change-Id: I926f9cce182308dc4a50abdb8ab684109ed95f17
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/60604
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
Tested-by: Ronald G. Minnich <rminnich@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
BUG=chrome-os-partner:19420
TEST=Built and booted into depthcharge on pit.
BRANCH=None
Change-Id: I0b7565bbfa5f9a4c7d0bd84f763c71032d12f379
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/60603
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
Tested-by: Ronald G. Minnich <rminnich@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
This driver is basically the same as the one in U-Boot but without the device
tree stuff. That driver is, in turn, a straightforward implementation of the
sequence of register writes described in the data sheet. Comments were added
in U-Boot which helpfully describe what the register writes are actually
doing and are kept.
BUG=chrome-os-partner:19420
TEST=Built and booted into depthcharge on pit and verified that after the
bridge was initialized, the link was initialized successfully.
BRANCH=None
Change-Id: Id4714780c7707325a8dff1cf424d9feb1c367cda
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/60602
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
Tested-by: Ronald G. Minnich <rminnich@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Data is intended to be a byte array, so it should be described by a type which
has a fixed size equal to an 8 bit byte. Also, the data passed to write
shouldn't be modified and can be const.
BUG=chrome-os-partner:19420
TEST=Built and booted into depthcharge on pit. Built and booted into ChromeOS
on snow.
BRANCH=None
Change-Id: Ib01c0218b95d8660418fea2181f6f38bc0675159
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/60601
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Tested-by: Ronald G. Minnich <rminnich@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
This was removed from ramstage a little while ago and should have been removed
from here as well.
BUG=chrome-os-partner:19420
TEST=Built and booted into depthcharge on pit.
BRANCH=None
Change-Id: I55bc0806597de51c411aadf55d7c8ea5e3175821
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/60600
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Tested-by: Ronald G. Minnich <rminnich@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
In some header shuffling stdint.h no longer included a definition
for NULL. Pull in string.h for the proper definition. Also, disable
the xHCI controller in libpayload as the firmware leaves control
of the USB 3.0 ports to the EHCI controller.
BUG=None
BRANCH=None
TEST=Was able to boot in in non-dev mode. In dev mode there were no
longer errors about the xHCI controller.
Change-Id: Iabf15b3b17d88784e0718dc9f0fd885e6551e0b1
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/60874
Reviewed-by: Sameer Nanda <snanda@chromium.org>
This appears to be needed, though we have no way to test yet.
BUG=None
TEST=it builds
BRANCH=None
Change-Id: I1fe20b35b0fc73ecfd7207c368a9ead89a097e70
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/60159
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Ronald G. Minnich <rminnich@chromium.org>
Tested-by: Ronald G. Minnich <rminnich@chromium.org>
Newer mainboards that use haswell -- and, presumably, chipsets to come -- need
some support functions. Add them in the drivers/intel/gma directory.
Currently, this is one file: intel_ddi.c, but more may come.
Compilation of this file is controlled by INTEL_DDI, defined
in the Kconfig as default n and used in the Makefile.inc
BUG=None
TEST=builds and boots on the FUI tree that uses it.
BRANCH=None
Change-Id: I501ee291c0d4589925ed3e478f67106337fcad31
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/60612
Tested-by: Ronald G. Minnich <rminnich@chromium.org>
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
Commit-Queue: Ronald G. Minnich <rminnich@chromium.org>
Now that we have horizontal display areas that are not multiples of 32 bytes,
things are more complex. We add three struct members (x, y resolution and
bytes per line) which are to be filled in by the mainboard as it sets the mode.
In future, the EDID code may take a stab at initializing these but the values are
context-dependent.
BUG=None
TEST=Build and boot slippy with these changes
BRANCH=None
Change-Id: Ib9102d6bbf8c66931f5adb1029a04b881a982cfe
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/60514
Tested-by: Ronald G. Minnich <rminnich@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Ronald G. Minnich <rminnich@chromium.org>
Limit power to 12W at 73C and remove limit at 68C.
BUG=chrome-os-partner:20604
BRANCH=none
TEST=manual:
To have the CPU consume maximum power it is necessary to stress
both the CPU and the GPU. Bastion (chrome.supergiantgames.com)
and/or webglsamples.googlecode.com can be useful for this.
Testing this properly requires a script to report the running
average power readings. The watch_power.sh script is attached
to this issue in the partner tracker.
1) Run watch_power.sh continuously:
localhost ~ # watch -n 0 bash -e /tmp/watch_power.sh
2) Start Bastion (or other stress apps). The power draw should
be close to 15W if under enough load.
3) Watch until temperature climbs above 73C and is caught by
the thermal zone 10 second poll, this can be sped up by blocking
or removing the fan.
4) The ACPI thermal zone states should change to reflect that
active[2] is now enabled and power consumption should drop to 12W.
5) Stop the stress apps and wait until the CPU cools off again,
enable the fan again if it was removed.
6) The ACPI thermal zone state should switch back to active[3].
Change-Id: Ie6714a8543d4f06edf8513086fc9c968273bdb23
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/60545
Add ACPI Methods to enable and disable power limiting with PL1.
This can be used in ACPI Thermal Zone or in EC ACPI _QXX events.
BUG=chrome-os-partner:20604
BRANCH=none
TEST=manual: emerge-falco chromeos-coreboot-falco
This commit adds new unused methods and is fully tested with the
subsequent commit that makes use of these methods.
Change-Id: I9d8d23bfe9cf7c756ff8ab0412e5a010826b12db
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/60546
1) fix enable of power aware interrupt routing
2) set BIOS_RESET_CPL to 3 instead of 1
3) mirror PKG power limit values from MSR to MMIO on all SKUs
4) mirror DDR power limit values from MMIO to MSR
5) remove DMI settings that were from snb/ivb as they do
not apply to haswell
BUG=chrome-os-partner:20604
BRANCH=none
TEST=manual:
1) verify power aware interrupt routing is working by looking
in /proc/interrupts to see interrupts routed to both cores
instead of always to core0
BEFORE: 58: 4943 0 PCI-MSI-edge ahci
AFTER: 58: 4766 334 PCI-MSI-edge ahci
2) read back BIOS_RESET_CPL to verify it is == 3
localhost ~ # iotools mmio_read32 0xfed15da8
0x00000003
3) read PKG power limit from MMIO and verify it is the same
as the MSR value
localhost ~ # rdmsr 0 0x610
0x0000809600dc8078
localhost ~ # iotools mmio_read32 0xfed159a0
0x00dc8078
localhost ~ # iotools mmio_read32 0xfed159a4
0x00008096
4) read DDR power limit from MSR and verify it is the same
as the MMIO value (note this is zero based on current MRC input)
localhost ~ # rdmsr 0 0x618
0x0000000000000000
localhost ~ # iotools mmio_read32 0xfed158e0
0x00000000
localhost ~ # iotools mmio_read32 0xfed158e4
0x00000000
Change-Id: I6cc4c5b2a81304e9deaad8cffcaf604ebad60b29
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/60544
In resume path, if memory setup takes too long without setting PS_HOLD, EC watch
dog may power off or reboot the system. To prevent that, we should enable
PS_HOLD in same timing as cold boot - right before starting memory setup.
BUG=none
TEST=emerge-daisy chromeos-coreboot-snow
BRANCH=none
Change-Id: I187b85d5ff17774dc83efe5c72d61caff1543113
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/60335
Reviewed-by: David Hendricks <dhendrix@chromium.org>
The functions which manipulated the tps65090 were removed a while ago because
it isn't accessible directly from the AP, it's on an I2C bus that has to be
accessed by the EC on our behalf. Now that that capability has been added, we
can rewrite the small portion of the the tps65090 we actually used but using
the EC passthrough commands.
Also, we should not be configuring the hardware display port hotplug detect
line since we're using it as a GPIO for other purposes. The GPIO we're using
instead defaults to being an input, but to be safe we should probably
explicitly configure it as one anyway.
BUG=chrome-os-partner:19420
TEST=Built and booted into depthcharge on pit. Verified that the registers
read from the tps65090 were reasonable, and that the registers being set
should correspond to the FETs that are being turned on. The display isn't
working yet so these functions couldn't be completely verified.
BRANCH=None
Change-Id: Ie70a7f659d02ddba8ca416fbb571870080a84ea8
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/60517
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
BUG=chrome-os-partner:19420
TEST=Built and booted into depthcharge on pit. Used the function to read and
write i2c registers on the tps65090 and verified that they were consistent
with expected values and were affected by writes in a reasonable way.
BRANCH=None
Change-Id: I57ea6be8b81e31191399a7457ef5106c56f7f27d
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/60516
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
The elog code calculates flash offsets and their equivalent
addresses in the memory address space. However, it assumes
the detected flash size is entirely mapped into the address
space. This can lead to incorrect calculations. Add code
to allow ROM_SIZE to be less than detected flash size. The
underlying assumption is that the first ROM_SIZE bytes are
programmed into the larger device.
BUG=None
BRANCH=None
TEST=Built and ran a 8MiB image on a 16MiB flash part.
Change-Id: Id848f136515289b40594b7d3762e26e3e55da62f
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/60501
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
The Intel GMA driver is in, this CL splices in the Makefile bits.
BUG=None
TEST=Build and boot falco
BRANCH=None
Change-Id: Icf42a537575b8cc90a679ec1fc15b09294630611
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/60346
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Commit-Queue: Ronald G. Minnich <rminnich@chromium.org>
Tested-by: Ronald G. Minnich <rminnich@chromium.org>
