summaryrefslogtreecommitdiff
path: root/src/drivers/intel
AgeCommit message (Collapse)Author
2021-02-06drivers/intel/fsp2_0: Add support for MP services2 PPIAamir Bohra
Add support for MP services2 PPIs, which is slight modification over MP services 1 PPIs. A new API StartupAllCPUs have been added to allow running a task on BSP and all APs. Also the EFI_PEI_SERVICES parameter has been removed from all MP PPI APIs. This implementation also selects the respective MP services PPI version supported for SoCs BUG=b:169196864 Change-Id: Id74baf17fb90147d229c78be90268fdc3ec1badc Signed-off-by: Aamir Bohra <aamir.bohra@intel.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/49474 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Furquan Shaikh <furquan@google.com>
2021-02-06intel: Rename config FSP_USES_MP_SERVICES_PPI to MP_SERVICES_PPIFurquan Shaikh
This change renames config FSP_USES_MP_SERVICES_PPI to MP_SERVICES_PPI in preparation to allow V1 and V2 versions of MP services PPI. TEST=Verified that timeless build for brya, volteer, icelake_rvp, elkhartlake_crb and waddledee shows no change in generated coreboot.rom Change-Id: I04acf1bc3a3739b31d6e9d01b6aa97542378754f Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/50275 Reviewed-by: Aamir Bohra <aamir.bohra@intel.com> Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org> Reviewed-by: Subrata Banik <subrata.banik@intel.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2021-02-06intel: Drop FSP_PEIM_TO_PEIM_INTERFACEFurquan Shaikh
This change drops the config FSP_PEIM_TO_PEIM_INTERFACE. FSP_PEIM_TO_PEIM_INTERFACE is used for: * Auto-selecting FSP_USES_MP_SERVICES_PPI * Including src/drivers/intel/fsp2_0/ppi/Kconfig * Adding ppi to subdirs-y * Setting USE_INTEL_FSP_TO_CALL_COREBOOT_PUBLISH_MP_PPI to y and is selected by SoCs that want to enable MP PPI services. Instead of using the indirect path of selecting MP PPI services, this change allows SoC to select FSP_USES_MP_SERVICES_PPI directly. The above uses are handled as follows: * Auto-selecting FSP_USES_MP_SERVICES_PPI --> This is handled by SoC selection of FSP_USES_MP_SERVICES_PPI. * Including src/drivers/intel/fsp2_0/ppi/Kconfig --> The guard isn't really required. The Kconfig options in this file don't present user prompts and don't really need to be guarded. * Adding ppi to subdirs-y --> Makefile under ppi/ already has conditional inclusion of files and does not require a top-level conditional. * Setting USE_INTEL_FSP_TO_CALL_COREBOOT_PUBLISH_MP_PPI to y --> This is set to y if FSP_USES_MP_SERVICES_PPI is selected by SoC. TEST=Verified that timeless build for brya, volteer, icelake_rvp, elkhartlake_crb and waddledee shows no change in generated coreboot.rom Change-Id: I0664f09d85f5be372d19925d47034c76aeeef2ae Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/50274 Reviewed-by: Aamir Bohra <aamir.bohra@intel.com> Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org> Reviewed-by: Subrata Banik <subrata.banik@intel.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2021-02-04drivers/intel/fsp2_0: Fix running on x86_64Patrick Rudolph
Add new Kconfig symbols to mark FSP binary as x86_32. Fix the FSP headers and replace void pointers by fixed sized integers depending on the used mode to compile the FSP. This issue has been reported here: https://github.com/intel/FSP/issues/59 This is necessary to run on x86_64, as pointers have different size. Add preprocessor error to warn that x86_64 FSP isn't supported by the current code. Tested on Intel Skylake. FSP-M no longer returns the error "Invalid Parameter". Change-Id: I6015005c4ee3fc2f361985cf8cff896bcefd04fb Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/48174 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
2021-02-04src: Remove useless comments in "includes" linesElyes HAOUAS
Change-Id: Ide5673dc99688422c5078c8c28ca5935fd39c854 Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/50186 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
2021-02-01drivers/intel/fsp2_0: Use CBFS_MCACHE when coreboot tears down CARArthur Heymans
TESTED on ocp/tiogapass. Change-Id: I30560149eeaec62af4c8a982815618be5546531c Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/49877 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
2021-02-01drivers/intel/fsp2_0: Use coreboot postcar with FSP-TArthur Heymans
Allow platforms to use the coreboot postcar code instead of calling into FSP-M TempRamExit API. There are several reasons to do this: - Tearing down CAR is easy. - Allows having control over MTRR's and caching in general. - The MTRR's set up in postcar be it by coreboot or FSP-M are overwritten later on during CPU init so it does not matter. - Avoids having to find a CBFS file before cbmem is up (this causes problems with cbfs_mcache) Change-Id: I6cf10c7580f3183bfee1cd3c827901cbcf695db7 Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/48466 Reviewed-by: Patrick Georgi <pgeorgi@google.com> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2021-01-30drivers/intel/fsp2_0: factor out and improve UPD signature checkFelix Held
In case of a mismatch print both the UPD signature in the FSP and the expected signature and then calls die(), since it shouldn't try calling into the wrong FSP binary for the platform. Signed-off-by: Justin Frodsham <justin.frodsham@protonmail.com> Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I469836e09db6024ecb448a5261439c66d8e65daf Reviewed-on: https://review.coreboot.org/c/coreboot/+/50090 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com> Reviewed-by: Furquan Shaikh <furquan@google.com>
2021-01-29stage_cache: Add resume_from_stage_cache()Kyösti Mälkki
Factor out the condition when an attempt to load stage from cache can be tried. Change-Id: I936f07bed6fc82f46118d217f1fd233e2e041405 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/50000 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
2021-01-29drivers/intel/fsp1_1: Drop s3_resume parameter to load_vbt()Kyösti Mälkki
Change-Id: Iaba88026906132b96fe3db3f05950df0e7eef896 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/50002 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
2021-01-29intel/fsp1_1: Declare fsp_load() as staticKyösti Mälkki
The function has only one local call-site. Change-Id: I623953796e6cd3a8e5b4f72293d953b61f14a5a1 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/49999 Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2021-01-25drivers/intel/fsp2_0/header_display.c: Correct component_attribute checkBenjamin Doron
According to FSP_INFO_HEADER structure in FSP EAS v2.0-v2.2, BIT1 indicates an "official" build. Change-Id: I94df6050a1ad756bbeff60cda0ebac76ae5f8249 Signed-off-by: Benjamin Doron <benjamin.doron00@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/49650 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
2021-01-24drivers/intel/gma/opregion.c: Use __func__Elyes HAOUAS
Change-Id: Ia45825ade0c9d24d5b87882e21bfc6df82a693e6 Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/49550 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Singer <felixsinger@posteo.net> Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
2021-01-24arch/x86/car.ld: Account for FSP-T reserved areaArthur Heymans
Tested - on ocp/deltalake: boots (with FSP-T). - qemu/i440fx: BUILD_TIMELESS=1 results in the same binary. Change-Id: I7e364ab039b65766eb95538db6b3507bbfbfb487 Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/49084 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
2021-01-23drivers/intel/fsp2_0: Add meaningful ERROR messageSubrata Banik
Add the "ERROR:" tag so that it ease debug effect. TEST=Test tools like "suspend_stress_test" (specific to Chrome OS) can identify the obvious coreboot ERROR prior running S3 resume test. Change-Id: I64717ce0412d43697f42ea2122b932037d28dd48 Signed-off-by: Subrata Banik <subrata.banik@intel.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/49798 Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org> Reviewed-by: Furquan Shaikh <furquan@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2021-01-22drivers/intel/usb4: Enable retimer FW upgrade mux interactionBrandon Breitenstein
In order to update the BB retimers for usb4/tbt they need to be turned on and into TBT mode. Expand the current DSM to allow for the use of an EC RAM byte RFWU to get the current state of each port and whether or not it has a retimer. It also allows Kernel to issue state transitions for the retimer to be put into TBT mode for firmware update. BUG=b:162528867 TEST=Along with work in progress kernel and EC patches, the Retimer firmware update is verified under device attached and no device attached scenarios. Change-Id: I768cfb56790049c231173b0ea0f8e08fe6b64b93 Signed-off-by: Brandon Breitenstein <brandon.breitenstein@intel.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/48630 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
2021-01-21drivers/intel/fsp1_1/temp_ram_exit.c: Initialize CBMEMFrans Hendriks
prog_locate() will load FSP, before CBMEM is initialized. The vboot workbuffer is used for loading, but CBMEM_ID_VBOOT_WORKBUF is not available. A NULL pointer is returned as workbuffer resulting in error 'Ramstage was not loaded!' at second boot. Initialize CBMEM before calling prog_locate(). BUG = N/A TEST = Build and boot on Facebook FBG1701 Change-Id: I2f04a326a95840937b71f6ad65a7c011268ec6d6 Signed-off-by: Frans Hendriks <fhendriks@eltan.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/49639 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
2021-01-18drivers/intel/gma/intel_bios.h: Remove repeated wordElyes HAOUAS
Change-Id: I5866a5e3240e49119e29f728202b33dd82ceaf77 Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/49514 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Jacob Garber <jgarber1@ualberta.ca>
2021-01-07arch/x86: Move prologue to .init sectionKyösti Mälkki
For arch/x86 the realmode part has to be located within the same 64 KiB as the reset vector. Some older intel platforms also require 4 KiB alignment for _start16bit. To enforce the above, and to separate required parts of .text without matching *(.text.*) rules in linker scripts, tag the pre-C environment assembly code with section .init directive. Description of .init section for ELF: This section holds executable instructions that contribute to the process initialization code. When a program starts to run, the system arranges to execute the code in this section before calling the main program entry point (called main for C programs). Change-Id: If32518b1c19d08935727330314904b52a246af3c Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/47599 Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2021-01-03drivers/intel/gma: add macro for one internal panel in gfx structMichael Niewöhner
Add a new macro `GMA_DEFAULT_PANEL(ssc)` as shortcut for specifying one internal panel at port A (0) in the devicetree. Change-Id: I5308b53667657d0b255ae5bc543f1a00431f5818 Signed-off-by: Michael Niewöhner <foss@mniewoehner.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/49054 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
2021-01-01nb/intel/hsw,soc/intel/{bdw,skl,apl},mb/*: unify dt panel settingsMichael Niewöhner
There are multiple different devicetree setting formats for graphics panel settings present in coreboot. Replace the ones for the platforms that already have (mostly) unified gma/graphics setup code by a unified struct in the gma driver. Hook it up in HSW, BDW, SKL, and APL and adapt the devicetrees accordingly. Always ensure that values don't overflow by applying appropriate masks. The remaining platforms implementing panel settings (GM45, i945, ILK and SNB) can be migrated later after unifying their gma/graphics setup code. Signed-off-by: Michael Niewöhner <foss@mniewoehner.de> Change-Id: I445defe01d5fbf9a69cf05cf1b5bd6c7c2c1725e Reviewed-on: https://review.coreboot.org/c/coreboot/+/48885 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Nico Huber <nico.h@gmx.de>
2020-12-30drivers/intel/gma: Include gfx.asl by default for all platforms...Matt DeVillier
which select INTEL_GMA_ACPI. Rework brightness level includes and platform-level asl files to avoid duplicate device definition for GFX0. Include gfx.asl for Skylake/Kabylake, since all other soc/intel/common platforms already do. Adjust mb/51nb/x210 to prevent device redefinition. Some OSes (e.g. Windows, MacOS) require/prefer the ACPI device for the IGD to exist, even if ACPI brightness controls are not utilized. This change adds a GFX0 ACPI device for all boards whose platforms select INTEL_GMA_ACPI without requiring non-functional brightness controls to be added at the board level. Change-Id: Ie71bd5fc7acd926b7ce7da17fbc108670fd453e0 Signed-off-by: Matt DeVillier <matt.devillier@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/48862 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
2020-12-30soc/intel/common: Move gfx.asl to drivers/intel/gmaMatt DeVillier
Adjust platform-level includes as needed. Change-Id: I376349ccddb95c166f0836ec1273bb8252c7c155 Signed-off-by: Matt DeVillier <matt.devillier@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/48959 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
2020-12-30soc/intel/cnl: add Kconfig values for GMA backlight registersMichael Niewöhner
Add the right register values for backlight control to CNL's Kconfig. To make iasl happy about the reversed register order, split the field. Change-Id: I05a06cc42397c202df9c9a1ebc72fb10da3b10ec Signed-off-by: Michael Niewöhner <foss@mniewoehner.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/48772 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
2020-12-28drivers/intel/gma: drop unused register to resolve name conflictMichael Niewöhner
The register `ESR` conflicts with the `Exception syndrome register` in UDK2017. To resolve the conflict, drop the unused `ESR` register from gma registers. It can be readded and prefixed or renamed if it's required at a later point. Change-Id: Icfdd834aea59ae69639a180221f5e97170fbac15 Signed-off-by: Michael Niewöhner <foss@mniewoehner.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/48758 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Matt DeVillier <matt.devillier@gmail.com> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
2020-12-28drivers/libgfxinit: Add Comet Lake to supported platformsFelix Singer
Signed-off-by: Felix Singer <felixsinger@posteo.net> Change-Id: I002ade555c0544e4ef738c1ad45ee3d8aa38e03e Reviewed-on: https://review.coreboot.org/c/coreboot/+/40720 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Michael Niewöhner <foss@mniewoehner.de> Reviewed-by: Nico Huber <nico.h@gmx.de> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
2020-12-283rdparty/libgfxinit: Update for Cannon Point supportNico Huber
We missed that Cannon Point, the PCH usually paired with Coffee, Whiskey and Comet Lake, differs a bit from its predecessors. Hence, libgfxinit now has a new Kconfig setting for the PCH. Change-Id: I1c02c0d9abb7340aabe94185ee5e17ef4c2b0d36 Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/48764 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Michael Niewöhner <foss@mniewoehner.de> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
2020-12-21drivers/intel/fsp2_0: recreate FSP targets on config changeMichael Niewöhner
When a different FSP binary was chosen in menuconfig, the split fd files do not get updated. Thus, make them depend on `.config` to trigger a rebuild when the config changes. Signed-off-by: Michael Niewöhner <foss@mniewoehner.de> Change-Id: I54739eae50fa1a47bf8f3fe2e79334bc7f7ac3d6 Reviewed-on: https://review.coreboot.org/c/coreboot/+/48663 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de> Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
2020-12-14drivers: Replace multiple fill_lb_framebuffer with single instancePatrick Rudolph
Currently it's not possible to add multiple graphics drivers into one coreboot image. This patch series will fix this issue by providing a single API that multiple graphics drivers can use. This is required for platforms that have two graphic cards, but different graphic drivers, like Intel+Aspeed on server platforms or Intel+Nvidia on consumer notebooks. The goal is to remove duplicated fill_fb_framebuffer(), the advertisment of multiple independent framebuffers in coreboot tables, and better runtime/build time graphic configuration options. Replace all duplications of fill_fb_framebuffer and provide a single one in edid_fill_fb.c. Should not change the current behaviour as still only one graphic driver can be active at time. Change-Id: Ife507f7e7beaf59854e533551b4b87ea6980c1f4 Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/39003 Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Frans Hendriks <fhendriks@eltan.com> Reviewed-by: Christian Walter <christian.walter@9elements.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-12-10drivers/intel/fsp1_1/cache_as_ram.S: Correct commentFrans Hendriks
Stack is set up for bootblock. Tested on Facebook FBG1701. Change-Id: I0dd3fc91c90bf76e0d93925da35dc197d68d3e88 Signed-off-by: Frans Hendriks <fhendriks@eltan.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/47802 Reviewed-by: Wim Vervoorn <wvervoorn@eltan.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-12-05drivers/intel/fsp2_0/memory_init: Wrap calls into FSPPatrick Rudolph
Use a wrapper code that does nothing on x86_32, but drops to protected mode to call into FSP when running on x86_64. Tested on Intel Skylake when running in long mode. Successfully run the FSP-M which is compiled for x86_32 and then continued booting in long mode. Change-Id: I9fb37019fb0d04f74d00733ce2e365f484d97d66 Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/48202 Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-12-04drivers/intel/fsp2_0: FSP-T requires NO_CBFS_MCACHEArthur Heymans
When FSP-T is used, the first thing done in postcar is to call FSP-M to tear down CAR. This is done before cbmem is initialized, which means CBFS_MCACHE is not accessible, which results in FSP-M not being found, failing the boot. TESTED: ocp/deltalake boots again. Change-Id: Icb41b802c636d42b0ebeb3e3850551813accda91 Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/48282 Reviewed-by: Christian Walter <christian.walter@9elements.com> Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-12-02cbfs: Simplify load/map API names, remove type argumentsJulius Werner
This patch renames cbfs_boot_map_with_leak() and cbfs_boot_load_file() to cbfs_map() and cbfs_load() respectively. This is supposed to be the start of a new, better organized CBFS API where the most common operations have the most simple and straight-forward names. Less commonly used variants of these operations (e.g. cbfs_ro_load() or cbfs_region_load()) can be introduced later. It seems unnecessary to keep carrying around "boot" in the names of most CBFS APIs if the vast majority of accesses go to the boot CBFS (instead, more unusual operations should have longer names that describe how they diverge from the common ones). cbfs_map() is paired with a new cbfs_unmap() to allow callers to cleanly reap mappings when desired. A few new cbfs_unmap() calls are added to generic code where it makes sense, but it seems unnecessary to introduce this everywhere in platform or architecture specific code where the boot medium is known to be memory-mapped anyway. In fact, even for non-memory-mapped platforms, sometimes leaking a mapping to the CBFS cache is a much cleaner solution than jumping through hoops to provide some other storage for some long-lived file object, and it shouldn't be outright forbidden when it makes sense. Additionally, remove the type arguments from these function signatures. The goal is to eventually remove type arguments for lookup from the whole CBFS API. Filenames already uniquely identify CBFS files. The type field is just informational, and there should be APIs to allow callers to check it when desired, but it's not clear what we gain from forcing this as a parameter into every single CBFS access when the vast majority of the time it provides no additional value and is just clutter. Signed-off-by: Julius Werner <jwerner@chromium.org> Change-Id: Ib24325400815a9c3d25f66c61829a24a239bb88e Reviewed-on: https://review.coreboot.org/c/coreboot/+/39304 Reviewed-by: Hung-Te Lin <hungte@chromium.org> Reviewed-by: Wim Vervoorn <wvervoorn@eltan.com> Reviewed-by: Mariusz Szafrański <mariuszx.szafranski@intel.com> Reviewed-by: Patrick Georgi <pgeorgi@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-12-01drivers/intel/fsp2_0/notify: Fix compilation under x86_64Patrick Rudolph
Change-Id: Id63b9b372bf23e80e25b7dbef09d1b8bfa9be069 Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/48168 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
2020-11-30drivers/intel/fsp2_0: Remove console in weak functionArthur Heymans
This pollutes the log on all platforms not implementing an override. Change-Id: I0d8371447ee7820cd8e86e9d3d5e70fcf4f91e34 Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/48128 Reviewed-by: Frans Hendriks <fhendriks@eltan.com> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-11-30drivers/intel/i210: Request Bus Master in .final opsAngel Pons
Commit bd31642ad8 (intel/i210: Set bus master bit in command register) is only necessary because a buggy OS expects Bus Master to be set, not because the hardware requires Bus Master during initialization. It is thus safe to defer the Bus Master request into the .final callback. Change-Id: Iecfa6366eb4b1438fd12cd9ebb1a77ada97fa2f6 Signed-off-by: Angel Pons <th3fanbus@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/47401 Reviewed-by: Felix Held <felix-coreboot@felixheld.de> Reviewed-by: Felix Singer <felixsinger@posteo.net> Reviewed-by: Werner Zeh <werner.zeh@siemens.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Tested-by: siemens-bot
2020-11-30drivers/intel/i210: Define MAC_ADDR_LENAngel Pons
Define and use the MAC_ADDR_LEN macro in place of the `6` magic value. Change-Id: Icfa2ad9bca6668bea3d84b10f613d01e437ac6a2 Signed-off-by: Angel Pons <th3fanbus@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/47404 Tested-by: siemens-bot Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
2020-11-26drivers/intel/fsp2_0: move the FSP FD PATH option down in menuconfigMichael Niewöhner
Move the FSP FD PATH option down, so it gets shown in place of the split FD files, when the users chooses to use a full FD binary. Change-Id: Ie03a418fab30a908d020abf94becbaedf54fbb99 Signed-off-by: Michael Niewöhner <foss@mniewoehner.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/47999 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Furquan Shaikh <furquan@google.com> Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
2020-11-26drivers/intel/fsp2_0: introduce possibility of using a full FD binaryMichael Niewöhner
Currently, setting a custom FSP binary is only possible by using split FSP-T/M/S FD files. This change introduces the possibility to pass a combined FD file (the "standard" FSP format). This is done by adding a new boolean Kconfig FSP_FULL_FD, specifying that the FSP is a single FD file instead of split FSP-T/M/S FD files, and making FSP_FD_PATH user-visible when the option is chosen. In this case, the other options for split files get hidden. When the user chooses to use a full FD file instead of the split ones, the FD file gets split during build, just like it is done when selecting the Github FSP repo (FSP_USE_REPO). Test: Supermicro X11SSM-F builds and boots fine with custom FSP FD set. Signed-off-by: Michael Niewöhner <foss@mniewoehner.de> Change-Id: I1cb98c1ff319823a2a8a95444c9b4f3d96162a02 Reviewed-on: https://review.coreboot.org/c/coreboot/+/47993 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Furquan Shaikh <furquan@google.com> Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
2020-11-22drivers/intel/fsp1_1: Add function to report FSP-T outputFrans Hendriks
This allows to compare the FSP-T output in %ecx and %edx to coreboot's CAR symbols. Tested on Facebook FBG1701 Change-Id: Ice748e542180f6e1dc1505e7f37b6b6c68772bda Signed-off-by: Frans Hendriks <fhendriks@eltan.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/47758 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
2020-11-22src/drivers/intel/fsp1_1/cache_as_ram.S: Clear _bss area onlyFrans Hendriks
Whole car region is cleared, while only small part needs to be done. Clear .bss area only Tested on Facebook FBG1701 Change-Id: I021c2f7d3531c553015fde98d155915f897b434d Signed-off-by: Frans Hendriks <fhendriks@eltan.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/47760 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
2020-11-20intel/fsp2_0: Add soc_validate_fsp_version for FSP version checkJohnny Lin
Only need to check this once so check it at romstage where the console is usually ready. Also define union fsp_revision to avoid code duplication. Change-Id: I628014e05bd567462f50af2633fbf48f3dc412bc Signed-off-by: Johnny Lin <johnny_lin@wiwynn.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/47559 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Marc Jones <marc@marcjonesconsulting.com> Reviewed-by: Jonathan Zhang <jonzhang@fb.com>
2020-11-20drivers/intel/fsp1_1/cache_as_ram.S: Use _car_stack area for stackFrans Hendriks
Top of Temp RAM is used as bootloader stack, which is the _car_region_end area. This area is not equal to CAR stack area as defined in car.ld file. Use _ecar_stack (end of CAR stack) as starting stack location. Tested VBOOT, Vendorboot security and no security on Facebook FBG1701. Change-Id: I16b077f60560de334361b1f0d3758ab1a5cbe895 Signed-off-by: Frans Hendriks <fhendriks@eltan.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/47737 Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-by: Wim Vervoorn <wvervoorn@eltan.com> Reviewed-by: Michał Żygowski <michal.zygowski@3mdeb.com> Reviewed-by: Christian Walter <christian.walter@9elements.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-11-16src/drivers/intel: Correct Kconfig option in MakefileMartin Roth
This Kconfig option was just added incorrectly, so would never add the verstage.c file. Signed-off-by: Martin Roth <martin@coreboot.org> Change-Id: I4c39dca9d429ed786ea42c0d421d6ee815e8c419 Reviewed-on: https://review.coreboot.org/c/coreboot/+/47368 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Furquan Shaikh <furquan@google.com> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
2020-11-13mrc_cache: Move code for triggering memory training into mrc_cacheShelley Chen
Currently the decision of whether or not to use mrc_cache in recovery mode is made within the individual platforms' drivers (ie: fsp2.0, fsp1.1, etc.). As this is not platform specific, but uses common vboot infrastructure, the code can be unified and moved into mrc_cache. The conditions are as follows: 1. If HAS_RECOVERY_MRC_CACHE, use mrc_cache data (unless retrain switch is true) 2. If !HAS_RECOVERY_MRC_CACHE && VBOOT_STARTS_IN_BOOTBLOCK, this means that memory training will occur after verified boot, meaning that mrc_cache will be filled with data from executing RW code. So in this case, we never want to use the training data in the mrc_cache for recovery mode. 3. If !HAS_RECOVERY_MRC_CACHE && VBOOT_STARTS_IN_ROMSTAGE, this means that memory training happens before verfied boot, meaning that the mrc_cache data is generated by RO code, so it is safe to use for a recovery boot. 4. Any platform that does not use vboot should be unaffected. Additionally, we have removed the MRC_CLEAR_NORMAL_CACHE_ON_RECOVERY_RETRAIN config because the mrc_cache driver takes care of invalidating the mrc_cache data for normal mode. If the platform: 1. !HAS_RECOVERY_MRC_CACHE, always invalidate mrc_cache data 2. HAS_RECOVERY_MRC_CACHE, only invalidate if retrain switch is set BUG=b:150502246 BRANCH=None TEST=1. run dut-control power_state:rec_force_mrc twice on lazor ensure that memory retraining happens both times run dut-control power_state:rec twice on lazor ensure that memory retraining happens only first time 2. remove HAS_RECOVERY_MRC_CACHE from lazor Kconfig boot twice to ensure caching of memory training occurred on each boot. Change-Id: I3875a7b4a4ba3c1aa8a3c1507b3993036a7155fc Signed-off-by: Shelley Chen <shchen@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/46855 Reviewed-by: Furquan Shaikh <furquan@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-11-09drivers/intel/gma: Add Kconfig option for vbt data sizeSrinidhi N Kaushik
From Tigerlake FSP v3373 onwards vbt binary size changed from 8KiB to 9KiB. Commit cf5d58328fe004d967466be42de62d6bab4c3133 had changed the size from 8 to 9 Kib. This change adds Kconfig option to choose vbt data size based on platform. BUG=b:171401992 BRANCH=none TEST=build and boot delbin and verify fw screen is loaded Signed-off-by: Srinidhi N Kaushik <srinidhi.n.kaushik@intel.com> Change-Id: Ia294fc94ce759666fb664dfdb910ecd403e6a2e9 Reviewed-on: https://review.coreboot.org/c/coreboot/+/47151 Reviewed-by: Wonkyu Kim <wonkyu.kim@intel.com> Reviewed-by: Nico Huber <nico.h@gmx.de> Reviewed-by: Furquan Shaikh <furquan@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-11-09acpi: Call acpi_fill_ssdt() only for enabled devicesKarthikeyan Ramasubramanian
Individual drivers check whether the concerned device is enabled before filling in the SSDT. Move the check before calling acpi_fill_ssdt() and remove the check in the individual drivers. BUG=None TEST=util/abuild/abuild Change-Id: Ib042bec7e8c68b38fafa60a8e965d781bddcd1f0 Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/47148 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Furquan Shaikh <furquan@google.com> Reviewed-by: Sumeet R Pawnikar <sumeet.r.pawnikar@intel.com> Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Christian Walter <christian.walter@9elements.com>
2020-11-02soc/intel/common: Create common Intel FSP reset code blockSubrata Banik
Create SOC_INTEL_COMMON_FSP_RESET Kconfig to have IA common code block to handle platform reset request raised by FSP. The FSP will use the FSP EAS v2.0 section 12.2.2 (OEM Status Code) to indicate that a reset is required. Make FSP_STATUS_GLOBAL_RESET depends on SOC_INTEL_COMMON_FSP_RESET. Signed-off-by: Subrata Banik <subrata.banik@intel.com> Change-Id: I934b41affed7bb146f53ff6a4654fdbc6626101b Reviewed-on: https://review.coreboot.org/c/coreboot/+/47017 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
2020-11-02drivers/intel/fsp2_0: Add function to report FSP-T outputArthur Heymans
This allows to compare the FSP-T output in %ecx and %edx to coreboot's CAR symbols: Change-Id: I8d79f97f8c12c63ce215935353717855442a8290 Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/46884 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
2020-10-21drivers/intel/gma: Increase vbt_data sizeSrinidhi N Kaushik
With TGL FSP v3373 onwards vbt binary size changed from 8KiB to 9KiB. Due to which cbfsf_decompression_info check failed when trying to load vbt binary from cbfs because vbt decompressed_size was greater than vbt_data size. This caused Graphics init and fw screen issues. Increase the vbt_data to 9KiB to accommodate new vbt binary. BUG=b:170656067 BRANCH=none TEST=build and boot delbin and verify fw screen is loaded Signed-off-by: Srinidhi N Kaushik <srinidhi.n.kaushik@intel.com> Change-Id: If6ffce028f9e8bc14596bbc0a3f1476843a9334e Reviewed-on: https://review.coreboot.org/c/coreboot/+/46374 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Dossym Nurmukhanov <dossym@google.com> Reviewed-by: Nick Vaccaro <nvaccaro@google.com> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
2020-10-20mrc_cache: Move mrc_cache_*_hash functions into mrc_cache driverShelley Chen
This CL would remove these calls from fsp 2.0. Platforms that select MRC_STASH_TO_CBMEM, updating the TPM NVRAM space is moved from romstage (when data stashed to CBMEM) to ramstage (when data is written back to SPI flash. BUG=b:150502246 BRANCH=None TEST=make sure memory training still works on nami Change-Id: I3088ca6927c7dbc65386c13e868afa0462086937 Signed-off-by: Shelley Chen <shchen@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/46510 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Furquan Shaikh <furquan@google.com> Reviewed-by: Julius Werner <jwerner@chromium.org>
2020-10-20mrc_cache: Add config MRC_SAVE_HASH_IN_TPMShelley Chen
Use this config to specify whether we want to save a hash of the MRC_CACHE in the TPM NVRAM space. Replace all uses of FSP2_0_USES_TPM_MRC_HASH with MRC_SAVE_HASH_IN_TPM and remove the FSP2_0_USES_TPM_MRC_HASH config. Note that TPM1 platforms will not select MRC_SAVE_HASH_IN_TPM as none of them use FSP2.0 and have recovery MRC_CACHE. BUG=b:150502246 BRANCH=None TEST=emerge-nami coreboot chromeos-bootimage Change-Id: Ic5ffcdba27cb1f09c39c3835029c8d9cc3453af1 Signed-off-by: Shelley Chen <shchen@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/46509 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Furquan Shaikh <furquan@google.com>
2020-10-19security/vboot: Rename mem_init.h to mrc_cache_hash_tpm.hShelley Chen
As ongoing work for generalizing mrc_cache to be used by all platforms, we are pulling it out from fsp 2.0 and renaming it as mrc_cache_hash_tpm.h in security/vboot. BUG=b:150502246 BRANCH=None TEST=emerge-nami coreboot chromeos-bootimage Change-Id: I5a204bc3342a3462f177c3ed6b8443e31816091c Signed-off-by: Shelley Chen <shchen@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/46508 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Furquan Shaikh <furquan@google.com>
2020-10-19drivers/intel/usb4: Add driver for USB4 retimer deviceDuncan Laurie
The USB4 retimer device needs to declare a _DSM with specific functions that allow for GPIO control to turn off the power when an external device is not connected. This driver allows the mainboard to provide the GPIO that is connected to the power control. BUG=b:156957424 Change-Id: Icfb85dc3c0885d828aba3855a66109043250ab86 Signed-off-by: Duncan Laurie <dlaurie@google.com> Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org> Reviewed-on: https://review.coreboot.org/c/coreboot/+/44918 Reviewed-by: Angel Pons <th3fanbus@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-10-13drivers/{intel/wifi,wifi/generic}: Drop separate Intel WiFi driverFurquan Shaikh
Currently, drivers/intel/wifi is a PCI driver (provides `struct pci_driver`) as well as a chip driver (provides `struct chip_operations`). However, there is no need for a separate chip driver for the WiFi device since drivers/wifi/generic already provides one. Having two separate chip drivers makes it difficult to multi-source WiFi devices and share the same firmware target without having to add a probe property for each of these devices. This is unnecessary since the WiFi driver in coreboot is primarily responsible for: 1. PCI resource allocation 2. ACPI SSDT node generation to expose wake property and SAR tables 3. SMBIOS table generation For the most part, coreboot can perform the above operations without really caring about the specifics of which WiFi device is being used by the mainboard. Thus, this change drops the driver for intel/wifi and moves the PCI driver support required for Intel WiFi chips into drivers/wifi/generic. The PCI driver is retained for backward compatibility with boards that never utilized the chip driver to support Intel WiFi device. For these devices, the PCI driver helps perform the same operations as above (except exposing the wake property) by utilizing the same `wifi_generic_ops`. This change also moves DRIVERS_INTEL_WIFI config to wifi/generic/Kconfig. BUG=b:169802515 BRANCH=zork Change-Id: I780a7d1a87f387d5e01e6b35aac7cca31a2033ac Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/46036 Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-10-13wifi: Move addition of CBFS SAR file to wifi/generic/Makefile.incFurquan Shaikh
This change moves the addition of CBFS SAR file from intel/wifi/Makefile.inc to wifi/generic/Makefile.inc to keep it in the same sub-directory as the Kconfig definition. BUG=b:169802515 BRANCH=zork Change-Id: I7ee33232b6a07bbf929f3a79fabe89130fb6fa6f Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/46039 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Michael Niewöhner <foss@mniewoehner.de> Reviewed-by: Martin Roth <martinroth@google.com> Reviewed-by: Rob Barnes <robbarnes@google.com> Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
2020-10-13drivers/{wifi/generic,intel/wifi}: Drop dependency on HAVE_ACPI_TABLESFurquan Shaikh
This change drops the dependency of DRIVERS_WIFI_GENERIC on HAVE_ACPI_TABLES as the driver provides operations other than the ACPI support for WiFi devices. Since the dependency is now dropped, ACPI operations in generic.c are guarded by CONFIG(HAVE_ACPI_TABLES). BUG=b:169802515 BRANCH=zork Change-Id: I16444a9d842a6742e3c97ef04c4f18e93e6cdaa9 Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/46037 Reviewed-by: Michael Niewöhner <foss@mniewoehner.de> Reviewed-by: Duncan Laurie <dlaurie@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-10-11drivers/wifi: Drop maxsleep parameter from chip configFurquan Shaikh
This change drops maxsleep parameter from chip config and instead hardcodes the deepest sleep state from which the WiFi device can wake the system up from to SLP_TYP_S3. This is similar to how other device drivers in coreboot report _PRW property in ACPI. It relieves the users from adding another register attribute to devicetree since all mainboards configure the same value. If this changes in the future, it should be easy to bring the maxsleep config parameter back. BUG=b:169802515 BRANCH=zork Change-Id: I42131fced008da0d51f0f777b7f2d99deaf68827 Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/46033 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Michael Niewöhner <foss@mniewoehner.de> Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
2020-10-11drivers/intel/wifi: Use newly added pci_dev_is_wake_sourceFurquan Shaikh
This change uses the newly added `pci_dev_is_wake_source()` helper function to determine and log WiFi wake source instead of assuming a hard-coded register value to check. This is done in preparation to merge the generic WiFi and Intel WiFi drivers in coreboot in follow-up changes. BUG=b:169802515 BRANCH=zork Change-Id: I9bdb453092b4ce7bdab2969f13e0c0aa8166dc0a Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/46031 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Rob Barnes <robbarnes@google.com> Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
2020-10-07drivers/intel/wifi: Drop call to pci_dev_initFurquan Shaikh
`pci_dev_init()` is used to load and run option ROM on VGA class devices (PCI_CLASS_DISPLAY_VGA). WiFi device is not a VGA class device and hence the call to `pci_dev_init()` is not required. This change drops the call to `pci_dev_init()` from `wifi_pci_dev_init()` in Intel WiFi driver. BUG=b:169802515 BRANCH=zork Change-Id: I6588ea0a5c848904088d05fd1cbdf677b2dc8ea9 Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/46029 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Rob Barnes <robbarnes@google.com> Reviewed-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-by: Michael Niewöhner <foss@mniewoehner.de> Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
2020-10-02drivers/intel/fsp2_0: use FSP to allocate APEI BERT memory regionJonathan Zhang
APEI (ACPI Platform Error Interface) defines BERT (Boot Error Record Table) memory region: * Bootloader (firmware) generates UEFI CPER (Common Platform Error Record) records, and populates BERT region. * OS parses ACPI BERT table, finds the BERT region address, inteprets the data and processes it accordingly. When CONFIG_ACPI_BERT is defined, update FSP UPD BootLoaderTolumSize, so FSP allocates memory region for it. The APEI BERT region is placed on top of CBMEM, for the size of CONFIG_ACPI_BERT_SIZE. Apart from APEI BERT region, we also have plan to add APEI HEST region which holds OS runtime hardware error record, based on firmware first hardware error handling model. HEST region will be reserved same way as BERT region. Note that CBMEM region can not be used for such purpose, the OS (bert/hest) drivers are not able to access data held in CBMEM region, as CBMEM is set as type 16 (configuration table). An option considered was to reserve the BERT region under CBMEM. However, we do not know the size of CBMEM till acpi tables are set up. On the other hand, BERT region needs to be filled up before ACPI BERT table is finalized. Change-Id: Ie72240e4c5fa01fcf937d33678c40f9ca826487a Signed-off-by: Jonathan Zhang <jonzhang@fb.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/45391 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
2020-09-21drivers/intel/fsp2_0: Add CONFIG_FSP_STATUS_GLOBAL_RESETSubrata Banik
Add CONFIG_FSP_STATUS_GLOBAL_RESET Kconfig to get correct FSP global reset type from respective SoC Kconfig. Supported value: 0x40000003-0x40000008, These are defined in FSP EAS v2.0 section 11.2.2 - OEM Status Code Unsupported value: 0xFFFFFFFF Signed-off-by: Subrata Banik <subrata.banik@intel.com> Change-Id: Idc04eb3a931d2d353808d02e62bd436b363600d1 Reviewed-on: https://review.coreboot.org/c/coreboot/+/45553 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Furquan Shaikh <furquan@google.com>
2020-09-21src/drivers: Drop unneeded empty linesElyes HAOUAS
Change-Id: I202e5d285612b9bf237b588ea3c006187623fdc3 Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/44609 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
2020-09-21drivers/intel/mipi_camera: Avoid resource leakJohn Zhao
Coverity detects variable dsd going out of scope leaks the storage it points to. Move dsd resource allocation after sanity check for config->nvm_compact to avoid leak. Found-by: Coverity CID 1432727 TEST=Built and boot up to kernel on Volteer. Signed-off-by: John Zhao <john.zhao@intel.com> Change-Id: I86af322dc78845b8b312b6815135336c2c56b4dd Reviewed-on: https://review.coreboot.org/c/coreboot/+/45531 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
2020-09-16drivers/intel/mipi_camera: Add compatible field for NVMPandya, Varshit B
Add compatible field for NVM Make PRP0001 as default HID if device type is INTEL_ACPI_CAMERA_NVM Signed-off-by: Pandya, Varshit B <varshit.b.pandya@intel.com> Change-Id: Iad7afa7b3170982eb5d6215e766f3e98f7a89213 Reviewed-on: https://review.coreboot.org/c/coreboot/+/45091 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Rizwan Qureshi <rizwan.qureshi@intel.com>
2020-09-06soc/intel/apl: Add panel power and backlight configurationNico Huber
Change-Id: Id8892ac7aafce1006831e2d9f2806919f5950756 Signed-off-by: Nico Huber <nico.huber@secunet.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/40694 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
2020-08-31{intel/gma,include/device}: Delete unused 'drm_dp_helper.h' fileElyes HAOUAS
'drm_dp_helper.h' file is duplicated and not used. Change-Id: Ibb08f7ff91c3914940dfe899be331b06e292c7c9 Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/44842 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de>
2020-08-24mrc_cache: Add mrc_cache fetch functions to support non-x86 platformsShelley Chen
Create two new functions to fetch mrc_cache data (replacing mrc_cache_get_current): - mrc_cache_load_current: fetches the mrc_cache data and drops it into the given buffer. This is useful for ARM platforms where the mmap operation is very expensive. - mrc_cache_mmap_leak: fetch the mrc_cache data and puts it into a given buffer. This is useful for platforms where the mmap operation is a no-op (like x86 platforms). As the name mentions, we are not freeing the memory that we allocated with the mmap, so it is the caller's responsibility to do so. Additionally, we are replacing mrc_cache_latest with mrc_cache_get_latest_slot_info, which does not check the validity of the data when retrieving the current mrc_cache slot. This allows the caller some flexibility in deciding where they want the mrc_cache data stored (either in an mmaped region or at a given address). BUG=b:150502246 BRANCH=None TEST=Testing on a nami (x86) device: reboot from ec console. Make sure memory training happens. reboot from ec console. Make sure that we don't do training again. Signed-off-by: Shelley Chen <shchen@google.com> Change-Id: I259dd4f550719d821bbafa2d445cbae6ea22e988 Reviewed-on: https://review.coreboot.org/c/coreboot/+/44006 Reviewed-by: Furquan Shaikh <furquan@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-08-18src: Remove unused 'include <lib.h>'Elyes HAOUAS
Change-Id: Ic09fc4ff4ee5524d89366e28d1d22900dd0c5b4d Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/44100 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2020-08-17drivers/intel/fsp2_0/hand_off_block: Remove dead decrementElyes HAOUAS
Value stored to 'size' is never read. Also drop unused parameter. Change-Id: If3e96ac90f06966ee408964e0748730bc237ec19 Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/41697 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
2020-08-13drivers/intel/fsp2_0: don't select FSP_USES_CB_STACK on FSP 2.0 platformFelix Held
soc/amd/picasso selected FSP_USES_CB_STACK even though it is FSP 2.0 based, so it doesn't reuse coreboot's stack, but sets up its own stack. In contrast to all other FSP 2.0 based platforms, this stack isn't in the CAR region, since AMD Picasso doesn't support CAR and the DRAM is already available when the x86 cores are released from reset. Selecting FSP_USES_CB_STACK ended up doing the right thing, but is semantically wrong. Instead of wrongly selecting FSP_USES_CB_STACK in soc/amd/picasso we take the corresponding code path if ENV_CACHE_AS_RAM is false which is only the case for non-CAR platforms. BUG=b:155501050 TEST=Timeless build results in an identical binary for amd/mandolin, asrock/h110m-dvs and intel/coffeelake_rvp11 which cover all 3 cases here. Change-Id: Icd0ff8e17a535e2c247793b64f4b0565887183d8 Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/44406 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Furquan Shaikh <furquan@google.com> Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
2020-08-13drivers/intel/fsp2_0: Fill EFI_CPU_PHYSICAL_LOCATION structure informationSubrata Banik
Latest EDK2 code inside "UefiCpuPkg\Library\RegisterCpuFeaturesLib\CpuFeaturesInitialize.c" is now looking for EFI_CPU_PHYSICAL_LOCATION structure variables hence coreboot need to fill required information (package, core and thread count). TEST=Able to see package, core and thread information as part of FSP debug log. Change-Id: Ieccf20a116d59aaafbbec3fe0adad9a48931cb59 Signed-off-by: Subrata Banik <subrata.banik@intel.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/44390 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Sridhar Siricilla <sridhar.siricilla@intel.com> Reviewed-by: Aamir Bohra <aamir.bohra@intel.com>
2020-08-06drivers/intel/fsp2_0: Do AP re-init after FSP-S if USE_INTEL_FSP_MP_INIT enableSubrata Banik
This patch ensures that coreboot is able to take control of APs back by doing a full AP re-initialization after FSP-S is done. TEST=Able to see all cores available after booting to OS using below command when coreboot is built with USE_INTEL_FSP_MP_INIT enable. > cat /proc/cpuinfo Without this CL : shows only 1 core (only BSP) With this CL : shows all possible cores available (BSP + APs) Change-Id: I247d8d1166c77bd01922323b6a0f14ec6640a666 Signed-off-by: Subrata Banik <subrata.banik@intel.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/44077 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Patrick Rudolph <siro@das-labor.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Furquan Shaikh <furquan@google.com>
2020-08-05drivers/intel/mipi_camera: Fix SSDT generation for IPU devicesSugnan Prabhu S
Includes changes in mipi_camera driver to fix following issues related to SSDT generation for IPU devices. 1. acpigen_write_device was not getting called for IPU devices 2. acpigen_pop_len was called for a generic devices without calling acpigen_write_device Change-Id: I309edd065719cb8250f1241898bb5854004d2a9f Signed-off-by: Sugnan Prabhu S <sugnan.prabhu.s@intel.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/44025 Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-08-03drivers/intel/mipi_camera: Add reference counting for shared resourcesSugnan Prabhu S
This change updates the mipi_camera driver to handle shared power resource between multiple cameras. This is achieved by adding a guard variable and methods to manipulate the guard variable before calling the actual platform method which enables or disables the resource. PowerResource will call these guarded methods to enable or disable the resource. This protects the shared resource from being enabled or disabled multiple times while the other camera is using the resource. Example: Consider a platform where two cameras are sharing a GPIO resource 0xXX and both the cameras calls enable and disable guarded methods for this GPIO. Actual platform disable method for the GPIO is called only after the last camera using the GPIO calls DSBx method and RESx becomes 0. Scope (\_SB.PCI0) { Name (RESx, Zero) Method (ENBx, 0, Serialized) { If ((RESx == Zero)) { \_SB.PCI0.STXS (0xXX) } RESx++ } Method (DSBx, 0, Serialized) { If ((RESx > Zero)) { RESx-- } If ((RESx == Zero)) { \_SB.PCI0.CTXS (0xXX) } } } Change-Id: I1468459d5bbb2fb07bef4e0590c96dd4dbab0d9c Signed-off-by: Sugnan Prabhu S <sugnan.prabhu.s@intel.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/43003 Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-07-28drivers/wifi: Adapt generic wifi driver into a chip driverKarthikeyan Ramasubramanian
Re-organize the existing generic wifi driver into a generic wifi chip driver. This allows generic wifi chip information to be added to the devicetree. BUG=None TEST=./util/abuild/abuild Change-Id: I63f957a008ecf4a6a810c2a135ed62ea81a79fe0 Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/43768 Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-07-26src/drivers/intel/soundwire/soundwire.h: Add include <types.h>Elyes HAOUAS
BIT(x) needs <types.h>. Change-Id: Icf8b77713e7b5deb9def19c3e14e89a40ba46107 Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/43710 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
2020-07-26drivers/intel/dptf: Remove prompts from DPTF config optionsTim Wawrzynczak
The prompts for the DPTF Kconfig options were not necessary, they should be selected based on what DPTF implementation is being used, ASL files or generated at runtime. It's not really meant to be fiddled with at build-time. Also rewrite the help text for the _HID selection, to try and make it more clear when to use y or n. Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org> Change-Id: I6edcabd28426916d9586d501b95b510dfc163fc1 Reviewed-on: https://review.coreboot.org/c/coreboot/+/43830 Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Caveh Jalali <caveh@chromium.org> Reviewed-by: Furquan Shaikh <furquan@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-07-26src: Change BOOL CONFIG_ to CONFIG() in comments & stringsMartin Roth
The Kconfig lint tool checks for cases of the code using BOOL type Kconfig options directly instead of with CONFIG() and will print out warnings about it. It gets confused by these references in comments and strings. To fix it so that it can find the real issues, just update these as we would with real issues. Signed-off-by: Martin Roth <martin@coreboot.org> Change-Id: I5c37f0ee103721c97483d07a368c0b813e3f25c0 Reviewed-on: https://review.coreboot.org/c/coreboot/+/43824 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
2020-07-26src: Remove whitespace between 'sizeof' and '('Elyes HAOUAS
Change-Id: Iaf22dc1986427e8aa4521b0e9b40fafa5a29dbbd Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/43720 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
2020-07-26drivers/intel/dptf: Add missing Scope operator for _FIFTim Wawrzynczak
Missed one other scope operator in the DPTF cleanup. This one is for the fan device, and without this fix, the kernel isn't able to properly control the fan (it gets confused about whether it's ACPI 4+ compatible or not). BUG=b:149722146 TEST=verify /sys/class/thermal/cooling_zone0/max_state returns > 1, and /sys/class/thermal/cooling_zone0/cur_state is writable, and writing the value of `max_state` causes the fan to spin faster. Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org> Change-Id: I7bd83967ace761ddd17eaeae9c25abb0b2cbe413 Reviewed-on: https://review.coreboot.org/c/coreboot/+/43840 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Furquan Shaikh <furquan@google.com>
2020-07-20drivers/intel/gma/Kconfig: Avoid dependency hell when ignoring strapsAngel Pons
Unconditionally selecting `GFX_GMA_IGNORE_PRESENCE_STRAPS` creates a hard dependency on `MAINBOARD_USE_LIBGFXINIT`, which is undesired. Move it out of the `if GFX_GMA` block to break this unwanted dependency. TEST=Build for Librem 13v4 with no graphics init successfully. Change-Id: I53e132c209c065068f20959fa1a6f5195f5fe766 Signed-off-by: Angel Pons <th3fanbus@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/43491 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Nico Huber <nico.h@gmx.de>
2020-07-18drivers/intel/dptf: Add missing scope operator around TSR optionsTim Wawrzynczak
The previous DPTF patch train missed the proper scope operator around all of the TSR options. Without this, the optional GTSH and/or _STR Methods end up in the wrong scope. Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org> Change-Id: I9298c442c047c5f7f606574d900057a7c004b47f Reviewed-on: https://review.coreboot.org/c/coreboot/+/43458 Reviewed-by: Karthik Ramasubramanian <kramasub@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-07-18dptf: Fix scope of TCPU deviceTim Wawrzynczak
In the initial DPTF refactor, the scope of the TCPU device was incorrectly set as \_SB, instead of \_SB.PCI0. However, because of the way that the acpi_inject_dsdt() callback currently works (it injects contents before the dsdt.aml file), the Scope where the TCPU device lives (\_SB.PCI0) doesn't exist yet. Therefore, to avoid playing games with *when* things are defined in the DSDT, switch to defining all of the DPTF devices in the SSDT. Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org> Change-Id: Ia4922b4dc6544d79d44d39e6ad18c6ab9fee0fd7 Reviewed-on: https://review.coreboot.org/c/coreboot/+/43529 Reviewed-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-by: Karthik Ramasubramanian <kramasub@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-07-14src: Remove unused 'include <stdint.h>Elyes HAOUAS
Found using: diff <(git grep -l '#include <stdint.h>' -- src/) <(git grep -l 'int8_t\|int16_t\|int32_t\|int64_t\|intptr_t\|intmax_t\|s8\|u8\|s16\|u16\|s32\|u32\|s64\|u64\|INT8_MIN\|INT8_MAX\|INT16_MIN\|INT16_MAX\|INT32_MIN\|INT32_MAX\|INT64_MIN\|INT64_MAX\|INTMAX_MIN\|INTMAX_MAX' -- src/) |grep -v vendorcode |grep '<' Change-Id: I5e14bf4887c7d2644a64f4d58c6d8763eb74d2ed Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/41827 Reviewed-by: Patrick Georgi <pgeorgi@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-07-12mb/google/volteer: Convert static ASL files to new DPTF implementationTim Wawrzynczak
This patch converts the current DPTF policies from static ASL files into the new SSDT-based DPTF implementation. All settings are intended to be copied exactly. Change-Id: I964c53afbd503d47a07b982672425f0e7a986a3f Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org> Reviewed-on: https://review.coreboot.org/c/coreboot/+/41895 Reviewed-by: Sumeet R Pawnikar <sumeet.r.pawnikar@intel.com> Reviewed-by: Nick Vaccaro <nvaccaro@google.com> Reviewed-by: Duncan Laurie <dlaurie@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-07-09drivers/intel/gma/i915_reg.h: Drop dead codeAngel Pons
This code is not even being build-tested. Drop it before it grows moss. Change-Id: Iff5007256fedebd98082a575773d7de181b321ab Signed-off-by: Angel Pons <th3fanbus@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/43249 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Michael Niewöhner
2020-07-07dptf: Add support for IDSPTim Wawrzynczak
\_SB.DPTF.IDSP adverties to the DPTF daemon which policies the implementation supports. Added a new acpigen function to figure out which policies are used, and fills out IDSP appropriately. Change-Id: Idf67a23bf38de4481c02f98ffb27afb8ca2d1b7b Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org> Reviewed-on: https://review.coreboot.org/c/coreboot/+/42081 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
2020-07-07dptf: Add support for Fan and TSR optionsTim Wawrzynczak
DPTF has several options on how to control the fan (fine-grained speed control, minimum speed change in percentage points, and whether or not the DPTF device should notify the Fan if it detects low speed). Individual TSRs can also set GTSH, which is the amount of hysteresis inherent in the measurement, either from circuitry (if analog), or in firmware (if digital). BUG=b:143539650 TEST=compiles Change-Id: I42d789d877da28c163e394d7de5fb1ff339264eb Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org> Reviewed-on: https://review.coreboot.org/c/coreboot/+/41891 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
2020-07-07dptf: Add support for Running Average Power LimitsTim Wawrzynczak
This change adds support for emitting the PPCC table, which describes the ranges available as knobs for DPTF to tune. It can support min/max power, min/max time window for averaging, and the minimum adjustment size (granularity or step size) of each power limit. The current implementation only supports PL1 and PL2. BUG=b:143539650 TEST=compiles Change-Id: I67e80d661ea5bb79980ef285eca40c9a4b0f1849 Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org> Reviewed-on: https://review.coreboot.org/c/coreboot/+/41890 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
2020-07-07dptf: Add support for Fan Performance StatesTim Wawrzynczak
This change adds support for generating the _FPS table for the DPTF Fan object. The table describes different levels of fan activity that may be applied to the system in order to actively cool it. The information includes fan speed at a (rough) percentage level, fan speed in RPM, potential noise level in centibels, and power in mA. BUG=b:143539650 TEST=compiles Change-Id: I5591eb527f496d0c4c613352d2a87625d47d9273 Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org> Reviewed-on: https://review.coreboot.org/c/coreboot/+/41889 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
2020-07-07dptf: Add support for Charger Performance StatesTim Wawrzynczak
This change generates the DPTF TCHG.PPSS table in the SSDT. This table describes different charging rates which are available to use. DPTF can pick different rates in order to passively cool (or not) the system. BUG=b:143539650 TEST=compiles Change-Id: I6df6bfbac628fa4e4d313e38b8e6c53fce70a7f2 Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org> Reviewed-on: https://review.coreboot.org/c/coreboot/+/41888 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
2020-07-07dptf: Add support for Critical PoliciesTim Wawrzynczak
This patch adds support for DPTF Critical Policies, which are consist of Method definitions only. They are `_CRT` and `_HOT`, which are defined as temperature thresholds that, when exceeded, will execute a graceful suspend or a graceful shutdown, respectively. BUG=b:143539650 TEST=compiles Change-Id: I711ecdcf17ae8f6e653f33069201da4515ace85e Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org> Reviewed-on: https://review.coreboot.org/c/coreboot/+/41887 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
2020-07-07dptf: Add support for Passive PoliciesTim Wawrzynczak
This patch adds support for emitting the Thermal Relationship Table, as well as _PSV Methods, which together form the basis for DPTF Passive Policies. BUG=b:143539650 TEST=compiles Change-Id: I82e1c9022999b0a2a733aa6cd9c98a850e6f5408 Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org> Reviewed-on: https://review.coreboot.org/c/coreboot/+/41886 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
2020-07-07dptf: Add support for generation of Active PoliciesTim Wawrzynczak
This change adds support for generating the different pieces of DPTF Active Policies. This includes the Active Relationship Table, in addition to _ACx methods. BUG=b:143539650 TEST=compiles Change-Id: Iea0ccbd96f88d0f3a8f2c77a7d0f3a284e5ee463 Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org> Reviewed-on: https://review.coreboot.org/c/coreboot/+/41885 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Sumeet R Pawnikar <sumeet.r.pawnikar@intel.com> Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
2020-07-07drivers/intel/dptf: Add current participant Devices to DSDTTim Wawrzynczak
In this DPTF implementation, the participant device objects are written into the DSDT with only minimal Names attached (_HID/_ADR, _STA, _UID, PTYP, and _STR). All other Methods & Names will be written into the SSDT. If a device is not used in any policy, then its _STA is set to return 0 ("off"). BUG=b:143539650 TEST=Compiles. Change-Id: Ief69a57adce9ee0b19056ce6a11ed8a5b51b3f87 Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org> Reviewed-on: https://review.coreboot.org/c/coreboot/+/41884 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Sumeet R Pawnikar <sumeet.r.pawnikar@intel.com> Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
2020-07-07drivers/intel/mipi_camera: Add camera power resource to SSDTSugnan Prabhu S
This change adds support function to parse entries in the devicetree to generate PowerResource entries for the MIPI camera. Change-Id: I31e198b50acf2c64035aff9cb054fbe3602dd83e Signed-off-by: Sugnan Prabhu S <sugnan.prabhu.s@intel.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/41624 Reviewed-by: Rizwan Qureshi <rizwan.qureshi@intel.com> Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-07-07drivers/intel/mipi_camera: Add support to handle CIO2 deviceMatt Delco
This change updates mipi_camera driver to handle CIO2 device type. Change-Id: I521740524bc1c4da3d8593f011a033542e4a872c Signed-off-by: Sugnan Prabhu S <sugnan.prabhu.s@intel.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/42470 Reviewed-by: Rizwan Qureshi <rizwan.qureshi@intel.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-07-07drivers/intel/mipi_camera: SSDT changes to add PLDMatt Delco
This change updates mipi_camera driver to add PLD section to SSDT. Change-Id: If65b9cbabca95e9645d8e5023ce7fd78b0625d1e Signed-off-by: Sugnan Prabhu S <sugnan.prabhu.s@intel.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/42469 Reviewed-by: Rizwan Qureshi <rizwan.qureshi@intel.com> Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-07-07drivers/intel/mipi_camera: SSDT changes to add DSMMatt Delco
This change updates mipi_camera driver to add DSM section to SSDT. Change-Id: Ic60e972b6aebad171a7b77fe0d99781693adfb20 Signed-off-by: Sugnan Prabhu S <sugnan.prabhu.s@intel.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/42468 Reviewed-by: Rizwan Qureshi <rizwan.qureshi@intel.com> Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>