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>
Let the linker do its job.
This fixes building with !CONFIG_PCIEXP_HOTPLUG on some platforms.
Change-Id: I46560722dcb5f1d902709e40b714ef092515b164
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51417
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Load VBIOS in pci set_resources to PCI_VGA_RAM_IMAGE_START (0xc0000)
since pci_dev_init() will not load it in GOP case (VGA_ROM_RUN is not
set). Add Cezanne GFX PID.
BUG=b:171234996
BRANCH=Zork
Change-Id: I4a6fea9b6cd60c862e15ed2ed539869c0f9bd363
Signed-off-by: Nikolai Vyssotski <nikolai.vyssotski@amd.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49867
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
This makes it clear what this function pointer is used for.
Change-Id: I2090e164edee513e05a9409d6c7d18c2cdeb8662
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51009
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Move SPD manufacturer ID decoding to device/dram. Will be used by the
following patch outside of SMBIOS scope as well.
Change-Id: Iec175cd6ab1d20761da955785e4bc0e87ae02dbb
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50544
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
It’s good practice to put the unit into the name.
Change-Id: I1493f61d4e495c22f09abf1829bb2eab9b1fd2b6
Signed-off-by: Paul Menzel <pmenzel@molgen.mpg.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50517
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
On some mainboards, codec configuration depends on settings that are
only known at runtime, which is impossible to specify using one verb
table. Add an optional `mainboard_azalia_program_runtime_verbs` hook
where mainboards can program runtime-dependent codec verbs.
Change-Id: I7efeba5c26051aeb5061cce191ace08c304a6c70
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50388
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
On some boards, Azalia configuration depends on config settings that are
not known at compile-time. Expose a function to program a verb table, to
be used in subsequent commits.
Change-Id: Ie9607f6e733df66f0ca26a4bb70e0864ce1d4512
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50387
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
The type of `verb_size` is unsigned, thus use `%u` to print its value.
Change-Id: I2b353b940e881dc8b5f0b902509d97d89c997a70
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50386
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
It was commented that the need for the delay was mainly related
to external displays and only with VBIOS execution. Move the
delay such that it is done only when we actually need to execute
the VBIOS aka option rom.
A delay is currently only defined for librem/purism_bdw in
its Kconfig. As the description of the issue sounds like it
would equally happen on other platforms when VBIOS is involved,
promote the Kconfig visible option to global scope.
Change-Id: I4503158576f35057373f003586bbf76af4d59b3d
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48787
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
First and last printk() log the same string.
Add done at end of function.
BUG = N/A
TEST = Build and boot faceboot FBG1701
Change-Id: I66a64c7473a65206c3a4c4396c8c8ecba1eb1a57
Signed-off-by: Frans Hendriks <fhendriks@eltan.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50189
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Revise the following aspects to follow coreboot's coding style:
- Drop braces for single-statement condition and loop bodies.
- Use `__func__` to print the current function's name.
- Reflow pointer dereferences to fit in a single line.
- Adjust the `*` position in pointer variable declarations.
- Drop unnecessary `else` statements.
BUG = N/A
TEST = Build Compulab Intense-PC with secure oprom enabled
Change-Id: I780251d946d5bea97658476d61d25555ec768dfc
Signed-off-by: Frans Hendriks <fhendriks@eltan.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49963
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
All uses of `mmconf_resource_init` have been replaced in previous
patches with `mmconf_resource`, which uses Kconfig symbol values.
Change-Id: I4473268016ed511aa5c4930a71977e722e34162a
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50112
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
This is necessary because ASL Memory32Fixed values cannot contain
operations, even if they can be evaluated to constants. Add a sanity
check in pci_mmio_cfg.h to ensure consistency with MMCONF_BUS_NUMBER.
Change-Id: I8f0b5edf166580cc12c1363d8d6b6ef0f2854be9
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50033
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Only specify the type of MMCONF_BASE_ADDRESS and MMCONF_BUS_NUMBER once.
Change-Id: Iacd2ed0dae5f1fb6b309124da53b3fa0eef32693
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50032
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Systems can boot to the OS without a display. Don't kill the boot
process based on a vBIOS error, instead just display a warning.
If the issue is actually fatal for some reason, it's going to die
at some point anyway.
BUG=b:175843172
TEST=Boot morphius to OS without a display
BRANCH=Zork
Signed-off-by: Martin Roth <martinroth@chromium.org>
Change-Id: I7d261321cdbe423dd754f6a354e5f50b53563fcb
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49764
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
