summaryrefslogtreecommitdiff
path: root/src/include/device
AgeCommit message (Collapse)Author
2020-09-14src/{device,include}: Use PNP_IDX_EN instead of magic numberElyes HAOUAS
Change-Id: I68590605e261ecaace9f3cea28cfa6ec3b913a8a Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/44835 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
2020-09-14src/include: Drop unneeded empty linesElyes HAOUAS
Change-Id: Ie325541547ea10946f41a8f979d144a06a7e80eb Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/44611 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
2020-09-11device: Fix incompatible-pointer-types build errorSubrata Banik
The build error `incompatible-pointer-types` occurs while using `pci_dev_request_bus_master` as part of device ops Signed-off-by: Subrata Banik <subrata.banik@intel.com> Change-Id: I3b1ce85b8db1ddf9ac860415edbe64694b91b3d1 Reviewed-on: https://review.coreboot.org/c/coreboot/+/45122 Reviewed-by: Angel Pons <th3fanbus@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-09-08pci_ids: Add Alder Lake DTT PCI IDsSubrata Banik
Add PCI IDs for Intel's Dynamic Tuning Technology (DTT) for ADL. Also add NULL terminator at end of pci_device_ids. Change-Id: If25b1f562567a833683b0b8796bd1d6cac0bd490 Signed-off-by: Subrata Banik <subrata.banik@intel.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/45140 Reviewed-by: Angel Pons <th3fanbus@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-09-08pci_ids: Add Alder Lake IPU PCI IDsSubrata Banik
Add PCI IDs for Intel's Image Processing Unit (IPU) for ADL. Also add NULL terminator at end of pci_device_ids. Change-Id: I327828d676422fc6162fadffd9b39529ecb89ace Signed-off-by: Subrata Banik <subrata.banik@intel.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/45139 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
2020-09-08soc/intel/elkhartlake: Add CPU, SA, PCH & IGD DIDs TableTan, Lean Sheng
1. Add CPU, SA, PCH & IGD DIDs table into report_platform.c 2. Add additional EHL SA DID in pci_ids.h Signed-off-by: Tan, Lean Sheng <lean.sheng.tan@intel.com> Change-Id: I5c98089873b17f82560eba13c7de3353b6d3e249 Reviewed-on: https://review.coreboot.org/c/coreboot/+/45074 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
2020-09-01{include,mb,soc,sb,vendorcode}: Make hexadecimal notation consistentSubrata Banik
Convert 0X -> 0x Signed-off-by: Subrata Banik <subrata.banik@intel.com> Change-Id: Iea3ca67908135d0e85083a05bad2ea176ca34095 Reviewed-on: https://review.coreboot.org/c/coreboot/+/44926 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
2020-08-31device: Add method to configure bus mastering based on KconfigFelix Singer
The bus master bit is set at many places in coreboot's code, but the reason for that is not quite clear. We examined not setting the bus master bit whereever possible and tried booting without it, which worked fine for internal PCI devices but not for PCIe. As a PCIe device we used a Samsung M.2 NVMe SSD. For security reasons, we would like to disable bus mastering where possible. Depending on the device, bus mastering might get enabled by the operating system (e.g. for iGPU) and it might be required for some devices to work properly. However, the idea is to leave it disabled and configure the IOMMU first before enabling it. To have some sort of "backwards compatibility", add a method which configures bus mastering based on an additional config option. Since CB:42460 makes usage of this treewide, enable it by default to keep the current behaviour for now. Tested with Siemens/Chili, a Coffee Lake based platform. Change-Id: I876c48ea3fb4f9cf7b6a5c2dcaeda07ea36cbed3 Signed-off-by: Felix Singer <felix.singer@secunet.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/42459 Reviewed-by: Nico Huber <nico.h@gmx.de> Reviewed-by: Subrata Banik <subrata.banik@intel.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-08-31include/device/azalia_device: Fix typoPatrick Rudolph
The code using the macro was found not working after finally enabling the HDA PCI device on the hermes board. Fix a typo to generate the correct verbs. Tested on prodrive/hermes. Change-Id: I953c2e9fbebc1f02bdf71ce868a95f578300c3a1 Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/44900 Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Christian Walter <christian.walter@9elements.com> Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
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-29PCI IDs: Add PCI ID for CML DPTF/DTT PCI deviceEdward O'Callaghan
This PCI ID is required in order for the CML devices to perform SSDT generation for DPTF. CML Processor, EDS, Vol 1, Table 9-5, Section 9.2. BUG=b:158986928 BRANCH=puff TEST=builds Signed-off-by: Edward O'Callaghan <quasisec@google.com> Change-Id: I94aea6b9e0f60656827daada7b2cc2741604b8b3 Reviewed-on: https://review.coreboot.org/c/coreboot/+/44902 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Sam McNally <sammc@google.com> Reviewed-by: Daniel Kurtz <djkurtz@google.com> Reviewed-by: Andrew McRae <amcrae@google.com>
2020-08-27soc/intel/common: Include Elkhart Lake SA IDsTan, Lean Sheng
Add additional Elkhart Lake specific SA IDs. Signed-off-by: Lean Sheng Tan <lean.sheng.tan@intel.com> Change-Id: I41af9b17b8121f3b47f2242d9beeec297893b378 Reviewed-on: https://review.coreboot.org/c/coreboot/+/40854 Reviewed-by: Subrata Banik <subrata.banik@intel.com> Reviewed-by: Werner Zeh <werner.zeh@siemens.com> Reviewed-by: Maulik V Vaghela <maulik.v.vaghela@intel.com> Reviewed-by: Praveen HP <praveen.hodagatta.pranesh@intel.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-08-17soc/intel/common: Move common HDA registers to <device/azalia_device.h>Elyes HAOUAS
Change-Id: I9ea191e5076e2f055405dc34d46dbbb8cfb0015e Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/44106 Reviewed-by: Angel Pons <th3fanbus@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-08-17soc/intel/jasperlake: Add IGD Device IDKrishna Prasad Bhat
Add IGD Device ID for Jasperlake. Reference is taken from Jasperlake EDS volume 1(Document Number: 613601). TEST=Build and boot Jasperlake platform. Change-Id: Iab3ba286f36afbf9533ac3cc62891fa390ca2441 Signed-off-by: Krishna Prasad Bhat <krishna.p.bhat.d@intel.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/44000 Reviewed-by: Subrata Banik <subrata.banik@intel.com> Reviewed-by: Aamir Bohra <aamir.bohra@intel.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-08-10soc/intel/common: Include Alder Lake SATA controller device IDsSubrata Banik
Document Number: 619501, 619362 Change-Id: Id3440b415ca80edebb6880b8b48f6094ebea4ae4 Signed-off-by: Subrata Banik <subrata.banik@intel.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/44298 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
2020-08-05drivers/genesyslogic/gl9763e: Add driver for Genesys Logic GL9763EBen Chuang
The device is a PCIe to eMMC bridge controller to be used in the Chromebook as the boot disk. The datasheet name is GL9763E and the revision is 02. The patch sets single request AXI, disables ASPM L0s and enables SSC. Signed-off-by: Ben Chuang <benchuanggli@gmail.com> Change-Id: I158c79f5ac6e559f335b6b50092469c7b1646c56 Reviewed-on: https://review.coreboot.org/c/coreboot/+/43751 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2020-08-05include/device/azalia_device.h: Include <stdint.h>Elyes HAOUAS
This file only needs <stdint.h>. So replace <types.h> with <stdint.h>. Change-Id: Ib58532837941d5324b28bc2c607d70555ce9caee Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/44134 Reviewed-by: Angel Pons <th3fanbus@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-08-05soc/intel/common: Include Alder Lake device IDsSubrata Banik
Add Alder Lake specific CPU, System Agent, PCH (Alder Point aka ADP), IGD device IDs. Document Number: 619501, 619362 Change-Id: I17ce56a220e4dce2db2e0e69561b3d6dac9e65a2 Signed-off-by: Subrata Banik <subrata.banik@intel.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/44108 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org> Reviewed-by: Furquan Shaikh <furquan@google.com>
2020-07-28device: Add find_dev_nested_path helper functionRob Barnes
Add find_dev_nested_path helper function to simplify finding deeply nested devices. BUG=b:157580724 TEST=Find bluetooth device on dalboz Change-Id: I48fa5fcad0030fb6dcea97b9fc76e1d3d3f9b28f Signed-off-by: Rob Barnes <robbarnes@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/43776 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Furquan Shaikh <furquan@google.com> Reviewed-by: Raul Rangel <rrangel@chromium.org>
2020-07-28PCI IDs: Add PCI ID for the realtek 5261Caveh Jalali
This adds the PCI ID of the realtek 5261 PCIe to SD Express card reader. BUG=b:161774205 TEST=none Change-Id: I4d5e6cfca59b02adc74a0c148281a92421fe209d Signed-off-by: Caveh Jalali <caveh@chromium.org> Reviewed-on: https://review.coreboot.org/c/coreboot/+/43848 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
2020-07-28src: Never set ISA Enable on PCI bridgesAngel Pons
Looks like no one really knows what this bit would be useful for, nor when it would need to be set. Especially if coreboot is setting it even on PCI *Express* bridges. Digging through git history, nearly all instances of setting it on PCIe bridges comes from i82801gx, for which no reason was given as to why this would be needed. The other instances in Intel code seem to have been, unsurprisingly, copy-pasted. Drop all uses of this definition and rename it to avoid confusion. The negation in the name could trick people into setting this bit again. Tested on Asrock B85M Pro4, no visible difference. Change-Id: Ifaff29561769c111fb7897e95dbea842faec5df4 Signed-off-by: Angel Pons <th3fanbus@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/43775 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Patrick Rudolph <siro@das-labor.org> Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
2020-07-26src/include: Add missing includesElyes HAOUAS
Change-Id: I746ea7805bae553a146130994d8174aa2e189610 Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/43368 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
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-26device/device.h: Add `is_dev_enabled` functionAngel Pons
There are many places where we do this. Put it inside an inline function for convenience reasons. Change-Id: I5515a52458b6c78c1a723cb08e6471eb9bac9cd6 Signed-off-by: Angel Pons <th3fanbus@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/43871 Reviewed-by: Felix Singer <felixsinger@posteo.net> Reviewed-by: Michael Niewöhner Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-07-25soc/intel/tigerlake: Update Tiger Lake SA IDsDerek Huang
This patch updates Tiger Lake SA DID and report platform. According to doc #613584, remove PCI_DEVICE_ID_INTEL_TGL_ID_U_1 and add below definitions of SA ID for TGL-UP4 skus: TGL-UP4(Y) (4+2): PCI_DEVICE_ID_INTEL_TGL_ID_Y_4_2 0x9A12h TGL-UP4(Y) (2+2): PCI_DEVICE_ID_INTEL_TGL_ID_Y_2_2 0x9A02h Change-Id: Id9d9c9ac3bf39582b0da610e6ef912031939c763 Signed-off-by: Derek Huang <derek.huang@intel.corp-partner.google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/43061 Reviewed-by: Sumeet R Pawnikar <sumeet.r.pawnikar@intel.com> Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org> Reviewed-by: Caveh Jalali <caveh@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-07-17device: Increase DEVICE_PATH_MAX to 40Furquan Shaikh
This change increases the maximum length of device path string to 40 characters to accommodate growing hierarchy of devices. TEST=Ensured that "\_SB.PCI0.LPCB.EC0.CREC.TUN0.RT58" is correctly added to SSDT. Change-Id: Id2ef71a32b26e366b56c652942a247de4889544a Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/43540 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2020-07-15PCI IDs: Add PCI ID for JSL DPTF/DTT PCI deviceTim Wawrzynczak
This PCI ID is required in order for JSL devices to perform SSDT generation for DPTF. Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org> Change-Id: I42209d15bc4f1654814465ce1412576f7349dddc Reviewed-on: https://review.coreboot.org/c/coreboot/+/43421 Reviewed-by: Karthik Ramasubramanian <kramasub@google.com> Reviewed-by: Duncan Laurie <dlaurie@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-07-12soc/intel/tigerlake: Add new IGD deviceRavi Sarawadi
Add new IGD device ID for new Tigerlake SKU support. BUG=b:160394260 Branch=None TEST=build, boot and check IGD device is reported. Signed-off-by: Ravi Sarawadi <ravishankar.sarawadi@intel.com> Change-Id: I1903d513b61655d0e939f80b0fd0108091fdd7e9 Reviewed-on: https://review.coreboot.org/c/coreboot/+/43163 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Wonkyu Kim <wonkyu.kim@intel.com>
2020-07-12device/xhci: Add helper method to iterate over xhci_supported_protoclRaul E Rangel
There is some boilerplate required to iterate over the USB supported protocol structs. Encapsulate all the in a method to make the callers simpler. BUG=b:154756391 TEST=Built test trembyle. Signed-off-by: Raul E Rangel <rrangel@chromium.org> Change-Id: I401f10d242638b0000ba697573856d765333dca0 Reviewed-on: https://review.coreboot.org/c/coreboot/+/43352 Reviewed-by: Furquan Shaikh <furquan@google.com> Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-07-07soc/intel/common/block: Add new block DTTTim Wawrzynczak
Intel Dynamic Tuning Technology is the name of a PCI device on some Intel SoCs. This minimal PCI driver is only used now for SSDT generation on TGL devices. Change-Id: Ib52f35e4e020ca3e6ab8b32cc3bf7df36041926e Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org> Reviewed-on: https://review.coreboot.org/c/coreboot/+/41893 Reviewed-by: Nick Vaccaro <nvaccaro@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-07-07pci_ids: Add TGL & JSL IPU PCI IDsTim Wawrzynczak
Add PCI IDs for Intel's Image Processing Unit (IPU) for TGL & JSL Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org> Change-Id: I71dc95a6692e82ca25b0252b4f0789ee059df89f Signed-off-by: Sugnan Prabhu S <sugnan.prabhu.s@intel.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/42811 Reviewed-by: Rizwan Qureshi <rizwan.qureshi@intel.com> Reviewed-by: Karthik Ramasubramanian <kramasub@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-06-22device/smbus_host: Declare common early SMBus prototypesKyösti Mälkki
Change-Id: I1157cf391178a27db437d1d08ef5cb9333e976d0 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/38233 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
2020-06-17device/pnp_ops.h: Use pnp.h functionsAngel Pons
With BUILD_TIMELESS=1, Asrock B85M Pro4 remains identical. Change-Id: I3ca080e700cf7b7f5b76cadddc7e41960413433c Signed-off-by: Angel Pons <th3fanbus@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/42133 Reviewed-by: Furquan Shaikh <furquan@google.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-06-10device/xhci: Add xHCI utility to enumerate capabilitiesRaul E Rangel
This will allow enumerating an xHCI controller to allow dynamically generating the ACPI device nodes. BUG=b:154756391 TEST=Boot trembyle and see capabilities printed on console xHCI Supported Protocol: Major: 0x2, Minor: 0x0, Protocol: 'USB ' Port Offset: 1, Port Count: 2 xHCI Supported Protocol: Major: 0x3, Minor: 0x10, Protocol: 'USB ' Port Offset: 3, Port Count: 1 Signed-off-by: Raul E Rangel <rrangel@chromium.org> Change-Id: I3065c3fffad01b5378a55cfe904f971079b13d0f Reviewed-on: https://review.coreboot.org/c/coreboot/+/41899 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Furquan Shaikh <furquan@google.com>
2020-06-09pci_ops.h: Turn and/or ops into update wrappersAngel Pons
Tested with BUILD_TIMELESS=1, Asus P8Z77-V LX2 does not change. Change-Id: I2d3779967f357dd380928869c630a1996fdd60ec Signed-off-by: Angel Pons <th3fanbus@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/42147 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2020-06-09include/device/pci_ops.h: Add bitwise AND opsAngel Pons
For the sake of completeness, we should provide these operations. Change-Id: Ia28af94ec86319c7380d8377f7e24e5cdf55dd9c Signed-off-by: Angel Pons <th3fanbus@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/42145 Reviewed-by: Nico Huber <nico.h@gmx.de> Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-06-08device: Add a disabling PCIe device bus master functionJohn Zhao
A function pci_dev_disable_bus_master() is created. This function can be used to disable Thunderbolt PCIe root ports, bridges and devices for Vt-d based security platform at end of boot service. BUG=None TEST=Verified PCIe device bus master enable bit is cleared. Signed-off-by: John Zhao <john.zhao@intel.com> Change-Id: Ie92a15bf2c66fdc311098acb81019d4fb7f68313 Reviewed-on: https://review.coreboot.org/c/coreboot/+/41042 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
2020-06-02fw_config: Add firmware configuration interfaceDuncan Laurie
This change introduces a new top-level interface for interacting with a bitmask providing firmware configuration information. This is motivated by Chromebook mainboards that need to support multiple different configurations at runtime with the same BIOS. In these devices the Embedded Controller provides a bitmask that can be broken down into different fields and each field can then be broken down into different options. The firmware configuration value could also be stored in CBFS and this interface will look in CBFS first to allow the Embedded Controller value to be overridden. The firmware configuration interface is intended to easily integrate into devicetree.cb and lead to less code duplication for new mainboards that make use of this feature. BUG=b:147462631 TEST=this provides a new interface that is tested in subsequent commits Change-Id: I1e889c235a81545e2ec0e3a34dfa750ac828a330 Signed-off-by: Duncan Laurie <dlaurie@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/41209 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Furquan Shaikh <furquan@google.com>
2020-06-02src: Remove redundant includesElyes HAOUAS
<types.h> is supposed to provide <commonlib/bsd/cb_err.h>, <stdbool.h>,<stdint.h> and <stddef.h>. So remove those includes each time when <types.h> is included. Change-Id: I886f02255099f3005852a2e6095b21ca86a940ed Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/41817 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2020-05-28device: Enable resource allocation above 4G boundary with allocator v4Furquan Shaikh
This change adds back CB:39487 which was reverted as part of CB:41412. Now that the resource allocator is split into old(v3) and new(v4), this change adds support for allocating resources above 4G boundary with the new allocator v4. Original commit message: This change adds support for allocating resources above the 4G boundary by making use of memranges for resource windows enabled in the previous CL. It adds a new resource flag IORESOURCE_ABOVE_4G which is used in the following ways: a) Downstream device resources can set this flag to indicate that they would like to have their resource allocation above the 4G boundary. These semantics will have to be enabled in the drivers managing the devices. It can also be extended to be enabled via devicetree. This flag is automatically propagated by the resource allocator from downstream devices to the upstream bridges in pass 1. It is done to ensure that the resource allocator has a global view of downstream requirements during pass 2 at domain level. b) Bridges have a single resource window for each of mem and prefmem resource types. Thus, if any downstream resource of the bridge requests allocation above 4G boundary, all the other downstream resources of the same type under the bridge will be allocated above 4G boundary. c) During pass 2, resource allocator at domain level splits IORESOURCE_MEM into two different memory ranges -- one for the window below 4G and other above 4G. Resource allocation happens separately for each of these windows. d) At the bridge level, there is no extra logic required since the resource will live entirely above or below the 4G boundary. Hence, all downstream devices of any bridge will fall within the window allocated to the bridge resource. To handle this case separately from that of domain, initializing of memranges for a bridge is done differently than the domain. Limitation: Resources of a given type at the bridge or downstream devices cannot live both above and below 4G boundary. Thus, if a bridge has some downstream resources requesting allocation for a given type above 4G boundary and other resources of the same type requesting allocation below 4G boundary, then all these resources of the same type get allocated above 4G boundary. Change-Id: I92a5cf7cd1457f2f713e1ffd8ea31796ce3d0cce Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/41466 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2020-05-28Remove new additions of "this file is part of" linesElyes HAOUAS
Change-Id: I6c69dcad82ee217ed4760dea1792dd1a6612cd8b Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/41606 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2020-05-26device: Move resource allocation into a separate compilation unitFurquan Shaikh
This change moves the resource allocator functions out of device.c and into two separate files: 1. resource_allocator_v3.c: This is the old implementation of resource allocator that uses a single window for resource allocation. It is required to support some AMD chipsets that do not provide an accurate map of allocated resources by the time the allocator runs. They work fine with the old allocator since it restricts itself to allocations in a single window at the top of the 4G space. 2. resource_allocator_common.c: This file contains the functions that can be shared by the old and new resource allocator. Entry point into the resource allocation is allocate_resources() which can be implemented by both old and new allocators. This change also adds a Kconfig option RESOURCE_ALLOCATOR_V3 which enables the old resource allocator. This config option is enabled by default currently, but in the following CLs this will be enabled only for the broken boards. Reason for this split: Both the old and new resource allocators need to be retained in the tree until the broken chipsets are fixed. Change-Id: I2f5440cf83c6e9e15a5f22e79cc3c66aa2cec4c0 Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/41442 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Mike Banon <mikebdp2@gmail.com> Reviewed-by: Nico Huber <nico.h@gmx.de> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-05-22drivers/soundwire/alc5682: Support Realtek ALC5682 SoundWire deviceDuncan Laurie
The ALC5682 headset codec can be connected over SoundWire and be configured for mainboards to use: - Data Port 0 and Bulk Register Access is supported - Data Ports 1-4 are supported as both source and sink The data port and audio mode properties are filled out as best as possible with the datasheet as a reference. The ACPI address for the codec is calculated with the information in the codec driver combined with the devicetree.cb hierarchy where the link and unique IDs are extracted from the device path. For example this device is connected to master link ID 0 and has strap settings configuring it for unique ID 1: chip drivers/soundwire/alc5682 register "desc" = ""Headset Codec"" device generic 0.1 on end end This driver was tested with the volteer reference design by booting and disassembling the runtime SSDT to ensure that the devices have the expected address and properties. Device (SW01) { Name (_ADR, 0x000021025D568200) Name (_DDN, "Headset Codec") Name (_DSD, Package () { ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"), Package () { Package () { "mipi-sdw-sw-interface-revision", 0x00010000 }, [...] }, ToUUID ("dbb8e3e6-5886-4ba6-8795-1319f52a966b"), Package () { Package () { "mipi-sdw-port-bra-mode-0", "BRA0" }, Package () { "mipi-sdw-dp-0-subproperties", "DP0" }, Package () { "mipi-sdw-port-audio-mode-0", "MOD0" }, Package () { "mipi-sdw-dp-1-source-subproperties", "SRC1" }, Package () { "mipi-sdw-dp-1-sink-subproperties", "SNK1" }, [...] } } Name (BRA0, Package () { ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"), Package () { Package () { "mipi-sdw-bra-mode-bus-frequency-configs", Package () { 0x000F4240, [...] } }, [...] } } Name (DP0, Package () { ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"), Package () { Package () { "mipi-sdw-bra-flow-controlled", Zero }, [...] }, ToUUID ("dbb8e3e6-5886-4ba6-8795-1319f52a966b"), Package () { Package () { "mipi-sdw-port-bra-mode-0", "BRA0" } } } Name (MOD0, Package () { ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"), Package () { Package () { "mipi-sdw-audio-mode-bus-frequency-configs", Package () { 0x000F4240, [...] } }, [...] } } Name (SNK1, Package () { ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"), Package () { Package () { "mipi-sdw-data-port-type", Zero }, [...] }, ToUUID ("dbb8e3e6-5886-4ba6-8795-1319f52a966b"), Package () { Package () { "mipi-sdw-port-audio-mode-0", "MOD0" } } } Name (SNK1, Package () { ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"), Package () { Package () { "mipi-sdw-data-port-type", Zero }, [...] }, ToUUID ("dbb8e3e6-5886-4ba6-8795-1319f52a966b"), Package () { Package () { "mipi-sdw-port-audio-mode-0", "MOD0" } } } } BUG=b:146482091 Signed-off-by: Duncan Laurie <dlaurie@google.com> Change-Id: I488dcd81d2e66a6f2c269ab7fa9f7ceaf2cbf003 Reviewed-on: https://review.coreboot.org/c/coreboot/+/40891 Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-05-22drivers/soundwire/max98373: Support MAX98373 SoundWire deviceDuncan Laurie
The MAX98373 smart speaker amp can be connected over SoundWire and be configured for mainboards to use: - Data Port 0 and Bulk Register Access is not supported - Data Port 1 is the 32bit data input for the speaker path - Data Port 3 is the 16bit data output for I/V sense ADC path The data port and audio mode properties are filled out as best as possible with the datasheet as a reference. The ACPI address for the codec is calculated with the information in the codec driver combined with the devicetree.cb hierarchy where the link and unique IDs are extracted from the device path. For example this device is connected to master link ID 1 and has strap settings configuring it for unique ID 3. chip drivers/soundwire/max98373 register "desc" = ""Left Speaker Amp"" device generic 1.3 on end end This driver was tested with the volteer reference design by booting and disassembling the runtime SSDT to ensure that the devices have the expected address and properties. Device (SW13) { Name (_ADR, 0x000123019F837300) Name (_DDN, "Left Speaker Amp") Method (_STA) { Return (0x0F) } Name (_DSD, Package () { ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"), Package () { Package () { "mipi-sdw-sw-interface-revision", 0x00010000 }, [...] }, ToUUID ("dbb8e3e6-5886-4ba6-8795-1319f52a966b"), Package () { Package () { "mipi-sdw-port-audio-mode-0", "MOD0" }, Package () { "mipi-sdw-dp-1-sink-subproperties", "SNK1" }, Package () { "mipi-sdw-dp-3-source-subproperties", "SRC3" }, } } Name (MOD0, Package () { ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"), Package () { Package () { "mipi-sdw-audio-mode-bus-frequency-configs", Package () { 0x00753000, [...] } }, [...] } } Name (SNK1, Package () { ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"), Package () { Package () { "mipi-sdw-data-port-type", Zero }, [...] }, ToUUID ("dbb8e3e6-5886-4ba6-8795-1319f52a966b"), Package () { Package () { "mipi-sdw-port-audio-mode-0", "MOD0" } } } Name (SRC3, Package () { ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"), Package () { Package () { "mipi-sdw-data-port-type", Zero }, [...] }, ToUUID ("dbb8e3e6-5886-4ba6-8795-1319f52a966b"), Package () { Package () { "mipi-sdw-port-audio-mode-0", "MOD0" } } } } BUG=b:146482091 Signed-off-by: Duncan Laurie <dlaurie@google.com> Change-Id: I3f8cb2779ddde98c5df739bd8a1e83a12a305c00 Reviewed-on: https://review.coreboot.org/c/coreboot/+/40890 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
2020-05-19device: Add definitions for SoundWire specificationDuncan Laurie
This header implements structures to describe the properties defined in the SoundWire Discovery and Configuration Specification Version 1.0. By itself this just provides the property definitions, it is then used by the code that generates ACPI device properties and by the controller and codec drivers. A new header for MIPI vendor/device IDs is also added, with the MIPI Alliance board members added by default. This will be used in the same way as pci_ids.h to track devices added to coreboot. BUG=b:146482091 Signed-off-by: Duncan Laurie <dlaurie@google.com> Change-Id: Ie9901d26d1efe68edad7c049c98a976c4e4f06f4 Reviewed-on: https://review.coreboot.org/c/coreboot/+/40883 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
2020-05-16Revert "device: Enable resource allocation above 4G boundary"Furquan Shaikh
This reverts commit 44ae0eacb82259243bf844a3fe5ad24a7821e997. Reason for revert: Resource allocator patches need to be reverted until the AMD chipsets can be fixed to handle the resource allocation flow correctly. BUG=b:149186922 Change-Id: I90f3eac2d23b5f59ab356ae48ed94d14c7405774 Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/41412 Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Mike Banon <mikebdp2@gmail.com> Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr> Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-05-12util/sconfig: Add LPC and ESPI busesRaul E Rangel
Picasso has an LPC and eSPI bridge on the same PCI DEVFN. They can both be active at the same time. This adds a way to specify which devices belong on which bus. i.e., device pci 14.3 on # - D14F3 bridge device espi 0 on chip ec/google/chromeec device pnp 0c09.0 on end end end device lpc 0 on end end BUG=b:154445472 TEST=Built trembyle and saw static.c contained the espi bus. Signed-off-by: Raul E Rangel <rrangel@chromium.org> Change-Id: I0c2f40813c05680f72e5f30cbb13617e8f994841 Reviewed-on: https://review.coreboot.org/c/coreboot/+/41099 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2020-05-12southbridge/intel/common: Add Process CallChristian Walter
Add functionality to use process call cycle. It can be used to write/read data to/from e.g. EEPROM attached to SMBus Controller via I2C. Tested on: * C246 Change-Id: Ifdac6cf70a4ce744601f5d152a83d2125ea88360 Signed-off-by: Christian Walter <christian.walter@9elements.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/39875 Reviewed-by: Patrick Rudolph <siro@das-labor.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-05-12device/pci_device: Extract pci_domain_set_resources from SOCRaul E Rangel
pci_domain_set_resources is duplicated in all the SOCs. This change promotes the duplicated function. Picasso was adding it again in the northbridge patch. I decided to promote the function instead of duplicating it. BUG=b:147042464 TEST=Build and boot trembyle. Signed-off-by: Raul E Rangel <rrangel@chromium.org> Change-Id: Iba9661ac2c3a1803783d5aa32404143c9144aea5 Reviewed-on: https://review.coreboot.org/c/coreboot/+/41041 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2020-05-12device: Enable resource allocation above 4G boundaryFurquan Shaikh
This change adds support for allocating resources above the 4G boundary by making use of memranges for resource windows enabled in the previous CL. It adds a new resource flag IORESOURCE_ABOVE_4G which is used in the following ways: a) Downstream device resources can set this flag to indicate that they would like to have their resource allocation above the 4G boundary. These semantics will have to be enabled in the drivers managing the devices. It can also be extended to be enabled via devicetree. This flag is automatically propagated by the resource allocator from downstream devices to the upstream bridges in pass 1. It is done to ensure that the resource allocator has a global view of downstream requirements during pass 2 at domain level. b) Bridges have a single resource window for each of mem and prefmem resource types. Thus, if any downstream resource of the bridge requests allocation above 4G boundary, all the other downstream resources of the same type under the bridge will be allocated above 4G boundary. c) During pass 2, resource allocator at domain level splits IORESOURCE_MEM into two different memory ranges -- one for the window below 4G and other above 4G. Resource allocation happens separately for each of these windows. d) At the bridge level, there is no extra logic required since the resource will live entirely above or below the 4G boundary. Hence, all downstream devices of any bridge will fall within the window allocated to the bridge resource. To handle this case separately from that of domain, initializing of memranges for a bridge is done differently than the domain. Limitation: Resources of a given type at the bridge or downstream devices cannot live both above and below 4G boundary. Thus, if a bridge has some downstream resources requesting allocation for a given type above 4G boundary and other resources of the same type requesting allocation below 4G boundary, then all these resources of the same type get allocated above 4G boundary. BUG=b:149186922 TEST=Verified that resources get allocated above the 4G boundary correctly on volteer. Signed-off-by: Furquan Shaikh <furquan@google.com> Change-Id: I7fb2a75cc280a307300d29ddabaebfc49175548f Reviewed-on: https://review.coreboot.org/c/coreboot/+/39487 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-17 18:57:21 +0000