Only scan one device if it's a PCIe downstream port.
A PCIe downstream port normally leads to a link with only device 0 on
it. As an optimization, scan only for device 0 in that case.
Signed-off-by: Jianjun Wang <jianjun.wang@mediatek.com>
Change-Id: Id184d03b33e1742b18efb3f11aa9b2f81fa03806
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56788
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
This method will allow preloading the VGA_BIOS_FILE. By preloading the
file, into cbfs_cache we reduce boot time. In the future we can also add
support for loading the second VGA_BIOS_FILE and the DGPU VGA_BIOS_FILE.
BUG=b:179699789
TEST=Boot guybrush to OS and verify 12 ms reduction in boot time
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: Icb54fe3a942e9507ff6f1173ba5620a8f4ce6549
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56581
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Rob Barnes <robbarnes@google.com>
The `dev` parameter of the `azalia_codecs_init()` function is not used.
Remove it, and update all call sites accordingly.
Change-Id: Idbe4a6ee5e81d5a7fd451fb83e0fe91bd0c09f0e
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/59119
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Make the `codec_init()` function non-static so that it can be used in
other places. Rename it to `azalia_codec_init()` for consistency with
the other functions of the API.
Also, update the function's signature to make it more flexible. Remove
the unused `dev` parameter and allow callers to pass the verb table to
use. Update the original call site to preserve behavior.
Change-Id: I5343796242065b5fedc78cd95bcf010c9e2623dd
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/59117
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Handle the return value of `azalia_program_verb_table()` and print
different messages accordingly.
Change-Id: I99e9e1416217c5e67c529944736affb31f9c7d2f
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/59115
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Make the `codecs_init()` function non-static so that it can be used in
other places. Rename it to `azalia_codecs_init()` to avoid name clashes
with static definitions in southbridge code (which will be removed in
subsequent commits).
Change-Id: I080a73102b0c4f9f8a283cd93bba9b3b23169be0
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/59108
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
List of changes:
1. Create Module Type macros as per Memory Type
(i.e. DDR2/DDR3/DDR4/DDR5/LPDDR4/LPDDR5) and fix compilation
issue due to renaming of existing macros due to scoping the Memory
Type.
2. Use dedicated Memory Type and Module type for `Form Factor`
and `TypeDetail` conversion using `get_spd_info()` function.
3. Create a new API (convert_form_factor_to_module_type()) for
`Form Factor` to 'Module type' conversion as per `Memory Type`.
4. Add new argument as `Memory Type` to
smbios_form_factor_to_spd_mod_type() so that it can internally
call convert_form_factor_to_module_type() for `Module Type`
conversion.
5. Update `test_smbios_form_factor_to_spd_mod_type()` to
accommodate different memory types.
6. Skip fixed module type to form factor conversion using DDR2 SPD4
specification (inside dimm_info_fill()).
Refer to datasheet SPD4.1.2.M-1 for LPDDRx and SPD4.1.2.L-3 for DDRx.
BUG=b:194659789
TEST=Refer to dmidecode -t 17 output as below:
Without this code change:
Handle 0x0012, DMI type 17, 40 bytes
Memory Device
Array Handle: 0x000A
Error Information Handle: Not Provided
Total Width: 16 bits
Data Width: 16 bits
Size: 2048 MB
Form Factor: Unknown
....
With this code change:
Handle 0x0012, DMI type 17, 40 bytes
Memory Device
Array Handle: 0x000A
Error Information Handle: Not Provided
Total Width: 16 bits
Data Width: 16 bits
Size: 2048 MB
Form Factor: Row Of Chips
....
Change-Id: Ia337ac8f50b61ae78d86a07c7a86aa9c248bad50
Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56628
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jakub Czapiga <jacz@semihalf.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>
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: I329efcb42a444b097794fde4f40acf5ececaea8c
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58910
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Lance Zhao
These issues were found and fixed by codespell, a useful tool for
finding spelling errors.
Signed-off-by: Martin Roth <martin@coreboot.org>
Change-Id: I5b8ecdfe75d99028fee820a2034466a8ad1c5e63
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58080
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
With use of device pointers, `dev_find_matching_device_on_bus()` is
now unused and hence this change drops the function.
Change-Id: I30fcb2d9932d770ca614cceffb15646ce8256465
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57846
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
The input buffer to the buffer_to_fifo family of functions is only read,
so it can be a const pointer. (Also, remove the MIPS check in libpayload
for these functions... the MIPS architecture has been removed a while
ago.)
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I021069680cf691590fdacc3d51f747f12ae3df31
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57731
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Add additonal LPDDR4 speed grades. This is needed because the limited
set has casued confusion when the reported speed did not match
expectations. There does not seem to be a definitive list of LPDDR4
speed grades, so this list is derieved from JEDEC 209-4C and a survey
of commonly used LPDDR4 speed grades.
BUG=b:194184950
TEST=Boot, dmidecode -t 17 reports correct speed
BRANCH=None
Change-Id: Ie7706fd4ad5a7df68c07b8ca43261429ba140c61
Signed-off-by: Rob Barnes <robbarnes@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57294
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Nikolai Vyssotski <nikolai.vyssotski@amd.corp-partner.google.com>
Sounds like we prefer to have this under drivers/ instead of device/.
Also move all MIPI-related headers out from device/ into their own
directory.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: Ib3e66954b8f0cf85b28d8d186b09d7846707559d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57128
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
This patch changes the sc7180 boards to use the new common MIPI panel
framework, which allows more flexible initialization command packing and
sharing panel definitions between boards. (I'm taking the lane count
control back out again for now, since it seems we only ever want 4 for
now anyway, and if we ever have a need for a different lane count it's
not clear whether that should be a property of the board or the panel or
both. Better to leave that decision until we have a real use case.)
Also, the code was not written to deal with DCS commands that were not a
length divisible by 4 (it would read over the end of the command
buffer). The corresponding kernel driver seems to pad the command with
0xff instead, let's do the same here. (Also increase the maximum allowed
command length to 256 bytes, as per Qualcomm's recommendation.)
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I78f6efbaa9da88a3574d5c6a51061e308412340e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56966
Reviewed-by: Shelley Chen <shchen@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
All boards that are trying to use MIPI panels eventually run into the
problem that they need to store physical parameters and a list of DCS
initialization commands for each panel, and these commands can be very
different (e.g. a large amount of very short commands, a few very large
commands, etc.). Finding a data format to fit all these different cases
efficiently into the same structures keeps being a challenge, and the
Kukui mainboard already once put a lot of effort into designing a
clean, flexible and efficient solution for this. This patch moves that
framework into a common src/device/mipi/ library where it can be used by
other boards as well. (Also, this will hopefully allow us to save some
duplicated work when using the same panel on different boards at some
point.)
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I877f2b0c7ab984412b288e2ed27f37cd93c70863
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56965
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
No reason to use the preprocessor for this.
BUG=none
TEST=build guybrush
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I920dfa2d27c2eb27e8bc50c615ccd13601610fd7
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56400
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
These methods are oprom specific. Move them out of CBFS. I also deleted
the tohex methods and replaced them with snprintf.
BUG=b:179699789
TEST=Boot guybrush and see oprom still loads
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I03791f19c93fabfe62d9ecd4f9b4fad0e6a6146e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56393
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
The ESPI & LPC keywords were added for the zork program, but it was
found that they weren't needed, so they were never used. The previous
patch removes them from sconfig, so now they aren't needed in coreboot.
BUG=None
TEST=Build
Signed-off-by: Martin Roth <martin@coreboot.org>
Change-Id: I9ae7817bb63d69ee272103b2d1186f125e188950
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56278
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The `irq` variable has the same value as `pIntAtoD[line - 1]`.
Change-Id: Iabf760adbc3014b32cfe6f908dc04c38b71bd980
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55892
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
devfn_disable() function is used to disable a device based on
given bus, device function number. This function checks if the
device is at enable state and disables the device.
Change-Id: Ia4a8bfec7fc95c729a5bb156f88e9aab3bf5dd41
Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55354
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
The `pnp_unset_and_set_config` function was only available when building
with `ENV_PNP_SIMPLE_DEVICE` set. Add the complementary definition using
device pointers, for the sake of completeness.
Change-Id: I2a21e635f41f3f786057500fa96a2b3116e30d76
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55255
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Máté Kukri <kukri.mate@gmail.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
Add lpddr4.c utility file with lpddr4_speed_mhz_to_reported_mts.
Fill in lpddr4_speeds using JDEC 209-4C table 210.
LPDDR4 SPD decoding utilities are not included since there isn't
a present need.
BUG=b:184124605
TEST=Build and run on guybrush
Change-Id: Id8ddfc98fff4255670c50e1ddd4d0a1326265772
Signed-off-by: Rob Barnes <robbarnes@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52745
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
is_devfn_enabled() function helps to check if a device
is enabled based on given device function number. This
function internally called is_dev_enabled() to check
device state.
Change-Id: I6aeba0da05b13b70155a991f69a6abf7eb48a78c
Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55278
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
With the introduction of fw_config support in coreboot, it is possible
for mainboards to control the state of a device (on/off) in ramstage
using fw_config probe conditions. However, the device tree in
immutable in all other stages and hence `is_dev_enabled()` does not
really reflect the true state as in ramstage.
This change adds a call to `fw_config_probe_dev()` in
`is_dev_enabled()` when device tree is immutable (by checking
DEVTREE_EARLY) to first check if device is disabled because of device
probe conditions. If so, then it reports device as being
disabled. Else, dev->enabled is used to report the device state.
This allows early stages (bootblock, romstage) to use
`is_dev_enabled()` to get the true state of the device by taking probe
conditions into account and eliminates the need for each caller to
perform their own separate probing.
Change-Id: Ifede6775bda245cba199d3419aebd782dc690f2c
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54752
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Reviewed-by: EricR Lai <ericr_lai@compal.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
For consistency with other log messages, print bus numbers in decimal.
Change-Id: Ib08ae40fc67c5f8fafd760e8dbb729d6de34c2bb
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54015
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
These global variables are not used anywhere. Drop them.
Change-Id: I3fe60b970153d913ae7b005257e2b53647d6f343
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/53977
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
With the recent switch to SMM module loader v2, the size of the SMM for
module google/volteer increased to above 64K in size, and thus failed to
install the permanent SMM handler. Turns out, the devicetree is all
pulled into the SMM build because of elog, which calls
`pci_dev_is_wake_source`, and is the only user of `struct device` in
SMM. Changing this function to take a pci_devfn_t instead allows the
linker to remove almost the entire devicetree from SMM (only usage left
is when disabling HECI via SMM).
BUG=b:186661594
TEST=Verify loaded program size of `smm.elf` for google/volteer is
almost ~50% smaller.
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Change-Id: I4c39e5188321c8711d6479b15065e5aaedad8f38
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52765
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
On Intel 6-series PCHs, the GCAP register is R/WO (Read / Write Once),
and needs to be written to after the HD Audio controller is taken out
of reset. Add a Kconfig option to read and write back GCAP in order to
lock it down. Follow-up commits will select this option when switching
platforms to use common Azalia code, to preserve original behaviour.
Change-Id: I70bab20816fb6c0bf7bff35c3d2f5828cd96172d
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50794
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
The default of 32 buses per hotplug bridge is rather high. Especially
for platforms that limit MMConf space to 64 buses: they run out of
numbers if there is more than a single hotplug bridge.
Lower the default to
* 8 if MMConf is limited to 64 or less buses,
* 16 if MMConf is limited to 128 or less buses.
Change-Id: I06d522dd92ceea9f4798273b26f947a5333800c3
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52069
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Drop unnecessary typedefs and rename DDR4-specific definitions to avoid
name clashes, as done for DDR3 in earlier commits. This allows including
and using both DDR3 and DDR4 headers in the same compilation unit.
Change-Id: I17f1cd88f83251ec23e9783a617f4d2ed41b07f0
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51898
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
To avoid name clashes with definitions for other DRAM generations,
rename the enum type and values to contain `ddr3` or `DDR3`.
Change-Id: If3710149ba94b94ed14f03e32f5e1533b4bc25c8
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51896
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
These typedefs are not necessary. Remove them, and rename some elements
to avoid any confusion with other DRAM generations, such as DDR4.
Change-Id: Ibe40f33372358262c540e371f7866b06a4ac842a
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51895
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The HD Audio spec states that the STATESTS register is 16 bits wide.
Change-Id: If7859ed33e58d907a91c4ac8675892e37998cf41
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50790
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
The timeout is never reached when the codec is functioning properly.
Using a small timeout value can result in spurious errors with some
codecs, e.g. a codec that is slow to respond but operates correctly.
When a codec is non-operative, the timeout is only reached once per
verb table, thus the impact on booting time is relatively small. So,
use a reasonably long enough timeout to cover all possible cases.
Remove the unconditional 25 µs delay and increase the timeout delay.
The new value of 1 ms is the maximum of all existing implementations.
Currently, the only boards using this code are AMD reference boards:
- AMD Bilby
- AMD Mandolin
- AMD Padmelon
Change-Id: Ia5e4829d404dcecdb9e7a377e896a319cb38531a
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51634
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Use timer.h helpers instead of open-coding timeout handling in polling
loops. The 25-microsecond delay in `wait_for_valid` looks odd, and may
be removed in subsequent commits. For now, preserve existing behavior.
Change-Id: Id1227c6812618597c37408a7bf53bcbcae97374a
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50789
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
I was bugged by spurious "Failed to enable LTR" messages for years.
Looking at the the current algorithm, it is flawed in multiple ways:
* It looks like the author didn't know they implemented a
recursive algorithm (pciexp_enable_ltr()) inside another
recursive algorithm (pciexp_scan_bridge()). Thus, at every
tree level, everything is run again for the whole sub-
tree.
* LTR is enabled no matter if `.set_ltr_max_latencies` is
implemented or not. Leaving the endpoints' LTR settings
at 0: They are told to always report zero tolerance.
In theory, depending on the root-complex implementation,
this may result in higher power consumption than without
LTR messages.
* `.set_ltr_max_latencies` is only considered for the direct
parent of a device. Thus, even with it implemented, an
endpoint below a (non-root) bridge may suffer from the 0
settings as described above.
* Due to the double-recursive nature, LTR is enabled starting
with the endpoints, then moving up the tree, while the PCIe
spec tells us to do it in the exact opposite order.
With the current implementation of pciexp_scan_bridge(), it is
hard to hook anything in that runs for each device from top to
bottom. So the proposed solution still adds some redundancy:
First, for every device that uses pciexp_scan_bus(), we enable
LTR if possible (see below). Then, when returning from the bus-
scanning recursion, we enable LTR for every device and configure
the maximum latencies (if supported). The latter runs again on
all bridges, because it's hard to know if pciexp_scan_bus() was
used for them.
When to enable LTR:
* For all devices that implement `.set_ltr_max_latencies`.
* For all devices below a bridge that has it enabled already.
Change-Id: I2c5b8658f1fc8cec15e8b0824464c6fc9bee7e0e
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51328
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
