Age | Commit message (Collapse) | Author | |
---|---|---|---|
2020-11-20 | soc/intel/common: Add PCIe Runtime D3 driver for ACPI | Duncan Laurie | |
This driver is for devices attached to a PCIe root port that support Runtime D3. It creates the necessary PowerResource in the root port to provide _ON/_OFF methods for which will turn off power and clocks to the device when it is in the D3cold state. The mainboard declares the driver in devicetree and provides the GPIOs that control power/reset for the device attached to the root port and the SRCCLK pin used for the PMC IPC mailbox to enable/disable the clock. An additional device property is created for storage devices if it matches the PCI storage class which is used to indicate that the storage device should use D3 for power savings. BUG=b:160996445 TEST=boot on volteer device with this driver enabled in the devicetree and disassemble the SSDT to ensure this code exists. Signed-off-by: Duncan Laurie <dlaurie@google.com> Change-Id: I13e59c996b4f5e4c2657694bda9fad869b64ffde Reviewed-on: https://review.coreboot.org/c/coreboot/+/46260 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Furquan Shaikh <furquan@google.com> | |||
2019-11-16 | soc/intel: Implement PCIe RP devicetree update based on LCAP | Nico Huber | |
Most of the current implementations for FSP-based platforms make (sometimes wrong) assumptions how FSP reorders root ports and what is specified in the devicetree. We don't have to make assumptions though, and can read the root-port number from the PCIe link capapilities (LCAP) instead. This is also what we do in ASL code for years already. This new implementation acts solely on information read from the PCI config space. In a first round, we scan all possible DEVFNs and store which root port has that DEVFN now. Then, we walk through the devicetree that still only knows devices that were originally mentioned in `devicetree.cb`, update device paths and unlink vanished devices. To be most compatible, we work with the following constraints: o Use only standard PCI config registers. o Most notable, don't try to read the registers that configure the function numbers. FSP has undocumented ways to block access to non-standard registers. o Don't make assumptions what function is assigned to hidden devices. The following assumptions were made, though: o The absolute root-port numbering as documented in datasheets matches what is read from LCAP. o This numbering doesn't contain any gaps. o Original root-port function numbers below a PCI device start at function zero and also don't contain any gaps. Change-Id: Ib17d2b6fd34608603db3936d638bdf5acb46d717 Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/35985 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Michael Niewöhner Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> | |||
2017-05-22 | soc/intel/common: Add Intel PCIe common code | Aamir Bohra | |
Add PCIe code support under soc/intel/common/block to initialize PCIe controller, allocate resources and configure L1 substate latency. Change-Id: I0c374317a3fe0be0bb1c5d9b16fcbc5cad83ca42 Signed-off-by: Aamir Bohra <aamir.bohra@intel.com> Reviewed-on: https://review.coreboot.org/19665 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Philippe Mathieu-Daudé <philippe.mathieu.daude@gmail.com> |