This patch provides an increased timeout (60ms -> 1s) for SPI
HW-sequencing flash erase operations. Without that the erase for MRC
cache writing on siemens/mc_bdx1 sometimes goes wrong because the
timeout stops waiting for flash cycle completion. It was found
during continuous integration. Investigation showed that the used flash
type takes sporadic (e.g. 5% of the test cycles) more time for completion
of erasing operation if the ambient temperature increases. The measured
time values are in range of data sheet of SPI flash. 60ms is a typical
value. So increasing the value is necessary.
tested on siemens/bdx1; measured time values with increased ambient
temperature of flash were always smaller than worst case value of 1s.
Change-Id: Id50636f9ed834ffd7810946798b300e58b2c14d2
Signed-off-by: Uwe Poeche <uwe.poeche@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/34173
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
This patch moves SPI_FLASH time-outs from spi/spi_flash_internal.h for
SPI SW-sequencing to include/spi-generic.h to provide also for
SPI HW-sequencing.
tested on siemens/bdx1 and checked if all includes of
spi_flash_internal.h on other places provide an include of
spi-generic.h before
Change-Id: I837f1a027b836996bc42389bdf7dbab7f0e9db09
Signed-off-by: Uwe Poeche <uwe.poeche@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/34345
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Enable I2C0 in fleex then verify EMR function successfully
BUG=b:135968368
BRANCH=octopus
TEST=EMR function working normally with I2C0 in Grob360S.
Change-Id: I784ff32418bc839bcec14fbfd7236f708828690e
Signed-off-by: Frank Wu <frank_wu@compal.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/34364
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Marco Chen <marcochen@google.com>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
vboot_handoff is no longer used in coreboot, and is not
needed in CBMEM or cbtable.
BUG=b:124141368, b:124192753
TEST=make clean && make runtests
BRANCH=none
Change-Id: I782d53f969dc9ae2775e3060371d06e7bf8e1af6
Signed-off-by: Joel Kitching <kitching@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/33536
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Martin Roth <martinroth@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
-W is the old name for -Wextra, so let's rename it to be consistent with
the rest of the utility Makefiles.
Change-Id: I0e50f13d2617b785d343707fc895516574164562
Signed-off-by: Jacob Garber <jgarber1@ualberta.ca>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/34455
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
size_t is the natural integer type for strlen() and array indices, and
this fixes several integer conversion and sign comparison warnings.
Change-Id: I5658b19f990de4596a602b36d9533b1ca96ad947
Signed-off-by: Jacob Garber <jgarber1@ualberta.ca>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/33794
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
- Constify the string argument
- Change int to size_t, which is what xmalloc expects
Change-Id: I8b5a13319ded4025f883760f2b6d4d7a9ad9fb8b
Signed-off-by: Jacob Garber <jgarber1@ualberta.ca>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/33793
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
The documented return value for strlcat is horribly wrong, as is the
return value itself. It should not return the number of appended bytes,
but rather the length of the concatenated string. From the man page:
The strlcpy() and strlcat() functions return the total length of the
string they tried to create. For strlcpy() that means the length of
src. For strlcat() that means the initial length of dst plus the
length of src. While this may seem somewhat confusing, it was done
to make truncation detection simple.
This change is more likely to fix existing code than break it, since
anyone who uses the return value of strlcat will almost certainly rely
on the standard behaviour rather than investigate coreboot's source code
to see that we have a quirky version.
Change-Id: I4421305af85bce88d12d6fdc2eea6807ccdcf449
Signed-off-by: Jacob Garber <jgarber1@ualberta.ca>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/33787
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
SRCCLKENA holds 26M clock, which will fail suspend/resume,
and the SRCCLKENA is not used by mt8183,
so we can simply release it for suspend/resume to work.
BUG=b:80501386
BRANCH=none
Test=Boots correctly on Kukui, suspend test pass.
Change-Id: Ib6e11faeb6936a1dd6bbe8b1a8b612446bf51082
Signed-off-by: Yanjie.jiang <yanjie.jiang@mediatek.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/32666
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
SSPM is "Secure System Power Manager" that provides power control in
secure domain. The initialization flow is to load SSPM firmware to
its SRAM space and then enable.
BUG=b:80501386
BRANCH=none
Test=Build pass
Change-Id: I4ae6034454326f5115cd3948819adc448b67fb1c
Signed-off-by: Erin Lo <erin.lo@mediatek.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/31516
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
commit bde6d309df (x86: Change MMIO addr in
readN(addr)/writeN(addr, val) to pointer) accidentally changed
the type of reg32 to a u8 *, so change it back to a u32.
Change-Id: If6beff17ed3ddf85889aba5f41d1ba112cd74075
Signed-off-by: Jacob Garber <jgarber1@ualberta.ca>
Found-by: Coverity CID 1402160
Reviewed-on: https://review.coreboot.org/c/coreboot/+/34486
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Martin Roth <martinroth@google.com>
The 'Jacuzzi' is a different base board that will share most of Kukui
design. For AP firmware, there will be only a few changes expected,
mostly in display (for MIPI bridge) and EC/keyboard so we want to create
it as variants inside Kukui folder, not forking a new directory.
BUG=b:137517228
TEST=make menuconfig; select 'krane' and build; select 'jacuzzi' and build.
Change-Id: Ic2b04e01628dc3db40f79f9bbdd5cc77d9466753
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/34344
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Calibrate RTC eosc clock which will be used when RTC goes into
low power state.
BUG=b:133872611
BRANCH=none
TEST=Boots correctly on Kukui
Change-Id: Ie8fd6f4cffdcf7cf410ce48343378a017923789c
Signed-off-by: Ran Bi <ran.bi@mediatek.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/33907
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: You-Cheng Syu <youcheng@google.com>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
It is proper to check cpu turbo mode capability after it is selected
to be enabled. If processor exhibits the presence of hardware support for
turbo, turbo global state will be updated with TURBO_ENABLE. Otherwise,
TURBO_UNAVAILABLE is applied to turbo global state.
TEST=Validated turbo state on GLK and WHL devices.
Change-Id: Ib1bc37fb339b4a0bb6a7cdc6cd4391575b22b55a
Signed-off-by: John Zhao <john.zhao@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/34145
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
We do not want to disguise somewhat complex function
calls as simple macros.
Change-Id: I298f7f9a1c6a64cfba454e919eeaedc7bb2d4801
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/34411
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
All the PCI accesses in the file are now accessed
without SA_DEV_ROOT expanding to function call.
Change-Id: I30d331e9c18a486ea971e8397a6e20a0f82d5f84
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/34410
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Since PCH_DEVFN_PMC device is a PCI device that may be
hidden from enumeration, use SA_DEVFN_ROOT instead to
locate the SOC configuration.
Change-Id: I4b5195827fb32ec1dbd0bd6c9e243f4f9a4775ca
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/34327
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
This is based on the grunt variant.
BUG=b:135551210
BRANCH=none
TEST=emerge-grunt coreboot chromeos-bootimage
Ensure that image-treeya.*.bin are created
Signed-off-by: Chris Wang <chris.wang@amd.corp-partner.google.com>
Change-Id: I40f3c9de87350777b02dd91d8c5b9dbe2eb9f6b5
Reviewed-on: https://review.coreboot.org/c/coreboot/+/34435
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
According to the documentation [1], by default the RX Level/Edge Trig
Configuration set to disable (2h = Drive '0') for each pad. Since this
setting doesn't matter for the GPO pad, there is no need to change the
default value for such pads. The patch updates PAD_CFG_GPO* macros to
set trig to disable. It also resolves some problems of creating the
PCH/SoC pads configuration based on information from the inteltool
dump [2,3]
[1] page 1429,Intel (R) 100 Series and Intel (R) C230 Series PCH
Family Platform Controller Hub (PCH), Datasheet, Vol 2 of 2,
February 2019, Document Number: 332691-003EN
https://www.intel.com/content/dam/www/public/us/en/documents/
datasheets/100-series-chipset-datasheet-vol-2.pdf
[2] https://review.coreboot.org/c/coreboot/+/34337
[3] https://github.com/maxpoliak/pch-pads-parser/issues/1
Change-Id: I39ba83ffaad57656f31147fc72d7a708e5f61163
Signed-off-by: Maxim Polyakov <max.senia.poliak@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/34406
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Furquan Shaikh <furquan@google.com>
In the case there is no the circuit diagram for motherboard, the
PCH/SoC GPIOs config is based on information from the inteltool
dump. However, available macros from gpio_defs.h can't define the
pad configuration from this dump:
0x0440: 0x0000002084000500 GPP_A8 CLKRUN#
0x0448: 0x0000102184000600 GPP_A9 CLKOUT_LPC0
0x0450: 0x0000102284000600 GPP_A10 CLKOUT_LPC1
To convert these raw DW0/DW1 register values to macros, the following
parameters must be set:
func - pad function,
pull - termination,
rst - pad reset config,
trig - rx level/edge configuration,
bufdis - rx/tx (in/output) buffer disable.
The patch resolves the above problem by adding a new macro for the
native function configuration:
PAD_CFG_NF_BUF_TRIG(pad, pull, rst, func, bufdis, trig)
These changes were tested on Asrock H110M-DVS motherboard [2].
It also resolves the problem of automatically creating pads
configuration [3,4]
[1] page 1429,Intel (R) 100 Series and Intel (R) C230 Series PCH
Family Platform Controller Hub (PCH), Datasheet, Vol 2 of 2,
February 2019, Document Number: 332691-003EN
https://www.intel.com/content/dam/www/public/us/en/documents/
datasheets/100-series-chipset-datasheet-vol-2.pdf
[2] https://review.coreboot.org/c/coreboot/+/33565
[3] https://github.com/maxpoliak/pch-pads-parser/issues/1
[4] https://github.com/maxpoliak/pch-pads-parser/commit/215d303
Change-Id: If9fe50ff9a680633db6228564345200c0e1ee3ea
Signed-off-by: Maxim Polyakov <max.senia.poliak@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/34337
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This change provides an implementation of variant_devtree_update() for
kindred that disable eMMC controller when SKU ID = 1 or 3
BUG=b:132918661
TEST=Verify eMMC is disabled when SKU ID = 1 or 3
Change-Id: I8ccb4dae54f223881e0ced9e034bf45b994cc6f2
Signed-off-by: David Wu <david_wu@quanta.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/34400
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
We would like to wake eve up in suspend from an MKBP event. This commit
simply enables MKBP events to wake the system in suspend using the
existing host event interface. There is an accompanying series of
patches in the EC firmware for eve that will allow a MKBP wake mask to
be configured.
BUG=chromium:786721
BRANCH=firmware-eve-9584.B
TEST=Build and flash eve, generate MKBP events on the EC and verify
that the system wakes up in suspend.
Change-Id: I75b05c83a4204d55df11589299a7488d04bbd073
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/34454
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Bit 18 of MSR_POWER_CTL is documented as reserved, but we're setting it on
Haswell in order to enable EPB. It seems to work on SKL/KBL as well, so
do it there too.
Signed-off-by: Matthew Garrett <mjg59@google.com>
Change-Id: I83da1a57a04dac206cc67f2c256d0c102965abc2
Reviewed-on: https://review.coreboot.org/c/coreboot/+/34458
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
DIMM_SPD_SIZE is no longer used and should have been removed in
78025f6 "soc/amd/picasso: Remove all AGESA references".
Change-Id: Iae15998835e4d8afdb44cca77d2c9009b7e3947a
Signed-off-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/34419
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
Make the option match the change in I7c3b3ec.
"stoneyridge/Kconfig: Enable stage cache based on HAVE_ACPI_RESUME"
Change-Id: I7fa13428ec0119b61f429116a52986067e833bdf
Signed-off-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/34418
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
Put the devices in Family/Model order instead of a mostly
chronological order.
Change-Id: I425736012b3bb68c9e0b417e90ff5261d1193aba
Signed-off-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/34415
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
The decision to leave the alignment in stoneyridge was driven because
of a spec difference with picasso. AMD has checked the design
materials and has confirmed there was no change.
TEST=Build Grunt successfully
BUG=b:130343127
Change-Id: If3a1d5a41dc175c9733fd09ad28627962646daf9
Signed-off-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/34414
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
Functional changes were already done in 5eb81bed2e (sb/intel/i82801gx:
Detect if the southbridge supports AHCI) but we forgot to update the
`chip.h` and devicetrees.
Change-Id: I0e25f54ead8f5bbc6041d31347038e800787b624
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/34462
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The EC ID of the ECDT needs to be null-terminated (see ACPI specification,
section 5.2.15), which currently isn't being done due to an off-by-one
error. strncpy() is bug-prone exactly because of issues like this, so just
skip it entirely and use memcpy() instead.
Change-Id: I0b62e1f32177c9768fa978053ab26bca93d7248d
Signed-off-by: Jacob Garber <jgarber1@ualberta.ca>
Found-by: Coverity CID 1402104
Reviewed-on: https://review.coreboot.org/c/coreboot/+/34374
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
path.mmio.addr is a uintptr_t, which is an unsigned long.
Change-Id: I5e43e0ab65cf59819abe1dde43143ff98e4553b0
Signed-off-by: Jacob Garber <jgarber1@ualberta.ca>
Found-by: Coverity CID 1402110
Reviewed-on: https://review.coreboot.org/c/coreboot/+/34370
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
Disable unused USB devices in the device tree so that the concerned ACPI
objects do not get exported to the OS.
BUG=b:133513961
BRANCH=octopus
TEST=Boot to ChromeOS. Ensure that the USB devices are disabled based
on port status and the concerned ACPI objects are not exported.
Change-Id: I0faccdfb8a9df9ec52130437433b15973e3d6f1a
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/34291
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Add devicetree configuration for USB devices so that USB Port
Capabilities (_UPC) and Physical Location of Device (_PLD) ACPI objects
can be exported to the OS.
BUG=b:133513961
BRANCH=octopus
TEST=Boot to ChromeOS. Ensure that the _UPC & _PLD ACPI objects are
exported for the configured USB devices in the SSDT table.
Change-Id: I832ffe305d256296b7447035c5e5dcafb7c296d9
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/33378
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Add API to disable USB devices that are not present but are configured
in the device tree either after probing the concerned port status or as
explicitly configured by the variants.
BUG=None
BRANCH=octopus
TEST=Boot to ChromeOS.
Change-Id: Ied12faabee1b8c096f2b27de89ab42ee8be5d94d
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/33377
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
It feels appropriate to define SoC specific XHCI USB info in SoC
specific XHCI source file and an API to get that information instead of
defining it in elog source file. This will help in other situations
where the information is required.
BUG=None
BRANCH=None
TEST=Boot to ChromeOS.
Change-Id: Ie63a29a7096bfcaab87baaae947b786ab2345ed1
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/34290
Reviewed-by: Paul Fagerburg <pfagerburg@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch lists all supported vesa mode by oprom
using Function 0x4F00 (return vbe controller information).
This information might be useful for user to select correct vesa
mode for oprom.
TEST=Enabling external pcie based graphics card on ICLRVP
Case 1: with unsupported vesa mode 0x118
Now coreboot will show below msg to user to know there is a potential
issue with choosen vesa mode and better users know the failure rather
going to depthcharge and debug further.
Calling Option ROM...
... Option ROM returned.
VBE: Getting information about VESA mode 4118
VBE: Function call invalid with unsupported video mode 0x118!
User to select mode from below list -
Supported Video Mode list for OpRom are:
0x110
0x111
0x113
0x114
0x116
0x117
0x119
0x11a
0x165
0x166
0x121
0x122
0x123
0x124
0x145
0x146
0x175
0x176
0x1d2
0x1d4
Error: In vbe_get_mode_info function
Case 2: with supported vesa mode 0x116
Calling Option ROM...
... Option ROM returned.
VBE: Getting information about VESA mode 4116
VBE: resolution: 1024x768@16
VBE: framebuffer: a0000000
VBE: Setting VESA mode 4116
VGA Option ROM was run
Change-Id: I02cba44374bc50ec3ec2819c97b6f5027c58387f
Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/34284
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
When generating entries in SSDT for DesignWare I2C controllers, only
use the speed selected in the devicetree, instead of trying all of them.
This quiets a message which looks like a bug ("dw_i2c: bad counts"),
later on in this driver when checking rise/fall times.
BUG=b:137298661
BRANCH=none
TEST=Boot and verify that I2C controllers still function, and
the nastygram message is gone.
Change-Id: I07207ec95652e8af1a42bfe31214f61a183a134e
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/34385
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Paul Fagerburg <pfagerburg@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
We would like to wake nocturne up in suspend from an MKBP event. On
Nocturne, MKBP events are notified to the host via a GPIO from the EC,
EC_INT_L. However, the AP cannot wake from suspend from this GPIO.
Therefore, we'll use the host event interface to wake the system
instead.
This commit simply enables MKBP events to wake the system in suspend.
BUG=chromium:786721
BRANCH=firmware-nocturne-10984.B
TEST=Build and flash nocturne, generate MKBP events on the EC and verify
that the system wakes up in suspend.
Change-Id: I6aff4d38051c939257533229fd0085e42c01d02f
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/34388
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Uwe Poeche