If panel has too small hfp or hbp, hfp_byte or hbp_byte may become
very small value or negative value. When very small value or
negative value is used, the panel will be scrolling or distorted.
This patch adjusts their values so that they are greater than
the minimum value and keep total of them unchanged.
DSI transfer HBP or HFP, There are some extra packet. ex. packet
header(4byte) and eof(2byte) and (next)hs packet header(4 byte).
the hfp_byte = HFP * BPP - packet header(4byte) and eof(2byte)
and (next)hs packet header(4 byte). So the min hfp_byte is 2 when
HFP = 4.
This is equivalent to the Linux kernel DSI change in:
https://chromium-review.googlesource.com/c/chromiumos/third_party/
kernel/+/2186872
BUG=b:144824303
BRANCH=kukui
TEST=boot damu board with panel CMN N120ACA-EA1 (12" panel and its
hbp only 6), the panel can display without scrolling or
distortions.
Signed-off-by: Paul Ma <magf@bitland.corp-partner.google.com>
Change-Id: I608c01d41ae93c8d5094647bbf3e0ae4a23d814c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41163
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Update processor power limit configuration parameters based on
common code base support for Intel Jasperlake SoC based platforms.
BRANCH=None
BUG=None
TEST=Built for jasperlake system
Change-Id: I9b725d041dcb8847f83ec103e58b9571b4c596ac
Signed-off-by: Sumeet R Pawnikar <sumeet.r.pawnikar@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41237
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Add processor power limits control support under common code.
BRANCH=None
BUG=None
TEST=Built and checked this entry on Volteer system,
cat /sys/class/powercap/intel-rapl/intel-rapl\:0/*
Change-Id: I41fd95949aa2b02828aa2d13d29b962cb579904a
Signed-off-by: Sumeet R Pawnikar <sumeet.r.pawnikar@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/39346
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
By default ROMSTAGE_ADDR and VERSTAGE_ADDR are set to 0x2000000. This
causes problems in a non-xip environment because when verstage loads
romstage, it overrides it's memory. So pick a different offset for
verstage.
BUG=b:147042464
TEST=Boot verstage on trembyle and see OS boot.
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I2464db6f3769bd23d250588b341d1c9e44f10d21
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41367
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This is required to enable VBOOT_STARTS_IN_BOOTBLOCK and
VBOOT_SEPARATE_VERSTAGE for picasso.
BUG=b:147042464
TEST=Boot verstage on picasso
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: Ic3e261a6919a78760d567be9cc684494a5aeab6d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41366
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
As per schematics configure headset interrupt as
edge both for ripto and volteer baseboard.
BUG=b:147085988
BRANCH=none
TEST=Build and boot ripto board. Test that jack functionality
is working fine and also confirm with evtest.
Signed-off-by: Shaunak Saha <shaunak.saha@intel.com>
Change-Id: I8e1625140ccf55db8cb0fe3c039f1c31c01069b0
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41335
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sathyanarayana Nujella <sathyanarayana.nujella@intel.com>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Srinidhi N Kaushik <srinidhi.n.kaushik@intel.com>
CPU to PCH method refers to PCH ACPI operation region which was wrongly
defined as SystemIO. This causes ACPI AE_LIMIT error from PM _DSW
method. Change the operation region from SystemIO to SystemMemory to
resolve this execution failure.
BUG=b:140290596
TEST=Built and booted to kernel. _DSW method executes successfully without
ACPI AE_LIMIT error.
Signed-off-by: John Zhao <john.zhao@intel.com>
Change-Id: I3965c3d891f7d3cf4a448edc0c3f7e7749a905a1
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41365
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
genrelnotes moves the tree between commits and so a relative location
like HEAD isn't stable. Since I ran into the HEAD issue while preparing
for two consecutive releases, let's guard against it.
Change-Id: I70c6812cdfe0d0671b3d653744a062d9920a2394
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41339
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
genrelnotes checks for cloc, git and rename but only reported about
needing the first two, so mention `rename` in missing message.
Change-Id: If91d759fc68760fd89b98756ac5b19ac3589c197
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41338
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Since I seem to forget to remove "Upcoming" in the release notes
every single time, and others might as well, fix it here and also
tell future release managers to take care of that.
Change-Id: I8ffe34f25e954621bdd635e115a8b1a914df9c27
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41337
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
NO_RANKSEL was introduced because it appeared less often and it did not
cause any lines to become too long. To simplify macro transmutation, add
the RANKSEL opposite and keep NO_RANKSEL as a no-op to ease replacement.
Line length limits are not for review. Breaking the lines unnecessarily
complicates search and replace operations, and wil be taken care of in
subsequent commits.
Tested with BUILD_TIMELESS=1, ASUS P8Z77-V LX2 remains unchanged.
Change-Id: I5d7aad59fc79840da7de2e9421b84834a6024eb9
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40977
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This is a temporary solution to simplify refactoring verification.
Programming a subsequence involves writing a group of four registers.
Abstract this into a "program subsequence" operation. This eliminates
register write noise, which should improve the readability of the code.
To replace the register writes with assignments to struct fields, we
would need to have the values as parameters of a single macro. So,
unroll SUBSEQ_CTRL and SP_CMD_ADDR into parameters of IOSAV_SUBSEQUENCE.
Line length limits are not for review. Breaking the lines unnecessarily
complicates search and replace operations, and wil be taken care of in
subsequent commits.
Tested with BUILD_TIMELESS=1, ASUS P8Z77-V LX2 remains unchanged.
Change-Id: I23f7706ba8a87c1c26f9d40a50b6d47dcf95106a
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40971
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
We have a single IOSAV sequence that is broadcast across all channels.
Introduce the BROADCAST_CH macro, so that we can use the per-channel
register definitions. Treating all IOSAV sequence writes the same eases
the refactoring done in subsequent commits. Also, drop the broadcast
register definitions for the IOSAV commands, as they are now obsolete.
Line length limits are not for review. Breaking the lines unnecessarily
complicates search and replace operations, and wil be taken care of in
subsequent commits.
Tested with BUILD_TIMELESS=1, ASUS P8Z77-V LX2 remains unchanged.
Change-Id: I2dbb100fcad68d128e92b1bc9321fc1e53b748c9
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40976
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The struct definition makes use of types defined in that header.
Change-Id: I1d989298b8bf6266905330491c136874be7f5e28
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41475
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
This was used by the now-gone Asus KFSN4-DRE mainboard. Drop it.
Change-Id: Id00c883ed0f80e7af96fdf3f6e2985dd5b227831
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41402
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
With conversion to variant structure complete, remove temporary guards
inserted to help validate the move.
With this change, all P2B family boards (currently p2b and p2b-ls)
share the same S-state declarations.
TEST=No apparent ACPI regression observed on p2b-ls.
Change-Id: Ibd6e49adeae2a42800ee5bfd74b3850eb19843a5
Signed-off-by: Keith Hui <buurin@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41051
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Lower 20bits of TOLUD register include 19 reserved bits and 1 lock
bit. If lock bit is set, then northbridge.asl was reporting the base
address of low MMIO incorrectly i.e. off by 1. This resulted in Linux
kernel complaining that the MMIO window allocated to the device at the
base of low MMIO is incorrect:
pci 0000:00:1c.0: can't claim BAR 8 [mem 0x7fc00000-0x7fcfffff]: no compatible brw
pci 0000:00:1c.0: [mem 0x7fc00000-0x7fcfffff] clipped to [mem 0x7fc00001-0x7fcfff]
pci 0000:00:1c.0: bridge window [mem 0x7fc00001-0x7fcfffff]
This change masks the lower 20 bits of TOLUD register when exposing it
in the ACPI tables to ensure that the base address of low MMIO region
is reported correctly.
TEST=Verified that kernel dmesg no longer complains about the BAR at
base of low MMIO.
Signed-off-by: Furquan Shaikh <furquan@google.com>
Change-Id: I4849367d5fa03d70c50dc97c7e84454a65d1887a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41455
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This reverts commit 3b02006afe.
Reason for revert: Resource allocator patches need to be reverted
until the AMD chipsets can be fixed to handle the resource allocation
flow correctly.
BUG=b:149186922
Change-Id: Id9872b90482319748b4f3ba2e0de2185d5c50667
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41413
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Mike Banon <mikebdp2@gmail.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This reverts commit 44ae0eacb8.
Reason for revert: Resource allocator patches need to be reverted
until the AMD chipsets can be fixed to handle the resource allocation
flow correctly.
BUG=b:149186922
Change-Id: I90f3eac2d23b5f59ab356ae48ed94d14c7405774
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41412
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Mike Banon <mikebdp2@gmail.com>
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This reverts commit dcbf6454b6.
Reason for revert: Resource allocator patches need to be reverted
until the AMD chipsets can be fixed to handle the resource allocation
flow correctly.
Change-Id: I58c9fff1a18ea1c9941e29c2c6e60e338c517c30
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41465
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Mike Banon <mikebdp2@gmail.com>
This reverts commit 2412924bc7.
Reason for revert: Resource allocator patches need to be reverted
until the AMD chipsets can be fixed to handle the resource allocation
flow correctly.
BUG=b:149186922
Change-Id: Iea6db8cc0cb5a0e81d176ed3199c91dcd02d1859
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41411
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Mike Banon <mikebdp2@gmail.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Based on the autoport. The OptiPlex 9010 comes in four different sizes:
MT, DT, SFF and USFF. Tested on SFF only. The other PCBs are slightly
different, but they are designed with intercompatibility in mind. With
small devicetree overrides it should work on OptiPlex 7010 and other
OptiPlex 9010 variants as well.
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Change-Id: I88d65cae30d08ca727d86d930707c2be25a527cf
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40351
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The SMSC SCH5545 is very similar to the publicly available
datasheet for the SCH5627.
TEST=use PS2 keyboard and mouse, serial port, runtime registers and
Embedded Memory Interface on Dell Optiplex 9010
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Change-Id: If8a60d5802675f09b08014ed583d2d8afa29fc04
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40350
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
If the device doesn't return a valid component type, that means the
device is non-functional.
The dw_i2c_regs had invalid offsets for the version field. I got the
correct value from the DesignWare DW_apb_i2c Databook v2.02a. It also
matches what the Picasso PPR says.
I also print out the version field of the controller.
BUG=b:153001807
BRANCH=none
TEST=Tested on PSP where I2C is non functional. Also tested on trembyle
and verified i2c was initialized.
Saw the following in the logs
I2C bus 2 version 0x3132322a
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: If5527972508e0f4b35cc9ecdb1491b1ce85ff3af
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/third_party/coreboot/+/2144540
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40870
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Correct comment on HMRFPO_ENABLE flow for CSE Lite SKU. In order to place
CSE into SECOVER_MEI_MSG mode, below procedure has to be followed.
1. Ensure CSE boots from RO(BP1).
- Set CSE's next boot partition to RO
- Issue GLOBAL_RESET HECI command to reset the system
2. Send HMRFPO_ENABLE command to CSE. Further, no reset is required.
TEST=Verified on hatch
Signed-off-by: Sridhar Siricilla <sridhar.siricilla@intel.com>
Change-Id: I213e02ba3898194fa6c8fe38fab34b5c19f25aa1
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41340
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Rizwan Qureshi <rizwan.qureshi@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Based on Fibocom HW user manual RESET should be deasserted at least 20ms after the power on pin.
The design for the reset pin is open drain connected to a pull up, so it is set to high-Z (configured as GPIO in) after 20ms.
BUG=b:152013143
BRANCH=none
TEST=traced the signals using a scope to verify timing is met.
Signed-off-by: Alex Levin <levinale@chromium.org>
Change-Id: I7c947d1bc4cce1f97383a2f2c254986e182661c5
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41356
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Power key is a special non-matrixed key. Chrome /powerd
only listens to the keyboard device for this key, so add
its keymap.
BUG=b:155941390
TEST=Test that power key generates KEY_POWER in linux evtest
Change-Id: I570602d9febcb5c17e58761f2004ee88be16c27f
Signed-off-by: Rajat Jain <rajatja@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41382
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Configuring pull for SD-card detect pin.
Without this SD-card detection is not working as expected
Signed-off-by: Shaik Sajida Bhanu <sbhanu@codeaurora.org>
Change-Id: I77bf355a049224784a160defa6bee66d0f9ceb75
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40534
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
The chipset code was incorrectly adding memory resources
to the domain device after resource allocation occurred.
It's not possible to get the correct view of the address space,
and it's generally incorrect to not add resources during
read_resources(). This change fixes the order by adding resources in
read_resources().
Signed-off-by: Furquan Shaikh <furquan@google.com>
Change-Id: I49ce6ac88c4cb7cd05ff9d78133593ce97304596
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41374
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The chipset code was incorrectly adding memory resources
to the domain device after resource allocation occurred.
It's not possible to get the correct view of the address space,
and it's generally incorrect to not add resources during
read_resources(). This change fixes the order by adding resources in
read_resources().
Signed-off-by: Furquan Shaikh <furquan@google.com>
Change-Id: I419be7edf289636b24b9a7d6c390866ade638de3
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41373
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The chipset code was incorrectly adding memory resources
to the domain device after resource allocation occurred.
It's not possible to get the correct view of the address space,
and it's generally incorrect to not add resources during
read_resources(). This change fixes the order by adding resources in
read_resources().
Signed-off-by: Furquan Shaikh <furquan@google.com>
Change-Id: I16f0439679471366723a0084918a20cd95834831
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41372
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The chipset code was incorrectly adding memory resources
to the domain device after resource allocation occurred.
It's not possible to get the correct view of the address space,
and it's generally incorrect to not add resources during
read_resources(). This change fixes the order by adding resources
during read_resources().
Signed-off-by: Furquan Shaikh <furquan@google.com>
Change-Id: I532f508936d5ec154cbcb3538949316ae4851105
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41369
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The chipset code was incorrectly adding memory resources
to the domain device after resource allocation occurred.
It's not possible to get the correct view of the address space,
and it's generally incorrect to not add resources during
read_resources(). This change fixes the order by adding resources in
read_resources().
Signed-off-by: Furquan Shaikh <furquan@google.com>
Change-Id: I84c1ba8645b548248a8bb8bf5bc4953d3be12475
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41368
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Keith Hui <buurin@gmail.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The chipset code was incorrectly adding memory resources
to the domain device after resource allocation occurred.
It's not possible to get the correct view of the address space,
and it's generally incorrect to not add resources during
read_resources(). Fix the order by hanging the resources off
of the host bridge device.
Change-Id: I8a7081020be43da055b7de5a56dd97a7b5a9f09c
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41364
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
GPIO B11 pin should be configured as PMCALERT function. This is
required for the intergrated USB-C feature to work in the SOC
BUG=b:154778458, b:156288164
TEST= build and boot coreboot image on deltan. Test Type-C port
enumeration on Chrome OS
Signed-off-by: Anil Kumar <anil.kumar.k@intel.com>
Change-Id: I8f995901b0a50d2c74f57aba96f86134c9d569e2
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41378
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Bora Guvendik <bora.guvendik@intel.com>
Reviewed-by: EricR Lai <ericr_lai@compal.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This change uses cpu_phys_address_size() to calculate the size of high
MMIO region instead of a macro for each SoC. This ensures that the
entire range above TOUUD that can be addressed by the CPU is used for
MMIO above 4G boundary.
Change-Id: I01a1a86c0c65856f9f35185c2f233c58f18f5dfe
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41347
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
There should be no harm in advertising the MMIO window above 4G in
ACPI tables unconditionally. OS can decide whether or not to use the
window. This change removes the config option enable_above_4GB_mmio
and instead adds the correct MMIO window (above 4G) details to ACPI
tables always.
Change-Id: Ie728f6ee7f396918e61b29ade862b57dac36cb08
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41276
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This change sets the base for MMIO above 4G to TOUDD. It matches what
is used by resource allocator if MMIO resources are allocated above 4G
and also matches the expectation in northbridge.asl. This change
also gets rid of the macro ABOVE_4GB_MEM_BASE_ADDRESS since it is now
unused.
BUG=b:149186922
TEST=Verified that kernel does not complain about MMIO windows above
4G.
Signed-off-by: Furquan Shaikh <furquan@google.com>
Change-Id: Ibbbfbdad867735a43cf57c256bf206a3f040f383
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41155
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Paul Ma