diff options
author | Furquan Shaikh <furquan@google.com> | 2020-03-31 21:21:52 -0700 |
---|---|---|
committer | Patrick Georgi <pgeorgi@google.com> | 2020-05-12 19:43:52 +0000 |
commit | 44ae0eacb82259243bf844a3fe5ad24a7821e997 (patch) | |
tree | 668de7be904d22dd99ecb4055280d7762daaadf6 /src/include | |
parent | 3b02006afe8a85477dafa1bd149f1f0dba02afc7 (diff) |
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')
-rw-r--r-- | src/include/device/resource.h | 2 |
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 */ |