summaryrefslogtreecommitdiff
path: root/src/mainboard/google/volteer/Kconfig
diff options
context:
space:
mode:
authorFurquan Shaikh <furquan@google.com>2020-05-15 17:33:52 -0700
committerPatrick Georgi <pgeorgi@google.com>2020-05-28 09:41:54 +0000
commit1bb05ef30b2dc5ccfbc26a185f350fdc8ee4f904 (patch)
tree73e31043c073c822515e33e1a2d731d7aa3ef2ab /src/mainboard/google/volteer/Kconfig
parentc351f57dcc070eb0365ab3bb05e0e65c770307ed (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/mainboard/google/volteer/Kconfig')
0 files changed, 0 insertions, 0 deletions