summaryrefslogtreecommitdiffstats
path: root/src/device/pci_device.c
Commit message (Collapse)AuthorAgeFilesLines
* device/device.h: Rename busses for clarityArthur Heymans2024-01-311-23/+23
| | | | | | | | | | This renames bus to upstream and link_list to downstream. Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Change-Id: I80a81b6b8606e450ff180add9439481ec28c2420 Reviewed-on: https://review.coreboot.org/c/coreboot/+/78330 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
* device/device.h: Drop multiple linksArthur Heymans2024-01-291-5/+2
| | | | | | | | | | | | | | | | | | | | Multiple links are unused throughout the tree and make the code more confusing as an iteration over all busses is needed to get downstream devices. This also not done consistently e.g. the allocator does not care about multiple links on busses. A better way of dealing multiple links below a device is to feature dummy devices with each their respective bus. This drops the sconfig capability to declare the same device multiple times which was previously used to declare multiple links. Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Change-Id: Iab6fe269faef46ae77ed1ea425440cf5c7dbd49b Reviewed-on: https://review.coreboot.org/c/coreboot/+/78328 Reviewed-by: Felix Held <felix-coreboot@felixheld.de> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Jincheng Li <jincheng.li@intel.com> Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
* device: Add support for multiple PCI segment groupsFelix Held2024-01-161-3/+12
| | | | | | | | | | | | | | | | | | Add initial support for multiple PCI segment groups. Instead of modifying secondary in the bus struct introduce a new segment_group struct element and keep existing common code. Since all platforms currently only use 1 segment this is not a functional change. On platforms that support more than 1 segment the segment has to be set when creating the PCI domain. Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com> Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ied3313c41896362dd989ee2ab1b1bcdced840aa8 Reviewed-on: https://review.coreboot.org/c/coreboot/+/79927 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de> Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
* x86: Separate CPU and SoC physical address sizeJeremy Compostella2023-12-221-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | The physical address size of the System-on-Chip (SoC) can be different from the CPU physical address size. These two different physical address sizes should be used for settings of their respective field. For instance, the physical address size related to the CPU should be used for MTRR programming while the physical address size of the SoC should be used for MMIO resource allocation. Typically, on Meteor Lake, the CPUs physical address size is 46 if TME is disabled and 42 if TME is enabled but Meteor Lake SoC physical address size is always 42. As a result, MTRRs should reflect the TME status while coreboot MMIO resource allocator should always use 42 bits. This commit introduces `SOC_PHYSICAL_ADDRESS_WIDTH' Kconfig to set the physical address size of the SoC for those SoCs. BUG=b:314886709 TEST=MTRR are aligned between coreboot and FSP Change-Id: Icb76242718581357e5c62c2465690cf489cb1375 Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/79665 Reviewed-by: Paul Menzel <paulepanter@mailbox.org> Reviewed-by: Subrata Banik <subratabanik@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
* device/device.h: Rename pci_domain_scan_busArthur Heymans2023-10-201-1/+1
| | | | | | | | | | | | | | On all targets the domain works as a host bridge. Xeon-sp code intends to feature multiple host bridges below a domain, hence rename the function to pci_host_bridge_scan_bus. Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Change-Id: I4e65fdbaf0b42c5f4f62297a60d818d299d76f73 Reviewed-on: https://review.coreboot.org/c/coreboot/+/78326 Reviewed-by: Felix Held <felix-coreboot@felixheld.de> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Reviewed-by: Yidi Lin <yidilin@google.com>
* commonlib/console/post_code.h: Change post code prefix to POSTCODElilacious2023-06-231-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The prefix POSTCODE makes it clear that the macro is a post code. Hence, replace related macros starting with POST to POSTCODE and also replace every instance the macros are invoked with the new name. The files was changed by running the following bash script from the top level directory. sed -i'' '30,${s/#define POST/#define POSTCODE/g;}' \ src/commonlib/include/commonlib/console/post_codes.h; myArray=`grep -e "^#define POSTCODE_" \ src/commonlib/include/commonlib/console/post_codes.h | \ grep -v "POST_CODES_H" | tr '\t' ' ' | cut -d ' ' -f 2`; for str in ${myArray[@]}; do splitstr=`echo $str | cut -d '_' -f2-` grep -r POST_$splitstr src | \ cut -d ':' -f 1 | xargs sed -i'' -e "s/POST_$splitstr/$str/g"; grep -r "POST_$splitstr" util/cbfstool | \ cut -d ':' -f 1 | xargs sed -i'' -e "s/POST_$splitstr/$str/g"; done Change-Id: I25db79fa15f032c08678f66d86c10c928b7de9b8 Signed-off-by: lilacious <yuchenhe126@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/76043 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Subrata Banik <subratabanik@google.com>
* device/pci: Limit default domain memory windowNico Huber2023-06-011-1/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When the default pci_domain_read_resources() is used, keep 32-bit memory resources below the limit given by CONFIG_DOMAIN_RESOURCE_32BIT_LIMIT. This serves as a workaround for missing/wrong reservations of chipset resources. This will help to get more stable results from our own allocator, but is far from a complete solution. Indvi- dual platform ASL code also needs to be considered, so the OS won't assign conflicting resources. Most platforms have reserved space between 0xfe000000 and the 4G barrier. So use that as a global default. In case of `soc/intel/common/`, use 0xe0000000 because this is what is advertised in ACPI and there are traces of resources below 0xfe000000 that are unknown to core- boot's C code (PCH_PRESERVED_BASE?). Tested on QEMU/Q35 and Siemens/Chili w/ and w/o top- down allocation. Fixes EHCI w/ top-down in QEMU. Change-Id: Iae0d888eebd0ec11a9d6f12975ae24dc32a80d8c Signed-off-by: Nico Huber <nico.huber@secunet.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/75102 Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Paul Menzel <paulepanter@mailbox.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
* device/pci_device.c: Add way to limit max bus numbersArthur Heymans2023-02-061-1/+13
| | | | | | | | | | | | | | | By default this limits PCI buses to CONFIG_MMCONF_BUS_NUMBER. Some platforms have multiple PCI root busses (e.g. xeon_sp), where bus numbers are limited. This provides a basic check. On some platforms it looks like programming 0xff to the subordinate bus number confuses and hangs the hardware. Change-Id: I0582b156df1a5f76119a3687886c4d58f2d3ad6f Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/59395 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Jonathan Zhang <jonzhang@fb.com> Reviewed-by: David Hendricks <david.hendricks@gmail.com>
* src/device/pci_: Remove unnecessary space after castsElyes Haouas2022-11-221-11/+11
| | | | | | | | Change-Id: I11593245fedc26489e3506d773aaff1ad34188b1 Signed-off-by: Elyes Haouas <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/69804 Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
* device & commonlib: Update pci_scan_bus postcodesMartin Roth2022-11-121-4/+2
| | | | | | | | | | | | | | | | | | | | The function pci_scan_bus had 3 post codes in it: 0x24 - beginning 0x25 - middle 0x55 - end I got rid of the middle postcode and used 0x25 for the code signifying the end of the function. I don't think all three are needed. 0x24 & 0x25 postcodes are currently also used in intel cache-as-ram code. Those postcodes should be adjusted to avoid conflicting. Signed-off-by: Martin Roth <gaumless@gmail.com> Change-Id: I19c9d5e256505b64234919a99f73a71efbbfdae3 Reviewed-on: https://review.coreboot.org/c/coreboot/+/69201 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Elyes Haouas <ehaouas@noos.fr> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
* /: Remove "ERROR: "/"WARNING: " prefixes from log messagesElyes Haouas2022-11-101-2/+2
| | | | | | | | | | | | It is no longer necessary to explicitly add "ERROR: "/"WARNING: " in front of every BIOS_ERR/BIOS_WARN message. Change-Id: I22ee6ae15c3d3a848853c5460b3b3c1795adf2f5 Signed-off-by: Elyes Haouas <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/69405 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com> Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
* device/pci_device: Add missing spaces to log messagesPaul Menzel2022-09-081-4/+4
| | | | | | | | | | | | Add the missing spaces to two log message, like the one below. WARNING: Device PCI: 03:00.0 requests a BAR with34 bits of address space, which coreboot is notconfigured to hand out, truncating to 29 bits Change-Id: If933d8fb0db5b58ff12f043cc73172a3f6ffc624 Signed-off-by: Paul Menzel <pmenzel@molgen.mpg.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/67370 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
* pciexp_device: Propagate above-4G flag to all hotplug devicesNico Huber2022-09-041-1/+5
| | | | | | | | | | | | | | | | The `IORESOURCE_ABOVE_4G` flag was only explicitly set for our dummy device that reserves resources behind a hotplug port. The current re- source allocator implicitly extends this to all devices below the port, including real ones. Let's make that explicit, so future changes to the allocator can't break this rule. Change-Id: Id4c90b60682cf5c8949cde25362d286625b3e953 Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/66719 Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
* pciexp_device: Join pciexp_find_(next_)extended_cap() APIsNico Huber2022-08-171-1/+1
| | | | | | | | | | | | | | | Move the `offset` parameter into pciexp_find_extended_cap(). If it's called with `0`, we start a new search. If it's an existing offset, we continue the search. This makes it easier to search for multiple occurences of a capa- bility in a single loop. Change-Id: I80115372a82523b90460d97f0fd0fa565c3f56cb Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/66453 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
* pci_device: Add a function to find PCI capability ID recursivelyBill XIE2022-08-071-0/+24
| | | | | | | | | | | | | Some PCI capabilities should only be enabled if it is available not only on a device, but also all bridge upstream of it. Checking only the device and the bridge just above it may not be enough. Signed-off-by: Bill XIE <persmule@hardenedlinux.org> Change-Id: I1237d3b4b86dd0ae5eb586e3c3c407362e6ca291 Reviewed-on: https://review.coreboot.org/c/coreboot/+/66383 Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
* device: Add IORESOURCE_ABOVE_4G flag to PCI64 resourcesTim Wawrzynczak2022-05-291-1/+3
| | | | | | | | | | | | | | | When a PCI resource is marked as 64-bits, the IORESOURCE_ABOVE_4G flag needs to be passed to the v4 allocator to ensure that the resource will be allocated in a range large enough to succeed. BUG=b:214443809 TEST=agah can successfully allocate all of the Nvidia GN20 BARs Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org> Change-Id: I3f16f52f2a64f8728853df263da29871dca533f7 Reviewed-on: https://review.coreboot.org/c/coreboot/+/64725 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin L Roth <gaumless@tutanota.com>
* device/pci_device.c: Return if the scan parameter is invalidArthur Heymans2022-03-301-0/+2
| | | | | | | | | | | Clang is unhappy about codepath of an invalid parameter because variables remain unset. Change-Id: I1ba392a48cf3f81a29d9645e5cf220b122d588af Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/63038 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
* device/pci_device.c: Improve pci_bridge_route() readabilityArthur Heymans2022-03-021-13/+13
| | | | | | | | | | | | | Both the secondary and subordinate bus numbers are configured in this function but it's not easy to search for in the tree as the PCI writes are hidden inside a bigger write to 'PCI_PRIMARY_BUS'. Use separate variables and PCI config writes to improve the readability. Change-Id: I3bafd6a2e1d3a0b8d1d43997868a787ce3940ca9 Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/59131 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de>
* device/pci_device: Fix PCIe bridge detectionNico Huber2022-02-281-0/+3
| | | | | | | | | | | | | | | | | | PCI bus 0 is not below any PCI device. In case of pci_domain_scan_bus(), it's our virtual `domain` device. Expecting a PCI device above bus 0 resulted in undefined behavior for all boards with PCI. Only boards with a PCI device 00:00.0 that looked like a PCIe bridge showed issues, though (e.g. OCP/DeltaLake). Change-Id: I1fd68b9dc0d2e388ec2bbba4adbadd33e14f0171 Signed-off-by: Nico Huber <nico.h@gmx.de> Fixes: commit 777ffff442 (device/pci_device.c: Scan only one device for PCIe) Reviewed-on: https://review.coreboot.org/c/coreboot/+/62376 Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Paul Menzel <paulepanter@mailbox.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
* device: Add support for PCIe Resizable BARsTim Wawrzynczak2022-02-161-3/+136
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Section 7.8.6 of the PCIe spec (rev 4) indicates that some devices can indicates support for "Resizable BARs" via a PCIe extended capability. When support this capability is indicated by the device, the size of each BAR is determined in a different way than the normal "moving bits" method. Instead, a pair of capability and control registers is allocated in config space for each BAR, which can be used to both indicate the different sizes the device is capable of supporting for the BAR (powers-of-2 number of bits from 20 [1 MiB] to 63 [8 EiB]), and to also inform the device of the size that the allocator actually reserved for the MMIO range. This patch adds a Kconfig for a mainboard to select if it knows that it will have a device that requires this support during PCI enumeration. If so, there is a corresponding Kconfig to indicate the maximum number of bits of address space to hand out to devices this way (again, limited by what devices can support and each individual system may want to support, but just like above, this number can range from 20 to 63) If the device can support more bits than this Kconfig, the resource request is truncated to the number indicated by this Kconfig. BUG=b:214443809 TEST=compile (device with this capability not available yet), also verify that no changes are seen in resource allocation for google/brya0 before and after this change. Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org> Change-Id: I14fcbe0ef09fdc7f6061bcf7439d1160d3bc4abf Reviewed-on: https://review.coreboot.org/c/coreboot/+/61215 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Subrata Banik <subratabanik@google.com>
* treewide: Remove "ERROR: "/"WARN: " prefixes from log messagesJulius Werner2022-02-071-4/+3
| | | | | | | | | | | | | | | | | | | | | | | | | Now that the console system itself will clearly differentiate loglevels, it is no longer necessary to explicitly add "ERROR: " in front of every BIOS_ERR message to help it stand out more (and allow automated tooling to grep for it). Removing all these extra .rodata characters should save us a nice little amount of binary size. This patch was created by running find src/ -type f -exec perl -0777 -pi -e 's/printk\(\s*BIOS_ERR,\s*"ERROR: /printk\(BIOS_ERR, "/gi' '{}' ';' and doing some cursory review/cleanup on the result. Then doing the same thing for BIOS_WARN with 's/printk\(\s*BIOS_WARNING,\s*"WARN(ING)?: /printk\(BIOS_WARNING, "/gi' Signed-off-by: Julius Werner <jwerner@chromium.org> Change-Id: I3d0573acb23d2df53db6813cb1a5fc31b5357db8 Reviewed-on: https://review.coreboot.org/c/coreboot/+/61309 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr> Reviewed-by: Lance Zhao Reviewed-by: Jason Glenesk <jason.glenesk@gmail.com>
* device/pci_device.c: Make sure the PCI bus has a deviceArthur Heymans2022-01-121-0/+3
| | | | | | | | | | | | | | Some SOC add PCI root busses structs at runtime without adding a device struct to the bus because pci_scan_bus does it. An example would be xeon_sp which has multiple root busses. TEST: ocp/deltalake boots again. Change-Id: I81d9c94652e34dbf9e8cec64fc34ef0042563037 Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/60876 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Jonathan Zhang <jonzhang@fb.com>
* pci_device.c: Don't guard `pci_dev_disable_bus_master()`Angel Pons2022-01-011-5/+5
| | | | | | | | | | | | The `pci_dev_disable_bus_master()` function doesn't need to be guarded with `CONFIG(PC80_SYSTEM)`, so move it out of the guard. Change-Id: I813e0f72c3c624c73ab9ecbe7512359608ace927 Signed-off-by: Angel Pons <th3fanbus@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/60599 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de> Reviewed-by: Felix Singer <felixsinger@posteo.net>
* device/pci_device.c: Scan only one device for PCIeJianjun Wang2021-11-291-0/+27
| | | | | | | | | | | | | Only scan one device if it's a PCIe downstream port. A PCIe downstream port normally leads to a link with only device 0 on it. As an optimization, scan only for device 0 in that case. Signed-off-by: Jianjun Wang <jianjun.wang@mediatek.com> Change-Id: Id184d03b33e1742b18efb3f11aa9b2f81fa03806 Reviewed-on: https://review.coreboot.org/c/coreboot/+/56788 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Yu-Ping Wu <yupingso@google.com>
* device: Reflow strings in printk statementsAngel Pons2021-07-051-11/+10
| | | | | | | | | | | | | To ease finding some log messages, reflow their strings to use one line. Tested with BUILD_TIMELESS=1, Asrock B85M Pro4 remains identical. Change-Id: I5284429ca6d07debf2d6c4fdbffa286140fb7694 Signed-off-by: Angel Pons <th3fanbus@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/56057 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Paul Menzel <paulepanter@mailbox.org> Reviewed-by: Nico Huber <nico.h@gmx.de>
* device/pci_device.c: Reuse `irq` variableAngel Pons2021-07-011-3/+2
| | | | | | | | | | | The `irq` variable has the same value as `pIntAtoD[line - 1]`. Change-Id: Iabf760adbc3014b32cfe6f908dc04c38b71bd980 Signed-off-by: Angel Pons <th3fanbus@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/55892 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Paul Menzel <paulepanter@mailbox.org> Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
* device/pci_device.c: Drop redundant guardAngel Pons2021-06-301-2/+0
| | | | | | | | | | | This guard is nested inside an identical guard already. Change-Id: I2b315ee6620865429097041035ad493ddcc51884 Signed-off-by: Angel Pons <th3fanbus@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/55891 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Paul Menzel <paulepanter@mailbox.org> Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
* device/pciexp_device.c: Remove CPP guardingArthur Heymans2021-03-141-7/+8
| | | | | | | | | | | | Let the linker do its job. This fixes building with !CONFIG_PCIEXP_HOTPLUG on some platforms. Change-Id: I46560722dcb5f1d902709e40b714ef092515b164 Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/51417 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Nico Huber <nico.h@gmx.de>
* device: Add unit to Kconfig option name: `PRE_GRAPHICS_DELAY_MS`Paul Menzel2021-02-151-2/+2
| | | | | | | | | | | It’s good practice to put the unit into the name. Change-Id: I1493f61d4e495c22f09abf1829bb2eab9b1fd2b6 Signed-off-by: Paul Menzel <pmenzel@molgen.mpg.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/50517 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Nico Huber <nico.h@gmx.de>
* soc/intel/broadwell: Conditionally skip PRE_GRAPHICS_DELAYKyösti Mälkki2021-02-061-0/+9
| | | | | | | | | | | | | | | | | | It was commented that the need for the delay was mainly related to external displays and only with VBIOS execution. Move the delay such that it is done only when we actually need to execute the VBIOS aka option rom. A delay is currently only defined for librem/purism_bdw in its Kconfig. As the description of the issue sounds like it would equally happen on other platforms when VBIOS is involved, promote the Kconfig visible option to global scope. Change-Id: I4503158576f35057373f003586bbf76af4d59b3d Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/48787 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
* device/pci_device.c: Use __func__Elyes HAOUAS2021-01-261-5/+4
| | | | | | | | Change-Id: Ia6c7de99164682dcbcc375969403d2bfb9675f3c Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/49544 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
* device/pci_device.c: Remove repeated wordElyes HAOUAS2021-01-181-1/+1
| | | | | | | | Change-Id: Ia6936675684e3eaf2a57e2d28e465b1f0768249b Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/49512 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Jacob Garber <jgarber1@ualberta.ca>
* device/pci_device.c: Use same indents for switch/caseFelix Singer2021-01-121-1/+1
| | | | | | | | | | Use same indents for switch/case to fix linter issues. Change-Id: I5c6abf5b918bac3df8d7617824392f2ec932cb32 Signed-off-by: Felix Singer <felixsinger@posteo.net> Reviewed-on: https://review.coreboot.org/c/coreboot/+/49205 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
* device: Drop unused HyperTransport codeAngel Pons2020-11-251-14/+0
| | | | | | | | | | Only two definitions are actually used somewhere, the rest is unused. Change-Id: Iec52d0d47fce6a1ec5455b670824b995a7a34a4c Signed-off-by: Angel Pons <th3fanbus@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/47407 Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
* device/pci: Add NULL check for PCI driver's .opsNico Huber2020-11-161-4/+7
| | | | | | | | | | | | | | | | | | | Add a NULL check and only skip setting the default operations if `.ops` was set by a driver. It's fairly unlikely that some- body adds a driver and forgets the `.ops` pointer. So this is mostly to increase readability: Nobody should have to wonder if we're missing a NULL-check. The condition is moved out of the loop to reduce indentation levels. Alternatively, we could jusk skip drivers that don't have `.ops` set (i.e. continue the loop). Change-Id: I5dcc05ebb092fb9c4be929c81ea2b05a10b1311b Signed-off-by: Nico Huber <nico.huber@secunet.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/46297 Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
* device: Enable bus mastering on system-class devices conditionallyFelix Singer2020-11-161-1/+2
| | | | | | | | | | | | Devices of class type "system" are arbitrary devices and it's not clear which of them need bus mastering. Therefore, enable bus mastering conditionally based on Kconfig option PCI_ALLOW_BUS_MASTER_ANY_DEVICE. Change-Id: Ia04e83606a0a081c0758ec59e52627aa1dbd2622 Signed-off-by: Felix Singer <felix.singer@secunet.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/45151 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de>
* device: Allow configuring bus mastering for PCI bridges conditionallyFelix Singer2020-11-161-1/+2
| | | | | | | | Change-Id: Ic7cacce28f473dda76ca203016dbb8e00149a990 Signed-off-by: Felix Singer <felix.singer@secunet.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/45150 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de>
* device: Move pci_dev_is_wake_source functionTim Wawrzynczak2020-11-091-18/+0
| | | | | | | | | | | | | Move this function to pci_ops.c, which is already included in the smm build. This is required to use this function in elog functionality, which is called from SMM. Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org> Change-Id: Ie5583c04366c9a16bc1b00a6892d39eeafe5da49 Reviewed-on: https://review.coreboot.org/c/coreboot/+/47260 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Furquan Shaikh <furquan@google.com> Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
* device: Allow virtual/generic devices under PCI in devicetreeDuncan Laurie2020-10-211-10/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This change allows a generic device to be described in the devicetree under a PCI device, such as a root port. Previously any device under a PCI device was expected to also be a PCI device and that does not allow for a virtual/generic device to be present, for example to provide ACPI properties for a root port. The changes are: - Ignore non-PCI devices found under a PCI device when scanning and do not print an error for each devfn scanned. - Don't treat non-PCI devices as leftover and remove them, instead enable them as a static device. - Don't attempt to configure a static device in the tree that is not a PCIe device type. With these changes it is now possible to have a generic device under a PCI device, for example in a USB4/TBT root port (PCIe hotplug device) this generic device will add ACPI properties for the PCIe tunnel routed to the external port: device pci 07.0 on chip soc/intel/common/block/pcie device generic 0 on end end end TEST=boot on volteer with the USB4 root port devices in chipset.cb and ensure they are enabled properly and there are no errors printed in the coreboot log, and that the device properties are created in the SSDT. Signed-off-by: Duncan Laurie <dlaurie@google.com> Change-Id: I56a491808067dc862a7adfd46852f0bd6b41cd95 Reviewed-on: https://review.coreboot.org/c/coreboot/+/46542 Reviewed-by: Furquan Shaikh <furquan@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
* pci_device: Add a helper function for determining if PCI device is wake sourceFurquan Shaikh2020-10-111-0/+18
| | | | | | | | | | | | | | | | This change adds a helper function `pci_dev_is_wake_source()` that checks PME_STATUS and PME_ENABLE bits in PM control and status register to determine if the given device is the source of wake. BUG=b:169802515 BRANCH=zork Change-Id: I06e9530b568543ab2f05a4f38dc5c3a527ff391e Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/46030 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Rob Barnes <robbarnes@google.com> Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
* src/device: Drop unneeded empty linesElyes HAOUAS2020-09-211-1/+0
| | | | | | | | Change-Id: Ief990b4174d13b3472ac75a042ae8d878640dda3 Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/44608 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
* Revert "device/pci_device.c: Do not complain about disabled devices"Nico Huber2020-08-041-4/+0
| | | | | | | | | | | | | This reverts commit ad247ac5d8ef4a38bd1d61fbd28076f343a46c5c. It doesn't work like this. The `dev->enable` field has already been updated and is always `0` at this point. Change-Id: I5b3560dcea2f226c841f4823526db2fdab149d22 Signed-off-by: Nico Huber <nico.huber@secunet.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/44078 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
* device/pci_device.c: Do not complain about disabled devicesAngel Pons2020-07-241-0/+4
| | | | | | | | | | | | | | One would expect disabled devices to not be present. So, don't print misleading warnings about it, because it only confuses people. Change-Id: I0f14174a1d460a479dc9f15b63486f4f27b8f67c Signed-off-by: Angel Pons <th3fanbus@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/43767 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de> Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Furquan Shaikh <furquan@google.com> Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
* device/pci_device.c: Drop dead codeAngel Pons2020-07-091-5/+0
| | | | | | | | | | This code is not even being build-tested. Drop it before it grows moss. Change-Id: Id3f9dd264e82f93a438422e388d70e3f88ae0df9 Signed-off-by: Angel Pons <th3fanbus@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/43210 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Michael Niewöhner
* device: Add a disabling PCIe device bus master functionJohn Zhao2020-06-081-0/+5
| | | | | | | | | | | | | | | 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>
* src: Remove redundant includesElyes HAOUAS2020-06-021-1/+0
| | | | | | | | | | | | | <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>
* device/pci: Handle unassigned bus resources gracefullyNico Huber2020-05-261-4/+10
| | | | | | | | | | | | | | The I/O windows of PCI bridges can be disabled individually by setting their limit lower than their base. Always do this if a resource wasn't assigned a value. Change-Id: I73f6817c4b12cb1689627044735d1fed6d825afe Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/41552 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Furquan Shaikh <furquan@google.com>
* device/pci: Refactor pci_set_resource()Nico Huber2020-05-261-54/+65
| | | | | | | | | | | | | This function is too long and quirky. Factor the actual resource write out, so we can focus on the logic. Change-Id: I6c7f930614dcd63d4ee2a4ca7cf541a9de4fd557 Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/41551 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Furquan Shaikh <furquan@google.com>
* device/pci_device: Add notion of "hidden" PCI devicesTim Wawrzynczak2020-05-201-2/+61
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On some SoCs, there are PCI devices that may get hidden from PCI enumeration by platform firmware. Because the Vendor ID reads back as 0xffffffff, it appears that there is no PCI device located at that BDF. However, because the device does exist, designers may wish to hang its PCI resources off of a real __pci_driver, as well as have it participate in ACPI table generation. This patch extends the semantics of the 'hidden' keyword in devicetree.cb. If a device now uses 'hidden' instead of 'on', then it will be assumed during PCI enumeration that the device indeed does exist, and it will not be removed as a "leftover device." This allows child devices to be enumerated correctly and also PCI resources can be designated from the {read,set}_resources callbacks. It should be noted that as of this commit, there are precisely 0 devices using 'hidden' in their devicetree.cb files, so this should be a safe thing to do. Later patches will begin moving PCI resources from random places (typically hung off of fixed SA and LPC) into the PMC device (procedure will vary per- platform). Change-Id: I16c2d3e1d1433343e63dfc16856cff69cd815e2a Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org> Reviewed-on: https://review.coreboot.org/c/coreboot/+/41384 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Furquan Shaikh <furquan@google.com>
* device/pci_device: Remove useless pci_bus_ops_pciTim Wawrzynczak2020-05-181-5/+0
| | | | | | | | | | | | | | | | The struct (formerly assigned to default_pci_ops_bus.ops_pci) only contained a NULL (well, 0) pointer for the set_subsystem callback, but usage of that callback is guarded with NULL checks when it is used, therefore it can be removed. TEST=still compiles Change-Id: I3943c8ae73b95e744a317264d7ceb8929cb28341 Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org> Reviewed-on: https://review.coreboot.org/c/coreboot/+/41432 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Furquan Shaikh <furquan@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-10 12:09:52 +0000