Move inline function where they belong to. Fixes compilation
on non x86 platforms.
Change-Id: Ia05391c43b8d501bd68df5654bcfb587f8786f71
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/25720
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
According to Intel document #559100 KBL EDS v2.8, section 7.2
DC specifications, the IccMax setting for KBL-U, KBL-U42 and
Celeron/Pentium are different. This patch overrides the IccMax
settings for KBL-U/R/Y since device tree could not handle all
KBL-U/R combinations when multiple SKUs are adopted in a project.
Besides, it is inefficient to maintain the same code for all
variants. Hence, place it in the common code so that all variants
could leverage the benefits.
+----------------+-------------+---------------+------+-----+
| Domain/Setting | SA | IA | GTUS | GTS |
+----------------+-------------+---------------+------+-----+
| IccMax(KBL-U/R)| 6A(U42) | 64A(U42) | 31A | 31A |
| | 4.5A(Others)| 29A(Celeron) | | |
| | | 32A(i3/i5) | | |
+----------------+-------------+---------------+------+-----+
| IccMax(KBL-Y) | 4.1A | 24A | 24A | 24A |
+----------------+-------------+---------------+------+-----+
BUG=b:71369428
BRANCH=None
TEST=Remove icc_max setting from devicetree & emerge-fizz coreboot
chromeos-bootimage & Ensure the KBL-U42, KBL-U22 and Celeron
SKUs are identified correctly and IccMax settings are passed
to FSPS correctly.
Change-Id: I291462b73d3fbd17f17975de7fd77dc48ca99251
Signed-off-by: Gaggery Tsai <gaggery.tsai@intel.com>
Reviewed-on: https://review.coreboot.org/23060
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Add options to set the AC and DC loadline values for each supported
VR type so these can be tuned on a per-board basis in devicetree.cb.
BUG=b:36228330
BRANCH=none
TEST=Build and boot on Eve and check debug FSP output to ensure that
it is applying the provided loadline values
Change-Id: I2a5533d2c9fd86351c86584e3738e80ac4c1f915
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/18819
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
With the move to FSP 2.0 the number of VR types supported was
reduced to 4, and the VR_RING type is no longer present.
This means all existing boards using FSP 2.0 are incorrectly
passing VR configuration into FSP as the values corresponding to
"GT Sliced" and "GT Unsliced" have changed.
Fix this by updating the skylake SOC VR handling to account for
changes in the FSP configuration and no longer provide VR_RING
type when using FSP 2.0.
BUG=b:36228330
BRANCH=none
TEST=manual: build and boot on Eve
Change-Id: I59eea9fba006a4c235d7b42d07fdc6e4f44f7351
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/18818
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins)
Add Initial pieces of code to support fsp2.0 in skylake keeping
the fsp1.1 flow intact.
The soc/romstage.h and soc/ramstage.h have a reference to
fsp driver includes, so split these header files for
each version of FSP driver.
Add the below files,
car_stage.S:
Add romstage entry point (car_stage_entry).
This calls into romstage_fsp20.c and aslo handles
the car teardown.
romstage_fsp20.c:
Call fsp_memory_init() and also has the callback
for filling memory init parameters.
Also add monotonic_timer.c to verstage.
With this patchset and relevant change in kunimitsu mainboard,
we are able to boot to romstage.
TEST= Build and Boot Kunimitsu with PLATFORM_USES_FSP1_1
Build and Boot Kunimitsu to romstage with PLATFORM_USES_FSP2_0
Change-Id: I4309c8d4369c84d2bd1b13e8ab7bfeaaec645520
Signed-off-by: Rizwan Qureshi <rizwan.qureshi@intel.com>
Reviewed-on: https://review.coreboot.org/16267
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
FSP 1.8.0 will do nothing with the VR settings if VrConfigEnable is
non-zero. That behavior is not desired because it's not clear what
the behavior will be for various processor SKUs. Instead provide
default values for the VR config. Note that PSI3 and PSI4 are not
enabled for those defaults.
BUG=chrome-os-partner:48466
BRANCH=None
TEST=Built and booted glados.
Change-Id: I02cb5fbdd4549cc827a0b0e4006bc21da4593b55
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: a68c53e0fdf15584270dfafc679a22319f497d17
Original-Change-Id: I82b1d1da2cfa3c83ccc6a981e30ffac6fb6c8c4b
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/318263
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/12983
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
