| Age | Commit message (Collapse) | Author |
|---|
|
Factor out the MSR access into a function with a more descriptive name.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I331c3205390edcbd8749b2d52b7cc7ac3a8ced5a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74020
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
|
|
The C state ACPI packages binaryPI generates and passes to coreboot in
the PSTATE SSDT only include the C2 state, but the kernel will add the
C1 state to its usable C states in this case. The native C state code
will generate both the C1 and C2 state packages to be more complete and
also to be more in line with the other AMD SoCs.
The code added in this commit isn't used yet, but will be used as soon
as Stoneyridge will be using the common AMD generate_cpu_entries by
selecting SOC_AMD_COMMON_BLOCK_ACPI_CPU_POWER_STATE once all needed
helper functions are implemented for Stoneyridge.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I06f90306ac196704e0102d0da6eab03f51513c29
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74001
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
|
|
The SOC_AMD_COMMON_BLOCK_TSC_FAM17H_19H option is valid for all SoCs
with Zen-based CPU cores including the family 1Ah, so remove the suffix.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I58d29e69a44b7b97fa5cfeb0e461531b926f7480
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74015
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
|
|
Move the static mhz variable inside the only function that is accessing
it.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ief98c0a1c35fe1bbc4ff38dd175f12e0b3ddc515
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74014
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
|
|
Use get_pstate_core_freq instead of open-coding the calculations in
tsc_freq_mhz. In the case of the CPU frequency divider being 0,
get_pstate_core_freq will return 0; in this case that shouldn't happen,
TSC_DEFAULT_FREQ_MHZ will be used as frequency, since for the TSC
frequency it's better to err on the end of the expected frequency being
too high which will cause longer than expected delays instead of too
short delays.
Now that the code is using get_pstate_core_freq, this code is valid for
Glinda too, so also remove the comment on the
SOC_AMD_COMMON_BLOCK_TSC_FAM17H_19H option being selected in the Glinda
Kconfig. This Kconfig option will be renamed in a follow-up patch.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I01168834d4018c92f44782eda0c65b1aa392030d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74013
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
|
|
Use get_pstate_core_freq instead of open-coding the calculations in
tsc_freq_mhz.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: If5d526e6b365c62a6669241f4fcdd25eca3f15fd
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74012
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
|
|
This function will be used in follow-up patches for both the TSC rate
calculation and the still to be implemented P state ACPI table
generation in coreboot. The was checked against BKDG 52740 Rev 3.05,
BKDG #55072 Rev 3.04, and BKDG #50742 Rev 3.08.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I9afaa044da994d330c3e546b774eb1f82e4f30e4
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74011
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
|
|
Factor out the get_pstate_core_freq function from the SoC's acpi.c files
to both avoid duplication and to also be able to use the same function
in the TSC frequency calculation in a follow-up patch. The family 17h
and 19h SoCs use the same frequency encoding in the P state MSRs while
the family 1Ah SoCs use a different encoding. The family 15h and 16h
SoCs use another encoding, but since this isn't implemented in
Stoneyridge's acpi.c, this will be added in a follow-up patch.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I8619822c2c61e06ae5db86896d5323c9b105b25b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74010
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
|
|
Due to a non-constant TSC rate before the microcode update is applied,
the Performance Time Stamp Counter is used instead. To clarify this, add
a comment to the timestamp_get implementation. See commit 24079323d4d8
("soc/amd/stoneyridge: provide alternate monotonic timer") and the
description of the TscInvariant bit in CPUID Fn8000_0007_EDX Advanced
Power Management Information in the public version of BKDG #55072 Rev
3.09 for more details.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I824b372c36fa6f3eb912469b235a9474f6a58ff5
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74018
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
|
|
Add UPD parameter for eDP power sequence adjust.
The pwr_on_vary_bl_to_blon is set one unit per 4ms.
BUG=b:271704149
TEST=Build; Verify the UPD was pass to system integrated table;
measure the power on sequence on whiterun
Signed-off-by: Chris.Wang <chris.wang@amd.corp-partner.google.com>
Change-Id: I25c9f962e70f599c780259f0943a03f8aa7cbfd1
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73752
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jason Glenesk <jason.glenesk@gmail.com>
|
|
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I2021a106e0d3a603b1a05296411700ffea32fc8c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74042
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
|
|
Move map_oprom_vendev to graphics.c to match the other AMD SoCs. Also
change the comment style to be more in line with the rest of coreboot
and drop the unneeded line break in the printk call.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Icc1f3d73fba973413c5a22e2f5ae01bc58bc3e76
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74041
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
|
|
Fix the VGA_BIOS_ID IDs to match the PCI IDs in the VBIOS binaries and
the PCI ID Stoneyidge's map_oprom_vendev returns. This fixes the problem
that the display wasn't initialized due to not finding the VBIOS file in
CBFS. This bug in the Stoneyridge Kconfig was unmasked by commit
42f0396a1028 ("device/pci_rom: rework PCI ID remapping in
pci_rom_probe").
TEST=Display in Careena lights up again.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I4d1e6a3a65d7d7b07f49df9ce90620b79d9a2d78
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74019
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
|
|
Stoneyridge uses the serial voltage ID 2 standard to tell the VRM on the
board which voltage it wants, so select the SOC_AMD_COMMON_BLOCK_SVI2
Kconfig option to have the corresponding code to decode the raw SVI2
value into a voltage.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I7d7031d9ad997a86c18d0e9e7af9a88ddf2d873c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73999
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
|
|
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Idb6087dc44e76ab63bc6b462c3328c23d83ae018
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74009
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
A core voltage ID larger than 0xff shouldn't happen, since SVI2's core
VID is only 8 bit long. In order for making it more difficult to use
this function in a wrong way that results in a very wrong voltage being
returned, also return 0 for those invalid core VID values.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I95417c45db86cd2373879cdad8a07fb9eb8dfdda
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74000
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Add UPD usb3_port_force_gen1 to support USB3 port force to gen1
BUG=b:273841155
BRANCH=skyrim
TEST=Build, verify USB3 port setting to gen1.
Change-Id: Iaa476f56cf10588d7de2203deca4122958c00783
Signed-off-by: Patrick Huang <patrick.huang@amd.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73916
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
|
|
Add the pstate_msr union of a bitfield struct and a raw uint64_t to
allow easier access of the bitfields of the P state MSRs which will be
used in future patches to generate the P state ACPI packages for the CPU
objects. BKDG #55072 Rev 3.04 was used as a reference.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I944c8598ba95a0333124655c61ef9eba8a7595c9
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73998
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Now that all get_pstate_core_power implementations in each SoC's acpi.c
file is identical, factor it out into a common implementation. This
implementation will also work for Stoneyridge which isn't using the
common P state code yet.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Iba3833024a5e3ca5a47ffb1c1afdbfd884313c96
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73997
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Since SVI3 has the CPU voltage ID split into two parts, a serial voltage
ID version specific function is needed to get the raw core VID value.
This will allow making get_pstate_core_power common for all AMD CPUs in
a follow-up patch.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I71ca88c38b307558905a26cce8be1e8ffc5fbed4
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73996
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Instead of implementing the conversion from the raw serial voltage ID
value to the voltage in microvolts in every SoC, introduce the
SOC_AMD_COMMON_BLOCK_SVI[2,3] Kconfig options for the SoC to select the
correct version, implement get_uvolts_from_vid for both cases and only
include the selected implementation in the build.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I344641217e6e4654fd281d434b88e346e0482f57
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73995
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
The included acpi/acpigen.h provides the cppc_config struct and nothing
in this header file is using the cppc_config struct.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ia91fd4105e6872d812f595447783d02a0dd1568b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73993
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
When the code was made common in commit 8f7f4bf87a23 ("soc/amd/cezanne,
common: factor out CPPC code to common AMD SoC code"), the include guard
wasn't renamed accordingly, so do that now.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I9eefe2065fae31e97aa4e6710008a6f9712bed40
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73992
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Picasso and Cezanne use the serial voltage ID 2 standard to communicate
the CPU voltage to the voltage regulator module on the mainboard, while
Mendocino, Phoenix and Glinda use the serial voltage ID 3 standard for
this. Both standards encode the voltage in a different way, so add the
serial VID version number to the defines to clarify for which version
the define is.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I8ddab8df27c86dc2c70a6dfb47908d9405d86240
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73994
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
|
|
Mendocino uses the SVI3 standard for CPU core voltage control which uses
9 data bits instead of the 8 in the SVI2 case and also calculates the
actual voltages with a different formula. The Mendocino code uses the
correct formula since commit 8d2bfbce23f6 ("soc/amd/sabrina/acpi:
Correct VID decoding on Sabrina"), but the MSR definition in the PPR
hasn't been updated to show the additional bit. The definition of the
register that is mirrored by these MSRs descries this 9th CPU voltage ID
bit though. Since this bit is expected to be zero, this shouldn't cause
a change in behavior.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I05acd239300836a34e40cd3f31ea819b79766e2e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73969
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
|
|
The _LO part in the definition names is a leftover from before moving to
the pstate_msr union access to the bitfield elements where it still
mattered if a bit was in the lower of higher half of the MSR. With the
mask-and-shift access to the two parts of the MSR being gone, the _LO
part in the name isn't useful any more and possibly a bit misleading, so
drop that part.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ib43c71e946388c944ecf40659d4c12ca02a27a5d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73927
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Since we already have and use the pstate_msr union in get_pstate_info,
also pass it directly to the get_pstate_core_freq and
get_pstate_core_power function calls avoids having to sort-of convert
the msr_t type parameter in the implementations of those two functions.
In amdblocks/cpu.h a forward declaration of the pstate_msr union is used
since soc/msr.h doesn't exist in the two pre-Zen SoCs that also include
amdblocks/cpu.h.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I112030a15211587ccdc949807d1a1d552fe662b4
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73926
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Use the pstate_msr union in get_pstate_info to check if the P state
enable bit is set. Also drop the now unused PSTATE_DEF_HI_ENABLE_SHIFT
and PSTATE_DEF_HI_ENABLE_MASK definitions.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I79119e09af79a4bb680a18e93b4a61a049f0080e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73925
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
|
|
Add the pstate_msr union of a bitfield struct and a raw uint64_t to
allow easier access of the bitfields of the P state MSRs which will be
implemented in a following patch. PPR #57254 Rev 1.52 was used as a
reference. This patch adds and uses the cpu_vid_8 bit which is the 9th
bit of the voltage ID specified in the SVI3 spec. The way the CPU
frequency is encoded in the PSTATE MSR has changed compared to Phoenix,
so also update the comment in the SoC's Kconfig file that the selected
SOC_AMD_COMMON_BLOCK_TSC_FAM17H_19H is likely incompatible which will be
addressed in the future.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I3d1878ce4d9bc62ac597e6f71ef9630491628698
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73924
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
|
|
Add the pstate_msr union of a bitfield struct and a raw uint64_t to
allow easier access of the bitfields of the P state MSRs and use this
bitfield struct in get_pstate_core_freq and get_pstate_core_power. The
signature of those two function will be changed in a follow-up commit.
PPR #57019 Rev 1.65 and PPR #57396 Rev 1.54 were used as a reference as
well as the reference code. This patch also adds and uses the cpu_vid_8
bit which is the 9th bit of the voltage ID specified in the SVI3 spec.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ia024d32ae75cf2ffbc2a2e86a8b3af3dc6cbad61
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73923
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
|
|
The internal GPP bridge to bus B is not used on MDN, so remove it.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I4f95afd192c5b799b7a3e12650476b7933cdd118
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73863
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
|
|
Assign true/false instead of 1/0 to the valid_freq_divisor bool variable
in get_pstate_core_freq.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I92d0eb029c55f80a2027ff6d404c63ed84282750
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73880
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
|
|
Mendocino only has 4 PCIe lanes exposed, so there's no need for 6
PCIe functions to control them. These functions just show up as
leftover devicetree devices.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I5b801d82f085d77706b8053a8fc9728101f155e2
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73853
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
|
|
Add the pstate_msr union of a bitfield struct and a raw uint64_t to
allow easier access of the bitfields of the P state MSRs and use this
bitfield struct in get_pstate_core_freq and get_pstate_core_power. The
signature of those two function will be changed in a follow-up commit.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ic489b8e1332dde2511647c065ccbdef541bcbcc5
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73645
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
|
|
Add the pstate_msr union of a bitfield struct and a raw uint64_t to
allow easier access of the bitfields of the P state MSRs and use this
bitfield struct in get_pstate_core_freq and get_pstate_core_power. The
signature of those two function will be changed in a follow-up commit.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: If92a4773c669ac2df45396eee52f6de780adbdca
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73644
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
|
|
Add the pstate_msr union of a bitfield struct and a raw uint64_t to
allow easier access of the bitfields of the P state MSRs and use this
bitfield struct in get_pstate_core_freq and get_pstate_core_power. The
signature of those two function will be changed in a follow-up commit.
TEST=The coreboot-generated SSDT containing the P state packages stays
identical on Mandolin.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I8dc293351f9941cfb8a9c84d9fb9a4fd76361d5d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73643
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
|
|
Provide support function to query fsp misc_data hob and return smu
reported power and thermal limit.
BUG=b:253301653
TEST=Use get_amd_smu_reported_tdp(&tdp) values match what FSP placed in
the hob.
Change-Id: I9f0d8cdd616726c5a714e99504b83b0126dd273b
Signed-off-by: Jason Glenesk <jason.glenesk@amd.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73747
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
The MP2 firmware doesn't do anything useful when booting into recovery
mode, so don't include it in the RO image if vboot is enabled.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I5afbf7e9e730e6951c416f3a3ca75f69a22099cf
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73660
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
When doing coreboot builds, we can set V=1 to see all of the make info
printed as the compile is happening. Use this flag to set the debug
flag for amdfwtool so it doesn't have to be enabled separately.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I5b05cbc9f9b540a174db479822af657cf35733de
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73658
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
|
|
The regex getting rid of lines containing a '*' didn't match anything
in any configs, so get rid of it. There's nothing in the amdfwtool
dataparse.c file that would match it either.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I05aaf46cfb479cebab9234a47574073335984a5f
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73669
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
|
|
After adding the ability to add paths into the amdfw.cfg file for the
amdfwtool, the dependency generation needs to be updated to not add
the firmware location in front of those values.
This also allows us to filter out the MP2 binaries as dependencies
based on whether or not the Kconfig value is set.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I3a9b9c8246808dc60020a32a7d9d926bc5e57ccd
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73657
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
|
|
Documentation and hardware differ in the number of MCA bank names, so
remove the excess ones to prevent a "CPU has an unexpected number of MCA
banks!" warning message.
Signed-off-by: Fred Reitberger <reitbergerfred@gmail.com>
Change-Id: I75a2348561833f3f19181b4f30a6971ecb317899
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73650
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
|
|
Since mst_t is a union of the struct containing the lower and higher 32
bits and the raw 64 bit value, the address of the microcode update can
be directly written to the raw value instead of needing to split it into
the lower and higher 32 bits and assigning those separately.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I51c84164e81477040a4b7810552d3d65c0e3656b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73636
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
|
|
Since mst_t is a union of the struct containing the lower and higher 32
bits and the raw 64 bit value, the address of the bootblock_resume_entry
can be directly written to the raw value instead of needing to split it
into the lower and higher 32 bits and assigning those separately.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Suggested-by: Arthur Heymans <arthur@aheymans.xyz>
Change-Id: I7ebab1784ec592e18c29001b1cf3ee7790615bf8
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73635
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
|
|
This separates the SPL fusing function into a separate C file which can
be excluded if it is not needed. This allows the psp_set_spl_fuse()
function to be made static again as the state of the function will
always match the boot_state entry.
Move the required #defines to the common header file so they can be
used by both psp_gen2.c & spl_fuse.c.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: Ifbc774a370dd35a5c1e82f271816e8a036745ad5
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73655
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
|
|
Even though right now TSEG will always be located below 4GB, better not
make assumptions in the SMM relocation code. Instead of clearing the
higher 32 bits and just assigning the TSEG base and per-core SMM base to
the lower 32 bits of the MSR, assign those two base addresses to the raw
64 bit MSR value to not truncate the base addresses. Since TSEG will
realistically never be larger than 4GB and it needs to be aligned to its
power-of-two size, the TSEG mask still only needs to affect the lower
half of the corresponding MSR value.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I1004b5e05a7dba83b76b93b3e7152aef7db58f4d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73639
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
|
|
Since mst_t is a union of the struct containing the lower and higher 32
bits and the raw 64 bit value, there's no need to convert the lower and
higher 32 bits into a 64 bit value and we can just use the 64 bit raw
value.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I5923df84f0eb3a28ba6eda4a06c7421f4459e560
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73638
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
|
|
Since mst_t is a union of the struct containing the lower and higher 32
bits and the raw 64 bit value, there's no need to convert the lower and
higher 32 bits into a 64 bit value and we can just use the 64 bit raw
value.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ibc5d64c74eaabfc4b7834a34410b48f590f78a12
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73637
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
|
|
And rename PSP_HW_IPCFG_FILE to PSP_HW_IPCFG_FILE_SUB0
Change-Id: Ia1ab8482074105de367905be2b4b0418066823d2
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73531
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
|
|
Change-Id: I078b57825377f97f9f5f2b607fa134e3a67e9685
Signed-off-by: Anand Vaikar <a.vaikar2021@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73557
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: ritul guru <ritul.bits@gmail.com>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
|
|
The get_threads_per_core function isn't specific to the non-CAR CPUs and
also applies for Stoneyridge and even for family 16h model 30h outside
of soc/amd, so move it from the non-CAR-specific cpu.c file to the
common AMD SoC cpu.c file.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I05946f163112ff93f33139f6c43fed5820fd0a3c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73615
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
|
|
Picasso already uses the Cxxx ACPI CPU device naming scheme, due to it
being what the AGESA reference code uses. We initially relied on the
AGESA/FSP generated SSDT for the P- and C-state support before we had a
native implementation for this in coreboot. The Cxxx naming scheme can
also be used for the other AMD SoCs except Stoneyridge which is pre-Zen
and doesn't select SOC_AMD_COMMON_BLOCK_NONCAR. The main advantage of
using Cxxx instead of CPxx is that the Cxxx scheme supports systems with
more than 256 CPU threads.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I884f5c0f234b5a3942dacd60847b2f095f9c0704
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73620
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Set up SoC-specific XHCI defines and enable SOC_AMD_COMMON_BLOCK_XHCI.
BRANCH=guybrush
BUG=b:186792595
TEST=builds
Signed-off-by: Robert Zieba <robertzieba@google.com>
Change-Id: I15e9c06cd38ac858b861a4d19626664704af7541
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67939
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
The GPE number used for XHCI has now been defined in AMD's common code
in CB:67936. Change over existing code to use this new definition.
BRANCH=guybrush
BUG=b:186792595
TEST=Ran on nipperkin device and verified that XHCI events string use
GPE 31.
Signed-off-by: Robert Zieba <robertzieba@google.com>
Change-Id: I9c2a44f7d2eb47422ae8c585e5e01ea0b420d461
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69917
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Set up SoC-specific XHCI defines and enable SOC_AMD_COMMON_BLOCK_XHCI.
BUG=b:186792595
TEST=builds
Change-Id: I16c789ff673c26ded84e4d46ab6dc743f33c5bb7
Signed-off-by: Robert Zieba <robertzieba@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67938
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
The GPE number used for XHCI has now been defined in AMD's common code
in CB:67936. Change over existing code to use this new definition.
BUG=b:186792595
TEST=Ran on skyrim device and verified XHCI GPE setting.
Signed-off-by: Robert Zieba <robertzieba@google.com>
Change-Id: I3bfc2256ea2ca851afe88f2cdb419f39eee76fdd
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69916
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
AMD SoCs currently only log the GPE# when an XHCI controller wakes the
system. Add code to log XHCI wake events to the elog.
BRANCH=guybrush
BUG=b:186792595
TEST=builds
Change-Id: Ic0489e1df55c4e63cb8a306099e3f31c82eebd58
Signed-off-by: Robert Zieba <robertzieba@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67936
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
|
|
This adds checks for three more error bits before requesting that the
SPL fuses are updated.
- While I'm here, I'm adding the include of types.h which was previously
done through other include files, but should be done independently.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I87a7d40850c4e9ddbb2d1913c1588a919fdb29d2
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73518
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
|
|
Use the presence of an SPL (Software Patch Level) file to trigger the
function that reads and writes the SPL fuses. The current Kconfig
option will be used to decide to write the fuses. This allows us to
see the state of the SPL update bit which determines whether or not
SPL fusing is allowed and needed before enabling the fusing.
- Refactor a bit to prepare for following changes.
- Update phrasing
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I7bd2798b984673a4bd3c72f3cab52f1c9a786c67
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73517
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
|
|
Now that the code using the ACPI_SSDT_PSD_INDEPENDENT Kconfig symbol is
moved to soc/amd/common/block/acpi/cpu_power_state.c, also move the
Kconfig symbol to the Kconfig file in this directory.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ide18111df38d4e9c81f7d183f49107f382385d85
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73550
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
|
|
Introduce the get_cstate_io_base helper function that write_cstate_entry
can call directly to get the C state control IO base address instead of
having get_cstate_info pass this Io address to each write_cstate_entry
call.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Suggested-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Change-Id: I4cc80ded0a2fbc2dee9ca819e86284d9ffd58685
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73533
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
|
|
The bit position of the P state enable bit in the 8 P state MSRs is
identical for all AMD chips including the family 16h model 30h APU that
lives outside of soc/amd. The other bits in those 8 MSRs are more or
less family- and model-specific.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ia69c33e28e2a91ff9a9bfe95859c1fd454921b77
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73506
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
|
|
The implementations of get_pstate_info of Picasso, Cezanne, Mendocino,
Phoenix and Glinda are identical, so factor it out and move it to the
common AMD SoC code. The SoC-specific get_pstate_core_freq and
get_pstate_core_power functions remain in the SoC-specific code.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ibe0494f1747f381a75b3dd71a8cc38fdc6dce042
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73505
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
|
|
With the exception of the generate_cppc_entries call, the
implementations of generate_cpu_entries of Picasso, Cezanne, Mendocino,
Phoenix and Glinda are identical, so factor it out and move it to the
common AMD SoC code. Since all SoCs that support CPPC already select the
SOC_AMD_COMMON_BLOCK_ACPI_CPPC Kconfig option, this can be used to only
call generate_cppc_entries for platforms where it is available.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I71323d9d071b6f9d82852479b60dc56c24f2b9ec
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73504
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
|
|
Split the big PSP FW data into two parts, head and body. The head
needs to be located at original specific location. The body address is
more flexible. So the big body will not cover other needed FWs like
EC.
Give the body a specific named AMDFWBODY, which should be defined in
flashmap.
This is one of series of patches to support 32/64M flash.
BUG=b:255374782
Change-Id: Ia8b318f71632a2c9b97ce67486374dc24d23e63e
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72703
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
|
|
Instead of hoping that the default the C state control IO address in
binaryPI won't interfere with any other IO space usage in coreboot,
assign the ACPI_CSTATE_CONTROL value to the CStateIoBaseAddress platform
config structure element to make sure that binaryPI will use a known
address for the IO port based C state control. binaryPI will write this
address to the MSR_CSTATE_ADDRESS and will then also use these IO ports
in the _CST packages in the PSTATE SSDT, so changing this won't cause
a mismatch between those two.
The default CStateIoBaseAddress in the FT4 Stoneyridge binaryPI used on
Careena is 0x1770, so this didn't collide with any other IO space
registers, but it's still much better to tell binaryPI which exact IO
addresses to use.
TEST=On Careena MSR_CSTATE_ADDRESS now contains the ACPI_CSTATE_CONTROL
IO base address 0x420 and the PSTATE SSDT has the IO address 0x421 in
the _CST package entry for the second C state which are both the
expected values.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I207202802427d4bf00f283bcbd83a174ab0a2846
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73497
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
|
|
Rework the way the C state info is generated before it gets passed to
acpigen_write_CST_package in generate_cpu_entries by separating the data
from the code. For this, the newly introduced common get_cstate_info
function is used. Separating the data from the code will eventually
allow moving generate_cpu_entries to the common AMD code.
The actual values in cstate_cfg_table haven't been checked against the
reference code yet.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I5157fc031c5b19d8633132222520f582620208c9
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73503
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
|
|
Rework the way the C state info is generated before it gets passed to
acpigen_write_CST_package in generate_cpu_entries by separating the data
from the code. For this, the newly introduced common get_cstate_info
function is used. Separating the data from the code will eventually
allow moving generate_cpu_entries to the common AMD code.
The actual values in cstate_cfg_table haven't been checked against the
reference code yet.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I4f5743dd2e4dfdfeb3ffb2e9b964bdc75c84e6c3
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73502
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
|
|
Rework the way the C state info is generated before it gets passed to
acpigen_write_CST_package in generate_cpu_entries by separating the data
from the code. For this, the newly introduced common get_cstate_info
function is used. Separating the data from the code will eventually
allow moving generate_cpu_entries to the common AMD code.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I3669c66094f0137081888ebdd1af838e2ea269b5
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73501
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
|
|
Rework the way the C state info is generated before it gets passed to
acpigen_write_CST_package in generate_cpu_entries by separating the data
from the code. For this, the newly introduced common get_cstate_info
function is used. Separating the data from the code will eventually
allow moving generate_cpu_entries to the common AMD code.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Id97fcb74ff3d48994a3181d9c31cbbeb5a76c60a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73500
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
|
|
Rework the way the C state info is generated before it gets passed to
acpigen_write_CST_package in generate_cpu_entries by separating the data
from the code. For this, the newly introduced common get_cstate_info
function is used. Separating the data from the code will eventually
allow moving generate_cpu_entries to the common AMD code.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Id6bd8879ce5968b24893b43041be98db55a4c3c6
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73499
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
|
|
Instead of using a magic constant in the bit_offset field of the C state
resource for the C1 state that's entered via the MWAIT instruction, use
the existing ACPI_FFIXEDHW_CLASS_MWAIT define. This value is checked by
acpi_processor_ffh_cstate_probe in the Linux kernel.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I9edc681efab15b5ceba91c8105f7dc6d687d8be8
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73498
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
|
|
Introduce the get_cstate_info helper function that populates the caller-
provided cstate_values array with the data returned by the SoC-specific
get_cstate_config_data function. From the array get_cstate_config_data
returns, only the ctype, latency and power fields are used, so the rest
can be left uninitialized. Those 3 fields are compile-time constants.
For each entry, write_cstate_entry will generate the corresponding
resource information from the given data. In the C1 case where ctype is
1, the state is entered via a MWAIT instruction, while the higher C
states are entered by doing an IO read from a specific IO address. This
IO address is x - 1 bytes into the IO region starting at
MSR_CSTATE_ADDRESS for the Cx state. So for example C2 is entered by
reading from the C state IO base address + 1. This resource information
is generated during runtime, since the contents of MSR_CSTATE_ADDRESS
aren't necessarily known at compile-time.
MAX_CSTATE_COUNT is introduced so that the caller can allocate and pass
a buffer with space for the maximum number of C state entries. This
maximum number corresponds to the number of IO addresses the CPU traps
beginning from MSR_CSTATE_ADDRESS. In practice, it's unlikely that more
than 3 or maybe 4 C states will be available though.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I2c36c1d604ced349c609882b9d9fe84d5f726a8d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73428
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
|
|
Instead of having binaryPI generate a PSTATE SSDT that uses \_PR_ as the
scope for the CPU objects and patching this SSDT in coreboot to use the
\_SB_ scope in patch_ssdt_processor_scope, request binaryPI to use the
\_SB_ scope instead by setting the late platform configuration option
ProcessorScopeInSb to true.
TEST=Careena still boots and Linux doesn't show any ACPI errors with
this patch applied. With only patch_ssdt_processor_scope removed, but
the ProcessorScopeInSb option not set, Linux will complain that it can't
resolve the \PR.P00x symbols.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: If88820a0f5df923f129e2e3b5335f5f0e38ee7f5
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73385
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
|
|
The legacy ACPI CPU control registers in IO space where the first 4 IO
locations control the CPU throttling value don't exist any more on the
Zen-based CPUs. Instead this IO address is written to MSR_CSTATE_ADDRESS
in set_cstate_io_addr which will cause accesses from the 8 IO addresses
beginning with ACPI_CSTATE_CONTROL to be trapped in the CPU core. Reads
from those IO addresses will cause the CPU to enter low C states.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I2c34e201cc0add1026edd7a97c70aa57f057782b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73427
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
|
|
Finally figured out why ACPI_GPE0_BLK only being 4 bytes after
ACPI_CPU_CONTROL won't work and its due to the CPU trapping 8 IO
addresses from ACPI_CPU_CONTROL on for C state control. This is set up
in set_cstate_io_addr by writing the ACPI_CPU_CONTROL value into
MSR_CSTATE_ADDRESS.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Iedf53bbdae6ca65224601aad5cd1163df4b54131
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73423
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
|
|
Picasso and newer don't implement the P_CNT register to control the CPU
duty cycle and also trap the C state control IO addresses directly in
the CPU, so those won't reach the FCH. This register is unused in the
Picasso code and not even defined any more in the Cezanne PPR. The
Picasso PPR does define this register, but since it's useless and might
even just be a leftover form a pre-Zen CPU generation, drop the define.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I3820db542c4714a100c7d36de673daa1a06e4a67
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73422
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
|
|
The FADT data structure is zero-initialized in acpi_create_fadt which
then calls the SoC-specific acpi_fill_fadt function, therefore it's not
needed to assign 0 to the duty_offset and duty_width FADT field in
acpi_fill_fadt for all SoC except Stoneyridge.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ib63b24891d44298841153dfc500b030619e1a5ea
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73421
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
|
|
Picasso neither has the corresponding P_CNT register implemented nor
writes a _PTC ACPI object that would specify the P_CNT register. The
Picasso UEFI reference code also sets the duty_width FADT entry to 0.
This also aligns the Picasso code with the Cezanne code in this regard.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I74645e5c4e54a2ad6bc7f9e72f5f656027a79860
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73420
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
|
|
The FADT data structure is zero-initialized in acpi_create_fadt which
then calls the SoC-specific acpi_fill_fadt function, therefore it's not
needed to assign 0 to the pstate_cnt FADT field in acpi_fill_fadt.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: If3ddb466de1d437361d811e45e328a1dbff02fcc
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73419
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
|
|
The FADT data structure is zero-initialized in acpi_create_fadt which
then calls the SoC-specific acpi_fill_fadt function, therefore it's not
needed to assign 0 to the mon_alrm FADT field in acpi_fill_fadt.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Iabb5fc7367f1e4e7acea1a58abdb643fc46ca776
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73418
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
|
|
Add stt settings for dptc tablet mode.
BUG=b:257149501
BRANCH=None
TEST=Check if the STT value matches the clamshell/tablet mode.
Run the WebGL aquarium with 5000 fish and verify that there is
no power drop peak.
Change-Id: Ib4aad3af8761b20084717b15a462edf4704b83cc
Signed-off-by: Chris Wang <chris.wang@amd.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73205
Reviewed-by: Tim Van Patten <timvp@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Frank Wu <frank_wu@compal.corp-partner.google.com>
|
|
The SPL parameter for DPTC settings is not available for STT-enabled
platforms. It needs to be removed to avoid confusing STT calculations.
BUG=b:265267957
BRANCH=none
TEST=Run the WebGL aquarium with 5000 fish and verify that
there are no power drop peaks.
Change-Id: I8e6dad7d24883f8aadce83ebac401ecd4137d61a
Signed-off-by: Chris Wang <chris.wang@amd.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73124
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Van Patten <timvp@google.com>
|
|
Phoenix' implementation of map_oprom_vendev uses this simplified
implementation, so port this back to Cezanne too.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I0aa3a0fed37c6cba15a668ada639f5fd0c212d2f
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73387
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
To support 32M flash, the non-vboot also need to split amdfw.
The amdfw.rom is the default filename added to CBFS.
Keep the default filename and then we don't have to change all the
CBFS definition.
This is one of series of patches to support 32/64M flash.
BUG=b:255374782
Change-Id: Id77b11422d4549cf57a1cd8980c7a9cf3597d1bc
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72702
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
|
|
Add a new parameter STT_ALPHA_APU' for each DPTC mode.
BUG=b:257149501
BRANCH=None
TEST=Check if the STT value matches the expected setting.
Change-Id: Ib27572712d57585f66030d9e927896a8249e97a7
Signed-off-by: Chris Wang <chris.wang@amd.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73123
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Van Patten <timvp@google.com>
Reviewed-by: Frank Wu <frank_wu@compal.corp-partner.google.com>
Reviewed-by: John Su <john_su@compal.corp-partner.google.com>
|
|
Instead of adding the P-state number to the PSTATE_0_MSR number to get
the P-state MSR number for the rdmsr call, provide a macro that directly
calculates the MSR number for a given power state. Also drop the unused
PSTATE_[1..4]_MSR definitions which also didn't cover all P-state MSRs
available in the hardware.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: If85acf556efe82c209e1608e56c05f7a2a748403
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73323
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
|
|
The latency values in the _CST package override the values in the
p_lvl2_lat and p_lvl3_lat FADT fields. In Picasso, Cezanne, Mendocino,
Phoenix and Glinda generate_cpu_entries generates the _CST packages for
each CPU device. The coreboot code for Stoneyridge doesn't generate _CST
packages for the CPU objects, but those are provided via the PSTATE SSDT
binaryPI generates and agesa_write_acpi_tables gets and adds to the ACPI
tables. The AGESA reference code also sets those two FADT entries to the
equivalents of ACPI_FADT_C2_NOT_SUPPORTED and ACPI_FADT_C3_NOT_SUPPORTED
so this also matches the AGESA behavior.
From the ACPI 6.4 spec: "Values provided by the _CST object override
P_LVLx values in P_BLK and P_LVLx_LAT values in the FADT."
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I1116a3013576b18b6f521604d6b0a9d75b971e0b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73231
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
|
|
IRQ9 is used as ACPI SCI IRQ, so add a define for that and use it in the
code like it is also done in the other SoCs in soc/amd.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Iddb51d70c15ab1d7088f62b61e22510bd1b30b1e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73320
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Since there's a define for the ACPI_SCI_IRQ 9, use the define instead of
a magic number in the code.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I23c8f62929f3f66192698e10826d10329ef3d8cc
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73319
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
The FADT data structure is zero-initialized in acpi_create_fadt which
then calls the SoC-specific acpi_fill_fadt function, therefore it's not
needed to assign 0 to the res2 FADT field in acpi_fill_fadt.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ifa69ae61bea82acf66e7210c4103ef48e36dbdd2
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73318
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Use enum cb_err to return an error/success state instead of an int in
get_nv_rdev and get_nv_rdev_rw.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I73706a93bc1dbc8556e11885faf7f486c468bea9
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73317
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
The bool type is used although stdbool.h isn't included. Include types.h
which will include both stdint.h and stdbool.h
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I5213ddae3ceb36e0b2e09f8ef3f7f414ebdf187f
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73316
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
It's sufficient to generate CPU devices for all available CPU cores/
threads instead of for the maximum number of possible CPU cores/threads.
TEST=google/careena with 2 cores still boots and Linux doesn't complain
about ACPI errors due to referenced but not present CPU objects.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I6850edfa305304060092cb5480f4296f4f5ddacc
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73070
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
|
|
On boards with RECOVERY_MRC_CACHE FMAP section, populate type 0x63 BIOS
directory entry in RO with that section. If the RECOVERY_MRC_CACHE
section is not present, then fall back to RW_MRC_CACHE.
BUG=b:270569389
TEST=Build and boot to OS in Skyrim. Ensure that the Type 0x63 BIOS
directory entry is populated with the base and size of appropriate MRC
cache.
Change-Id: I49ec4f64e33c4d5780a7fe6a5540eab42b6cec9f
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73169
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
|
|
If a mainboard has RECOVERY_MRC_CACHE and the recovery mode is enabled,
then use APOB data from that section and make any updates to that
section. Otherwise continue to use DEFAULT_MRC_CACHE section.
BUG=b:270569389
TEST=Build and boot to OS in Skyrim.
When in normal mode, DEFAULT_MRC_CACHE is used.
Normal Mode Boot1:
------------------
[DEBUG] FMAP: area RW_MRC_CACHE found @ 0 (122880 bytes)
[INFO ] APOB RAM hash differs from flash
[SPEW ] Copy APOB from RAM 0x02001000/0x1db18 to flash 0x0/0x1e000
[DEBUG] FMAP: area RW_MRC_CACHE found @ 0 (122880 bytes)
[DEBUG] SF: Successfully erased 122880 bytes @ 0x0
[INFO ] Updated APOB in flash
Normal Mode Boot2:
-----------------
[DEBUG] FMAP: area RW_MRC_CACHE found @ 0 (122880 bytes)
[DEBUG] APOB hash matches flash
When the device is in recovery mode, RECOVERY_MRC_CACHE is used.
Recovery Mode Boot1:
--------------------
[DEBUG] FMAP: area RECOVERY_MRC_CACHE found @ 650000 (122880 bytes)
[INFO ] APOB RAM hash differs from flash
[SPEW ] Copy APOB from RAM 0x02001000/0x1db18 to flash 0x650000/0x1e000
[DEBUG] FMAP: area RECOVERY_MRC_CACHE found @ 650000 (122880 bytes)
[DEBUG] SF: Successfully erased 122880 bytes @ 0x650000
[INFO ] Updated APOB in flash
Recovery Mode Boot2:
--------------------
[DEBUG] FMAP: area RECOVERY_MRC_CACHE found @ 650000 (122880 bytes)
[DEBUG] APOB hash matches flash
Switch from Recovery Mode to Normal Mode:
-----------------------------------------
[DEBUG] FMAP: area RW_MRC_CACHE found @ 0 (122880 bytes)
[DEBUG] APOB hash matches flash
Switch from Normal Mode to Recovery Mode:
-----------------------------------------
[DEBUG] FMAP: area RECOVERY_MRC_CACHE found @ 650000 (122880 bytes)
[DEBUG] APOB hash matches flash
Change-Id: I93f357e407c98b6e5fca495f4f779fad54a3430f
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73168
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
|
|
Because the ChromeOS boards don't fill a manufacturer in for the memory
SPDs, that information isn't available from the FSP. We can get the
Manufacturer ID based on the memory name from CBI instead. Use this
information to fill in an ID so that the manufacturer name is available
in the SMBIOS information.
BUG=None
TEST=Look at dmidecode output
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I810c3191180dd3b566d7ea64006f29b625b10526
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73255
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
|
|
The DMI error correction type was not being filled in, so was reporting
as "Error Correction Type: <OUT OF SPEC>". This patch fixes that.
Since it's now filling in information for both Type 16 & 17, rename
the function to reflect that.
BUG=None
TEST=dmidecode now reports the type correctly.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I6b51612d808c63de1acd2be952cb6c152f8a1be5
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73253
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
|
|
Add option for mainboards to target builds for SimNow.
Signed-off-by: Fred Reitberger <reitbergerfred@gmail.com>
Change-Id: Id765437b69f1bc3a9f9d7858edcd27e687d5a7f3
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73164
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
|
|
Rather than explicitly checking for Recovery or Developer mode via
vboot, use display_init_required() so that vboot is not required, and
other instances where the display is needed pre-OS (such as when
applying a critical system update) are covered as well.
With this change, SoCs implementing selective GOP init will need to
select VBOOT_MUST_REQUEST_DISPLAY in order for display_init_required()
to not assert on compilation.
BUG=b:255812886
TEST=build/boot skyrim
Change-Id: Iac7e06863764a9f21c8a50fc19050cb5a6627df2
Signed-off-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73046
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
|
