Once platform code has filled in the (legacy) ACPI PM register
map, added function will fill in the extended entries in FADT.
TEST=samsung/lumpy and amd/mandolin FADT stays unchanged.
Change-Id: I90925fce35458cf5480bfefc7cdddebd41b42058
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74913
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
If ACPI is above 4G it's not possible to have a valid RSDT pointer in
RSDP, therefore swap RSDT and XSDT. Both are always generated on x86.
On other architectures RSDT is often skipped, e.g. aarch64. On top of
that the OS looks at XSDT first. So unconditionally using XSDT and not
RSDT is fine.
This also deal with the ACPI pointer being above 4G. This currently
never happens with x86 platforms.
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Change-Id: I6588676186faa896b6076f871d7f8f633db21e70
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76000
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
TESTED acpixtract -a is able to extract all the dumped tables including
FACS and DSDT.
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Change-Id: I7fad86ead3b43b6819a2da030a72322b7e259376
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76350
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
It's not expected that non-x86 arch implement x86 style sleep states and
resume.
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Change-Id: I7a1f36616e7f6adb021625e62e0fdf81864c7ac3
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76178
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Reviewed-by: Sridhar Siricilla <sridhar.siricilla@intel.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
acpi.c contains architectural specific things like IOAPIC, legacy IRQ,
DMAR, HPET, ... all which require the presence of architectural headers.
Instead of littering the code with #if ENV_X86 move the functions to
different compilation units.
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Change-Id: I5083b26c0d4cc6764b4e3cb0ff586797cae7e3af
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76008
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
With arm64 -Wstack-usage= is enabled which is triggered on any use of
alloca(). Since this function basically works on x86 without wrecking
things and causing massive stack consumption it's unlikely to cause
problems on arm64.
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Change-Id: I5d445d151db5e6cc7b6e13bf74ce81007d819f1d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76007
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Tim Wawrzynczak <inforichland@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
From the Linux documentation (Documentation/PCI/acpi-info.rst):
[6] PCI Firmware 3.2, sec 4.1.2:
If the operating system does not natively comprehend reserving the
MMCFG region, the MMCFG region must be reserved by firmware. The
address range reported in the MCFG table or by _CBA method (see Section
4.1.3) must be reserved by declaring a motherboard resource. For most
systems, the motherboard resource would appear at the root of the ACPI
namespace (under \_SB) in a node with a _HID of EISAID (PNP0C02), and
the resources in this case should not be claimed in the root PCI bus’s
_CRS. The resources can optionally be returned in Int15 E820 or
EFIGetMemoryMap as reserved memory but must always be reported through
ACPI as a motherboard resource.
So in order for the OS to use ECAM MMCONF over legacy PCI IO
configuration, a PNP0C02 HID device needs to reserve this region.
As no AMD platform has this defined in DSDT this fixes Linux using
legacy PCI IO configuration over MMCONF. Tianocore messes with e820
table in such a way that it prevents Linux from using PCIe ECAM. This
change fixes that problem.
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Change-Id: I852e393726a1b086cf582f4d2d707e7cde05cbf4
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75729
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Sean Rhodes <sean@starlabs.systems>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Fix regression introduced with commit 01af0f8ac8 ("acpi/acpi.c: Reduce boilerplate").
DSDT table is not to be listed within RSDT/XSDT, ACPICA and/or OSPM may
try load it twice raising conflicts in the namespace and effectively ignoring all or most of the AML.
Change-Id: I0e6d07b35522f2bf9a51cef0a7e3181b15087d88
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76321
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Reviewed-by: Sean Rhodes <sean@starlabs.systems>
This reduces boilerplate. One functional difference is that SSDT no
longer has oem_revision set to 42.
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Change-Id: Id2e54d61970294e028a61ba86c07c5482784e307
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76143
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Adding tables to R/XSDT, aligning current pointer, computing checksum is
a lot of boilerplate that needs to be done for each table.
TESTED on foxconn/g41.
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Change-Id: If4915b8cdfcfdbb34284ea75fa8a0fd23554152d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76127
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
This was missed recently when adding the table. Linux complains about
the missing checksum, e.g.
[ 0.186070] ACPI BIOS Warning (bug): Incorrect checksum in table [SPCR] - 0x00, should be 0x87 (20210730/tbprint-173)
Tested with QEMU/Q35, albeit with changes to the special handling for
ACPI with QEMU. The warning goes away.
Change-Id: I0086a3e8c5b3a06da9edf40a7a288c534fc5a6b2
Signed-off-by: Nico Huber <nico.h@gmx.de>
Fixes: commit 90464073e4 (acpi: Add SPCR table)
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76158
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
TESTED works on IO and MMIO console with linux using 'earlycon=' in the
commandline argument.
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Change-Id: I64e624c17a27b9215a8ba83bd6cbb2c0a7aa1dfc
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75685
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The sign of 'char' is not standardized and with GCC is architecture
dependent.
This fixes warnings when compiling this file on arm64.
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Change-Id: I53b99835b2ffec5d752fc531fd59e4715f61aced
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76006
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Returning a constant value makes the function easier to read and think
about.
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Change-Id: Ifdf7acec38a7c958aac2cf1f3bbf16c27fa90b8c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75903
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The argument is copied into current and is never modified.
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Change-Id: I3084e43ccbe9749bc726af3120decfe8b52e1709
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75902
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Loop over tables in xsdt instead of maintaining a list of local
variables to loop over. Some tables were not generated directly in the
write_acpi_tables function, like IVRS or SRAT. Now those tables are
printed too and the code is simpler.
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Change-Id: Ie0a6e2b6e2b72b5c8f59e730bea9b51007b507b6
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75860
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Reviewed-by: Marvin Drees <marvin.drees@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Sometimes systems don't boot to the OS due to wrong ACPI tables.
Printing the tables in an ACPICA compatible format makes analysis of
ACPI tables easier.
The ACPICA format (acpidump, acpixtract) is the following:
"
FACS @ 0x0000000000000000
0000: 46 41 43 53 40 00 00 00 E8 24 00 00 00 00 00 00 FACS@....$......
0010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0020: 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
"
To achieve analyze ACPI tables capture the coreboot log between
"Printing ACPI in ACPICA compatible table" and "Done printing ACPI in
ACPICA compatible table". Remove the prefix "[SPEW ] " and then call
'acpixtract -a dump' to extract all the tables. Then use 'iasl -d' on
the .dat files to decompile the tables.
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Change-Id: I7b5d879014563f7a2e1f70c45cf871ba72f142dc
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75677
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
When an IO resource producer is generated that covers the whole IO space
from 0 to 0xffff, the length field in the word resource ACPI type would
overflow and be truncated which results in Linux not finding any usable
IO space to use for the PCI IO BARs. Instead generate a double word IO
resource producer to have all cases supported. Beware that covering all
IO ports with the IO resource producer while covering the PCI config IO
ports with a resource consumer in the same PCI root device will make
Linux a bit unhappy and it will complain due to the overlap, but still
end up doing the right thing:
acpi PNP0A08:00: host bridge window expanded to [io 0x0000-0xffff]; [io 0x0000-0xffff window] ignored
The SoC code should make sure to carve out the PCI config IO ports from
the IO resource producer.
TEST=Both Ubuntu 2022.04.1 LTS and Windows 10 are ok with the IO DWord
resource producer.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I8a59cdfcfa30a8fdd13f8db3dc1447994c266c8b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75613
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The acpigen_resource_[bus_number,io,mmio*] functions didn't make it very
clear that they are generating resource producer ranges and not resource
consumer ranges. To clarify this, change the function names to
acpigen_resource_producer_[bus_number,io,mmio*] and explicitly add the
ADDR_SPACE_GENERAL_FLAG_PRODUCER flag which evaluates to 0, so this
doesn't change the functionality.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I334f38aa8ab418d5577f92b980ff750504e2bb4e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75486
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <inforichland@gmail.com>
Add the acpigen_resource_mmio helper function to generate an MMIO range
resource.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Change-Id: I38d55dfcc2892bcb5d253a3aef6ed993cfdba0a5
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75045
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Make ACPI code print a debug warning message when a timeout is
detected in a loop waiting for a condition.
This timeout message won't be displayed when this function is used as
delay loop (ie. without checking variable condition).
The following is required to get this log in kernel log buffer:
echo 1 > /sys/module/acpi/parameters/aml_debug_output
Here is an example of generated code when waiting for variable L23E to
be 0.
Local7 = 0x08
While ((Local7 > Zero))
{
If ((L23E == Zero))
{
Break
}
Sleep (0x10)
Local7--
If ((Local7 == Zero))
{
Debug = "WARN: Wait loop timeout for variable L23E"
}
}
BRANCH=firmware-brya-14505.B
TEST=Boot to OS and check that the Debug print is added to the
function.
Change-Id: I3843e51988527e99822017d1b5f653ff2eaa7958
Signed-off-by: Cliff Huang <cliff.huang@intel.com>
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73348
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Generate formatted string and ACPI code to print debug string.
For example (with pcie_rp = 1):
acpigen_write_debug_sprintf("calling _ON for RP: %u", pcie_rp);
generates the following ACPI code:
Debug = "calling _ON for RP: 1"
With this new function, the following functions are not needed anymore
and therefore are removed by this patch.
- acpigen_concatenate_string_string()
- acpigen_concatenate_string_int()
- acpigen_write_debug_concatenate_string_string()
- acpigen_write_debug_concatenate_string_int()
BRANCH=firmware-brya-14505.B
TEST=Add above functions in the acpigen code and check the generated
SSDT table after OS boot. Check the debug messages is in the
kernel log when /sys/modules/acpi/parameters/aml_debug_output is
set to '1'.
Change-Id: Id4a42e5854516a22b7bc4559c2ed08680722c5ba
Signed-off-by: Cliff Huang <cliff.huang@intel.com>
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73113
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Bora Guvendik <bora.guvendik@intel.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Zhixing Ma <zhixing.ma@intel.com>
Reviewed-by: Musse Abdullahi <musse.abdullahi@intel.corp-partner.google.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Since it's not obvious, add comments to acpigen_resource_word,
acpigen_resource_dword and acpigen_resource_qword to clarify out what
the magic number in byte 0 means. The most significant bit of byte 0
indicates if it is a small or large resource data type. In the case of
the MSB being 0, it's a small resource data type (aka type 0), and the
other bits encode bit the type and size of the item; if the MSB is 1,
it's a large resource data type (aka type 1), and the other bits just
encode the type and there are two separate bytes to encode the size.
Beware that the large resource's data type values in the ACPI
specification don't include the MSB that's set, but only the 7 lower
bits.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ia6a6c9fb1bcde232122bb5899b9a0983ef48e12b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75158
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <inforichland@gmail.com>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
In ACPI 1.0 the processor objects were inside the \_PR scope, but since
ACPI 2.0 the \_SB scope can be used for that. Outside of coreboot some
firmwares still used the \_PR scope for a while for legacy ACPI 1.0 OS
compatibility, but apart from that the \_PR scope is deprecated.
coreboot already uses the \_SB scope for the processor devices
everywhere, so move the \_SB scope out of the ACPI_CPU_STRING to the
format string inside the 3 snprintf statements that use the
ACPI_CPU_STRING.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Suggested-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Change-Id: I76f18594a3a623b437a163c270547d3e9618c31a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75167
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Tim Wawrzynczak <inforichland@gmail.com>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Add the acpigen_resource_io helper function to generate an I/O range
resource.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Change-Id: I177f59b52d4dbbff0a3ceeef5fc8c7455cef9ff8
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75044
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <inforichland@gmail.com>
Add the acpigen_resource_bus_number helper function to generate a bus
number range resource.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Change-Id: Ib1f1da3dbe823c6bc4fc30c0622653410cfbf301
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75043
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <inforichland@gmail.com>
At present coreboot_rsdp remains unset for QEMU, which results in
an incomplete LB_TAG_ACPI_RSDP coreboot table generated.
Fix this by assigning coreboot_rsdp properly.
TEST=Build coreboot for QEMU x86 i440fx (default) with U-Boot x86
as the payload, boot coreboot.rom with QEMU, and run 'acpi list'
from U-Boot shell to show the ACPI tables.
Signed-off-by: Bin Meng <bmeng@tinylab.org>
Change-Id: I5bc3f0528d4431fd388ca52b8865f9be0e1faf92
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75088
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Tim Wawrzynczak <inforichland@gmail.com>
Introduce acpigen_write_BBN to generate the ACPI method object that
returns the base bus number for a PCI(e) host bridge. When called, the
base_bus_number argument must be the first PCI bus number that got
assigned to the corresponding host bridge.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ib67bf42b9c77c262d8a02d8f28ac5cb8482136b9
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74991
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <inforichland@gmail.com>
cbfs_map() can allocate memory, so cbfs_unmap() should be
called before leaving the function.
BUG=b:278264488
TEST=Built and run with additional debugs on Skyrim device
to confirm that data are correctly unmapped
Change-Id: Ibf7ba6842f42404ad8bb415f8e7fda10403cbe2e
Signed-off-by: Grzegorz Bernacki <bernacki@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74715
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jakub Czapiga <jacz@semihalf.com>
Reviewed-by: Tim Van Patten <timvp@google.com>
This allows mainboards to override available sleep states at runtime.
This is done by adding a IntObj in SSDT that DSDT consumes to override
the available _Sx states.
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Change-Id: Ic21830c1ef9c183b1e3005cc1f8b7daf7e9ea998
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74762
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Jakub Czapiga <jacz@semihalf.com>
Reviewed-by: Jan Samek <jan.samek@siemens.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
For AMD, replace name RTC_ALT_CENTURY with RTC_CLK_ALTCENTURY
that points to same offset. Since the century field inside
RTC falls within the NVRAM space, and could interfere with
OPTION_TABLE, it is now guarded with config USE_PC_CMOS_ALTCENTURY.
There were no reference for the use of offset 0x48 for century.
Change-Id: I965a83dc8daaa02ad0935bdde5ca50110adb014a
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74601
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Add Kconfig COMMON_ACPI_MADT_IOAPIC to replace platforms'
implementations of adding IOAPIC and IRQ override entries
for ACPI MADT tables.
Platforms that have a more complex MADT may continue to
add custom entries using CUSTOM_ACPI_MADT.
Change-Id: I0b77769f89cc319ad228eb37bc341e2150b8a892
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74348
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Platform needs to implement this to provide information about SCI IRQ
pin and polarity, to be used for filling in ACPI FADT and MADT entries.
Change-Id: Icea7e9ca4abf3997c01617d2f78f25036d85a52f
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74337
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
According to ACPI Release 6.5 systems supporting PIC (i8259)
interrupt mechanism need to report IRQ vector for the SCI_INT
field. In PIC mode only IRQ0..15 are allowed hardware vectors.
This change should cover section 5.2.9 to not pass SCI_INT
larger than IRQ15. Section 5.2.15.5 needs follow-up work.
Care should be taken that ioapic_get_sci_pin() is called
after platform code has potentially changed the routing
from the default.
It appears touched all platforms except siemens/mc_aplX
currently program SCI as IRQ9.
Change-Id: I723c207f1dcbba5e6fc0452fe1dbd087fad290ee
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74326
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <inforichland@gmail.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
These functions are only used in one compilation unit.
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Change-Id: I6f8282f308506a68b14ce3101f11078cb13709f2
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74756
Reviewed-by: Jan Samek <jan.samek@siemens.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com>
Reviewed-by: Tim Wawrzynczak <inforichland@gmail.com>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
After the obsoletion of Processor() it is necessary to provide
_PTC package to define P_CNT IO address for clock throttling.
The platforms touched here already emit empty _PTC to disable
clock throttling.
Change-Id: I0e84c8ccd2772c9b3d61f71b74324c8d28f4eefe
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74438
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
After the obsoletion of Processor() it is necessary to provide
_CST package to define P_LVLx IO addresses for C2/C3 transitions.
The latency values from _CST will always replace those in FADT.
Change-Id: I3230be719659fe9cdf9ed6ae73bc91b05093ab97
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74430
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Boards with SOC_INTEL_COMMON_BLOCK_ACPI_CPU_HYBRID have
special handling for the time being.
Change of aopen/dxplplusu is coupled with sb/intel/i82801dx.
Change of emulation/qemu-i440fx is coupled with intel/i82371eb.
For asus/p2b, this adds MADT LAPIC entries, even though platform
has ACPI_NO_MADT selected. Even previously ACPI_NO_MADT creates
the MADT, including an entry for LAPIC address.
Change-Id: I1f8d7ee9891553742d73a92b55a87c04fa95a132
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74316
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Secondary threads need to be added after the primary threads.
Change-Id: I3a98560760b662a7ba7efb46f5f7882fb0f7bb1f
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69225
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
This reverts commit 4dba71fd25.
Add multiple fan support for dptf policies.
This also fixes the Google Meet resolution drop issue as per
b:246535768 comment#12. When system starts Google Meet video call,
it uses the hardware accelerated encoder as expected. But, as soon as
another system connects to the call, an immediate fallback is observed
from hardware to software encoder. Due to this, Google Meet resolution
dropped from 720p to 180p. This issue is observed on Alder Lake-N SoC
based fanless platforms. This same issue was not seen on fan based
systems. With the fix in dptf driver where fan configures appropriate
setting for only fan participant, not for other device participants,
able to see consistent 720p resolution.
BUG=b:246535768,b:235254828
BRANCH=None
TEST=Built and tested on Alder Lake-P Redrix system for two fans
support and on Alder Lake-N fanless systems. With this code change
Google Meet resolution drop not observed.
Signed-off-by: Sumeet Pawnikar <sumeet.r.pawnikar@intel.com>
Change-Id: Id07d279ff962253c22be9d395ed7be0d732aeaa7
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73249
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Reka Norman <rekanorman@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
