coreboot-gerrit June 2020

coreboot-gerrit@coreboot.org

1 participants
2825 discussions

Change in coreboot[master]: Documentation: Add section about 'hidden' devices to 4.13 release notes
by Tim Wawrzynczak (Code Review) 07 Jun '20

07 Jun '20

Tim Wawrzynczak has uploaded this change for review. ( https://review.coreboot.org/c/coreboot/+/41563 ) Change subject: Documentation: Add section about 'hidden' devices to 4.13 release notes ...................................................................... Documentation: Add section about 'hidden' devices to 4.13 release notes CB:41384 added some new functionality to devicetree files ("hidden PCI devices"). It's a decent enough semantic change that it should be added to the release notes for the 4.13 release. Change-Id: I52969f63dbc492afd32279176cbcfc2b76d7ac33 Signed-off-by: Tim Wawrzynczak <twawrzynczak(a)chromium.org> --- M Documentation/releases/coreboot-4.13-relnotes.md 1 file changed, 14 insertions(+), 1 deletion(-) git pull ssh://review.coreboot.org:29418/coreboot refs/changes/63/41563/1 diff --git a/Documentation/releases/coreboot-4.13-relnotes.md b/Documentation/releases/coreboot-4.13-relnotes.md index 94e93bb..0175250 100644 --- a/Documentation/releases/coreboot-4.13-relnotes.md +++ b/Documentation/releases/coreboot-4.13-relnotes.md @@ -13,4 +13,17 @@ Significant changes ------------------- -### Add significant changes here +### Hidden PCI devices + +This new functionality takes advantage of the existing 'hidden' keyword in the +devicetree. Since no existing boards were using the keyword, its usage was +repurposed to make dealing with some unique PCI devices easier. The particular +case here is Intel's PMC (Power Management Controller). During the FSP-S run, +the PMC device is made hidden, meaning that its config space looks as if there +is no device there (Vendor ID reads as 0xFFFF_FFFF). However, the device does +have fixed resources, both MMIO and I/O. These were previously recorded in +different places (MMIO was typically an SA fixed resource, and I/O was treated +as an LPC resource). With this change, when a device in the tree is marked as +'hidden', it is not probed (`pci_probe_dev()`) but rather assumed to exist so +that its resources can be placed in a more natural location. This also adds the +ability for the device to participate in SSDT generation. -- To view, visit https://review.coreboot.org/c/coreboot/+/41563 To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings Gerrit-Project: coreboot Gerrit-Branch: master Gerrit-Change-Id: I52969f63dbc492afd32279176cbcfc2b76d7ac33 Gerrit-Change-Number: 41563 Gerrit-PatchSet: 1 Gerrit-Owner: Tim Wawrzynczak <twawrzynczak(a)chromium.org> Gerrit-MessageType: newchange

7 16

Change in coreboot[master]: google/trogdor: Remove RO_FSG region
by Julius Werner (Code Review) 07 Jun '20

07 Jun '20

Hello Philip Chen, I'd like you to do a code review. Please visit https://review.coreboot.org/c/coreboot/+/41980 to review the following change. Change subject: google/trogdor: Remove RO_FSG region ...................................................................... google/trogdor: Remove RO_FSG region We decided to store the FSG on eMMC instead of SPI flash, so we don't need this region anymore. Getting rid of it allows us to put more space into CBFS (to store hi-res bitmaps). Also grow VPD by some remaining amount to keep the FMAP alignment reasonable. Signed-off-by: Julius Werner <jwerner(a)chromium.org> Change-Id: If73450b65718affae71b6ada70ded5c5f45cfb4c --- M src/mainboard/google/trogdor/chromeos.fmd 1 file changed, 3 insertions(+), 4 deletions(-) git pull ssh://review.coreboot.org:29418/coreboot refs/changes/80/41980/1 diff --git a/src/mainboard/google/trogdor/chromeos.fmd b/src/mainboard/google/trogdor/chromeos.fmd index 2f93712..3aa0473 100644 --- a/src/mainboard/google/trogdor/chromeos.fmd +++ b/src/mainboard/google/trogdor/chromeos.fmd @@ -2,17 +2,16 @@ FLASH@0x0 8M { WP_RO 4M { - RO_SECTION 0x204000 { + RO_SECTION 0x3c4000 { BOOTBLOCK 96K COREBOOT(CBFS) - FMAP@0x200000 0x1000 + FMAP@0x3c0000 0x1000 GBB 0x2f00 RO_FRID 0x100 } - RO_VPD(PRESERVE) 16K + RO_VPD(PRESERVE) 228K RO_DDR_TRAINING(PRESERVE) 8K RO_LIMITS_CFG(PRESERVE) 4K - RO_FSG(PRESERVE) } RW_VPD(PRESERVE) 32K -- To view, visit https://review.coreboot.org/c/coreboot/+/41980 To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings Gerrit-Project: coreboot Gerrit-Branch: master Gerrit-Change-Id: If73450b65718affae71b6ada70ded5c5f45cfb4c Gerrit-Change-Number: 41980 Gerrit-PatchSet: 1 Gerrit-Owner: Julius Werner <jwerner(a)chromium.org> Gerrit-Reviewer: Philip Chen <philipchen(a)chromium.org> Gerrit-MessageType: newchange

3 5

Change in coreboot[master]: soc/amd/common/spi: add and use define for last FIFO position
by Felix Held (Code Review) 07 Jun '20

07 Jun '20

Felix Held has uploaded this change for review. ( https://review.coreboot.org/c/coreboot/+/42076 ) Change subject: soc/amd/common/spi: add and use define for last FIFO position ...................................................................... soc/amd/common/spi: add and use define for last FIFO position The existing define for SPI_FIFO_DEPTH looked a bit suspicious, but turned out to be correct. Change-Id: I91e65d922673f5c451a336ae013cb75f87a3fc98 Signed-off-by: Felix Held <felix-coreboot(a)felixheld.de> --- M src/soc/amd/common/block/include/amdblocks/spi.h 1 file changed, 2 insertions(+), 1 deletion(-) git pull ssh://review.coreboot.org:29418/coreboot refs/changes/76/42076/1 diff --git a/src/soc/amd/common/block/include/amdblocks/spi.h b/src/soc/amd/common/block/include/amdblocks/spi.h index fec099d..6854a1a 100644 --- a/src/soc/amd/common/block/include/amdblocks/spi.h +++ b/src/soc/amd/common/block/include/amdblocks/spi.h @@ -55,7 +55,8 @@ #define SPI_RD4DW_EN_HOST BIT(15) #define SPI_FIFO 0x80 -#define SPI_FIFO_DEPTH (0xc7 - SPI_FIFO) +#define SPI_FIFO_LAST_BYTE 0xc7 +#define SPI_FIFO_DEPTH (SPI_FIFO_LAST_BYTE - SPI_FIFO) struct spi_config { /* -- To view, visit https://review.coreboot.org/c/coreboot/+/42076 To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings Gerrit-Project: coreboot Gerrit-Branch: master Gerrit-Change-Id: I91e65d922673f5c451a336ae013cb75f87a3fc98 Gerrit-Change-Number: 42076 Gerrit-PatchSet: 1 Gerrit-Owner: Felix Held <felix-coreboot(a)felixheld.de> Gerrit-MessageType: newchange

5 8

Change in coreboot[master]: soc/amd/picasso: Add set_mmio_dev_ops() to set ops for MMIO devices
by Furquan Shaikh (Code Review) 07 Jun '20

07 Jun '20

Furquan Shaikh has uploaded this change for review. ( https://review.coreboot.org/c/coreboot/+/42067 ) Change subject: soc/amd/picasso: Add set_mmio_dev_ops() to set ops for MMIO devices ...................................................................... soc/amd/picasso: Add set_mmio_dev_ops() to set ops for MMIO devices This change adds a helper function set_mmio_dev_ops() in chip.c which is used for setting the dev->ops for MMIO devices based on the comparison of MMIO address in device tree to the pre-defined base addresses in iomap.h. Call to i2c_acpi_name() is replaced with set_mmio_dev_ops and scope of i2c_acpi_name is restricted to i2c.c since it is not required to be exposed out of that file. Change-Id: I31f96cfe8267b0df37012baeb7cfcaec9c2280f6 Signed-off-by: Furquan Shaikh <furquan(a)google.com> --- M src/soc/amd/picasso/chip.c M src/soc/amd/picasso/i2c.c 2 files changed, 14 insertions(+), 7 deletions(-) git pull ssh://review.coreboot.org:29418/coreboot refs/changes/67/42067/1 diff --git a/src/soc/amd/picasso/chip.c b/src/soc/amd/picasso/chip.c index dc661d2..ed39b53 100644 --- a/src/soc/amd/picasso/chip.c +++ b/src/soc/amd/picasso/chip.c @@ -8,6 +8,7 @@ #include <soc/acpi.h> #include <soc/cpu.h> #include <soc/data_fabric.h> +#include <soc/iomap.h> #include <soc/pci_devs.h> #include <soc/southbridge.h> #include "chip.h" @@ -15,7 +16,6 @@ /* Supplied by i2c.c */ extern struct device_operations picasso_i2c_mmio_ops; -extern const char *i2c_acpi_name(const struct device *dev); struct device_operations cpu_bus_ops = { .read_resources = noop_read_resources, @@ -119,6 +119,17 @@ .acpi_fill_ssdt = acpi_device_write_pci_dev, }; +static void set_mmio_dev_ops(struct device *dev) +{ + switch (dev->path.mmio.addr) { + case APU_I2C2_BASE: + case APU_I2C3_BASE: + case APU_I2C4_BASE: + dev->ops = &picasso_i2c_mmio_ops; + break; + } +} + static void enable_dev(struct device *dev) { /* Set the operations if it is a special bus type */ @@ -136,8 +147,7 @@ } sb_enable(dev); } else if (dev->path.type == DEVICE_PATH_MMIO) { - if (i2c_acpi_name(dev) != NULL) - dev->ops = &picasso_i2c_mmio_ops; + set_mmio_dev_ops(dev); } } diff --git a/src/soc/amd/picasso/i2c.c b/src/soc/amd/picasso/i2c.c index 4c8c669..fa59b99 100644 --- a/src/soc/amd/picasso/i2c.c +++ b/src/soc/amd/picasso/i2c.c @@ -13,9 +13,6 @@ #include <soc/southbridge.h> #include "chip.h" -/* Global to provide access to chip.c */ -const char *i2c_acpi_name(const struct device *dev); - /* * We don't have addresses for I2C0-1. */ @@ -48,7 +45,7 @@ return &config->i2c[bus]; } -const char *i2c_acpi_name(const struct device *dev) +static const char *i2c_acpi_name(const struct device *dev) { switch (dev->path.mmio.addr) { case APU_I2C2_BASE: -- To view, visit https://review.coreboot.org/c/coreboot/+/42067 To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings Gerrit-Project: coreboot Gerrit-Branch: master Gerrit-Change-Id: I31f96cfe8267b0df37012baeb7cfcaec9c2280f6 Gerrit-Change-Number: 42067 Gerrit-PatchSet: 1 Gerrit-Owner: Furquan Shaikh <furquan(a)google.com> Gerrit-MessageType: newchange

4 3

Change in coreboot[master]: sb/intel/bd82x6x: Remove dead code
by Angel Pons (Code Review) 07 Jun '20

07 Jun '20

Angel Pons has uploaded this change for review. ( https://review.coreboot.org/c/coreboot/+/42013 ) Change subject: sb/intel/bd82x6x: Remove dead code ...................................................................... sb/intel/bd82x6x: Remove dead code Drop functions that are not being used. Change-Id: If406601f3bb7a98a621c1339b2f3413a43b8cc9f Signed-off-by: Angel Pons <th3fanbus(a)gmail.com> --- M src/southbridge/intel/bd82x6x/me.c M src/southbridge/intel/bd82x6x/me_8.x.c 2 files changed, 0 insertions(+), 48 deletions(-) git pull ssh://review.coreboot.org:29418/coreboot refs/changes/13/42013/1 diff --git a/src/southbridge/intel/bd82x6x/me.c b/src/southbridge/intel/bd82x6x/me.c index b319c28..c60b673 100644 --- a/src/southbridge/intel/bd82x6x/me.c +++ b/src/southbridge/intel/bd82x6x/me.c @@ -112,39 +112,6 @@ return 0; } -#if CONFIG(CHROMEOS) && 0 /* DISABLED */ -/* Tell ME to issue a global reset */ -int mkhi_global_reset(void) -{ - struct me_global_reset reset = { - .request_origin = GLOBAL_RESET_BIOS_POST, - .reset_type = CBM_RR_GLOBAL_RESET, - }; - struct mkhi_header mkhi = { - .group_id = MKHI_GROUP_ID_CBM, - .command = MKHI_GLOBAL_RESET, - }; - struct mei_header mei = { - .is_complete = 1, - .length = sizeof(mkhi) + sizeof(reset), - .host_address = MEI_HOST_ADDRESS, - .client_address = MEI_ADDRESS_MKHI, - }; - - printk(BIOS_NOTICE, "ME: Requesting global reset\n"); - - /* Send request and wait for response */ - if (mei_sendrecv(&mei, &mkhi, &reset, NULL, 0) < 0) { - /* No response means reset will happen shortly... */ - halt(); - } - - /* If the ME responded it rejected the reset request */ - printk(BIOS_ERR, "ME: Global Reset failed\n"); - return -1; -} -#endif - #ifdef __SIMPLE_DEVICE__ static void intel_me7_finalize_smm(void) diff --git a/src/southbridge/intel/bd82x6x/me_8.x.c b/src/southbridge/intel/bd82x6x/me_8.x.c index 12b3a46..0d51f6f 100644 --- a/src/southbridge/intel/bd82x6x/me_8.x.c +++ b/src/southbridge/intel/bd82x6x/me_8.x.c @@ -324,21 +324,6 @@ (me.buffer_depth - 1); } -#if 0 -/* This function is not yet being used, keep it in for the future. */ -static u32 host_to_me_words_room(void) -{ - struct mei_csr csr; - - read_me_csr(&csr); - if (!csr.ready) - return 0; - - read_host_csr(&csr); - return (csr.buffer_read_ptr - csr.buffer_write_ptr - 1) & - (csr.buffer_depth - 1); -} -#endif /* * mbp seems to be following its own flow, let's retrieve it in a dedicated * function. -- To view, visit https://review.coreboot.org/c/coreboot/+/42013 To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings Gerrit-Project: coreboot Gerrit-Branch: master Gerrit-Change-Id: If406601f3bb7a98a621c1339b2f3413a43b8cc9f Gerrit-Change-Number: 42013 Gerrit-PatchSet: 1 Gerrit-Owner: Angel Pons <th3fanbus(a)gmail.com> Gerrit-MessageType: newchange

4 5

Change in coreboot[master]: nb/intel/gm45: Fix 16-bit read/write PCI_COMMAND register
by HAOUAS Elyes (Code Review) 07 Jun '20

07 Jun '20

HAOUAS Elyes has uploaded this change for review. ( https://review.coreboot.org/c/coreboot/+/40835 ) Change subject: nb/intel/gm45: Fix 16-bit read/write PCI_COMMAND register ...................................................................... nb/intel/gm45: Fix 16-bit read/write PCI_COMMAND register Change-Id: I7c7fb10308a6fcd1ead292c53ed03ddc693f6f15 Signed-off-by: Elyes HAOUAS <ehaouas(a)noos.fr> --- M src/northbridge/intel/gm45/iommu.c 1 file changed, 3 insertions(+), 3 deletions(-) git pull ssh://review.coreboot.org:29418/coreboot refs/changes/35/40835/1 diff --git a/src/northbridge/intel/gm45/iommu.c b/src/northbridge/intel/gm45/iommu.c index 4d88e36..a0f85f9 100644 --- a/src/northbridge/intel/gm45/iommu.c +++ b/src/northbridge/intel/gm45/iommu.c @@ -37,9 +37,9 @@ pci_devfn_t igd = PCI_DEV(0, 2, 0); /* setup somewhere */ - u8 cmd = pci_read_config8(igd, PCI_COMMAND); + u16 cmd = pci_read_config16(igd, PCI_COMMAND); cmd |= PCI_COMMAND_MASTER | PCI_COMMAND_MEMORY; - pci_write_config8(igd, PCI_COMMAND, cmd); + pci_write_config16(igd, PCI_COMMAND, cmd); void *bar = (void *)pci_read_config32(igd, PCI_BASE_ADDRESS_0); /* clear GTT, 2MB is enough (and should be safe) */ @@ -47,7 +47,7 @@ /* and now disable again */ cmd &= ~(PCI_COMMAND_MASTER | PCI_COMMAND_MEMORY); - pci_write_config8(igd, PCI_COMMAND, cmd); + pci_write_config16(igd, PCI_COMMAND, cmd); pci_write_config32(igd, PCI_BASE_ADDRESS_0, 0); } -- To view, visit https://review.coreboot.org/c/coreboot/+/40835 To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings Gerrit-Project: coreboot Gerrit-Branch: master Gerrit-Change-Id: I7c7fb10308a6fcd1ead292c53ed03ddc693f6f15 Gerrit-Change-Number: 40835 Gerrit-PatchSet: 1 Gerrit-Owner: HAOUAS Elyes <ehaouas(a)noos.fr> Gerrit-MessageType: newchange

5 11

Change in coreboot[master]: src/mainboard/supermicro/x11-lga1151v2-series: Add Support for X11SCH-F
by Paul Menzel (Code Review) 07 Jun '20

07 Jun '20

1 0

Change in coreboot[master]: src/mainboard/supermicro/x11-lga1151v2-series: Add Support for X11SCH-F
by Paul Menzel (Code Review) 07 Jun '20

07 Jun '20

Paul Menzel has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/37441 ) Change subject: src/mainboard/supermicro/x11-lga1151v2-series: Add Support for X11SCH-F ...................................................................... Patch Set 51: (18 comments) https://review.coreboot.org/c/coreboot/+/37441/51//COMMIT_MSG Commit Message: https://review.coreboot.org/c/coreboot/+/37441/51//COMMIT_MSG@7 PS51, Line 7: src/mainboard/supermicro/x11-lga1151v2-series: Add Support for X11SCH-F > mb/supermicro/x11-lga1151v2-series: Add support for X11SCH-F https://review.coreboot.org/c/coreboot/+/37441/51//COMMIT_MSG@15 PS51, Line 15: DevTree I’d spell it devicetree. https://review.coreboot.org/c/coreboot/+/37441/51//COMMIT_MSG@16 PS51, Line 16: Linux What version (and what payload)? https://review.coreboot.org/c/coreboot/+/37441/51//COMMIT_MSG@17 PS51, Line 17: Slots slots https://review.coreboot.org/c/coreboot/+/37441/51//COMMIT_MSG@21 PS51, Line 21: * Proper ACPI Tables What does this mean? https://review.coreboot.org/c/coreboot/+/37441/51//COMMIT_MSG@22 PS51, Line 22: * Windows Support What version, and what payload (with version)? https://review.coreboot.org/c/coreboot/+/37441/51//COMMIT_MSG@25 PS51, Line 25: Tested with Intel Xeon E-2186G and 64 GB ECC RAM. How long does coreboot take to execute? https://review.coreboot.org/c/coreboot/+/37441/51//COMMIT_MSG@26 PS51, Line 26: Please mention, why the code can’t be shared with the x11-lga1151 series code. https://review.coreboot.org/c/coreboot/+/37441/51/Documentation/mainboard/i… File Documentation/mainboard/index.md: https://review.coreboot.org/c/coreboot/+/37441/51/Documentation/mainboard/i… PS51, Line 150: LGA1151V2 v2 https://review.coreboot.org/c/coreboot/+/37441/51/Documentation/mainboard/s… File Documentation/mainboard/supermicro/x11-lga1151v2-series/x11-lga1151v2-series.md: https://review.coreboot.org/c/coreboot/+/37441/51/Documentation/mainboard/s… PS51, Line 1: LGA1151V2 v2? https://review.coreboot.org/c/coreboot/+/37441/51/Documentation/mainboard/s… PS51, Line 3: series series boards https://review.coreboot.org/c/coreboot/+/37441/51/Documentation/mainboard/s… PS51, Line 18: - [Intel FSP2.0] can not be removed as long as there is no free replacement Please add a dot at the end of sentences. https://review.coreboot.org/c/coreboot/+/37441/51/Documentation/mainboard/s… PS51, Line 29: - MRC caching does not work on cold boot with Intel SPS (see [Intel FSP2.0]) 1. Please add a dot/period at the end of sentences. 2. Please mention the result: The full RAM training of 64 GB ECC RAM lasts X seconds. https://review.coreboot.org/c/coreboot/+/37441/51/Documentation/mainboard/s… PS51, Line 52: https://www.supermicro.com/en/products/motherboards?pro=cpu%3DUP%26processo… That URL does not work for me. https://review.coreboot.org/c/coreboot/+/37441/51/Documentation/mainboard/s… PS51, Line 52: LGA1151 v2 https://review.coreboot.org/c/coreboot/+/37441/51/Documentation/mainboard/s… File Documentation/mainboard/supermicro/x11-lga1151v2-series/x11sch-f/x11sch-f.md: https://review.coreboot.org/c/coreboot/+/37441/51/Documentation/mainboard/s… PS51, Line 3: This section details how to run coreboot on the [Supermicro X11SCH-F]. … The -F denotes that a BMC is part of the device. https://review.coreboot.org/c/coreboot/+/37441/51/Documentation/mainboard/s… PS51, Line 30: - TPM on TPM expansion header Mention the patching of IFD as written in the commit message? https://review.coreboot.org/c/coreboot/+/37441/51/Documentation/mainboard/s… PS51, Line 34: See general issue section. Where is that section? Maybe link to it? -- To view, visit https://review.coreboot.org/c/coreboot/+/37441 To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings Gerrit-Project: coreboot Gerrit-Branch: master Gerrit-Change-Id: I0ab1cb9462607b9af068bc2374508d99c60d0a30 Gerrit-Change-Number: 37441 Gerrit-PatchSet: 51 Gerrit-Owner: Christian Walter <christian.walter(a)9elements.com> Gerrit-Reviewer: Angel Pons <th3fanbus(a)gmail.com> Gerrit-Reviewer: Christian Walter <christian.walter(a)9elements.com> Gerrit-Reviewer: Guido Beyer @ Prodrive Technologies <guido.beyer(a)prodrive-technologies.com> Gerrit-Reviewer: Justin van Son <justin.van.son(a)prodrive-technologies.com> Gerrit-Reviewer: Martin Roth <martinroth(a)google.com> Gerrit-Reviewer: Nico Huber <nico.h(a)gmx.de> Gerrit-Reviewer: Patrick Georgi <pgeorgi(a)google.com> Gerrit-Reviewer: Patrick Rudolph <patrick.rudolph(a)9elements.com> Gerrit-Reviewer: Patrick Rudolph <siro(a)das-labor.org> Gerrit-Reviewer: Philipp Deppenwiese <zaolin.daisuki(a)gmail.com> Gerrit-Reviewer: Stef van Os <stef.van.os(a)prodrive-technologies.com> Gerrit-Reviewer: build bot (Jenkins) <no-reply(a)coreboot.org> Gerrit-Reviewer: wouter.eckhardt(a)prodrive-technologies.com Gerrit-CC: Paul Menzel <paulepanter(a)users.sourceforge.net> Gerrit-Comment-Date: Sun, 07 Jun 2020 14:58:10 +0000 Gerrit-HasComments: Yes Gerrit-Has-Labels: No Gerrit-MessageType: comment

1 0

Change in coreboot[master]: src/mainboard/supermicro/x11-lga1151v2-series: Add Support for X11SCH-F
by Angel Pons (Code Review) 07 Jun '20

07 Jun '20

Angel Pons has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/37441 ) Change subject: src/mainboard/supermicro/x11-lga1151v2-series: Add Support for X11SCH-F ...................................................................... Patch Set 51: (1 comment) https://review.coreboot.org/c/coreboot/+/37441/51/Documentation/mainboard/s… File Documentation/mainboard/supermicro/x11-lga1151v2-series/x11sch-f/x11sch-f_flash.jpg: PS51: That looks rather small to be a flash chip. Is it in a 150 mil SOIC-8 package, as opposed to the usual 200 mil packages for flash chips? -- To view, visit https://review.coreboot.org/c/coreboot/+/37441 To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings Gerrit-Project: coreboot Gerrit-Branch: master Gerrit-Change-Id: I0ab1cb9462607b9af068bc2374508d99c60d0a30 Gerrit-Change-Number: 37441 Gerrit-PatchSet: 51 Gerrit-Owner: Christian Walter <christian.walter(a)9elements.com> Gerrit-Reviewer: Angel Pons <th3fanbus(a)gmail.com> Gerrit-Reviewer: Christian Walter <christian.walter(a)9elements.com> Gerrit-Reviewer: Guido Beyer @ Prodrive Technologies <guido.beyer(a)prodrive-technologies.com> Gerrit-Reviewer: Justin van Son <justin.van.son(a)prodrive-technologies.com> Gerrit-Reviewer: Martin Roth <martinroth(a)google.com> Gerrit-Reviewer: Nico Huber <nico.h(a)gmx.de> Gerrit-Reviewer: Patrick Georgi <pgeorgi(a)google.com> Gerrit-Reviewer: Patrick Rudolph <patrick.rudolph(a)9elements.com> Gerrit-Reviewer: Patrick Rudolph <siro(a)das-labor.org> Gerrit-Reviewer: Philipp Deppenwiese <zaolin.daisuki(a)gmail.com> Gerrit-Reviewer: Stef van Os <stef.van.os(a)prodrive-technologies.com> Gerrit-Reviewer: build bot (Jenkins) <no-reply(a)coreboot.org> Gerrit-Reviewer: wouter.eckhardt(a)prodrive-technologies.com Gerrit-Comment-Date: Sun, 07 Jun 2020 14:08:25 +0000 Gerrit-HasComments: Yes Gerrit-Has-Labels: No Gerrit-MessageType: comment

1 0

Change in coreboot[master]: device: Add support for resource allocator v4
by Furquan Shaikh (Code Review) 07 Jun '20

07 Jun '20

Furquan Shaikh has uploaded this change for review. ( https://review.coreboot.org/c/coreboot/+/41443 ) Change subject: device: Add support for resource allocator v4 ...................................................................... device: Add support for resource allocator v4 This change adds back support for the resource allocator using multiple ranges as originally landed in CB:39486 and reverted in CB:41413. The new resource allocator can be selected by Kconfig option RESOURCE_ALLOCATOR_V4. It was identified that there are some AMD chipsets in the tree that do not really work well with the dynamic resource allocation. Until these chipsets are fixed, old(v3) and new(v4) of the resource allocator need to live side-by-side in the tree. This change picks up the same additions as performed in CB:39486 along with the following changes: 1. Changes are incorporated to avoid fixed resources hanging off pci domain device (CB:41363) 2. Changes to set up alignment for memranges when intializing them. This is done to ensure that the right granularity is used for IORESOURCE_IO(no special alignment) and IORESOURCE_MEM(4KiB) resource requests. Original commit message: This change updates the resource allocator in coreboot to allow using multiple ranges for resource allocation rather than restricting available window to a single base/limit pair. This is done in preparation to allow 64-bit resource allocation. Following changes are made as part of this: a) Resource allocator still makes 2 passes at the entire tree. The first pass is to gather the resource requirements of each device under each domain. It walks recursively in DFS fashion to gather the requirements of the leaf devices and propagates this back up to the downstream bridges of the domain. Domain is special in the sense that it has fixed resource ranges. Hence, the resource requirements from the downstream devices have no effect on the domain resource windows. This results in domain resource limits being unmodified after the first pass. b) Once the requirements for all the devices under the domain are gathered, resource allocator walks a second time to allocate resources to downstream devices as per the requirements. Here, instead of maintaining a single window for allocating resources, it creates a list of memranges starting with the resource window at domain and then applying constraints to create holes for any fixed resources. This ensures that there is no overlap with fixed resources under the domain. c) Domain does not differentiate between mem and prefmem. Since they are allocated space from the same resource window at the domain level, it considers all resource requests from downstream devices of the domain independent of the prefetch type. d) Once resource allocation is done at the domain level, resource allocator walks down the downstream bridges and continues the same process until it reaches the leaves. Bridges have separate windows for mem and prefmem. Hence, unlike domain, the resource allocator at bridge level ensures that downstream requirements are satisfied by taking prefetch type into consideration. e) This whole 2-pass process is performed for every domain in the system under the assumption that domains do not have overlapping address spaces. Noticeable differences from previous resource allocator: a) Changes in print logs observed due to flows being slightly different. b) Base, limit and size of domain resources are no longer updated based on downstream requirements. c) Memranges are used instead of a single base/limit pair for determining resource allocation. d) Previously, if a resource request did not fit in the available base/limit window, then the resource would be allocated over DRAM or any other address space defeating the principle of "no overlap". With this change, any time a resource cannot fit in the available ranges, it complains and ensures that the resource is effectively disabled by setting base same as the limit. e) Resource allocator no longer looks at multiple links to determine the right bus for a resource. None of the current boards have multiple buses under any downstream device of the domain. The only device with multiple links seems to be the cpu cluster device for some AMD platforms. Change-Id: Ide4d98528197bb03850a8fb4d73c41cd2c0195aa Signed-off-by: Furquan Shaikh <furquan(a)google.com> --- M src/device/Kconfig M src/device/Makefile.inc A src/device/resource_allocator_v4.c 3 files changed, 570 insertions(+), 0 deletions(-) git pull ssh://review.coreboot.org:29418/coreboot refs/changes/43/41443/1 diff --git a/src/device/Kconfig b/src/device/Kconfig index bfa4759..e340841 100644 --- a/src/device/Kconfig +++ b/src/device/Kconfig @@ -801,4 +801,13 @@ This config option enables resource allocator v3 which performs top down allocation of resources in a single MMIO window. +config RESOURCE_ALLOCATOR_V4 + bool + default n if RESOURCE_ALLOCATOR_V3 + default y if !RESOURCE_ALLOCATOR_V3 + help + This config option enables resource allocator v4 which uses multiple + ranges for allocating resources. This allows allocation of resources + above 4G boundary as well. + endmenu diff --git a/src/device/Makefile.inc b/src/device/Makefile.inc index 9bbab37..2e62d42 100644 --- a/src/device/Makefile.inc +++ b/src/device/Makefile.inc @@ -61,3 +61,4 @@ ramstage-y += resource_allocator_common.c ramstage-$(CONFIG_RESOURCE_ALLOCATOR_V3) += resource_allocator_v3.c +ramstage-$(CONFIG_RESOURCE_ALLOCATOR_V4) += resource_allocator_v4.c diff --git a/src/device/resource_allocator_v4.c b/src/device/resource_allocator_v4.c new file mode 100644 index 0000000..ac65ed4 --- /dev/null +++ b/src/device/resource_allocator_v4.c @@ -0,0 +1,560 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ + +#include <console/console.h> +#include <device/device.h> +#include <memrange.h> +#include <post.h> + +/** + * Round a number up to an alignment. + * + * @param val The starting value. + * @param pow Alignment as a power of two. + * @return Rounded up number. + */ +static resource_t round(resource_t val, unsigned long pow) +{ + return ALIGN_UP(val, POWER_OF_2(pow)); +} + +static const char *resource2str(const struct resource *res) +{ + if (res->flags & IORESOURCE_IO) + return "io"; + if (res->flags & IORESOURCE_PREFETCH) + return "prefmem"; + if (res->flags & IORESOURCE_MEM) + return "mem"; + return "undefined"; +} + +static bool dev_has_children(const struct device *dev) +{ + const struct bus *bus = dev->link_list; + return bus && bus->children; +} + +/* + * During pass 1, once all the requirements for downstream devices of a bridge are gathered, + * this function calculates the overall resource requirement for the bridge. It starts by + * picking the largest resource requirement downstream for the given resource type and works by + * adding requirements in descending order. + * + * Additionally, it takes alignment and limits of the downstream devices into consideration and + * ensures that they get propagated to the bridge resource. This is required to guarantee that + * the upstream bridge/domain honors the limit and alignment requirements for this bridge based + * on the tightest constraints downstream. + */ +static void update_bridge_resource(const struct device *bridge, struct resource *bridge_res, + unsigned long type_match) +{ + const struct device *child; + struct resource *child_res; + resource_t base; + bool first_child_res = true; + const unsigned long type_mask = IORESOURCE_TYPE_MASK | IORESOURCE_PREFETCH; + struct bus *bus = bridge->link_list; + + child_res = NULL; + + /* + * `base` keeps track of where the next allocation for child resource can take place + * from within the bridge resource window. Since the bridge resource window allocation + * is not performed yet, it can start at 0. Base gets updated every time a resource + * requirement is accounted for in the loop below. After scanning all these resources, + * base will indicate the total size requirement for the current bridge resource + * window. + */ + base = 0; + + printk(BIOS_SPEW, "%s %s: size: %llx align: %d gran: %d limit: %llx\n", + dev_path(bridge), resource2str(bridge_res), bridge_res->size, + bridge_res->align, bridge_res->gran, bridge_res->limit); + + while ((child = largest_resource(bus, &child_res, type_mask, type_match))) { + + /* Size 0 resources can be skipped. */ + if (!child_res->size) + continue; + + /* + * Propagate the resource alignment to the bridge resource if this is the first + * child resource with non-zero size being considered. For all other children + * resources, alignment is taken care of by updating the base to round up as per + * the child resource alignment. It is guaranteed that pass 2 follows the exact + * same method of picking the resource for allocation using + * largest_resource(). Thus, as long as the alignment for first child resource + * is propagated up to the bridge resource, it can be guaranteed that the + * alignment for all resources is appropriately met. + */ + if (first_child_res && (child_res->align > bridge_res->align)) + bridge_res->align = child_res->align; + + first_child_res = false; + + /* + * Propagate the resource limit to the bridge resource only if child resource + * limit is non-zero. If a downstream device has stricter requirements + * w.r.t. limits for any resource, that constraint needs to be propagated back + * up to the downstream bridges of the domain. This guarantees that the resource + * allocation which starts at the domain level takes into account all these + * constraints thus working on a global view. + */ + if (child_res->limit && (child_res->limit < bridge_res->limit)) + bridge_res->limit = child_res->limit; + + /* + * Alignment value of 0 means that the child resource has no alignment + * requirements and so the base value remains unchanged here. + */ + base = round(base, child_res->align); + + printk(BIOS_SPEW, "%s %02lx * [0x%llx - 0x%llx] %s\n", + dev_path(child), child_res->index, base, base + child_res->size - 1, + resource2str(child_res)); + + base += child_res->size; + } + + /* + * After all downstream device resources are scanned, `base` represents the total size + * requirement for the current bridge resource window. This size needs to be rounded up + * to the granularity requirement of the bridge to ensure that the upstream + * bridge/domain allocates big enough window. + */ + bridge_res->size = round(base, bridge_res->gran); + + printk(BIOS_SPEW, "%s %s: size: %llx align: %d gran: %d limit: %llx done\n", + dev_path(bridge), resource2str(bridge_res), bridge_res->size, + bridge_res->align, bridge_res->gran, bridge_res->limit); +} + +/* + * During pass 1, resource allocator at bridge level gathers requirements from downstream + * devices and updates its own resource windows for the provided resource type. + */ +static void compute_bridge_resources(const struct device *bridge, unsigned long type_match) +{ + const struct device *child; + struct resource *res; + struct bus *bus = bridge->link_list; + const unsigned long type_mask = IORESOURCE_TYPE_MASK | IORESOURCE_PREFETCH; + + for (res = bridge->resource_list; res; res = res->next) { + if (!(res->flags & IORESOURCE_BRIDGE)) + continue; + + if ((res->flags & type_mask) != type_match) + continue; + + /* + * Ensure that the resource requirements for all downstream bridges are + * gathered before updating the window for current bridge resource. + */ + for (child = bus->children; child; child = child->sibling) { + if (!dev_has_children(child)) + continue; + compute_bridge_resources(child, type_match); + } + + /* + * Update the window for current bridge resource now that all downstream + * requirements are gathered. + */ + update_bridge_resource(bridge, res, type_match); + } +} + +/* + * During pass 1, resource allocator walks down the entire sub-tree of a domain. It gathers + * resource requirements for every downstream bridge by looking at the resource requests of its + * children. Thus, the requirement gathering begins at the leaf devices and is propagated back + * up to the downstream bridges of the domain. + * + * At domain level, it identifies every downstream bridge and walks down that bridge to gather + * requirements for each resource type i.e. i/o, mem and prefmem. Since bridges have separate + * windows for mem and prefmem, requirements for each need to be collected separately. + * + * Domain resource windows are fixed ranges and hence requirement gathering does not result in + * any changes to these fixed ranges. + */ +static void compute_domain_resources(const struct device *domain) +{ + const struct device *child; + + if (domain->link_list == NULL) + return; + + for (child = domain->link_list->children; child; child = child->sibling) { + + /* Skip if this is not a bridge or has no children under it. */ + if (!dev_has_children(child)) + continue; + + compute_bridge_resources(child, IORESOURCE_IO); + compute_bridge_resources(child, IORESOURCE_MEM); + compute_bridge_resources(child, IORESOURCE_MEM | IORESOURCE_PREFETCH); + } +} + +static unsigned char get_alignment_by_resource_type(const struct resource *res) +{ + if (res->flags & IORESOURCE_MEM) + return 12; /* Page-aligned --> log2(4KiB) */ + else if (res->flags & IORESOURCE_IO) + return 0; /* No special alignment required --> log2(1) */ + + die("Unexpected resource type: flags(%d)!\n", res->flags); +} + +static void initialize_memranges(struct memranges *ranges, const struct resource *res, + unsigned long memrange_type) +{ + resource_t res_base; + resource_t res_limit; + unsigned align = get_alignment_by_resource_type(res); + + memranges_init_empty_with_alignment(ranges, NULL, 0, align); + + if (res == NULL) + return; + + res_base = res->base; + res_limit = res->limit; + + if (res_base == res_limit) + return; + + memranges_insert(ranges, res_base, res_limit - res_base + 1, memrange_type); +} + +static void print_resource_ranges(const struct memranges *ranges) +{ + const struct range_entry *r; + + printk(BIOS_INFO, "Resource ranges:\n"); + + if (memranges_is_empty(ranges)) + printk(BIOS_INFO, "EMPTY!!\n"); + + memranges_each_entry(r, ranges) { + printk(BIOS_INFO, "Base: %llx, Size: %llx, Tag: %lx\n", + range_entry_base(r), range_entry_size(r), range_entry_tag(r)); + } +} + +static void mark_resource_invalid(struct resource *res) +{ + res->base = res->limit; + res->flags |= IORESOURCE_ASSIGNED; +} + +/* + * This is where the actual allocation of resources happens during pass 2. Given the list of + * memory ranges corresponding to the resource of given type, it finds the biggest unallocated + * resource using the type mask on the downstream bus. This continues in a descending + * order until all resources of given type are allocated address space within the current + * resource window. + * + * If a downstream resource cannot be allocated space for any reason, then its base is set to + * its limit and flags are updated to indicate that the resource assignment is complete. This is + * done to ensure that it does not confuse find_pci_tolm(). + */ +static void allocate_child_resources(struct bus *bus, struct memranges *ranges, + unsigned long type_mask, unsigned long type_match) +{ + struct resource *resource = NULL; + const struct device *dev; + + while ((dev = largest_resource(bus, &resource, type_mask, type_match))) { + + if (!resource->size) { + mark_resource_invalid(resource); + continue; + } + + if (memranges_steal(ranges, resource->limit, resource->size, resource->align, + type_match, &resource->base) == false) { + printk(BIOS_ERR, "ERROR: Resource didn't fit!!! "); + printk(BIOS_SPEW, "%s %02lx * size: 0x%llx limit: %llx %s\n", + dev_path(dev), resource->index, + resource->size, resource->limit, resource2str(resource)); + mark_resource_invalid(resource); + continue; + } + + resource->limit = resource->base + resource->size - 1; + resource->flags |= IORESOURCE_ASSIGNED; + + printk(BIOS_SPEW, "%s %02lx * [0x%llx - 0x%llx] limit: %llx %s\n", + dev_path(dev), resource->index, resource->base, + resource->size ? resource->base + resource->size - 1 : + resource->base, resource->limit, resource2str(resource)); + } +} + +static void update_constraints(void *gp, struct device *dev, struct resource *res) +{ + struct memranges *ranges = gp; + + if (!res->size) + return; + + printk(BIOS_SPEW, "%s: %s %02lx base %08llx limit %08llx %s (fixed)\n", + __func__, dev_path(dev), res->index, res->base, + res->base + res->size - 1, resource2str(res)); + + memranges_create_hole(ranges, res->base, res->size); +} + +static void constrain_domain_resources(struct device *domain, struct memranges *ranges, + unsigned long type) +{ + struct resource *res; + struct bus *bus = domain->link_list; + unsigned long mask_match = type | IORESOURCE_FIXED; + + /* + * Scan the entire tree to identify any fixed resources allocated by any device to + * ensure that the address map for domain resources are appropriately updated. + * + * Domains can typically provide memrange for entire address space. So, this function + * punches holes in the address space for all fixed resources that are already + * defined. Both IO and normal memory resources are added as fixed. Both need to be + * removed from address space where dynamic resource allocations are sourced. + */ + search_bus_resources(bus, mask_match, mask_match, update_constraints, ranges); + + if (type == IORESOURCE_IO) { + /* + * Don't allow allocations in the VGA I/O range. PCI has special cases for + * that. + */ + memranges_create_hole(ranges, 0x3b0, 0x3df); + + /* + * Resource allocator no longer supports the legacy behavior where I/O resource + * allocation is guaranteed to avoid aliases over legacy PCI expansion card + * addresses. + */ + } + + /* + * Some domains have fixed resources hanging directly off the device. Avoid those fixed + * resources in the address space for alocation. + */ + for (res = domain->resource_list; res != NULL; res = res->next) { + if ((res->flags & mask_match) != mask_match) + continue; + update_constraints(ranges, domain, res); + } +} + +/* + * This function creates a list of memranges of given type using the resource that is + * provided. If the given resource is NULL or if the resource window size is 0, then it creates + * an empty list. This results in resource allocation for that resource type failing for all + * downstream devices since there is nothing to allocate from. + * + * In case of domain, it applies additional constraints to ensure that the memranges do not + * overlap any of the fixed resources under that domain. Domain typically seems to provide + * memrange for entire address space. Thus, it is up to the chipset to add DRAM and all other + * windows which cannot be used for resource allocation as fixed resources. + */ +static void setup_resource_ranges(struct device *dev, const struct resource *res, + unsigned long type, struct memranges *ranges) +{ + printk(BIOS_SPEW, "%s %s: base: %llx size: %llx align: %d gran: %d limit: %llx\n", + dev_path(dev), resource2str(res), res->base, res->size, res->align, + res->gran, res->limit); + + initialize_memranges(ranges, res, type); + + if (dev->path.type == DEVICE_PATH_DOMAIN) + constrain_domain_resources(dev, ranges, type); + + print_resource_ranges(ranges); +} + +static void cleanup_resource_ranges(const struct device *dev, struct memranges *ranges, + const struct resource *res) +{ + memranges_teardown(ranges); + printk(BIOS_SPEW, "%s %s: base: %llx size: %llx align: %d gran: %d limit: %llx done\n", + dev_path(dev), resource2str(res), res->base, res->size, res->align, + res->gran, res->limit); +} + +/* + * Pass 2 of resource allocator at the bridge level loops through all the resources for the + * bridge and generates a list of memory ranges similar to that at the domain level. However, + * there is no need to apply any additional constraints since the window allocated to the bridge + * is guaranteed to be non-overlapping by the allocator at domain level. + * + * Allocation at the bridge level works the same as at domain level (starts with the biggest + * resource requirement from downstream devices and continues in descending order). One major + * difference at the bridge level is that it considers prefmem resources separately from mem + * resources. + * + * Once allocation at the current bridge is complete, resource allocator continues walking down + * the downstream bridges until it hits the leaf devices. + */ +static void allocate_bridge_resources(struct device *bridge) +{ + struct memranges ranges; + const struct resource *res; + struct bus *bus = bridge->link_list; + unsigned long type_match; + struct device *child; + const unsigned long type_mask = IORESOURCE_TYPE_MASK | IORESOURCE_PREFETCH; + + for (res = bridge->resource_list; res; res = res->next) { + if (!res->size) + continue; + + if (!(res->flags & IORESOURCE_BRIDGE)) + continue; + + type_match = res->flags & type_mask; + + setup_resource_ranges(bridge, res, type_match, &ranges); + allocate_child_resources(bus, &ranges, type_mask, type_match); + cleanup_resource_ranges(bridge, &ranges, res); + } + + for (child = bus->children; child; child = child->sibling) { + if (!dev_has_children(child)) + continue; + + allocate_bridge_resources(child); + } +} + +static const struct resource *find_domain_resource(const struct device *domain, + unsigned long type) +{ + const struct resource *res; + + for (res = domain->resource_list; res; res = res->next) { + if (res->flags & IORESOURCE_FIXED) + continue; + + if ((res->flags & IORESOURCE_TYPE_MASK) == type) + return res; + } + + return NULL; +} + +/* + * Pass 2 of resource allocator begins at the domain level. Every domain has two types of + * resources - io and mem. For each of these resources, this function creates a list of memory + * ranges that can be used for downstream resource allocation. This list is constrained to + * remove any fixed resources in the domain sub-tree of the given resource type. It then uses + * the memory ranges to apply best fit on the resource requirements of the downstream devices. + * + * Once resources are allocated to all downstream devices of the domain, it walks down each + * downstream bridge to continue the same process until resources are allocated to all devices + * under the domain. + */ +static void allocate_domain_resources(struct device *domain) +{ + struct memranges ranges; + struct device *child; + const struct resource *res; + + /* Resource type I/O */ + res = find_domain_resource(domain, IORESOURCE_IO); + if (res) { + setup_resource_ranges(domain, res, IORESOURCE_IO, &ranges); + allocate_child_resources(domain->link_list, &ranges, IORESOURCE_TYPE_MASK, + IORESOURCE_IO); + cleanup_resource_ranges(domain, &ranges, res); + } + + /* + * Resource type Mem: + * Domain does not distinguish between mem and prefmem resources. Thus, the resource + * allocation at domain level considers mem and prefmem together when finding the best + * fit based on the biggest resource requirement. + */ + res = find_domain_resource(domain, IORESOURCE_MEM); + if (res) { + setup_resource_ranges(domain, res, IORESOURCE_MEM, &ranges); + allocate_child_resources(domain->link_list, &ranges, IORESOURCE_TYPE_MASK, + IORESOURCE_MEM); + cleanup_resource_ranges(domain, &ranges, res); + } + + for (child = domain->link_list->children; child; child = child->sibling) { + if (!dev_has_children(child)) + continue; + + /* Continue allocation for all downstream bridges. */ + allocate_bridge_resources(child); + } +} + +/* + * This function forms the guts of the resource allocator. It walks through the entire device + * tree for each domain two times. + * + * Every domain has a fixed set of ranges. These ranges cannot be relaxed based on the + * requirements of the downstream devices. They represent the available windows from which + * resources can be allocated to the different devices under the domain. + * + * In order to identify the requirements of downstream devices, resource allocator walks in a + * DFS fashion. It gathers the requirements from leaf devices and propagates those back up + * to their upstream bridges until the requirements for all the downstream devices of the domain + * are gathered. This is referred to as pass 1 of resource allocator. + * + * Once the requirements for all the devices under the domain are gathered, resource allocator + * walks a second time to allocate resources to downstream devices as per the + * requirements. It always picks the biggest resource request as per the type (i/o and mem) to + * allocate space from its fixed window to the immediate downstream device of the domain. In + * order to accomplish best fit for the resources, a list of ranges is maintained by each + * resource type (i/o and mem). Domain does not differentiate between mem and prefmem. Since + * they are allocated space from the same window, the resource allocator at the domain level + * ensures that the biggest requirement is selected indepedent of the prefetch type. Once the + * resource allocation for all immediate downstream devices is complete at the domain level, + * resource allocator walks down the subtree for each downstream bridge to continue the + * allocation process at the bridge level. Since bridges have separate windows for i/o, mem and + * prefmem, best fit algorithm at bridge level looks for the biggest requirement considering + * prefmem resources separately from non-prefmem resources. This continues until resource + * allocation is performed for all downstream bridges in the domain sub-tree. This is referred + * to as pass 2 of resource allocator. + * + * Some rules that are followed by the resource allocator: + * - Allocate resource locations for every device as long as the requirements can be satisfied. + * - If a resource cannot be allocated any address space, then that resource needs to be + * properly updated to ensure that it does not incorrectly overlap some address space reserved + * for a different purpose. + * - Don't overlap with resources in fixed locations. + * - Don't overlap and follow the rules of bridges -- downstream devices of bridges should use + * parts of the address space allocated to the bridge. + */ +void allocate_resources(const struct device *root) +{ + struct device *child; + + if ((root == NULL) || (root->link_list == NULL)) + return; + + for (child = root->link_list->children; child; child = child->sibling) { + + if (child->path.type != DEVICE_PATH_DOMAIN) + continue; + + post_log_path(child); + + /* Pass 1 - Gather requirements. */ + printk(BIOS_INFO, "Resource allocator: %s - Pass 1 (gathering requirements)\n", + dev_path(child)); + compute_domain_resources(child); + + /* Pass 2 - Allocate resources as per gathered requirements. */ + printk(BIOS_INFO, "Resource allocator: %s - Pass 2 (allocating resources)\n", + dev_path(child)); + allocate_domain_resources(child); + } +} -- To view, visit https://review.coreboot.org/c/coreboot/+/41443 To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings Gerrit-Project: coreboot Gerrit-Branch: master Gerrit-Change-Id: Ide4d98528197bb03850a8fb4d73c41cd2c0195aa Gerrit-Change-Number: 41443 Gerrit-PatchSet: 1 Gerrit-Owner: Furquan Shaikh <furquan(a)google.com> Gerrit-Reviewer: Martin Roth <martinroth(a)google.com> Gerrit-Reviewer: Patrick Georgi <pgeorgi(a)google.com> Gerrit-MessageType: newchange

9 34

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

coreboot-gerrit June 2020