I2C bus and address of the TPM are typically fixed on hardware so
there is no need to be able to configure this in menuconfig.
Change-Id: I1b6afa68fe753fb76348e0461209d218b14df7cb
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/59802
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
The variable `custom_count` is the number of custom fields, so only
holds non-negative values, so change the struct member type from int to
size_t.
Change-Id: Ic35aafefc870092298523ba2e10adf4fcb687a01
Signed-off-by: Paul Menzel <pmenzel@molgen.mpg.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/60790
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Building an image for OCP DeltaLake with `x86_64-linux-gnu-gcc-11` fails
with the format warning below as the size of char * differs between
32-bit and 64-bit.
CC ramstage/drivers/ipmi/ipmi_fru.o
src/drivers/ipmi/ipmi_fru.c: In function 'read_fru_chassis_info_area':
src/drivers/ipmi/ipmi_fru.c:192:57: error: format '%ld' expects argument of type 'long int', but argument 4 has type 'unsigned int' [-Werror=format=]
192 | printk(BIOS_ERR, "%s failed to malloc %ld bytes for "
| ~~^
| |
| long int
| %d
193 | "chassis custom data array.\n", __func__,
194 | info->custom_count * sizeof(char *));
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| |
| unsigned int
src/drivers/ipmi/ipmi_fru.c: In function 'read_fru_board_info_area':
src/drivers/ipmi/ipmi_fru.c:291:57: error: format '%ld' expects argument of type 'long int', but argument 4 has type 'unsigned int' [-Werror=format=]
291 | printk(BIOS_ERR, "%s failed to malloc %ld bytes for "
| ~~^
| |
| long int
| %d
292 | "board custom data array.\n", __func__,
293 | info->custom_count * sizeof(char *));
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| |
| unsigned int
src/drivers/ipmi/ipmi_fru.c: In function 'read_fru_product_info_area':
src/drivers/ipmi/ipmi_fru.c:398:57: error: format '%ld' expects argument of type 'long int', but argument 4 has type 'unsigned int' [-Werror=format=]
398 | printk(BIOS_ERR, "%s failed to malloc %ld bytes for "
| ~~^
| |
| long int
| %d
399 | "product custom data array.\n", __func__,
400 | info->custom_count * sizeof(char *));
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| |
| unsigned int
Fix the mismatches in `read_fru_chassis_info_area()` by using the length
modifier `z` for size_t as that is what `size_of` yields to.
Change-Id: If0c4266b19d56fa88abc397f305154d473ae1a93
Found-by: gcc (Debian 11.2.0-10) 11.2.0
Signed-off-by: Paul Menzel <pmenzel@molgen.mpg.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/59055
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Group all data specific to each notify phase in a struct to avoid
redundant code.
Change-Id: Ib4ab3d87edfcd5426ce35c168cbb780ade87290e
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/60639
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Sort includes alphabetically, drop spaces after type casts and unbreak
some long lines that are less than 96 characters long.
Tested with BUILD_TIMELESS=1, Prodrive Hermes remains identical.
Change-Id: I2dafd677abbdd892745fea1bf4414f6e0d5549bb
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/60638
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
When coreboot goes to die because FSP returned an error, log the return
value in the message printed by `die()` or `die_with_post_code()`.
Change-Id: I6b9ea60534a20429f15132007c1f5770760481af
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/60637
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
The Realtek RTL8125 has four registers for four leds
and a feature config register.
We use led0 and led2 in brask, so modify ethernet driver.
Those registers' IO address are based on RTL8125 datasheet.
BUG=b:193750191
TEST=Modify overridetree.cb to verify LEDs' settings.
Signed-off-by: Rory Liu <rory.liu@quanta.corp-partner.google.com>
Change-Id: I4b05a859dc0a0d2b8d6b35d6491fc88f7077cb92
Reviewed-on: https://review.coreboot.org/c/coreboot/+/59531
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Currently, the pmc_mux/conn driver uses integer fields to store the
USB-2 and USB-3 port numbers from the SoC's point of view. Specifying
these as integers in the devicetree is error-prone, and this
information can instead be represented using pointers to the USB-2 and
USB-3 devices. The port numbers can then be obtained from the paths of
the linked devices, i.e. dev->path.usb.port_id.
Modify the driver to store device pointers instead of integer port
numbers, and update all devicetrees using the driver. These are the
mainboards affected (all are Intel TGL or ADL based):
google/brya
google/volteer
intel/adlrvp
intel/shadowmountain
intel/tglrvp
system76/darp7
system76/galp5
system76/lemp10
Command used to update the devicetrees:
git grep -l "usb._port_number" src/mainboard/ | \
xargs sed -i \
-e 's/register "usb2_port_number" = "\(.*\)"/use usb2_port\1 as usb2_port/g' \
-e 's/register "usb3_port_number" = "\(.*\)"/use tcss_usb3_port\1 as usb3_port/g'
BUG=b:208502191
TEST=Build test all affected boards. On brya0, boot device and check
that the ACPI tables generated with and without the change are the same.
Change-Id: I5045b8ea57e8ca6f9ebd7d68a19486736b7e2809
Signed-off-by: Reka Norman <rekanorman@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/60143
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Tim Crawford <tcrawford@system76.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
The Bayhub LV2 has a known errata wherein PCI config registers at
offsets 0x234, 0x238, and 0x24C will only correctly accept writes
when they are addressed via a DWORD (32-bit) wide write operation
on the PCIe bus. Offset 0x234 is the LTR max snoop and max no-snoop
latency register, therefore add a finalize callback to this driver
which will program the LTR max-snoop/no-snoop register with a 32-bit
write using the values from pciexp_get_ltr_max_latencies().
BUG=b:204343849
TEST=verified the PCI config space writes took effect on google/taeko
Change-Id: I1813f798faa534fb212cb1a074bc7bcadd17a517
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/60016
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
This should make it a bit clearer what the differences between
SPI_CNTRLR_DEDUCT_OPCODE_LEN and SPI_CNTRLR_DEDUCT_CMD_LEN and the
corresponding functionality in spi_crop_chunk are.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I809adebb182fc0866b93372b5b486117176da388
Reviewed-on: https://review.coreboot.org/c/coreboot/+/60122
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
In the case of deduct_cmd_len being set and the adjusted cmd_len >=
ctrlr_max, ctrlr_max wasn't being adjusted and still had the value of
ctrlr->max_xfer_size. Handle this edge case (which we should never run
into) by setting ctrlr_max to 0 and printing a warning to the console.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I9941b2947bb0a44dfae8ee69f509795dfb0cb241
Reviewed-on: https://review.coreboot.org/c/coreboot/+/60121
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Currently coreboot interprets TCSS port number as per physical port
number while EC abstracts port number and provides indices as port
number. For example, if TCSS port 1 and 3 are enabled on the board,
coreboot will interpret port numbers as 0 and 2, but since only 2 ports
are enabled in the system EC will assign port numbers as 0 and 1.
This creates a port number mismatch while communicating between EC and
coreboot. This patch addresses issue where SoC can implement function
to map correct EC port as per port enabled in mainboard.
BUG=b:207057940
BRANCH=None
TEST=Check if code compiles successfully. Functionality will work once
function is implemented in SoC code.
Change-Id: Ia7a5e63838e6529196bd211516e4d665b084f79e
Signed-off-by: MAULIK V VAGHELA <maulik.v.vaghela@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/59665
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Add entry in ACPI table under IPU device to provide silicon type
information to IPU driver. IPU kernel driver can decide the type of
firmware to load based on this information.
BUG=b:207721978
BRANCH=none
TEST=Check for the ACPI entry in the SSDT after booting to kernel
Change-Id: I4e0af1dd50b9c014cae5454fcd4f9f76d0e0a85f
Cq-Depend: chromium:3319905
Signed-off-by: Sugnan Prabhu S <sugnan.prabhu.s@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/59869
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sridhar Siricilla <sridhar.siricilla@intel.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
The Realtek RT8168 and RT8125 have a similar programming interface,
therefore add the PCI device ID for the RT8125 into driver for support.
BUG=b:193750191
TEST=emerge-brask coreboot chromeos-bootimage. Test on brask whose NIC
is RT8125. Check if the default MAC is written into the NIC.
Signed-off-by: Alan Huang <alan-huang@quanta.corp-partner.google.com>
Change-Id: Iaa4c41f94fd6e5fd6393abbb30bfc22a149f5d71
Reviewed-on: https://review.coreboot.org/c/coreboot/+/59086
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Zhuohao Lee <zhuohao@google.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
The current implementations of edid_read() and segments_edid_read() have
a few problems:
1. The type of variable `c` is incorrect, not matching the return type
of sp_tx_aux_rd(). In addition, the meaning of `c` is unknown.
2. It is pointless to do `cnt++` when sp_tx_aux_rd() fails.
3. These two functions ignore the return value of
anx7625_reg_block_read().
4. In segments_edid_read(), anx7625_reg_write() might return a positive
value on failure.
Fix all of the 4 issues, and modify the code to be closer to kernel
5.10's implementation (drivers/gpu/drm/bridge/analogix/anx7625.c). Note
that, however, unlike in kernel, anx7625_reg_block_read() here doesn't
return the number of bytes. On success, 0 is returned instead.
In addition, following coreboot's convention, always return negative
error codes. In particular, change the return value to -1 for
edid_read() and segments_edid_read() on failure.
BUG=b:207055969
TEST=emerge-asurada coreboot
BRANCH=none
Change-Id: Ife9d7d97df2926b4581ba519a152c9efed8cd969
Signed-off-by: Yu-Ping Wu <yupingso@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/59540
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Some boards may want to use a _HID instead of an _ADR to locate a
graphics device. This patch provides that option in the devicetree.
BUG=b:206850071
TEST=Add `hid` entry in devicetree, dump SSDT and see _HID instead of
_ADR
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Change-Id: I32be4abf5c60be1f94aabaa2e9c734215c4e291e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/59730
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
The SMMSTORE_IN_CBFS option was just meant as a workaround for an
attempt to backport SMMSTORE into older Chromebooks that never actually
happened. All current and future users of coreboot should be using
SMMSTORE in an FMAP region. The APIs needed for SMMSTORE_IN_CBFS clash
with the CBFS rdev isolation needed for CBFS_VERIFICATION, so let's just
get rid of it.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: Ia0604a4ffd20b46774631d585925311b65d5a0e9
Reviewed-on: https://review.coreboot.org/c/coreboot/+/59680
Reviewed-by: Patrick Georgi <patrick@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Some boards may use more than 4 temperature sensors for DPTF thermal
control, so this patch adds support for one more temperature sensor.
BUG=b:207585491
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Change-Id: Ibf9666bade23b9bb4f740c6c4df6ecf5227cfb45
Reviewed-on: https://review.coreboot.org/c/coreboot/+/59632
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Scott Chao <scott_chao@wistron.corp-partner.google.com>
Reviewed-by: Sumeet R Pawnikar <sumeet.r.pawnikar@intel.com>
CB:59479 introduced a blank default statement. This is treated as an
error or warning on some older toolchains. Add a break statement on
default case.
BUG=None
TEST=Build the Guybrush mainboard.
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Change-Id: I3d034cfebc8b8ae7d7024d41b4b2207cdeb083e8
Reviewed-on: https://review.coreboot.org/c/coreboot/+/59551
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Patrick Georgi <patrick@coreboot.org>
Reviewed-by: Rob Barnes <robbarnes@google.com>
The device is a PCIe Gen1 to SD 3.0 card reader controller to be
used in the Chromebook. The datasheet name is GL9750S and the revision
is 01.
The patch disables ASPM L0s.
BUG=b:206014046
TEST=Verify GL9750 enters L1 by observing CLKREQ# de-asserts.
Signed-off-by: Ben Chuang <benchuanggli@gmail.com>
Change-Id: I6d60cef41baade7457a159d3ce2f8d2e6b66e71c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/59429
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Introduce firmware-power-managed DSD ACPI property for TPM devices.
This property can be checked by the kernel TPM driver to override how
the TPM power states are managed. This is a tri-state flag, true,
false, or unset. So an enum used to keep the flag is unset by default.
When firmware-power-managed is true, the kernel driver will not send a
shutdown during s2idle/s0i3 suspend.
BUG=b:200578885
BRANCH=None
TEST=TPM shutdown is triggered on s0ix suspend on guybrush with patched
kernel
Change-Id: Ia48ead856fc0c6e637a2e07a5ecc58423f599c5b
Signed-off-by: Rob Barnes <robbarnes@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/59479
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
The _DSC (Device State for Configuration) object evaluates to an integer
may be used to tell Linux the highest allowed D state for a device
during probe. The support for _DSC requires support from the kernel
bus type if the bus driver normally sets the device in D0 state for
probe.
The D states and thus also the allowed values for _DSC are listed below.
Number State Description
0 D0 Device fully powered on
1 D1
2 D2
3 D3hot
4 D3cold Off
More details can be found here https://lkml.org/lkml/2021/10/25/397
BUG=none
BRANCH=none
TEST=Add corresponding field in brya, boot and dump SSDT to check if
_DSC field is as per expectation.
Name (_ADR, Zero) // _ADR: Address
Name (_HID, "OVTI8856") // _HID: Hardware ID
Name (_UID, Zero) // _UID: Unique ID
Name (_DDN, "Ov 8856 Camera") // _DDN: DOS Device Name
Method (_STA, 0, NotSerialized) // _STA: Status
{
Return (0x0F)
}
Method (_DSC, 0, NotSerialized)
{
Return (0x04)
}
Signed-off-by: Varshit B Pandya <varshit.b.pandya@intel.com>
Change-Id: I5471f144918413a2982f86beaf3dbf7e4e66cc9b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58767
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Maulik V Vaghela <maulik.v.vaghela@intel.com>
Reviewed-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
So far POST codes were mapped on IO port 0x80 inside the NC FPGA which
was connected via the LPC bus to the host CPU. On recent x86 generations
the LPC bus was replaced with eSPI and not all Siemens boards have the
eSPI routed to the NC FPGA. In order to have POST codes visible on those
boards the display is accessible via PCI in addition.
This patch adds the feature of sending the POST codes to the NC FPGA via
a PCI mapped register.
Change-Id: Ie15686de49cface17830365d78fe7c54cce183a0
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/59346
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Mario Scheithauer <mario.scheithauer@siemens.com>
Change to use MAX_DSAR_SET_COUNT which WLAN driver always expects 3
no matter what the revision is for EWRD.
It will pass the WLAN driver check then to retrieve the data properly.
BUG=b:204414616
TEST= tested on brya with DRTU tool to verify if SAR table is
read properly or not.
Change-Id: I18e7d5f658bbf42b7eeed3da330508f14b86c0f8
Signed-off-by: Matt Chen <matt.chen@intel.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58951
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kane Chen <kane.chen@intel.corp-partner.google.com>
Reviewed-by: EricR Lai <ericr_lai@compal.corp-partner.google.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Currently, the MMCONF Kconfigs only support the Enhanced Configuration
Access mechanism (ECAM) method for accessing the PCI config address
space. Some platforms have a different way of mapping the PCI config
space to memory. This patch renames the following configs to
make it clear that these configs are ECAM-specific:
- NO_MMCONF_SUPPORT --> NO_ECAM_MMCONF_SUPPORT
- MMCONF_SUPPORT --> ECAM_MMCONF_SUPPORT
- MMCONF_BASE_ADDRESS --> ECAM_MMCONF_BASE_ADDRESS
- MMCONF_BUS_NUMBER --> ECAM_MMCONF_BUS_NUMBER
- MMCONF_LENGTH --> ECAM_MMCONF_LENGTH
Please refer to CB:57861 "Proposed coreboot Changes" for more
details.
BUG=b:181098581
BRANCH=None
TEST=./util/abuild/abuild -p none -t GOOGLE_KOHAKU -x -a -c max
Make sure Jenkins verifies that builds on other boards
Change-Id: I1e196a1ed52d131a71f00cba1d93a23e54aca3e2
Signed-off-by: Shelley Chen <shchen@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57333
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
In the non-XIP world, FSP is normally memmapped and then decompressed.
The AMD SPI DMA controller can actually read faster than mmap. So by
reading the contents into a buffer and then decompressing we reduce boot
time.
BUG=b:179699789
TEST=Boot guybrush and see 30ms reduction in boot time
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I28d7530ae9e50f743e3d6c86a5a29b1fa85cacb6
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58987
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
This option will allow setting the FSP alignment in CBFS.
BUG=b:179699789
TEST=Boot with and without the option set and verify -a option was
passed.
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I4533f6c9d56bea6520aa3aa87dd49f2144a23850
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58986
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
AMD platforms pass in the base address to cbfs tool:
fspm.bin-options: -b $(CONFIG_FSP_M_ADDR)
There is no technical reason not to allow FSP-M to be relocated when
!XIP. By allowing this, we no longer need to pass in the base address
into cbfstool when adding fspm.bin. This enables passing in the
`--alignment` argument to cbfs tool instead. cbfstool currently has a
check that prevents both `-b` and `-a` from being passed in.
BUG=b:179699789
TEST=Boot guybrush to OS
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I797fb319333c53ad0bbf7340924f7d07dfc7de30
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58984
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
elog init requires doing a lot of SPI transactions. This change makes it
clear how long we spend initializing elog.
BUG=b:179699789
TEST=Boot guybrush and see elog init timestamps
114:started elog init 3,029,116 (88)
115:finished elog init 3,071,281 (42,165)
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: Ia92372dd76535e06eb3b8a08b53e80ddb38b7a8f
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58957
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The `find_resource` function will never return null (will die instead).
In cases where the existing code already accounts for null pointers, it
is better to use `probe_resource` instead, which returns a null pointer
instead of dying.
Change-Id: Ia9a4b62c857f7362d67aee4f9de3bb2da1838394
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58908
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Add backlight support in ps8640 through the AUX channel using eDP
DPCD registers.
BUG=b:202966352
BRANCH=trogdor
TEST=verified firmware screen works on homestar rev4
Change-Id: Ief1bf56c89c8215427dcbddfc67e8bcd4c3607d2
Signed-off-by: xuxinxiong <xuxinxiong@huaqin.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58624
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
