summaryrefslogtreecommitdiffstats
path: root/src/device/pciexp_device.c
Commit message (Collapse)AuthorAgeFilesLines
* device/device.h: Rename busses for clarityArthur Heymans2024-01-311-5/+5
| | | | | | | | | | 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>
* arch to drivers/intel: Fix misspellings & capitalization issuesMartin Roth2023-09-081-1/+1
| | | | | | | | | Signed-off-by: Martin Roth <gaumless@gmail.com> Change-Id: Ic52f01d1d5d86334e0fd639b968b5eed43a35f1d Reviewed-on: https://review.coreboot.org/c/coreboot/+/77633 Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com> Reviewed-by: Elyes Haouas <ehaouas@noos.fr> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
* device/pciexp_device.c: Do not enable common clock if already activeWerner Zeh2023-03-021-0/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The Common Clock Configuration (CCC) is a PCIe feature for cases where the upstream and downstream device of a link share the same reference clock. After a change in this setting a link re-training is mandatory to make it effective. On recent Intel platforms (tested on Elkhart Lake) the FSP code which is executed before coreboot performs the PCI scan already enumerates all PCI buses for its internal uses. While this is done, all the PCI express features of a link are configured, which includes CCC. If the link supports common clock, FSP performs the link re-training already. When the execution flow is returned to coreboot, the same link treatment is applied again (coded in 'pciexp_tune_dev()') and CCC is enabled a second time, just a few milliseconds after FSP did this already. Because enabling CCC requires a link re-training, there are two link re-trainings on the PCIe link within a few milliseconds (one from the FSP code and one from coreboot) which can lead to issues with a connected PCIe device on this link. In particular, link issues were discovered with a Pericom PCIe switch (PI7C9X2G608) on mc_ehl1 where the link has stalled for a while after the second re-training. This in turn leads to non-initialized PCI devices on the bus after coreboot has finished. This patch checks if CCC is already enabled on a link and does not perform the steps to enable it again in coreboot which safes a link re-training (and thus execution time) and a potential link stability issue. Test=Check log output on mc_ehl1 which shows the following lines: [DEBUG] PCI: pci_scan_bus for bus 09 [DEBUG] PCI: 09:00.0 [8086/1533] enabled [INFO ] PCIe: Common Clock Configuration already enabled Change-Id: I747fa406a120a215de189d7252f160c8ea2e3716 Signed-off-by: Werner Zeh <werner.zeh@siemens.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/73310 Reviewed-by: Subrata Banik <subratabanik@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
* device/pciexp: add pcie_find_dsn()Jonathan Zhang2022-11-201-0/+51
| | | | | | | | | | | Add pcie_find_dsn() to detect and match PCIe device serial number. In addition, vendor ID is matched when provided. Change-Id: I54b6dc42c8da47cd7b4447ab23a6a21562c7618 Signed-off-by: Jonathan Zhang <jonzhang@meta.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/54510 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Marc Jones <marc@marcjonesconsulting.com>
* device: Clear lane error statusWilson Chou2022-09-121-0/+28
| | | | | | | | | | | | | | | | | | | | | Refer to PCI Express Base rev6.0 v1.0, 4.2.7 Link Training and Status State Rules, Lane Error Status is normal to record the error when link training. To make sure Lane Error Status is correct in OS runtime, add a Kconfig PCIEXP_LANE_ERR_STAT_CLEAR that clears the PCIe lane error status register at the end of PCIe link training. Test=On Crater Lake, lspci -vvv shows bb:01.0 PCI bridge: Intel Corporation Device 352a (rev 03) (prog-if 00 [Normal decode]) Capabilities: [a30 v1] Secondary PCI Express LnkCtl3: LnkEquIntrruptEn- PerformEqu- LaneErrStat: LaneErr at lane: 0 Signed-off-by: Wilson Chou <Wilson.Chou@quantatw.com> Change-Id: I6344223636409d8fc25e365a6375fc81e69f41a5 Reviewed-on: https://review.coreboot.org/c/coreboot/+/67264 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Jonathan Zhang <jonzhang@fb.com>
* pciexp_device: Propagate above-4G flag to all hotplug devicesNico Huber2022-09-041-0/+1
| | | | | | | | | | | | | | | | 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: Move PCI path check one level up to pciexp_enable_ltr()Nico Huber2022-08-291-2/+3
| | | | | | | | | | | | | If we have a PCIe root port without `ops_pci` or without `get_ltr_max_latencies`, the parent device wouldn't be PCI. Hence, check for a PCI path early. Change-Id: I358cb6756750bb10d0a23ab7133b917bfa25988b Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/66845 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Jonathan Zhang <jonzhang@fb.com> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
* pciexp_device: Fix offset handling for extended capabilitiesNico Huber2022-08-171-2/+2
| | | | | | | | | | | | | | | | | The PCIe spec explicitly states that the bottom-two bits of the next offset are reserved for future use and should be masked. We can also change the loop condition to avoid wrong offsets below 0x100 (exten- ded capabilities always reside in the extended config space). The whole patch series was tested on Google Samus and keeps the L1ss configuration of the WiFi device in tact. Change-Id: I0b622a0ce0a4a1127d266226ade0ec1e66e9fb79 Signed-off-by: Nico Huber <nico.h@gmx.de> Tested-by: Patrick Georgi <patrick@coreboot.org> Reviewed-on: https://review.coreboot.org/c/coreboot/+/66459 Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
* pciexp: Refactor extended capability handlingNico Huber2022-08-171-11/+21
| | | | | | | | | | | | Add some inline functions for the bit-wise operations, change the loop body to an if-bail-out style and remove stateful variables. Change-Id: Ia8db915f375737064e3486d313383d9b6c3eb2b8 Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/66458 Reviewed-by: Bill XIE <persmule@hardenedlinux.org> Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
* pciexp_device: Drop quirk handling in pciexp_get_ext_cap_offset()Nico Huber2022-08-171-4/+1
| | | | | | | | | | | | | | | | | Keeping these checks in generic code seems rather dangerous. In theory, it could lead to endless loops even for compliant devices, if we accidentally detect arbitrary register contents as capability and use them as a pointer to another one. Not to forget that the register reads can have side effects. All users of this `cafe` have been converted to use pciexp_find_ext_vendor_cap(). Change-Id: I70d21534e04282a4156572a290b83c46be085e0c Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/66456 Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
* pciexp_device: Properly search for Intel's 0xcafe capabilityNico Huber2022-08-171-1/+5
| | | | | | | | | | | | | | | | | | | | We have this quirk in our tree since the introduction of L1-substate support[1]. The way we searched for this capability was rather crude: We simply assumed that it would show up in the first data word of another capability. As it turned out that it is actually a proper vendor-specific capa- bility that we are looking for, we can drop some of the mystic code. This was confirmed to work on the device that was originally used during development, Google/Samus. [1] commit 31c6e632cf (PCIe: Add L1 Sub-State support.) Change-Id: I886fb96e9a92387bc0e2a7feb746f7842cee5476 Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/66455 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
* pciexp_device: Introduce pciexp_find_ext_vendor_cap()Nico Huber2022-08-171-0/+29
| | | | | | | | | | | | Vendors can choose to add non-standard capabilities inside a Vendor-Specific Extended Capability. These are identified by the Extended Capability ID 0x0b. Change-Id: Idd6dd0e98bd53b19077afdd4c402114578bec966 Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/66454 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
* pciexp_device: Join pciexp_find_(next_)extended_cap() APIsNico Huber2022-08-171-11/+23
| | | | | | | | | | | | | | | 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>
* pciexp_device: Fix pciexp_find_next_extended_cap()Nico Huber2022-08-151-2/+2
| | | | | | | | | | | | | | | | | If we already encountered the last extended capability in the list, we'd call pciexp_get_ext_cap_offset() with `offset == 0`. So it also needs to check if the passed offset is valid. As there were no callers of pciexp_find_next_extended_cap() yet, pciexp_get_ext_cap_offset() was only ever called with `PCIE_EXT_CAP_OFFSET`. Change-Id: I155c4691a34ff16661919913a3446fa915ac535e Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/66452 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Bill XIE <persmule@hardenedlinux.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
* pciexp_device: Handle unsupported requests in pciexp_get_ext_cap_offset()Bill XIE2022-08-071-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Looking into pciexp_get_ext_cap_offset() it seems a little hackish and prone to endless loops. Either it should limit the loop or bail out when pci_read_config32() returns 0xffffffff, meaning "Unsupported Requests". This commit fixes an endless loop when the queried PCIe device is downstream of a legacy PCI bus which doesn't support extended config space, thus pci_read_config32() will return 0xffffffff, for example, the combination below with CONFIG_PCIEXP_SUPPORT_RESIZABLE_BARS enabled. TEST=Build and boot to OS in ASUS P8C WS with the following peripherals and CONFIG_PCIEXP_SUPPORT_RESIZABLE_BARS enabled: 00:1c.4 PCI bridge [0604]: Intel Corporation 7 Series/C210 Series Chipset Family PCI Express Root Port 5 [8086:1e18] (rev c4) 00:1c.4/00.0 SATA controller [0106]: Marvell Technology Group Ltd. 88SE9170 PCIe 2.0 x1 2-port SATA 6 Gb/s Controller [1b4b:9170] (rev 13) 00:1e.0 PCI bridge [0604]: Intel Corporation 82801 PCI Bridge [8086:244e] (rev a4) 00:1e.0/00.0 PCI bridge [0604]: PLX Technology, Inc. PEX 8111 PCI Express-to-PCI Bridge [10b5:8111] (rev 21) 00:1e.0/03.0 FireWire (IEEE 1394) [0c00]: VIA Technologies, Inc. VT6306/7/8 [Fire II(M)] IEEE 1394 OHCI Controller [1106:3044] (rev c0) 00:1e.0/00.0/00.0 Network controller [0280]: Qualcomm Atheros AR93xx Wireless Network Adapter [168c:0030] (rev 01) with 00:1c.4/00.0 being successfully tuned with pciexp_tune_dev(), and 00: 1e.0/00.0/00.0 not tuned as expected. Change-Id: Ibb92548c47288b40e851fcc0a8a37937e8bdbf3c Signed-off-by: Bill XIE <persmule@hardenedlinux.org> Reviewed-on: https://review.coreboot.org/c/coreboot/+/66439 Reviewed-by: Paul Menzel <paulepanter@mailbox.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com> Reviewed-by: Martin L Roth <gaumless@gmail.com>
* pciexp_device: Fix a bug in pciexp_enable_ltr()Bill XIE2022-08-071-1/+1
| | | | | | | | | | | | | | 'parent_cap' should be found from 'parent' instead of 'dev'. Signed-off-by: Bill XIE <persmule@hardenedlinux.org> Change-Id: I99dab83d90287ca924d30dc4aeac0ff96e877e5c Reviewed-on: https://review.coreboot.org/c/coreboot/+/66385 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Elyes Haouas <ehaouas@noos.fr> Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-by: Nico Huber <nico.h@gmx.de> Reviewed-by: Martin L Roth <gaumless@gmail.com>
* device/pciexp_device: Set resources for pciexp_hotplug_dummy_opsJohn Su2022-03-281-0/+1
| | | | | | | | | | | | | | | | | | | | Without setting the set_resources field for pciexp_hotplug_dummy_ops, we will get an error during pciexp_hotplug_dummy. [ERROR] NONE missing set_resources Because the set_resources field is considered mandatory, explicitly set it as no-op noop_set_resources. BUG=b:220639445 TEST=emerge-brya coreboot Signed-off-by: John Su <john_su@compal.corp-partner.google.com> Change-Id: Ifee7479c69cf16025dbd4e3924056ed7f8e253cf Reviewed-on: https://review.coreboot.org/c/coreboot/+/63101 Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com> Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
* device: Add pciexp_find_next_extended_cap functionTim Wawrzynczak2022-02-101-11/+21
| | | | | | | | | | | | | | | | | | | Some PCIe devices have extended capability lists that contain multiples instances of the same capability. This patch provides a function similar to pciexp_find_extended_cap that can be used to search through multiple instances of the same capability by returning the offset of the next extended capability of the given type following the passed-in offset. The base functionality of searching for a given capability from an offset is extracted to a local helper function and both pciexp_find_extended_cap and pciexp_find_next_extended_cap use this helper. Change-Id: Ie68dc26012ba57650484c4f2ff53cc694a5347aa Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org> Reviewed-on: https://review.coreboot.org/c/coreboot/+/57784 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Karthik Ramasubramanian <kramasub@google.com> Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
* device: constify pciexp_find_extended_cap()Tim Wawrzynczak2022-01-241-1/+1
| | | | | | | | | | | The object pointed to by the struct device * argument is not modified, therefore it can be made const. Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org> Change-Id: I300d2a59eb0513ddd08d4f1d2a3c6eb829e3f836 Reviewed-on: https://review.coreboot.org/c/coreboot/+/61214 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
* device: Make pciexp_get_ltr_max_latencies a public functionTim Wawrzynczak2021-12-221-1/+1
| | | | | | | | | | | | | | | | Some device drivers may need to get access to the LTR values for their respective devices, therefore export this function instead of marking it static. BUG=b:204343849 Change-Id: Id372600e8adec0d55d3483726bb9353139685774 Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org> Reviewed-on: https://review.coreboot.org/c/coreboot/+/60015 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nick Vaccaro <nvaccaro@google.com> Reviewed-by: Karthik Ramasubramanian <kramasub@google.com> Reviewed-by: Subrata Banik <subratabanik@google.com>
* pciexp_device: Rewrite LTR configurationNico Huber2021-03-151-39/+69
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I was bugged by spurious "Failed to enable LTR" messages for years. Looking at the the current algorithm, it is flawed in multiple ways: * It looks like the author didn't know they implemented a recursive algorithm (pciexp_enable_ltr()) inside another recursive algorithm (pciexp_scan_bridge()). Thus, at every tree level, everything is run again for the whole sub- tree. * LTR is enabled no matter if `.set_ltr_max_latencies` is implemented or not. Leaving the endpoints' LTR settings at 0: They are told to always report zero tolerance. In theory, depending on the root-complex implementation, this may result in higher power consumption than without LTR messages. * `.set_ltr_max_latencies` is only considered for the direct parent of a device. Thus, even with it implemented, an endpoint below a (non-root) bridge may suffer from the 0 settings as described above. * Due to the double-recursive nature, LTR is enabled starting with the endpoints, then moving up the tree, while the PCIe spec tells us to do it in the exact opposite order. With the current implementation of pciexp_scan_bridge(), it is hard to hook anything in that runs for each device from top to bottom. So the proposed solution still adds some redundancy: First, for every device that uses pciexp_scan_bus(), we enable LTR if possible (see below). Then, when returning from the bus- scanning recursion, we enable LTR for every device and configure the maximum latencies (if supported). The latter runs again on all bridges, because it's hard to know if pciexp_scan_bus() was used for them. When to enable LTR: * For all devices that implement `.set_ltr_max_latencies`. * For all devices below a bridge that has it enabled already. Change-Id: I2c5b8658f1fc8cec15e8b0824464c6fc9bee7e0e Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/51328 Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
* device/pciexp_device.c: Remove CPP guardingArthur Heymans2021-03-141-3/+0
| | | | | | | | | | | | 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>
* pci_def.h: Introduce PCI_EXP_DEVCAP2 & PCI_EXP_DEVCTL2 properNico Huber2021-03-121-4/+4
| | | | | | | | | | | | | | | | Replace the existing, odd looking, unordered definitions used for LTR configuration with the usual names used by upstream libpci. TEST=Built google/brya0 with BUILD_TIMELESS=1: no changes. Fixes: Code looked like UEFI copy-pasta. Header file was a mess. Change-Id: Icf666692e22730e1bdf4bcdada433b3219af568a Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/51327 Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Furquan Shaikh <furquan@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
* device: Give `pci_ops.set_L1_ss_latency` a proper nameNico Huber2021-03-121-2/+2
| | | | | | | | | | | | | | Rename `set_L1_ss_latency` to what it does: `set_ltr_max_latencies`. TEST=Built google/brya0 with BUILD_TIMELESS=1: no changes. Change-Id: I7008aa18bf80d6709dce1b2d3bfbb5ea407a0574 Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/51326 Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Furquan Shaikh <furquan@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
* device: Allow virtual/generic devices under PCI in devicetreeDuncan Laurie2020-10-211-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Revert "Revert "pciexp_device: Add option to allocate prefetch memory above ↵Furquan Shaikh2020-05-281-3/+7
| | | | | | | | | | | | | | | | | | | 4G boundary"" This reverts commit e15f352039a371156ceef37f0434003228166e99. Reason for revert: Resource allocator is split into old(v3) and new(v4). So, this change to provide an option to allocate prefetch memory above 4G boundary can be added back. Since the support for allocating above 4G boundary is available only in resource allocator v4, Kconfig option is accordingly updated to add depends on RESOURCE_ALLOCATOR_V4. Change-Id: I94e5866458c79c2719fd780f336fb5da71a7df66 Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/41467 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
* Revert "pciexp_device: Add option to allocate prefetch memory above 4G boundary"Furquan Shaikh2020-05-161-7/+3
| | | | | | | | | | | | | | | This reverts commit dcbf6454b6d2d9b3627a14126ef20ed4b9c7d954. Reason for revert: Resource allocator patches need to be reverted until the AMD chipsets can be fixed to handle the resource allocation flow correctly. Change-Id: I58c9fff1a18ea1c9941e29c2c6e60e338c517c30 Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/41465 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Mike Banon <mikebdp2@gmail.com>
* pciexp_device: Add option to allocate prefetch memory above 4G boundaryFurquan Shaikh2020-05-121-3/+7
| | | | | | | | | | | | | | | | | | | | | | | | This change adds a Kconfig option to request allocation of prefetch memory for hotplug devices above the 4G boundary. In order to select this option by default and still allow users to disable this if required, another option is added to request allocation of prefetch memory below 4G boundary which defaults to n but can be overriden by mainboards. Without this change, if the number of pciexp bridges supporting hot-plug is more than 4 or if the reserved prefetch memory size for hot-plug cases was increased, then the resource allocator would fail to satisfy the resource requirement below 4G boundary. BUG=b:149186922 TEST=Enabled resource allocation above 4G for prefetch memory on volteer and verified that it gets allocated above 4G boundary. Signed-off-by: Furquan Shaikh <furquan@google.com> Change-Id: I061d935eef9fcda352230b03b5cf14e467924e50 Reviewed-on: https://review.coreboot.org/c/coreboot/+/39489 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
* treewide: Remove "this file is part of" linesPatrick Georgi2020-05-111-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Stefan thinks they don't add value. Command used: sed -i -e '/file is part of /d' $(git grep "file is part of " |egrep ":( */\*.*\*/\$|#|;#|-- | *\* )" | cut -d: -f1 |grep -v crossgcc |grep -v gcov | grep -v /elf.h |grep -v nvramtool) The exceptions are for: - crossgcc (patch file) - gcov (imported from gcc) - elf.h (imported from GNU's libc) - nvramtool (more complicated header) The removed lines are: - fmt.Fprintln(f, "/* This file is part of the coreboot project. */") -# This file is part of a set of unofficial pre-commit hooks available -/* This file is part of coreboot */ -# This file is part of msrtool. -/* This file is part of msrtool. */ - * This file is part of ncurses, designed to be appended after curses.h.in -/* This file is part of pgtblgen. */ - * This file is part of the coreboot project. - /* This file is part of the coreboot project. */ -# This file is part of the coreboot project. -# This file is part of the coreboot project. -## This file is part of the coreboot project. --- This file is part of the coreboot project. -/* This file is part of the coreboot project */ -/* This file is part of the coreboot project. */ -;## This file is part of the coreboot project. -# This file is part of the coreboot project. It originated in the - * This file is part of the coreinfo project. -## This file is part of the coreinfo project. - * This file is part of the depthcharge project. -/* This file is part of the depthcharge project. */ -/* This file is part of the ectool project. */ - * This file is part of the GNU C Library. - * This file is part of the libpayload project. -## This file is part of the libpayload project. -/* This file is part of the Linux kernel. */ -## This file is part of the superiotool project. -/* This file is part of the superiotool project */ -/* This file is part of uio_usbdebug */ Change-Id: I82d872b3b337388c93d5f5bf704e9ee9e53ab3a9 Signed-off-by: Patrick Georgi <pgeorgi@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/41194 Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
* Drop explicit NULL initializations from `device_operations`Elyes HAOUAS2020-04-051-2/+0
| | | | | | | | | | | | | | Unmentioned fields are initialized with 0 (or NULL) implicitly. Beside that, the struct has grown over the years. There are too many optional fields to list them all. Change-Id: Icb9e14c58153d7c14817bcde148e86e977666e4b Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr> Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/40126 Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
* src/device: Use SPDX for GPL-2.0-only filesAngel Pons2020-04-041-12/+2
| | | | | | | | | | Done with sed and God Lines. Only done for C-like code for now. Change-Id: Id5fe26564147ec532850430ea55b19ee94d5c5a5 Signed-off-by: Angel Pons <th3fanbus@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/40050 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
* pciexp: Add support for allocating PCI express hotplug resourcesJeremy Soller2020-02-051-0/+59
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This change adds support for allocating resources for PCI express hotplug bridges when PCIEXP_HOTPLUG is selected. By default, this will add 32 PCI subordinate numbers (buses), 256 MiB of prefetchable memory, 8 MiB of non-prefetchable memory, and 8 KiB of I/O space to any device with the PCI_EXP_SLTCAP_HPC bit set in the PCI_EXP_SLTCAP register, which indicates hot-plugging capability. The resource allocation is configurable, please see the PCIEXP_HOTPLUG_* variables in src/device/Kconfig. In order to support the allocation of hotplugged PCI buses, a new field is added to struct device called hotplug_buses. This is defaulted to zero, but when set, it adds the hotplug_buses value to the subordinate value of the PCI bridge. This allows devices to be plugged in and unplugged after boot. This code was tested on the System76 Darter Pro (darp6). Before this change, there are not enough resources allocated to the Thunderbolt PCI bridge to allow plugging in new devices after boot. This can be worked around in the Linux kernel by passing a boot param such as: pci=assign-busses,hpbussize=32,realloc This change makes it possible to use Thunderbolt hotplugging without kernel parameters, and attempts to match closely what our motherboard manufacturer's firmware does by default. Signed-off-by: Jeremy Soller <jeremy@system76.com> Change-Id: I500191626584b83e6a8ae38417fd324b5e803afc Reviewed-on: https://review.coreboot.org/c/coreboot/+/35946 Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
* device/pciexp: Match Max_Payload_Size between ends of a linkKyösti Mälkki2019-12-191-0/+44
| | | | | | | | | | | | | | | | | Ends of a PCIe link may advertise different Max_Payload_Size in their PCIe Express Capabilities, Device Capabilities block. For correct operation, both ends of the link need to have their Device Control Max_Payload_Size programmed to match and not exceed the other end's Device Capabilities. Fixes: https://ticket.coreboot.org/issues/218 Change-Id: I8b1de13e9c73abb30e5ccc792918bb4f81e5fe84 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/37769 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
* src/device: Fix typoElyes HAOUAS2019-12-091-1/+1
| | | | | | | | | Change-Id: Ibe99264a82fdea0e185907d2d2d4c57078ef3ae4 Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/37571 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Patrick Georgi <pgeorgi@google.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
* src/[arch-lib]: change "unsigned" to "unsigned int"Martin Roth2019-10-271-8/+8
| | | | | | | | Signed-off-by: Martin Roth <martin@coreboot.org> Change-Id: Ibb7b48a7a144421aff29acbb7ac30968ae5fe5ab Reviewed-on: https://review.coreboot.org/c/coreboot/+/36329 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Patrick Rudolph <siro@das-labor.org>
* src: Remove unused include '<device/pci_ids.h>'Elyes HAOUAS2019-10-181-1/+0
| | | | | | | | Change-Id: Ic90dcff9d0b49a75a26556e4a1884a2954ef68f6 Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/36063 Reviewed-by: Felix Held <felix-coreboot@felixheld.de> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
* AUTHORS: Move src/device copyrights into AUTHORS fileMartin Roth2019-09-171-3/+0
| | | | | | | | | | | | | | | As discussed on the mailing list and voted upon, the coreboot project is going to move the majority of copyrights out of the headers and into an AUTHORS file. This will happen a bit at a time, as we'll be unifying license headers at the same time. Additional cleanup - Unify "Inc" to "Inc." and "LLC." to "LLC" Signed-off-by: Martin Roth <martin@coreboot.org> Change-Id: Ie03a3ce1f6085494bd5f38da76e2467970cf301a Reviewed-on: https://review.coreboot.org/c/coreboot/+/35430 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
* coreboot: Replace all IS_ENABLED(CONFIG_XXX) with CONFIG(XXX)Julius Werner2019-03-081-4/+4
| | | | | | | | | | | | This patch is a raw application of find src/ -type f | xargs sed -i -e 's/IS_ENABLED\s*(CONFIG_/CONFIG(/g' Change-Id: I6262d6d5c23cabe23c242b4f38d446b74fe16b88 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/c/coreboot/+/31774 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
* src: Remove unneeded whitespaceElyes HAOUAS2018-10-231-2/+2
| | | | | | | | Change-Id: I6c77f4289b46646872731ef9c20dc115f0cf876d Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/29161 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
* src/device/pciexp_device.c: Get rid of device_tElyes HAOUAS2018-05-041-22/+22
| | | | | | | | | | Use of `device_t` has been abandoned in ramstage. Change-Id: I82b73e1698d8d44e32ad9f21e575a7fce35baa1c Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/26003 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
* device: Add flag to disable PCIe ASPMNico Huber2018-04-261-0/+3
| | | | | | | | | | | | For broken devices that spuriously advertise ASPM, make it possible to decide ASPM activation in the device driver. Change-Id: I491aa32a3ec954be87a474478609f0f3971d0fdf Signed-off-by: Nico Huber <nico.huber@secunet.com> Reviewed-on: https://review.coreboot.org/25617 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
* pci: Move inline PCI functions to pci_ops.hPatrick Rudolph2018-04-201-0/+1
| | | | | | | | | | | Move inline function where they belong to. Fixes compilation on non x86 platforms. Change-Id: Ia05391c43b8d501bd68df5654bcfb587f8786f71 Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com> Reviewed-on: https://review.coreboot.org/25720 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
* device/pciexp_device: Set values numerically instead of as bitmaskPatrick Georgi2017-12-081-4/+13
| | | | | | | | | | | | | | | | | | | As noted on linux-pci, we have a weird way to handling "value" and "scale" fields that are supposed to contain numerical values: we encode them as a bitfield. Instead define the two fields (offset and mask) and use numbers. Another issue, not fixed in this CL, is that we write hard-coded values while these fields really need to contain the max() of acceptable delays of the downstream devices. That way the controller can decide whether or not to enter a deeper power management state. It's noted as a TODO. Change-Id: I895b9fe2ee438d3958c2d787e70a84d73eaa49d2 Signed-off-by: Patrick Georgi <pgeorgi@google.com> Found-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-on: https://review.coreboot.org/22740 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
* src/device: Update LTR configuration schemeAamir Bohra2017-10-131-11/+44
| | | | | | | | | | | | | | | | | | | | | This patch moves out LTR programming under L1 substate to pchexp_tune_device function, as substate programming and LTR programming are independent. LTR programming scheme is updated to scan through entire tree and enable LTR mechanism on pci device if LTR mechanism is supported by device. BRANCH=none BUG=b:66722364 TEST=Verify LTR is configured for end point devices and max snoop latency gets configured. Change-Id: I6be99c3b590c1457adf88bc1b40f128fcade3fbe Signed-off-by: Aamir Bohra <aamir.bohra@intel.com> Reviewed-on: https://review.coreboot.org/21868 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
* device/pciexp_device.c: Terminate CLK PM message with newlineArthur Heymans2017-07-151-1/+1
| | | | | | | | | Change-Id: I746e2cc47a83cb04fd404851d3644b8341761022 Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/20544 Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
* pciexp_device: Remove useless write on a read-only registerYouness Alaoui2017-06-091-5/+0
| | | | | | | | | | | | | | | | | | | | | The Role-Based Error Reporting is not a configurable field, it's a read only field in the Device Capability register. This code was old and comes from commit f6eb88ad but evidently is not useful in any way. The PCIe Specification [1] states that it's read-only and must always be set to 1. I have also done tests on purism/librem13 hardware, trying to change that value, without any success. [1]: PCI Express Base Specification Revision 3.0 Page 612 Change-Id: I729617a5c6f4f52dfc4c422df78379b309066399 Signed-off-by: Youness Alaoui <youness.alaoui@puri.sm> Reviewed-on: https://review.coreboot.org/19901 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Philippe Mathieu-Daudé <philippe.mathieu.daude@gmail.com> Reviewed-by: Martin Roth <martinroth@google.com>
* pciexp_device: Prevent race condition with retrain linkYouness Alaoui2017-06-091-2/+20
| | | | | | | | | | | | | | | | | | | | The PCIe specification[1] describes a race condition that can occur when using the Retrain Link bit in the Link Control Register. The race condition is avoided by checking the retrain link bit in the link status register and waiting until it is set to 0, before initiating a new link retraining. [1] PCI Express Base Specification Revision 3.0 Page 633 Change-Id: I9d5840fb9a6e63838b5a4084d3bbe483f1d870ed Signed-off-by: Youness Alaoui <youness.alaoui@puri.sm> Reviewed-on: https://review.coreboot.org/19556 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-by: Martin Roth <martinroth@google.com>
* PCI ops: Define read-modify-write routines globallyKyösti Mälkki2016-12-061-18/+8
| | | | | | | | Change-Id: I7d64f46bb4ec3229879a60159efc8a8408512acd Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/17690 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
* PCIEXP_PLUGIN_SUPPORT: Change dependency on PCI accessKyösti Mälkki2016-12-011-28/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | Some PCI-e capability registers are located starting from 0x100, these are not accessible using the conventional PCI IO config operations at 0xcf8/0xcfc, unless PCI_CFG_EXT_IO was selected. Thus any feature that calls pciexp_find_extended_cap() depends on either MMCONF_SUPPORT_DEFAULT or PCI_CFG_EXT_IO being enabled on the platform. In theory there can be system without MMCONF_SUPPORT, but with complete PCI Express configuration space available using PCI_CFG_EXT_IO. Do not use explicit PCI MMCONF operations here, but rely on the default PCI access method to be able to access all of the configuration space. While at it, convert to IS_ENABLED() everywhere in the source and organize Kconfig file better. Change-Id: Ica6e16d2fb2adc532e644c4b2c47806490235715 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/17546 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
* PCIEXP_ASPM: Unify code with other PCI-e tuningKyösti Mälkki2016-12-011-17/+7
| | | | | | | | | | | | Error reporting can be enabled together with ASPM, there is no other use for function return value. Change-Id: I58081fac0df5205a5aea65d735d34b375c2af9cd Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/17654 Tested-by: build bot (Jenkins) Reviewed-by: Nico Huber <nico.h@gmx.de> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-18 15:10:08 +0000