Requesting low power acpi cpu c-states has two software interfaces:
Using P_LVLx I/O reads or using equivalent MWAIT requests.
This change makes it more consistent with newer targets that use MWAIT
requests.
There also exists extended intel acpi c-states which can be enabled
in two ways:
- using a substate hint to the mwait request (defined in bios);
- setting a model specific register (msr)
Currently this is done by setting the right msr bits but with this
change one can experiment by adding substate hints.
BUG=None
BRANCH=None
TEST=None
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/14801
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Change-Id: I9eeb5b008e2ddc2193725667f2c13582a4877e3c
Reviewed-on: https://chromium-review.googlesource.com/397909
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
MHCBAR(CLKCFG) was previously incorrectly written by the
sdram_program_memory_frequency function which required falsely
limiting the max dram frequency for 945GC.
TESTED on Intel d945gclf (memclock 667 and fsb 533) and
Gigabyte ga-945gcm-s2l (memclock 667 and fsb 1067)
BUG=None
BRANCH=None
TEST=None
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/16940
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
Change-Id: I520efd69fa09fc9fde87c5301fd81121fde6a700
Reviewed-on: https://chromium-review.googlesource.com/397905
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
An epic battle to fix Nehalem finally ended when we found an odd mask
set in SMRR. This was caused by a wrong calculation of TSEG size. It
was assumed that TSEG spans the whole space between TSEG base
and GTT. This is wrong as TSEG base might have been aligned down.
TEST: On X201, copied 1GiB from usb key to sd-card and verified.
BUG=None
BRANCH=None
TEST=None
Found-by: Alexander Couzens, Nico Huber
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/16939
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Alexander Couzens <lynxis@fe80.eu>
Reviewed-by: Kysti Mlkki <kyosti.malkki@gmail.com>
Change-Id: Id8c8a656446f092629fe2517f043e3c6d0f1b6b7
Reviewed-on: https://chromium-review.googlesource.com/397904
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This patch implements native resolution, VESA mode, on the VGA output of
x4x.
It relies on EDID to modeset, but has a fallback-mode (640 x 480 @
60Hz) if this is no EDID could be found. This fallback mode only works
in textmode since in VESA mode some payloads (grub2) rely on VBE info,
which is being generated from an EDID.
BUG=None
BRANCH=None
TEST=None
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/16498
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Change-Id: I247ea7171ba3c5dc3b209d00e4dcb2d2069abd75
Reviewed-on: https://chromium-review.googlesource.com/396255
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Maxim98357a speaker amp requires BCLK & SFRM to be active
and stable before it is unmuted. If there is a BLCK and no
SFRM, it results in a pop sound.
sdmode_delay property already exists which facilitates this
configuration. This patch updates "sdmode_delay" to avoid
pop sound.
BUG=chrome-os-partner:58356
BRANCH=None
TEST=while audio playback via headset, remove headset.
Audio will be switched playback to speaker. Observe if
pop sound comes from speaker.
Signed-off-by: Sathyanarayana Nujella <sathyanarayana.nujella@intel.com>
Reviewed-on: https://review.coreboot.org/16933
Tested-by: build bot (Jenkins)
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Change-Id: I7ad68caa88d7b3ff52ac1379fe6564de27d97777
Reviewed-on: https://chromium-review.googlesource.com/396251
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Sathyanarayana Nujella <sathyanarayana.nujella@intel.com>
The datasheets "Intel Core Duo Processor and Intel Core Solo
Processor on 65 nm Process" mentions cpu C-states substates which can
either be attained by adding a substate hint to the MWAIT/P_LVLx request
or automatically by setting some msr bits correctly.
This just sets the same msr bits as model_6fx to enable
dynamic L2 cache, C2E and C4E acpi cpu states.
The result is that when limiting a thinkpad x60 with a yonah T2400
cpu to the acpi cpu C2 state, the idle power usage drops from 18W to
14W. When the lowest C-state is set to C4 the idle power usage seems
to remain similar.
BUG=None
BRANCH=None
TEST=None
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/16901
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Change-Id: I6c422656ace04659f32082a5944617eda6c79ec3
Reviewed-on: https://chromium-review.googlesource.com/396245
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
When timestamp is enabled, the system hangs because the timestamp data
is not yet available. Add a temporary work around that starts the
timestamp after the FspInit() making this data available.
Verified on Intel Camelback Mountain CRB and ensured that system can
boot to payload with timpstamp feature enabled.
BUG=None
BRANCH=None
TEST=None
Signed-off-by: York Yang <york.yang@intel.com>
Reviewed-on: https://review.coreboot.org/16894
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Change-Id: I59c4bb83ae7e166cceca34988d5a392e5a831afa
Reviewed-on: https://chromium-review.googlesource.com/396230
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The enforced FSP 1.0 APIs call was used to work around an fsp1.0 driver
issue. As the issue has been addressed in fsp1.0 driver (Change 9780),
remove the enforced workaround. Otherwise will see error message
'FSP API NotifyPhase failed' in serial log.
Verified on Intel Camelback Mountain CRB and confirmed that the serial
log error message regarding the 'FSP API NotifyPhase failed' is gone.
BUG=None
BRANCH=None
TEST=None
Signed-off-by: York Yang <york.yang@intel.com>
Reviewed-on: https://review.coreboot.org/16892
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Change-Id: Iafa1d22e2476769fd841a3ebaa1ab4f9713c6c39
Reviewed-on: https://chromium-review.googlesource.com/396229
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
When compiling a non-x86 platform with DRIVERS_INTEL_WIFI enabled,
we get the build error:
src/drivers/intel/wifi/wifi.c:17:30: fatal error:
arch/acpi_device.h: No such file or directory
acpi_device.h only exists in the x86 architecture directory.
BUG=None
BRANCH=None
TEST=None
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/16906
Tested-by: build bot (Jenkins)
Reviewed-by: Antonello Dettori <dev@dettori.io>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@googlemail.com>
Change-Id: Id0e29558336bf44e638cfcb97c22f31683ea4ec7
Reviewed-on: https://chromium-review.googlesource.com/396228
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Converged Security Engine (CSE) has a secure variable storage feature.
However, this storage is expected to be reset during S3 resume flow.
Since coreboot does not use secure storage feature, disable HECI2 reset
request. This saves appr. 130ms of resume time.
BUG=chrome-os-partner:56941
BRANCH=none
TEST=powerd_dbus_suspend; resume; check time with cbmem -t. Note
FspMemoryInit time is not significantly different from normal boot
time case.
Signed-off-by: Andrey Petrov <andrey.petrov@intel.com>
Reviewed-on: https://review.coreboot.org/16870
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Change-Id: I485a980369c6bd97c43b9e554d65ee89e84d8233
Reviewed-on: https://chromium-review.googlesource.com/396226
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
These header files contain a few new UPDs. The EnableS3Heci2
UPD will be used to save ~100ms from the S3 resume time on
Apollolake chrome platforms.
BUG=chrome-os-partner:58121
BRANCH=none
TEST=built coreboot for reef and verified no regressions
Signed-off-by: Brandon Breitenstein <brandon.breitenstein@intel.com>
Reviewed-on: https://review.coreboot.org/16869
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Change-Id: I1f324d00237c7150697800258a2f7b7eed856417
Reviewed-on: https://chromium-review.googlesource.com/396165
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
commit 028200f7 - x86/acpi_device: Add support for GPIO output polarity
updated ACPI_GPIO_OUTPUT to ACPI_GPIO_OUTPUT_ACTIVE_HIGH for the other
boards that needed it, but pyro wasn't in the tree when it was initially
pushed. Now that pyro is in the tree, it needs to be updated as well.
BUG=None
BRANCH=None
TEST=None
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/16930
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Change-Id: I617999b06ee584e0543d7ae3232bb2be2ff7429c
Reviewed-on: https://chromium-review.googlesource.com/396164
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This patch enables stage cache to save ~40ms during S3 resume.
It saves ramstage in the stage cache and restores it on resume
so that ramstage does not have to reinitialize during the
resume flow. Stage cache functionality is added to postcar stage
since ramstage is called from postcar.
BUG=chrome-os-partner:56941
BRANCH=none
TEST=built for Reef and tested ramstage being cached
Signed-off-by: Brandon Breitenstein <brandon.breitenstein@intel.com>
Reviewed-on: https://review.coreboot.org/16833
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Change-Id: I1551fd0faca536bd8c8656f0a8ec7f900aae1f72
Reviewed-on: https://chromium-review.googlesource.com/396161
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Instead of hard-coding the polarity of the GPIO to active high/low,
accept it as a parameter in devicetree. This polarity can then be used
while calling into acpi_dp_add_gpio to determine the active low status
correctly.
BUG=chrome-os-partner:55988
BRANCH=None
TEST=Verified that correct polarity is set for reset-gpio on reef.
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://review.coreboot.org/16877
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
Change-Id: I4aba4bb8bd61799962deaaa11307c0c5be112919
Reviewed-on: https://chromium-review.googlesource.com/396152
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Only acpi_dp of type DP_TYPE_TABLE is allowed to be an array. This
DP_TYPE_TABLE does not have a value which is written. Thus,
acpi_dp_write_array needs to start counting from the next element type
in the array. Fix this by updating the initialization in for loop for
writing array elements.
BUG=chrome-os-partner:55988
BRANCH=None
TEST=Verified that the correct number of elements are passed for
add_gpio in maxim sdmode-gpio.
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://review.coreboot.org/16871
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Change-Id: I8e1e540d66086971de2edf0bb83494d3b1dbd176
Reviewed-on: https://chromium-review.googlesource.com/396151
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
There is no code which uses the backup space in TPM created for vboot
nvram.
All chromebooks currently supported at the trunk store vboot nvram
in flash directly or as a backup.
BUG=chrome-os-partner:47915
BRANCH=none
TEST=emerge-samus coreboot
Change-Id: Ied0cec0ed489df3b39f6b9afd3941f804557944f
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/395507
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Some PVT units encountered DRAM calibration failure during power on/off
tests. The failure is caused by higher impedance of the DRAM on those units.
So increase the driving strength for 4GB DRAMs.
BUG=chrome-os-partner:57392
TEST=run cold reboot 100 times on PVT units which have DRAM calibration issue.
Change-Id: I0d1776cd1a5892d1f82e9bf414620d1ef6d29132
Signed-off-by: PH Hsu <ph.hsu@mediatek.com>
Reviewed-on: https://chromium-review.googlesource.com/394451
Commit-Ready: Yidi Lin <yidi.lin@mediatek.com>
Tested-by: Yidi Lin <yidi.lin@mediatek.com>
Reviewed-by: Pin-Huan Hsu <ph.hsu@mediatek.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
