List of changes:
1. Define new configs for Opregion versions.
2. Assign RVDA to relative address of the Opregion buffer
in case of opregion 2.1+.
BUG=b:190019970
BRANCH=None
Signed-off-by: Meera Ravindranath <meera.ravindranath@intel.com>
Change-Id: I95a9f3df185002a4e38faa910f867ace0b97ac2b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52758
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
The Fast Read Dual Output and Fast Read Dual I/O commands are
practically identical, the only difference being how the read address is
transferred (saving a whooping 2 bytes which is totally irrelevant for
the amounts of data coreboot tends to read). We originally implemented
Fast Read Dual Output since it's the older command and some older
Winbond chips only supported that one... but it seems that some older
Macronix parts for whatever reason chose to only support Fast Read Dual
I/O instead. So in order to make this work for as many parts as
possible, I guess we'll have to implement both. (Also, the Macronix
device ID situation is utter madness with different chips with different
capabilities often having the same ID, so we basically have to make a
best-effort guess to strike a trade-off between fast speeds and best
chance at supporting all chips. If this turns out to be a problem later,
we may have to add Kconfig overrides for this or resort to SFDP parsing,
although that would defeat the whole point of trying to be fast.)
BUG=b:193486682
TEST=Booted CoachZ (with Dual I/O)
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: Ia1a20581f251615127f132eadea367b7b66c4709
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56287
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
A regular assignment works just as well and also allows type-checking.
It also avoids a common mistake where `sizeof` is applied to a pointer
to obtain the size of the data it points to, without dereferencing it.
Found-by: Coverity CID 1458231
Change-Id: I7ed05322c3c911f3da4145f81e4d9760a275fec2
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56265
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Since initial_lapicid() returns an unsigned int, change the type of the
local variables the return value gets assigned to to unsigned int as
well if applicable. Also change the printk format strings for printing
the variable's contents to %u where it was %d before.
Change-Id: I289015b81b2a9d915c4cab9b0544fc19b85df7a3
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55063
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This reverts commit ce0e2a0140 which was
originally introduced as a workaround for the bug that the Linux kernel
doesn't know what to do with type 16 memory region in the e820 table
where CBMEM resides and disallowed accessing it. After depthcharge was
patched to mark the type 16 region as a normal reserved region, the
Linux kernel now can access the BERT region and print BERT errors. When
SeaBIOS was used as payload it already marked the memory region
correctly, so it already worked in that case.
After commit 8c3a8df102 that removed the
usage of the BERT memory region reserved by the FSP driver by the AMD
Picasso and Cezanne SoCs and made them use CBMEM for the BERT region,
no other SoC code uses this functionality. The Intel Alderlake and
Tigerlake SoCs put the BERT region in CBMEM and never used this reserved
memory region and the change for the Intel server CPU to use this was
abandoned and never landed in upstream coreboot. AMD Stoneyridge is the
only other SoC/chipset that selects ACPI_BERT, but since it doesn't
select or use the FSP driver, it also won't be affected by this change.
TEST=Behavior of the BERT code doesn't change on Mandolin
Change-Id: I6ca095ca327cbf925edb59b89fff42ff9f96de5d
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56163
Reviewed-by: Jonathan Zhang <jonzhang@fb.com>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Currently, we get PLD information from USB port structure itself, so
devicetree does not need to fill PLD structure anymore. Thus remove
obsolete variable.
Change-Id: I7a561677ab65ddb870d1b00b35ee9d7a22ef9c70
Signed-off-by: Maulik V Vaghela <maulik.v.vaghela@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56025
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Since TBT controller can have maximum 2 ports per controller, our
code will loop over DFP structure twice and determine port number.
Retimer driver used to assign port number as below:
1. Check if power GPIO is assigned for particular DFP entry or not
2. If entry is there, assign loop count as port number
Since loop count is 2, retimer will never assign port number = 2
even if it's present. In case of more than 1 controller, port number
assigned will still be 0 or 1 even though actual port index might
be 2 or 3. This will create an issue where even if you do transaction
on device on controller 2 (port index 2 or 3), EC will route it on
port 0 or 1 due to incorrect port index.
Update the driver flow as per below to handle this scenario:
1. Check if power GPIO is assigned for particular DFP entry or not
2. Get USB port number from config since it's stored in usb port
information under devicetree
3. Pass the port number to ACPI SSDT and EC code
Above changes will ensure that we're assigning correct port
number as per calculation and EC will use correct port index.
BUG=b:189476816
BRANCH=None
TEST=Checked that retimer firmware update works on both ports and update
happens on correct port index.
Change-Id: Ib11637ae39046e0afdacd33bc34e8a59e6f2bfb1
Signed-off-by: Maulik V Vaghela <maulik.v.vaghela@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55945
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Create a separate function to get PLD information from USB device.
This is helpful in retimer driver where we can attach same USB
port information to retimer instance and we can avoid duplication
of information.
BUG=None
BRANCH=None
TEST=Check if code compiles and function returns correct value
Change-Id: Iaaf140ce1965dce3a812aa2701ce0e29b34ab3e7
Signed-off-by: Maulik V Vaghela <maulik.v.vaghela@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56024
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
This message is not an error, but just informational.
BUG=none
TEST=Boot with CONSOLE_LOGLEVEL_3 and no longer see it printed
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: Ifb64edbe029cafa82aec99aa50de47f51cd50dce
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55971
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
Currently the flow for opregion init is as below:
1. Allocate memory for opregion first (cbmem_add(opregion))
2. Check if VBT size > 6 KiB (this requires extended VBT support)
3. In case of extended VBT requirement, we allocate another chunk
of memory which is equal to size of VBT (cbmem_add(extended_vbt))
4. Pass physical address pointer to OS via RVDA
We can optimize the above flow to allocate single chunk of memory by
checking VBT size in earlier step. The new optimized flow for opregion
init is as below:
1. Check if VBT size > 6 KiB (this requires extended VBT support)
2. In case of extended VBT requirement, total memory to be allocated
is calculated as sizeof(opregion) + sizeof (extended_vbt)
In case where VBT size is < 6 KiB, total memory requirement would
be equal to sizeof(opregion)
3. Based on above calculation, allocate single chunk of memory based on
total size.
This will also be helpful for the case of virtualization where guest
users don't have access to physical address and when it needs relative
address of VBT compared to absolute address.
In case of opregion 2.1 spec, we need to pass relative address of
VBT from opregion base in RVDA. This optimization will help in meeting
this requirement since relative address of extended VBT is easy to get.
This change will ensure that it meets opregion specification
requirement and will be compatible with future versions as well.
BUG=b:190019970
BRANCH=None
TEST=check the address of extended VBT region and address is coming
correctly.
Change-Id: Ic0e255df63145409096b0b9312c6c51c05f49931
Signed-off-by: Maulik V Vaghela <maulik.v.vaghela@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55341
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
This adds OEM variables feature under DPTF as per BWG doc #541817. Using
this, platform vendors can expose an array of OEM-specific values as OEM
variables to be used in determining DPTF policy. These are obtained via
the ODVP method, and then simply exposed under sysfs. In addition, these
gets updated when a notification is received or when the DPTF policy is
changed by userspace.
BRANCH=None
BUG=b:187253038
TEST=Built and tested on dedede board
Change-Id: Iaf3cf7b40e9a441b41d0c659d76895a58669c2fb
Signed-off-by: Sumeet R Pawnikar <sumeet.r.pawnikar@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50127
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Now that the refactoring is complete, the unions for the table header
are no longer needed. Therefore, drop them.
Change-Id: I4e170e84a12646386d3fd84ae973dd6c18f25809
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55910
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Introduce the `smbios_full_table_len` function to consolidate table
length calculation. The case where the length of a table equals the
length of the structure happens when a table has no strings.
Change-Id: Ibc60075e82eb66b5d0b7132b16da000b153413f9
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55909
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Factor out some boilerplate code into a helper `smbios_carve_table`
function, which zeroes out the table memory and fills in the header
fields common to all tables.
Change-Id: Iece2f64f9151d3c79813f6264dfb3a92d98c2035
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55907
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Michał Żygowski <michal.zygowski@3mdeb.com>
All SMBIOS `type X` tables start with the same 4-byte header. Add a
struct definition for it, and use it where applicable. The union is
temporary and allows doing the necessary changes in smaller commits.
Change-Id: Ibd9a80010f83fd7ebefc014b981d430f5723808c
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55906
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Where applicable, use the size of the associated variable.
Change-Id: Ibbac2a82893232a6f87182a6a965b84a599d633e
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55904
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Where applicable, use the size of the associated variable.
Change-Id: Icf4f1c8fe9f54c44b041a65eb46d6ec9f9fd6367
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55902
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
gpio_num is used to indicate the GPIO which is taken from gpio_soc_defs.h file.
Support for dynamic generation of ASL file for Camera was added for JSL
when there were less than 256 GPIOs. ADL now has more GPIOs and therefore
uint8_t is not enough any more
Signed-off-by: Varshit B Pandya <varshit.b.pandya@intel.com>
Change-Id: I0a5fdb612c8cf689d356af8591b9ad101360c25d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55538
Reviewed-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-by: Maulik V Vaghela <maulik.v.vaghela@intel.com>
Reviewed-by: Ronak Kanabar <ronak.kanabar@intel.com>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add FSP_ARRAY_LOAD macro for checking and loading
array type configs into array type UPDs to increase readability.
Signed-off-by: Lean Sheng Tan <lean.sheng.tan@intel.com>
Change-Id: I307340a2bfc0a54f2ab7241af2f24dfbf8bb111d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55559
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch removes unnecessary __packed attribute from the structure
defined in chip.h
BUG=None
TEST=Tested WFC camera on Brya
Change-Id: I1174606cd22cd353f01d865d0c25bb6f8f8de055
Signed-off-by: Sugnan Prabhu S <sugnan.prabhu.s@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55566
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Varshit B Pandya <varshit.b.pandya@intel.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
APIC Serial Bus pins were removed with ICH5 already, so a choice
'irq_on_fsb = 0' would not take effect. The related register BOOT_CONFIG
0x3 is also not documented since ICH5.
For emulation/qemu-q35 with ICH9 the choice INTERRUPT_ON_APIC_BUS was
wrong and ignored as BOOT_CONFIG register emulation was never implemented.
For ICH4 and earlier, the choice to use FSB can be made based on the
installed CPU model but this is now just hardwired to match P4 CPUs of
aopen/dxplplusu.
For sb/intel/i82371eb register BOOT_CONFIG 0x3 is also not defined
and the only possible operation mode there is APIC Serial Bus, which
requires no configuration.
Change-Id: Id433e0e67cb83b44a3041250481f307b2ed1ad18
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55257
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Restructuring opregion VBT related code to make it more generalize
for future revision of opregion spec.
Moved logic to locate VBT from different region (CBMEM, PCI option
ROM or VBIOS) into separate function.
Created a new function to check if extended VBT region is required.
This will be helpful in the subsequent changes to determine if
extended VBT region is needed and handle memory allocation
accordingly.
BUG=None
BRANCH=None
TEST=check the address of extended VBT region and address is coming
correctly.
Change-Id: I479d57cd326567192a3cd1969f8125ffe1934399
Signed-off-by: MAULIK V VAGHELA <maulik.v.vaghela@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55318
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
The loads of the FSPM and FSPS binaries are not insignificant amounts of
time, and without these timestamps, it's not clear what's going on in
those time blocks. For FSPM, the timestamps can run together to make it
look like that time is still part of the romstage init time.
Example:
6:end of verified boot 387,390 (5,402)
13:starting to load romstage 401,931 (14,541)
14:finished loading romstage 420,560 (18,629)
970:loading FSP-M 450,698 (30,138)
15:starting LZMA decompress (ignore for x86) 464,173 (13,475)
16:finished LZMA decompress (ignore for x86) 517,860 (53,687)
...
9:finished loading ramstage 737,191 (18,377)
10:start of ramstage 757,584 (20,393)
30:device enumeration 790,382 (32,798)
971:loading FSP-S 840,186 (49,804)
15:starting LZMA decompress (ignore for x86) 853,834 (13,648)
16:finished LZMA decompress (ignore for x86) 888,830 (34,996)
BUG=b:188981986
TEST=Build & Boot guybrush, look at timestamps.
Signed-off-by: Martin Roth <martinroth@chromium.org>
Change-Id: I5796d4cdd512799c2eafee45a8ef561de5258b91
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52867
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
This driver was inspired from soc/intel/common/block/pci/rtd3. I decided
to copy and modify it because the Intel driver has a lot of Intel
specific code.
This driver has been stripped down to only provide a power resource and
set the StorageD3Enable property. This driver is SoC agnostic and does
not handle suspending the actual PCIe root port. That should be
implemented by an SoC specific driver.
This is required for Guybrush to suspend/resume properly because the
NVMe power is tied to the S0 power rails, so the kernel needs to place
the device into D3.
BUG=b:184617186
TEST=Guybrush is able to suspend/resume properly. Also see power
resource get enabled / disabled.
[ 56.075559] power-0416 __acpi_power_off : Power resource [RTD3] turned off
[ 56.075562] device_pm-0279 device_set_power : Device [PXSX] transitioned to D3cold
[ 56.075567] pci_pm_suspend_noirq: nvme 0000:02:00.0: PCI PM: Suspend power state: D3cold
[ 56.075569] nvme 0000:02:00.0: pci_pm_suspend_noirq+0x0/0x413 returned 0 after 15978 usecs
[ 123.464874] nvme 0000:02:00.0: calling pci_pm_resume_noirq+0x0/0x11d @ 7, parent: 0000:00:02.4
[ 123.464891] acpi_device_set_power: ACPI: \_SB_.PCI0.GP14.PXSX: Power state change: D3cold -> D0
[ 123.464982] power-0360 __acpi_power_on : Power resource [RTD3] turned on
[ 123.464984] device_pm-0279 device_set_power : Device [PXSX] transitioned to D0
[ 123.465039] nvme 0000:02:00.0: pci_pm_resume_noirq+0x0/0x11d returned 0 after 158 usecs
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I2adfc925183ff7a19ab97e89212bc87c40d552d0
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54966
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Since the OS provides its own driver for the I2C controller it can
choose to use a bus speed other than the one used at coreboot runtime.
In this case it would be good to provide a way how the needed bus
timings are communicated to the OS, since these are very board-specific
and there is no way that the OS can know them other than read the
appropriate ACPI reported timings.
This patch adds some code to report additional bus speed timings if
there are some defined in the devicetree.
Change-Id: If921e0613864660dc1bb8d7c1b30fb9db8ac655d
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55088
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Mario Scheithauer <mario.scheithauer@siemens.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
As per the comments in CB:54090 mainboard api
mainboard_tcss_get_port_info() is simplified and moved to tcss common
block code.
Signed-off-by: Deepti Deshatty <deepti.deshatty@intel.com>
Change-Id: I7894363df4862f7cfe733d93e6160677fb8a9e31
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54733
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: EricR Lai <ericr_lai@compal.corp-partner.google.com>
This will be used to pass information to driver through ACPI in devicetree.
Example https://review.coreboot.org/c/coreboot/+/52013
register "clk_panel.clks[0].clknum" = "IMGCLKOUT_3"
register "clk_panel.clks[0].freq" = "FREQ_19_2_MHZ"
TEST=Add these macros in devicetree, build and check static.c for consistency
Signed-off-by: Varshit B Pandya <varshit.b.pandya@intel.corp-partner.google.com>
Change-Id: Ia4137e09c934bf06857ceedb933e616bed5070dd
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55097
Reviewed-by: Maulik V Vaghela <maulik.v.vaghela@intel.com>
Reviewed-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Rizwan Qureshi <rizwan.qureshi@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
There are cases where the RTC_VRT bit in register D stays set after a
power failure while the real date and time registers can contain rubbish
values (can happen when RTC is not buffered). If we do not detect this
invalid date and/or time here and keep it, Linux will use these bad
values for the initial timekeeper init. This in turn can lead to dates
before 1970 in user land which can break a lot assumptions.
To fix this, check date and time sanity when the RTC is initialized and
reset the values if needed.
Change-Id: I5bc600c78bab50c70372600347f63156df127012
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54914
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
In commit b64db833d6 a basic ACPI support was added to the driver.
With this support an SSDT-entry is created for this RTC and it is now
visible to the OS via ACPI. In Linux the PNP-devices, which are
reported over ACPI, are scanned rather early and if the entry is found,
the device is claimed even if there is no driver available yet.
In this case, when the native RTC-driver without ACPI-support is loaded
and tries to register this device, the RTC is already blocked by the
PNP-drivers and cannot be used anymore. This leads to a non-usable RTC
on kernels where the needed ACPI-extension is not yet merged into the
RTC driver.
This patch provides a way to disable the ACPI-support for the RTC if
needed.
Change-Id: Ic65794d409d13a78d17275c86ec14ee6f04cd2a6
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55003
Reviewed-by: Mario Scheithauer <mario.scheithauer@siemens.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
fsp_temp_ram_exit() function is only getting called by
late_car_teardown() function inside temp_ram_exit.c file.
Hence, make function as static and removed from include/fsp/api.h.
Change-Id: I2239400e475482bc21f771d41a5ac524222d40fc
Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55025
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
The only FSP 1.1 platform is Braswell. Drop unnecessary functions which
only have a weak stub definition.
Change-Id: Ie60213e5a6ae67bd8b982ee505f4b512253577c6
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54957
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The only FSP 1.1 platform is Braswell, which has a non-weak definition
for the `soc_silicon_init_params` function. This changes the resulting
BUILD_TIMELESS=1 coreboot image for Facebook fbg1701, for some reason.
Change-Id: I2a1b51cda9eb21d7af8372c16a43195a4bdd9543
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54956
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
The only FSP 1.1 platform is Braswell. Drop unused weak definitions for
functions where a non-weak definition always exists.
Tested with BUILD_TIMELESS=1, Facebook fbg1701 remains identical.
Change-Id: Ifaf40a1cd661b123911fbeaafeb2b7002559a435
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54955
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Commit 736a1028fb (drivers/intel/fsp1_1:
Drop dead MMA code) dropped FSP 1.1 MMA code, but missed a few things.
Change-Id: I556e7125eff21c49609bb1e5e1f23e99e692756f
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54954
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
No board uses AMD PI 00630F01, so drop it. And drop a single reference
to the now-removed `NORTHBRIDGE_AMD_PI_00630F01` Kconfig option inside
the `drivers/amd/agesa/acpi_tables.c` file.
Change-Id: Ibc45a4a6041220ed22273c1d41f9b796e1acb901
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54897
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Prepare to allow using other backends to store options.
Change-Id: I3f838d27bf476207c6dc8f2c1f15c3fa9ae47d87
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54727
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Added SW_MUTE_DEVICE event type for mic mute switch.
BUG=b:184593945
BRANCH=puff
TEST=build image and verify with evtest on puff:
/dev/input/event3: mic_mute_switch
UI event_device_info receives the proper name.
Change-Id: I09c52dc3df63e266c73741b102a22f8a2b896791
Signed-off-by: Ben Zhang <benzh@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54689
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Added the label field to the gpio_keys _DSD so that the kernel driver
can use a meaningful name instead of the generic _HID PRP0001.
BUG=b:184593945
BRANCH=puff
TEST=build image and verify with evtest on puff:
/dev/input/event3: mic_mute_switch
UI event_device_info receives the proper name.
Change-Id: I0377851b9cf23bab31930aed6e7de91b4ac3505b
Signed-off-by: Ben Zhang <benzh@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54332
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Along with upstream kernel for Retimer firmware upgrade, coreboot
provides DFPx under host router where each DFP has its PLD and DSM. The
DFPx's functions encapsulates power control through GPIO, PD
suspend/resume and modes setting for Retimer firmware update under NDA
scenario.
BUG=b:186521258
TEST=Booted to kernel and validated host router's DFPx properties after
decomposing SSDT table.
Signed-off-by: John Zhao <john.zhao@intel.com>
Change-Id: I81bef80729f6df57119f5523358620cb015e5406
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52712
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
HSBIAS_SENSE_EN configures HSBIAS output current sense through
the external 2.21-k resistor. HSBIAS_SENSE is hardware feature to reduce
the potential pop noise during the headset plug out slowly. But on some
platforms ESD voltage will affect it causing test to fail, especially
with CTIA headset type. For different hardware setups, a designer might
want to tweak default behavior.
Signed-off-by: Vitaly Rodionov <vitaly.rodionov@cirrus.corp-partner.google.com>
Change-Id: I87c6f01af1bdb5b1cb8e399191519598d7fbe9ea
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52981
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
