summaryrefslogtreecommitdiff
path: root/src/include/device
diff options
context:
space:
mode:
authorFurquan Shaikh <furquan@google.com>2020-03-31 21:21:52 -0700
committerPatrick Georgi <pgeorgi@google.com>2020-05-12 19:43:52 +0000
commit44ae0eacb82259243bf844a3fe5ad24a7821e997 (patch)
tree668de7be904d22dd99ecb4055280d7762daaadf6 /src/include/device
parent3b02006afe8a85477dafa1bd149f1f0dba02afc7 (diff)
downloadcoreboot-44ae0eacb82259243bf844a3fe5ad24a7821e997.tar.xz
device: Enable resource allocation above 4G boundary
This change adds support for allocating resources above the 4G boundary by making use of memranges for resource windows enabled in the previous CL. It adds a new resource flag IORESOURCE_ABOVE_4G which is used in the following ways: a) Downstream device resources can set this flag to indicate that they would like to have their resource allocation above the 4G boundary. These semantics will have to be enabled in the drivers managing the devices. It can also be extended to be enabled via devicetree. This flag is automatically propagated by the resource allocator from downstream devices to the upstream bridges in pass 1. It is done to ensure that the resource allocator has a global view of downstream requirements during pass 2 at domain level. b) Bridges have a single resource window for each of mem and prefmem resource types. Thus, if any downstream resource of the bridge requests allocation above 4G boundary, all the other downstream resources of the same type under the bridge will be allocated above 4G boundary. c) During pass 2, resource allocator at domain level splits IORESOURCE_MEM into two different memory ranges -- one for the window below 4G and other above 4G. Resource allocation happens separately for each of these windows. d) At the bridge level, there is no extra logic required since the resource will live entirely above or below the 4G boundary. Hence, all downstream devices of any bridge will fall within the window allocated to the bridge resource. To handle this case separately from that of domain, initializing of memranges for a bridge is done differently than the domain. Limitation: Resources of a given type at the bridge or downstream devices cannot live both above and below 4G boundary. Thus, if a bridge has some downstream resources requesting allocation for a given type above 4G boundary and other resources of the same type requesting allocation below 4G boundary, then all these resources of the same type get allocated above 4G boundary. BUG=b:149186922 TEST=Verified that resources get allocated above the 4G boundary correctly on volteer. Signed-off-by: Furquan Shaikh <furquan@google.com> Change-Id: I7fb2a75cc280a307300d29ddabaebfc49175548f Reviewed-on: https://review.coreboot.org/c/coreboot/+/39487 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Diffstat (limited to 'src/include/device')
-rw-r--r--src/include/device/resource.h2
1 files changed, 2 insertions, 0 deletions
diff --git a/src/include/device/resource.h b/src/include/device/resource.h
index 1d04e9a1c8..4ebdfa3d47 100644
--- a/src/include/device/resource.h
+++ b/src/include/device/resource.h
@@ -24,6 +24,8 @@
#define IORESOURCE_SUBTRACTIVE 0x00040000
/* The IO resource has a bus below it. */
#define IORESOURCE_BRIDGE 0x00080000
+/* This is a request to allocate resource about 4G boundary. */
+#define IORESOURCE_ABOVE_4G 0x00100000
/* The resource needs to be reserved in the coreboot table */
#define IORESOURCE_RESERVE 0x10000000
/* The IO resource assignment has been stored in the device */