diff options
author | Furquan Shaikh <furquan@google.com> | 2020-05-15 17:33:52 -0700 |
---|---|---|
committer | Patrick Georgi <pgeorgi@google.com> | 2020-05-28 09:41:54 +0000 |
commit | 1bb05ef30b2dc5ccfbc26a185f350fdc8ee4f904 (patch) | |
tree | 73e31043c073c822515e33e1a2d731d7aa3ef2ab /src/include/device | |
parent | c351f57dcc070eb0365ab3bb05e0e65c770307ed (diff) |
device: Enable resource allocation above 4G boundary with allocator v4
This change adds back CB:39487 which was reverted as part of
CB:41412. Now that the resource allocator is split into old(v3) and
new(v4), this change adds support for allocating resources above 4G
boundary with the new allocator v4.
Original commit message:
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.
Change-Id: I92a5cf7cd1457f2f713e1ffd8ea31796ce3d0cce
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41466
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.h | 2 |
1 files changed, 2 insertions, 0 deletions
diff --git a/src/include/device/resource.h b/src/include/device/resource.h index c97b01d22f..42c7e6ae45 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 */ |