Earlier we did not have definition for BIT27 for PAD_CFG0 register, we
will use this BIT to enable "virtual wire messaging for native function"
If this bit is enabled, whenever change is detected on the pad, virtual
wire message is generated and sent to destination set by native function.
This bit must be set while enabling CPU PCIe root port programming for
ADL and thus defining a new macro to set native pad function along with
NAF_VWE bit to make GPIO programming easier from coreboot.
BUG=None
BRANCH=None
TEST=Code compilation works fine and if we use this macro to program
GPIO, proper bit is getting set in PAD_CFG register
Change-Id: I732e68b413eb01b8ae1a4927836762c8875b73d2
Signed-off-by: Maulik V Vaghela <maulik.v.vaghela@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52782
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Subrata Banik <subrata.banik@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Pen Detect GPIO is exported through GPIO keys driver to the kernel so
that stylus tools is popped on pen eject event. Hence enable the GPIO
keys driver and configure the devicetree.
BUG=b:186011392
TEST=Build and boot to OS in guybrush. Ensure that PRP0001 device is
added to the ACPI SSDT table. Ensure that the Pen Eject events are
detected.
Event: time 1620159356.243180, type 5 (EV_SW), code 15 (SW_PEN_INSERTED), value 1
Event: time 1620159356.243180, -------------- SYN_REPORT ------------
Event: time 1620159356.735316, type 5 (EV_SW), code 15 (SW_PEN_INSERTED), value 0
Ensure that when the device is suspended, it wake on Pen Eject event and
does not wake on Pen Insert event.
Change-Id: I4d2aa29c0f1839c563b40734527a687a5618ba5c
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52906
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Should use `name` instead of `field->name`, because `field is supposed
to be NULL at this point.
TEST=add new field from bits 29-64 to volteer, ensure sconfig prints an
error instead of segfaulting.
Change-Id: I933330494e0b10e8494a92e93d6beb58fbec0bc1
Found-by: Coverity CID 1452916
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52888
Reviewed-by: Duncan Laurie
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Using PAD_WAKE is actually wrong. The wake bits are only supposed to be
set when using the GPIO controller to wake the system. coreboot's
current architecture relies on using GPEs to wake the system.
BUG=b:186011392
TEST=Wake system from S0i3 with EC and see GPE 3 increment.
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: If7f9d2c13503c01fb9d834c436dac723f2c3b24c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52801
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
The only use case for FSP-T in coreboot is for 'Intel Bootguard'
support at the moment. Bootguard can do verification FSP-T but there
is no verification on whether the FSP found by walkcbfs_asm is the one
actually verified as an IBB by Bootguard. A fixed pointer needs to be
used.
TESTED on OCP/Deltalake, still boots.
Change-Id: I1ec8b238384684dccf39e5da902d426d3a32b9db
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52850
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
From tests this does not lock down SMRAM and it's also not possible to
read back what is written, be it via PCI mmconfig or io ops. The
FSP integration can be assumed to be bogus on this point.
Change-Id: Ia0526774f7b201d2a3c0eefb578bf0a19dae9212
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51532
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Some crc16_byte() and crc32_byte() tests had uint8_t instead of uint16_t
or uint32_t. That caused CRC values to be truncated and made tests
incorrect.
Also fix incorrect pre-calculated CRC values and change test buffer name
to more the accurate.
Signed-off-by: Jakub Czapiga <jacz@semihalf.com>
Change-Id: I61ee029a6950a8dfeb54520b634eaf4ed6bac576
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52708
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Fagerburg <pfagerburg@chromium.org>
This patch removes a call to console_init() and debug print message since
the code is not thread safe. This prevents system hangs (soft hangs)
while in SMM if user drops in a new SOC with more cores or another
socket or as a result of bad configuration. Console is already
initialized after the lock has been acquired so this does not affect any
other functionality.
Tested on DeltaLake mainboard with SMM enabled and 52 CPU threads.
Change-Id: I7e8af35d1cde78b327144b6a9da528ae7870e874
Signed-off-by: Rocky Phagura <rphagura@fb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52518
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
In follow-up patches, we need to set multiple power domains to
power on the display and audio on MT8195.
Move the power domain data under each SoC and make power_on() API
to support multiple settings.
Signed-off-by: Weiyi Lu <weiyi.lu@mediatek.com>
Change-Id: I8c3d19f1e9a4e516d674d68989ad509f37e5b593
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52881
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
MT8195 also uses mt6359p so we can reuse most drivers.
The only differences are IO configuaration, clock setting, and PMIC
internal setting related to soc.
Reference datasheet: MT6315 datasheet v1.4.2.pdf, RH-D-2019-0616.
Reference datasheet: MT6359_PMIC_Data_Sheet_V1.5.docx, RH-D-2018-0205.
Change-Id: I73f9c9bf92837f262c15758f16dacf52261dd3a3
Signed-off-by: Henry Chen <henryc.chen@mediatek.com>
Signed-off-by: Yidi Lin <yidi.lin@mediatek.com>
Signed-off-by: Rex-BC Chen <rex-bc.chen@mediatek.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52668
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
If device is supported as a wake source, _S0W should be set to D3hot.
This ensures that the device is put into D3hot by the OSPM.
Power resource(PRIC) for the device is listed in both _PR0 and _PR3. Thus, it ensures that the OSPM does not turn off power resource when device is put into D0 and D3hot. Hence, it is capable of waking the system from D3hot state. However, if it is put into D3cold, then the power resource is turned off by the OSPM.
The devices we are currently looking at for touchscreen/touchpad
do not really support auxiliary power and so do not support wake from D3cold.
BUG=b:186070097
TEST=build and check device wake state _S0W set to 3 in ssdt table.
Change-Id: I34e4b2350875530d3337be700276bcc4fb1f810a
Signed-off-by: Tony Huang <tony-huang@quanta.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52847
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Using PAD_WAKE is actually wrong. The wake bits are only supposed to be
set when using the GPIO controller to wake the system. coreboot's
current architecture relies on using GPEs to wake the system.
BUG=b:186011392
TEST=none
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: Ib956fc299fe21cd7ea0b465cbdc5c8da830a668d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52802
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: EricR Lai <ericr_lai@compal.corp-partner.google.com>
The usage of `pci_devfn_t` here is misleading, as these intentionally
store the `PCH_DEVFN_*` macros so they can be used across `smm` and
`ramstage` without requiring the device model. Update to `unsigned int`
instead, as `pci_devfn_t` implies the data is an MMCONF-compatible PCI
devfn offset.
Change-Id: Ic8880de984e6eceda4cbe141e118f3a5fdd672a2
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52808
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
With the recent switch to SMM module loader v2, the size of the SMM for
module google/volteer increased to above 64K in size, and thus failed to
install the permanent SMM handler. Turns out, the devicetree is all
pulled into the SMM build because of elog, which calls
`pci_dev_is_wake_source`, and is the only user of `struct device` in
SMM. Changing this function to take a pci_devfn_t instead allows the
linker to remove almost the entire devicetree from SMM (only usage left
is when disabling HECI via SMM).
BUG=b:186661594
TEST=Verify loaded program size of `smm.elf` for google/volteer is
almost ~50% smaller.
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Change-Id: I4c39e5188321c8711d6479b15065e5aaedad8f38
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52765
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Add a Kconfig option to set the keyboard translation state on exit and
set the default to true. This restores the keyboard to the power-up
defaults for firmware that does not always run libpayload keyboard init
to have consistent state, and provides an option to disable translation
for keyboards that might need it.
Change-Id: I25dfe3f425a5bb57e97476564886672b707aa3bd
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52737
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
While building adlrvp board with chromeos.fmd and adding all chromeos
related artifacts, RO region is running out of space. Also, we need
to increase RW region size to accommodate all binaries and artifacts.
Aligning chromeos.fmd with Brya will help in solving this issue, thus
aligning chromeos.fmd with Brya.
BUG=b:184997582
BRANCH=NONE
TEST=Code compiles fine and able to boot adlrvp platform
Change-Id: I644e2e5ba06d2b816d413a7cc9f5f248d8a6fee8
Signed-off-by: Maulik V Vaghela <maulik.v.vaghela@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52732
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Kconfig change which enables the hwp cppc acpi support is to get the
maximum performance of each CPU to check and enable Intel Turbo Boost
Max Technology.
BUG=none
BRANCH=none
TEST=check GCPC and CPC generated in acpi tables for each CPU
Change-Id: I5d93774e8025466f1911cf77459910fe872bfcc8
Signed-off-by: ravindr1 <ravindra@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51795
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Sooner or later, some board was going to need extra FW_CONFIG bits for
a field that was already in production, so this patch adds support for
adding extra (unused) bits to a field.
The extra are appended via a syntax like:
`field FIELD_NAME START0 END0 | START1 END1 | START2 END2 ...`
and the suffixed bits are all treated as if they are contiguous when
defining option values.
BUG=b:185190978
TEST=Modified volteer fw_config to the following:
field AUDIO 8 10 | 29 29 | 31 31
option NONE 0
option MAX98357_ALC5682I_I2S 1
option MAX98373_ALC5682I_I2S 2
option MAX98373_ALC5682_SNDW 3
option MAX98373_ALC5682I_I2S_UP4 4
option MAX98360_ALC5682I_I2S 5
option RT1011_ALC5682I_I2S 6
option AUDIO_FOO 7
option AUDIO_BAR 8
option AUDIO_QUUX 9
option AUDIO_BLAH1 10
option AUDIO_BLAH2 15
option AUDIO_BLAH3 16
option AUDIO_BLAH4 31
end
which yielded (in static_fw_config.h):
FW_CONFIG_FIELD_AUDIO_MASK 0xa0000700
FW_CONFIG_FIELD_AUDIO_OPTION_NONE_VALUE 0x0
FW_CONFIG_FIELD_AUDIO_OPTION_MAX98357_ALC5682I_I2S_VALUE 0x100
FW_CONFIG_FIELD_AUDIO_OPTION_MAX98373_ALC5682I_I2S_VALUE 0x200
FW_CONFIG_FIELD_AUDIO_OPTION_MAX98373_ALC5682_SNDW_VALUE 0x300
FW_CONFIG_FIELD_AUDIO_OPTION_MAX98373_ALC5682I_I2S_UP4_VALUE 0x400
FW_CONFIG_FIELD_AUDIO_OPTION_MAX98360_ALC5682I_I2S_VALUE 0x500
FW_CONFIG_FIELD_AUDIO_OPTION_RT1011_ALC5682I_I2S_VALUE 0x600
FW_CONFIG_FIELD_AUDIO_OPTION_AUDIO_FOO_VALUE 0x700
FW_CONFIG_FIELD_AUDIO_OPTION_AUDIO_BAR_VALUE 0x20000000
FW_CONFIG_FIELD_AUDIO_OPTION_AUDIO_QUUX_VALUE 0x20000100
FW_CONFIG_FIELD_AUDIO_OPTION_AUDIO_BLAH1_VALUE 0x20000200
FW_CONFIG_FIELD_AUDIO_OPTION_AUDIO_BLAH2_VALUE 0x20000700
FW_CONFIG_FIELD_AUDIO_OPTION_AUDIO_BLAH3_VALUE 0x80000000
FW_CONFIG_FIELD_AUDIO_OPTION_AUDIO_BLAH4_VALUE 0xa0000700
Change-Id: I5ed76706347ee9642198efc77139abdc3af1b8a6
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52747
Reviewed-by: Duncan Laurie <duncan@iceblink.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
