We use cpuid_eax to get the cpuid family.
BUG=b:179699789
TEST=build guybrush
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: Ib73e66241bb0cfd99a035c217c527338aa2d0e4d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57566
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
By adding TEST_PRINT=1 to <test-name>-config field or by passing it as
a parameter to make one can enable printing in printk() and vprintk().
This can be helpful when developing unit tests.
Note, that to effectively enable or disable printk() printing to stdout,
test(s) have to be recompiled.
Signed-off-by: Jakub Czapiga <jacz@semihalf.com>
Change-Id: Ibdec8bb128f42ba4d9cb8bbb4a8c5159a2b52ac5
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57526
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Reviewed-by: Paul Fagerburg <pfagerburg@chromium.org>
Manually maintaining a list of fields just to avoid printing some
unnecessary CPP guards isn't worth the maintenance burden. Instead,
always generate these guards, even if they guard nothing.
Change-Id: I6c84180d83ac39a895e02d196acb7074eb052d7f
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57459
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
If a device is disabled, do not call the `get_smbios_data` code.
Change-Id: I8960f869e0864f7c82d5fe507f96b62cbd045569
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57458
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
The call to the `get_smbios_data` device operation is followed by
calls to unconditional default functions, which lacks flexibility.
Instead, have devices that implement `get_smbios_data` call these
default functions as needed.
Most `get_smbios_data` implementations are in mainboard code, and are
bound to the root device. The default functions only operate with PCI
devices because of the `dev->path.type != DEVICE_PATH_PCI` checks, so
calling these functions for non-PCI devices is unnecessary. QEMU also
implements `get_smbios_data` but binds it to the domain device, which
isn't PCI either.
Change-Id: Iefbf072b1203d04a98c9d26a30f22cfebe769eb4
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57366
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Avoid SMBIOS type 16 Maximum Capacity showing incorrect
information when value of maximum capacity exceeds 32 bits by
extending the type.
Handle 0x0009, DMI type 16, 23 bytes
Physical Memory Array
Location: System Board Or Motherboard
Use: System Memory
Error Correction Type: Single-bit ECC
Maximum Capacity: 4 TB
Error Information Handle: Not Provided
Number Of Devices: 6
Tested=On OCP Crater Lake, the SMBIOS type 16 shows expected
Maximum Capacity.
Signed-off-by: Jingle Hsu <jingle_hsu@wiwynn.com>
Change-Id: Iaa79cc587808f1eab0a48e2ce1dab089e84e9721
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57520
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Daocheng Bu <daocheng.bu@intel.com>
...because I just spent hours chasing a refactoring bug that would have
been way more obvious with a little more error transparency in here.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I3354ff0370ae79f05e5c37d292ac16d446898606
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57573
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Add additonal LPDDR4 speed grades. This is needed because the limited
set has casued confusion when the reported speed did not match
expectations. There does not seem to be a definitive list of LPDDR4
speed grades, so this list is derieved from JEDEC 209-4C and a survey
of commonly used LPDDR4 speed grades.
BUG=b:194184950
TEST=Boot, dmidecode -t 17 reports correct speed
BRANCH=None
Change-Id: Ie7706fd4ad5a7df68c07b8ca43261429ba140c61
Signed-off-by: Rob Barnes <robbarnes@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57294
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Nikolai Vyssotski <nikolai.vyssotski@amd.corp-partner.google.com>
Add supported memory parts in the mem_parts_used.txt and generate the
SPD ID for the parts. The memory parts being added are:
1. K4U6E3S4AA-MGCR (Samsung)
BUG=b:192521391
BRANCH=dedede
TEST=Build and boot bugzzy board
Change-Id: Ic0b02559c671845a73a71bd57cd7237850c76645
Signed-off-by: Seunghwan Kim <sh_.kim@samsung.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57522
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Fixes commit bd5b4aa683
"soc/intel/cannonlake: Switch PMC to use device callbacks" as it
requires the PCI device 1f.2 to be present in the devicetree.
It was missing for this mainboard and caused a boot failure.
Change-Id: Iaf508b2d955578efa2a266af50c568f5c0a47aaf
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57574
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
The MIPI source video data has a large variation (e.g. 59Hz ~ 61Hz),
anx7625 defines K ratio for matching MIPI input video clock and
DP output video clock. A bigger k value can match a bigger video data
variation. IVO panel has smaller variation than DP CTS spec, so decrease
k value to 0x3b.
BUG=b:194659777
BRANCH=none
TEST=Display is normal on Asurada
Change-Id: If3a09811999babda45e9a9a559dd447920109204
Signed-off-by: Xin Ji <xji@analogixsemi.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57439
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
The ANX7625 display bridge requires customized
hs_da_trail time.
This patch is based on CB:51433 (commit 6482b16,
"mb/google/kukui: fine tune the data lane trail")
BUG=b:198558237
TEST=emerge-asurada coreboot
BRANCH=asurada
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Change-Id: I0eedb8fa6a1b3dfd9619c7cbf755c9c4071a8484
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57481
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Rex-BC Chen <rex-bc.chen@mediatek.corp-partner.google.com>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Add mipi panel support for mrbland
- Setup gpio and modify LCD sequence.
- Use the following panel for mrbland:
AUO B101UAN08.3
BOE TV101WUM-N53
- Use panel_id to distinguish which mipi panel to use.
BUG=b:195516474,b:197300875,b:197300876
BRANCH=none
TEST=emerge-strongbad coreboot
Change-Id: Ib7cd2da429b114bf6bad5af312044a0f01319b46
Signed-off-by: Zanxi Chen <chenzanxi@huaqin.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57336
Reviewed-by: Bob Moragues <moragues@google.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Our MIPI panel initialization framework differentiates between DCS and
GENERIC commands, but the exact interpretation of those terms is left to
the platform drivers. In practice, the MIPI DSI transaction codes for
these are standardized and platforms always need to do the same
operation of combining the command length and transfer type into a
correct DSI protocol code. This patch factors out the various
platform-specific DSI protocol definitions into a single global one and
moves the transaction type calculation into the common panel framework.
The Qualcomm SC7180 implementation which previously only supported DCS
commands is enhanced to (hopefully? untested for now...) also support
GENERIC commands. While we're rewriting that whole section also fix some
other issues about how exactly long and short commands need to be passed
to that hardware which we identified in the meantime.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I09ade7857ca04e89d286cf538b1a5ebb1eeb8c04
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57150
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
The USB descriptions are flipped. Fix by inverting the USB descriptions
in devicetree.
BUG=None
TEST=Build
BRANCH=None
Signed-off-by: Rob Barnes <robbarnes@google.com>
Change-Id: I4b33f4de137536c5f3592380da15f6b3a3633bf5
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57538
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add a short documenting comment to each usb entry in devicetree so it is
clear which function each usb port maps to.
BUG=None
TEST=Build
BRANCH=None
Change-Id: I14cbb6af021bb27c89aa82456722f21aa09617be
Signed-off-by: Rob Barnes <robbarnes@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56725
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Moves MAX_EVENT_SIZE to commonlib/bsd/include, and renames it
ELOG_MAX_EVENT_SIZE to give it an "scoped" name.
The moving is needed because this defined will be used from
util/cbfstool (see next CL in the chain).
BUG=b:172210863
TEST=compiles Ok
Change-Id: I86b06d257dda5b325a8478a044045b2a63fb1a84
Signed-off-by: Ricardo Quesada <ricardoq@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57394
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jack Rosenthal <jrosenth@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Adds "clear" command to cbfsutil/elogtool tool.
"clear" clears the RW_ELOG region by using either:
* flashrom if no file is provided
* or using file write if an input file is provided.
The region is filled with ELOG_TYPE_EOL. And a
ELOG_TYPE_LOG_CLEAR event is inserted.
Additionally, it does a minor cleanup to command "list", like:
* use buffer_end()
* add "list" to the cmds struct
* and make elog_read() very similar to elog_write()
Usage:
$ elogtool clear
BUG=b:172210863
TEST=elogtool clear && elogtool list
elogtool clear -f invalid.raw
elogtool clear -f valid.raw
Change-Id: Ia28a6eb34c82103ab078a0841b022e2e5e430585
Signed-off-by: Ricardo Quesada <ricardoq@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56883
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Jack Rosenthal <jrosenth@chromium.org>
After switching to runtime generation of the Intel Power Engine (PEPD)
device, this file is no longer required.
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Change-Id: I2444433f08bfda6f79589a397a2ad2b5a3ecb0ed
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56015
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
The pep.asl file is being obsoleted by runtime generation, therefore
switch skylake boards to this method.
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Change-Id: I7c7cb424278946a9767ea329d18fb03d4e57dce8
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56014
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
In order to get rid of pep.asl, skylake also needs to support runtime
generation of the Intel Power Engine, therefore add this support to
devices that have a discoverable PMC as well.
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Change-Id: I4bf0c4a338301b335fa78617e0f2ed5a9f4360ed
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56013
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
The pep.asl file is being obsoleted by runtime generation, therefore
switch elkhartlake boards to this method.
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Change-Id: I47f03b440729d4b37ae0abc84bd1d18c4e01657d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56012
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
The pep.asl file is being obsoleted by runtime generation, therefore
switch jasperlake boards to this method.
soc/intel/jasperlake: Switch to acpigen PEPD
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Change-Id: Ib7f17f9b3b1396708ba68fa7a6d199d6e8b0ba11
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56011
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Now that the PMC device is marked as hidden in devicetrees, the device
callbacks can be used instead of BOOT_STATE_INIT_ENTRY callbacks.
Note that this moves PMC initialization from BS_DEV_INIT_CHIPS to
BS_DEV_ENUMERATE, which aligns with other Intel SoCs.
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Change-Id: If292728ad975ba803fed6abea879f6f634470a11
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56009
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
FSP-S hides the PMC from the PCI bus when it runs, but there are still
initialization steps coreboot programs for the PMC. Therefore, change
all of the cannonlake mainboards to set the PMC as hidden in the
devicetree, which means the device will be skipped during enumeration,
but device callbacks are still issued as if the device were enabled.
TEST=Ran full patch train on google/dratini, disassembled SSDT and the
PEPD device matches what is in pep.asl. Also verified via dmesg that the
INT33A1 device is still initialized by the kernel.
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Change-Id: Ib4a20ce9075ce7653388a5d3e281fe774bf89355
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56008
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
The pep.asl file is being obsoleted by runtime generation, therefore
switch tigerlake boards to this method.
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Change-Id: I8e97c589273e934e89d69d8829680b9cac1ff9f5
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56007
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
The LPM enable mask is useful to have in more than one place, therefore
more the get_disable_mask() function and its helpers to lpm.c
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Change-Id: Ibe83dc106f5f37baf9d5c64f68c47d85ea4e6dd4
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56460
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
The pep.asl file is being obsoleted by runtime generation, therefore
switch alderlake boards to this method.
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Change-Id: I617bc3d1c3cf4ac6b6cbbd790dcf62e731024834
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56006
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
There is a use-case for generating the AML bytecode at runtime for the
Intel Power Engine device, which comes in a followup patch.
BUG=b:185437326
TEST=verified on google/brya and google/dratini by dumping SSDT and
verifying the PEPD device matches what was previously in the DSDT:
Scope (\_SB.PCI0)
{
Device (PEPD)
{
Name (_HID, "INT33A1")
Name (_CID, EisaId ("PNP0D80")
Method (_DSM, 4, Serialized)
{
ToBuffer (Arg0, Local0)
If ((Local0 == ToUUID ("c4eb40a0-6cd2-11e2-bcfd-0800200c9a66")))
{
ToInteger (Arg2, Local1)
If ((Local1 == Zero))
{
Return (Buffer (One)
{
0x63
})
}
If ((Local1 == One))
{
Return (Package (0x01)
{
Package (0x03)
{
\NULL,
Zero,
Package (0x02)
{
Zero,
Package (0x02)
{
0xFF,
Zero
}
}
}
})
}
If ((Local1 == 0x02)){}
If ((Local1 == 0x03)){}
If ((Local1 == 0x04)){}
If ((Local1 == 0x05))
{
If (CondRefOf (\_SB.PCI0.LPCB.EC0.S0IX))
{
\_SB.PCI0.LPCB.EC0.S0IX (One)
}
If (CondRefOf (\_SB.MS0X))
{
\_SB.MS0X (One)
}
If (CondRefOf (\_SB.PCI0.EGPM))
{
\_SB.PCI0.EGPM ()
}
}
If ((Local1 == 0x06))
{
If (CondRefOf (\_SB.PCI0.LPCB.EC0.S0IX))
{
\_SB.PCI0.LPCB.EC0.S0IX (Zero)
}
If (CondRefOf (\_SB.MS0X))
{
\_SB.MS0X (Zero)
}
If (CondRefOf (\_SB.PCI0.RGPM))
{
\_SB.PCI0.RGPM ()
}
}
Return (Buffer (One)
{
0x00
})
}
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Change-Id: Ie83722e0ed5792e338fc5c39a57eef43b7464e3b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56004
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Since the value returned by _DSM function 0 for a given UUID is trivial
to calculate, add the ability to do so to the
acpigen_write_dsm() functions.
Change-Id: Id9be050442485b42202cf91649aa94e56f35032a
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56459
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Use the get_supported_lpm_states() function to set the respective FSP
UPD.
TEST=with patchtrain on brya0,
/sys/kernel/debug/pmc_core/substate_requirements shows only the
substates that are applicable to the design (S0i2.0, S0i3.0).
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Change-Id: I5bb8b3671e78c5f2706db2d3a21b25cf90a14275
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56458
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
This function searches the known MCH device IDs for Alder Lake and
returns the appropriate enum value representing ADL-P, ADL-M, ADL-S, or
unknown.
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Change-Id: I26354b340e0c5f15ba246c1cb831d7feaf62d2ee
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57151
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Some bridge chips or panels require DSI signal output
before the DSI receiver is ready to work.
This patch is based on CB:47380 (commit b32e4d6,
"mb/google/kukui: Add panel api after dsi start")
BUG=b:198558237
TEST=emerge-asurada coreboot
BRANCH=asurada
Change-Id: Id72560caee9352f88db2de7269b1472f56ac1bdf
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57485
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Reviewed-by: Rex-BC Chen <rex-bc.chen@mediatek.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
On some platforms, runtime firmware crashes write logs to the CBMEM
console. For those, since a crash reboots the system, by the time we
have a chance to run `cbmem` again the boot where the crash happened
will be the one before the "last" (current) boot. So cbmem -1 doesn't
show the interesting part, and cbmem -c potentially shows a lot that is
cumbersome to dig through. This patch introduces a new option cbmem -2
to explicitly show only the boot cycle before the last one.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I6725698f4c9ae07011cbacf0928544cebb4ad6f8
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57510
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
This reverts commit b90e6fdd25. Latest
releases of PSP does not load PSP verstage on S0i3 resume. Hence no need
to skip PSP verstage on S0i3 resume.
BUG=b:196400450
TEST=Build and boot to OS in Guybrush. Trigger a suspend/resume cycle
and then a reboot and ensure that the system boots to OS.
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Change-Id: Iaeb92edb69662e6c06f4d0e3d7b760d4597bf650
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57506
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
ALC5682-VD/ALC5682-VS load different kernel driver by different hid
name. Update hid name depending on the AUDIO_CODEC_SOURCE field of
fw_config. Define SSFC bit 9-11 in coreboot for codec within ec.
ALC5682-VD: _HID = "10EC5682"
ALC5682I-VS: _HID = "RTL5682"
BUG=b:193694180
TEST=ALC5682-VD/ALC5682-VS audio codec can work
Signed-off-by: Stanley Wu <stanley1.wu@lcfc.corp-partner.google.com>
Change-Id: Ib458cf47909a2d7a65f086c5f30f85a16f78d589
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57367
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Add the pin definitions for the remote GPIOs and the GPIO pin mux values
for the GPIO mode of those pins. For now, accessing the remote GPIOs is
only supported from the native coreboot code running on the x86 cores
and not from verstage on PSP or ACPI.
BUG=b:194524995
TEST=On Majolica with a Cezanne APU configuring GPIO 262 as output and
then toggling that GPIO in an infinite loop in the mainboard's bootblock
code results in GPIO 262 toggling as expected.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I0e57042e74da88503b36d6065e9500876287f8bb
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56811
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Right now the ACPI code doesn't support accessing the remote GPIO block
yet, so don't generate invalid remote GPIO access functions and warn
about those being unsupported.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Id364a59c9650bf4e3633b494b01ab23c0bbc50b2
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56817
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Jason Glenesk <jason.glenesk@gmail.com>
Some AMD SoCs have a 5th GPIO bank, the remote GPIO bank, which isn't
located right after the 4th GPIO bank, but instead at a different
location inside the APCIMMIO region. A difference to the first 4 GPIO
banks is that the corresponding GPIO MUX registers aren't in a separate
bank, but at the end of the remote GPIO region. So this remote GPIO
region only supports 48 GPIOs with a 32 bit configuration register each
and has the 8 bit GPIO MUX registers beginning at offset 0xc0 in the
remote GPIO region.
For now using the remote GPIOs from verstage on PSP isn't supported. To
support this, it would need to map acpimmio_remote_gpio and update the
pointer like it already does for acpimmio_gpio0, acpimmio_iomux and a
few others.
BUG=b:194524995
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ic8d7ff677a99381a5558782b80b0c4cae67602db
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56810
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Raul E Rangel