This change updates the resource limit for PCI domain to allow
resource allocation above 4G boundary. The resource limit is set to
the highest physical address for the CPU.
BUG=b:149186922
Signed-off-by: Furquan Shaikh <furquan@google.com>
Change-Id: Idfcc9a390d309886ee2b7880b29502c740e6578e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/39488
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This change adds support for allocating resources above the 4G
boundary by making use of memranges for resource windows enabled in
the previous CL.
It adds a new resource flag IORESOURCE_ABOVE_4G which is used in the
following ways:
a) Downstream device resources can set this flag to indicate that they
would like to have their resource allocation above the 4G
boundary. These semantics will have to be enabled in the drivers
managing the devices. It can also be extended to be enabled via
devicetree. This flag is automatically propagated by the resource
allocator from downstream devices to the upstream bridges in pass
1. It is done to ensure that the resource allocator has a global view
of downstream requirements during pass 2 at domain level.
b) Bridges have a single resource window for each of mem and prefmem
resource types. Thus, if any downstream resource of the bridge
requests allocation above 4G boundary, all the other downstream
resources of the same type under the bridge will be allocated above 4G
boundary.
c) During pass 2, resource allocator at domain level splits
IORESOURCE_MEM into two different memory ranges -- one for the window
below 4G and other above 4G. Resource allocation happens separately
for each of these windows.
d) At the bridge level, there is no extra logic required since the
resource will live entirely above or below the 4G boundary. Hence, all
downstream devices of any bridge will fall within the window allocated
to the bridge resource. To handle this case separately from that of
domain, initializing of memranges for a bridge is done differently
than the domain.
Limitation:
Resources of a given type at the bridge or downstream devices
cannot live both above and below 4G boundary. Thus, if a bridge has
some downstream resources requesting allocation for a given type above
4G boundary and other resources of the same type requesting allocation
below 4G boundary, then all these resources of the same type get
allocated above 4G boundary.
BUG=b:149186922
TEST=Verified that resources get allocated above the 4G boundary
correctly on volteer.
Signed-off-by: Furquan Shaikh <furquan@google.com>
Change-Id: I7fb2a75cc280a307300d29ddabaebfc49175548f
Reviewed-on: https://review.coreboot.org/c/coreboot/+/39487
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This change updates the resource allocator in coreboot to allow using
multiple ranges for resource allocation rather than restricting
available window to a single base/limit pair. This is done in
preparation to allow 64-bit resource allocation.
Following changes are made as part of this:
a) Resource allocator still makes 2 passes at the entire tree. The
first pass is to gather the resource requirements of each device
under each domain. It walks recursively in DFS fashion to gather the
requirements of the leaf devices and propagates this back up to the
downstream bridges of the domain. Domain is special in the sense that
it has fixed resource ranges. Hence, the resource requirements from
the downstream devices have no effect on the domain resource
windows. This results in domain resource limits being unmodified after
the first pass.
b) Once the requirements for all the devices under the domain are
gathered, resource allocator walks a second time to allocate resources
to downstream devices as per the requirements. Here, instead of
maintaining a single window for allocating resources, it creates a
list of memranges starting with the resource window at domain and then
applying constraints to create holes for any fixed resources. This
ensures that there is no overlap with fixed resources under the
domain.
c) Domain does not differentiate between mem and prefmem. Since they
are allocated space from the same resource window at the domain level,
it considers all resource requests from downstream devices of the
domain independent of the prefetch type.
d) Once resource allocation is done at the domain level, resource
allocator walks down the downstream bridges and continues the same
process until it reaches the leaves. Bridges have separate windows for
mem and prefmem. Hence, unlike domain, the resource allocator at
bridge level ensures that downstream requirements are satisfied by
taking prefetch type into consideration.
e) This whole 2-pass process is performed for every domain in the
system under the assumption that domains do not have overlapping
address spaces.
Noticeable differences from previous resource allocator:
a) Changes in print logs observed due to flows being slightly
different.
b) Base, limit and size of domain resources are no longer updated
based on downstream requirements.
c) Memranges are used instead of a single base/limit pair for
determining resource allocation.
d) Previously, if a resource request did not fit in the available
base/limit window, then the resource would be allocated over DRAM or
any other address space defeating the principle of "no overlap". With
this change, any time a resource cannot fit in the available ranges,
it complains and ensures that the resource is effectively disabled by
setting base same as the limit.
e) Resource allocator no longer looks at multiple links to determine
the right bus for a resource. None of the current boards have multiple
buses under any downstream device of the domain. The only device with
multiple links seems to be the cpu cluster device for some AMD
platforms.
BUG=b:149186922
TEST=Verified that resource allocation looks correct based on
addresses assigned on Volteer.
Signed-off-by: Furquan Shaikh <furquan@google.com>
Change-Id: Ia1f089877c62e119c6a994a10809c9cc0050ec9a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/39486
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Currently inteltool uses the addresses and names of the PCH of
previous generations. It's wrong for Lynx Point LP and Wildcat Point.
The addresses and names of the I/O registers can be found in "Mobile
4th Generation Intel Core Processor Family I/O Datasheet" (Document
Number: 329003-003) for Lynx Point LP and "Mobile 5th Generation Intel
Core Processor Family I/O, Intel Core M Processor Family I/O, Mobile
Intel Pentium Processor Family I/O, and Mobile Intel Celeron Processor
Family I/O Datasheet" (Document Number: 330837-004) for Wildcat Point.
Change-Id: If6ba718ccff077aa89affec89018bd7923527466
Signed-off-by: Iru Cai <mytbk920423@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40273
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
We should not need that.
Change-Id: Ic0181a300670ed7ee999dafedac79f3f89bfbee9
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41114
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Michael Niewöhner
This reverts commit cc805d9dd6.
Advertising certain Windows versions triggers different paths in
the OS. As there may also be device specific quirks in the OS, such
changes need to be tested thoroughly on all affected devices.
There was at least one very subtle regression introduced by this.
When Linux sees "Windows 2012" support advertised, it disables the
`acpi_video` backlight controls, at least on devices with Intel IGD.
Without user-space handling the ACPI events, keyboard backlight
controls stop working.
Moreover, the commit message didn't state any reason for this change.
Why was it merged?
Change-Id: I722075f8e8f836b039fb8b8277e665fb49dac8f4
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41192
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
This reverts commit b3100775ae.
This was part of a series that moved things to common code and causes
regressions.
Change-Id: I239906e498c8352e6880408744f176a8aeb13dc8
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41191
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
All boards using this northbridge now enable serial in bootblock,
so this is no longer needed.
Change-Id: I6baf2de81870dbba2a7f1abb3f1fdd6716d64511
Signed-off-by: Keith Hui <buurin@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41048
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This change splits lpc_set_spibase() into two separate functions:
lpc_set_spibase() - Sets MMIO base address for SPI controller and eSPI
controller (if supported by platforms)
lpc_enable_spi_rom() - Enables SPI ROM
This split is done to allow setting of MMIO base independent of ROM
enable bits. On platforms like Picasso, eSPI base is determined by the
same register and hence eSPI can set the BAR without having to touch
the enable bits.
Signed-off-by: Furquan Shaikh <furquan@google.com>
Change-Id: I3f270ba1745b4bb8a403f00cd069a02e21d444be
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41247
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
This change adds support for struct soc_amd_common_config that allows
multiple AMD SoCs to share common configuration. This can then be used
by common/block drivers to get the required configuration from device
tree. It also provides function declaration for
soc_get_common_config() that needs to be provided by SoCs making use
of the common configuration structure.
Signed-off-by: Furquan Shaikh <furquan@google.com>
Change-Id: Idb0d797525414c99894a8e4ede65469381db7794
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41246
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Fill in some blanks for 4.12, mark it done, add template for 4.13.
Also update the list of vboot supported boards.
Change-Id: Id6b663f13367eb40e66af30aadd33991c8dd635c
Signed-off-by: Patrick Georgi <patrick@georgi.software>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41259
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
We only write to the IOSAV LFSR registers twice, but we do so between
the writes to the other four IOSAV per-subsequence registers. Since we
know that the IOSAV is sleeping when we program the subsequences, we
might as well do the two oddball LFSR register writes after we have
programmed the always-written-to group of four registers. That way,
subsequent changes can reproducibly replace the four writes with a
single macro.
Tested on Asus P8Z77-V LX2, still boots.
Change-Id: If7bb14a9862a53a3eba565d17401347dcc9ffbe9
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40973
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reorder the order of the operands in three register writes, so that
replacing them with macros in a follow-up does not change the binary.
Tested on Asus P8Z77-V LX2, still boots.
Change-Id: I44aee9c0f49770586de322ee7f44c3609dbadd0b
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40972
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch implements the pin changes needed for Trogdor rev1.
Unfortunately, coreboot has to get the EC and TPM SPI busses compiled
into Kconfig, so we cannot really build a single image that runs on both
revisions. Introduce a Kconfig to handle this instead.
Change-Id: I2e48dc4565682c12089b6cf92c29f4cef4d61bb8
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/38773
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add support to configure the Silver and L3 PLLs and switch the APSS
GFMUX to use the PLL to speed up the boot cores.
Tested: CPU speed frequency validated for speed bump
Change-Id: Iafd3b618fb72e0e8cc8dd297e4a3e16b83550883
Signed-off-by: Taniya Das <tdas@codeaurora.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/39234
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Update memory regions, etc.
Change-Id: If852fe4465fb431809570be6cdccff3ad9d9f4f0
Signed-off-by: T Michael Turney <mturney@codeaurora.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/39362
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Change-Id: I8ff5dd63fac28ffa558aec71e79a6de87d7885e0
Signed-off-by: T Michael Turney <mturney@codeaurora.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/37306
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Transfer sequence used by SPI-Flash application present in CB/DC.
1. Assert CS through GPIO
2. Data transfer through QSPI (involves construction of command
descriptor for multiple read/write transfers)
3. De-assert CS through GPIO.
With above sequence, in DMA mode we dont have the support for read
transfers that are not preceded by write transfer in QSPI controller.
Ex: "write read read read" sequence results in hang during DMA transfer,
where as "write read write read" sequence has no issue.
As we have application controlling CS through GPIO, we are making
fragment bit "set" for all transfers, which keeps CS in asserted
state although the ideal way to operate CS is through QSPI controller.
Change-Id: Ia45ab793ad05861b88e99a320b1ee9f10707def7
Signed-off-by: satya priya <skakit@codeaurora.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/39807
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This change moves all the logic for setting up decode windows for LPC
under configure_child_lpc_windows() which is called from
lpc_enable_children_resources(). This is in preparation to configure
decode windows for eSPI differently if mainboard decides to use eSPI
instead of LPC.
Side-effect of this change is that the IO decode registers are written
after each child device resources are considered.
BUG=b:154445472
Change-Id: Ib8275bc4ce51cd8afd390901ac723ce71c7a9148
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41070
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
eSPI on Picasso is configured using the LPC bridge configuration
registers. This change enables config options to allow SoC to select
if it supports eSPI (SOC_AMD_COMMON_BLOCK_HAS_ESPI) and mainboard to
select if it wants to use eSPI instead of LPC for talking to legacy
devices and embedded controllers (SOC_AMD_COMMON_BLOCK_USE_ESPI).
BUG=b:154445472
Change-Id: I15e9eb25706e09393c019eea4d61b66f17490be6
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41069
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
One author put their name on a separate line from the rest of the
Copyright statement, so copy it in.
Change-Id: I041bc60079a238f59bb23556a80398052744fd5c
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41231
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The Historical Permission Notice and Disclaimer (with and without
permission to sell) is a BSD-style license family that OSI and SPDX
consider deprecated - and yet, it's right here in our tree.
Change-Id: I61624b6e54e9aba6e2f54822c1f68967c416ad3d
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41221
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add an SSDT generator for Maxim 98390 kernel driver.
Copied from 'drivers/i2c/rt1011'.
BUG=b:149443429
BRANCH=None
TEST=built coreboot and checked audio function with kernel patch on nightfury
Change-Id: I64d776c6c9726eb5822ad4dd82f6826c2a30cb1d
Signed-off-by: Seunghwan Kim <sh_.kim@samsung.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/39463
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Copyright notices are best stored in AUTHORS
Change-Id: Ib9025c58987ee2f7db600e038f5d3e4edc69aacc
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41203
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
In a few cases a license was added: Stuff coming from Linux is
"GPL-2.0" (not GPL-2.0-only!), build-release is by me and got the
usual GPL-2.0-only treatment. uio_usbdebug and spkmodem had their
licenses propagate to all their files.
Change-Id: Ia5712bbaa417cb9e937834512351fcc0acfa16be
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41202
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Stefan thinks they don't add value.
Command used:
sed -i -e '/file is part of /d' $(git grep "file is part of " |egrep ":( */\*.*\*/\$|#|;#|-- | *\* )" | cut -d: -f1 |grep -v crossgcc |grep -v gcov | grep -v /elf.h |grep -v nvramtool)
The exceptions are for:
- crossgcc (patch file)
- gcov (imported from gcc)
- elf.h (imported from GNU's libc)
- nvramtool (more complicated header)
The removed lines are:
- fmt.Fprintln(f, "/* This file is part of the coreboot project. */")
-# This file is part of a set of unofficial pre-commit hooks available
-/* This file is part of coreboot */
-# This file is part of msrtool.
-/* This file is part of msrtool. */
- * This file is part of ncurses, designed to be appended after curses.h.in
-/* This file is part of pgtblgen. */
- * This file is part of the coreboot project.
- /* This file is part of the coreboot project. */
-# This file is part of the coreboot project.
-# This file is part of the coreboot project.
-## This file is part of the coreboot project.
--- This file is part of the coreboot project.
-/* This file is part of the coreboot project */
-/* This file is part of the coreboot project. */
-;## This file is part of the coreboot project.
-# This file is part of the coreboot project. It originated in the
- * This file is part of the coreinfo project.
-## This file is part of the coreinfo project.
- * This file is part of the depthcharge project.
-/* This file is part of the depthcharge project. */
-/* This file is part of the ectool project. */
- * This file is part of the GNU C Library.
- * This file is part of the libpayload project.
-## This file is part of the libpayload project.
-/* This file is part of the Linux kernel. */
-## This file is part of the superiotool project.
-/* This file is part of the superiotool project */
-/* This file is part of uio_usbdebug */
Change-Id: I82d872b3b337388c93d5f5bf704e9ee9e53ab3a9
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41194
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
As requested by Stefan.
For nvramtool some of these lines are part of a paragraph of fluff,
so manual processing was easier than adapting the script used for
the rest of the tree.
Change-Id: Id52c4c264cded0582a97da131b695a046cbd67c6
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41195
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
Reviewed-by: Martin Roth <martinroth@google.com>
This is all code coming from the outside, so let's keep these files
untouched as much as possible.
A couple of files is added to the list by name because their license,
while free, can't be properly modelled in SPDX:
- lzmadecode is (LGPL OR CPL) WITH special-exception
- stack.c and start16 are some weird (but free) US Gov't license grant
- two XGI related files have "BSD except for Linux, where it's GPL"
Change-Id: I42dec503b9c427a66792d3fec99ca8df1a360e47
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41193
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
Signed-off-by: Jan Dabros <jsd@semihalf.com>
Change-Id: Id6365b86640832b91a722cd12f64c03fc8a41fd7
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41025
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Paul Fagerburg <pfagerburg@chromium.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Fold this last ASUS 440BX board into the P2B family, while bringing in
some changes:
- Devicetree becomes overridetree.
- Remove non-existent IR device and disable ACPI device on Super I/O to
match OEM firmware.
- Add SB GPO settings from OEM firmware to devicetree. This disables
the SPD enabling magic this board needs. By moving the enabling part
to bootblock the hacky enable_spd hook can be eliminated.
- Initialize the serial port in bootblock, like the other boards.
Boot tested on hardware.
Change-Id: I65f2cb9d1bd4c82550de43889e3502526a46bd18
Signed-off-by: Keith Hui <buurin@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41047
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Commit 73b723d [google/cyan: Switch Touchpad and Touchscreen...]
in additon to changing the touchpad/touchscreen interrupts from
edge to level triggered, also marked them as maskable.
This was partially reverted in a86bbea0 [google/cyan: set
touchscreen GPIO to non_maskable], but did not resolve all of the
issues. Additionally, 73b723d also accidentally changed the pad
interrupt select from L3 to L1 for all touchscreen GPIOs.
Clean up this mess by setting all touchpad/touchscreen GPIOs
back to maskable, and set the pad level to L3 for all touchscreen
GPIOs.
Tested on several cyan variants
Change-Id: I70e8e2d4ff317c3b9b4108ed6c5bc80e9b0bbc75
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41176
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Add setting of the MaxPayload for each root port from the device tree.
By default MaxPayload is set to 128 bytes. This change allows changing
to 256 bytes.
BUG=N/A
TEST=tested on facebook monolith
Change-Id: I61e1d619588a7084d52bbe101acd757cc7293cac
Signed-off-by: Wim Vervoorn <wvervoorn@eltan.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41170
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Frans Hendriks <fhendriks@eltan.com>
Really old versions of W83977TF Super I/O had an IR logical device, but
is no longer the case. It does not exist in the newer W83977EF version,
installed in some Asus P2B family boards, and served by this same code.
Add a config option on the off chance we may see board with it (as if
we would) and don't include this device unless it is set. Saves us from
the need to declare a not-present device off and/or extraneous PNP
device errors about a not-present device.
Change-Id: I761ebc41f1735a03e768339a68ca139167edc095
Signed-off-by: Keith Hui <buurin@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41004
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
LTE module Fibocom L850-GL is lost after idle overnight, with this workaround, host will not initiate U3 wakeup at the same time with device, which will avoid the race condition.
Disable XHCI LFPS power management. If the option is set in the devicetree, the bits[7:4] in XHCI MMIO BAR + offset 0x80A4 (PMCTRL_REG) will be updated from default 9 to 0.
BUG=b:155955302
BRANCH=octopus
TEST=build coreboot with DisableXhciLfpsPM being set to 1 and flash
the image to the device. Run following command to check if
bits[7:4] are set 0:
>iotools mmio_read32 "XHCI MMIO BAR + 0x80A4"
Signed-off-by: Kenneth Chan <kenneth.chan@quanta.corp-partner.google.com>
Change-Id: I88357f44317a5cff2e04508638eb065e5ada4c4c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41143
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Marco Chen <marcochen@google.com>
Reviewed-by: Ren Kuo <ren.kuo@quanta.corp-partner.google.com>
This is used for 'KHz' (line #19)
Change-Id: I4d610607b50d2fac1150deaaf94f3cb331540fbc
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41151
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Philipp Hug <philipp@hug.cx>
C-State latency table was exposed by both intel-idle driver and
BIOS/coreboot. And table in Kernel was used before.
After kernel patch (https://patchwork.kernel.org/patch/11290319/),
only BIOS/coreboot exposes C-State latency table through _CST.
As current C-State latency table info is not correct for Tigerlake,
update proper info according to BWG and reference code.
- Update latency: CpuPowerMgmt.h
Use BIOS reference code as values in BWG is not up-to-dated
- Remove MSR program for latency: BWG 4.6.4.3.4
Reference:
- TGL BWG #611569 Rev 0.7.6
- https://github.com/otcshare/CCG-TGL-Generic-SiC/blob/master/
ClientOneSiliconPkg/Cpu/Include/CpuPowerMgmt.h
BUG=b:155223704
BRANCH=None
TEST=Boot to OS and check C-State latency
expected result
>cat /sys/devices/system/cpu/cpu0/cpuidle/state*/{name,latency}
POLL
C1_ACPI
C2_ACPI
C3_ACPI
0
1
253
1048
For detail, refer Bug info.
Signed-off-by: Wonkyu Kim <wonkyu.kim@intel.com>
Change-Id: I8bf2976ad35b4cf6f637a99c26b4f98f9f6ee563
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40816
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Srinidhi N Kaushik <srinidhi.n.kaushik@intel.com>
Furquan Shaikh