allocator_v4: Treat above 4G resources more natively

We currently have two competing mechanisms to limit the placement of
resources:

 1. the explicit `.limit` field of a resource, and
 2. the IORESOURCE_ABOVE_4G flag.

This makes the resource allocator unnecessarily complex. Ideally, we
would always reduce the `.limit` field if we want to "pin" a specific
resource below 4G. However, as that's not done across the tree yet,
we will use the _absence_ of the IORESOURCE_ABOVE_4G flag as a hint
to implicitly lower the `limit` of a resource. In this patch, this
is done inside the effective_limit() function that hides the flag
from the rest of the allocator.

To automatically place resources above 4G if their limit allows it,
we have to allocate from top down. Hence, we disable the prompt for
RESOURCE_ALLOCATION_TOP_DOWN and turn it on by default. Platforms
that are incompatible should be fixed, but can also override the
default as a temporary measure.

One implication of the changes is that we act differently when a
cold-plugged device reports a prefetchable resource with 32-bit
limit. Before this change, we would fail to allocate the resource.
After this change, it forces everything on the same root port below
the 4G line.

A possible solution to get completely rid of the IORESOURCE_ABOVE_4G
flag would be rules to place resources of certain devices below 4G.
For instance, the primary VGA device and storage and HID devices
could be made available to a payload that can only address 32 bits.

For now, effective_limit() provides us enough abstraction as if the
`limit` would be the only variable to consider. With this, we get
rid of all the special handling of above 4G resources during phase 2
of the allocator. Which saves us about 20% of the code :D

An earlier version of this change (commit 117e43611548) had to be
reverted because of missing resource reservations in platform code.
This is worked around now with commit ae81497cb6c7 (device/pci:
Limit default domain memory window).

Change-Id: Ia822f0ce648c7f7afc801d9cb00b6459fe7cebea
Signed-off-by: Nico Huber <nico.h@gmx.de>
Original-reviewed-on: https://review.coreboot.org/c/coreboot/+/65413
Original-reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Original-reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75012
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>

1 files changed, 5 insertions, 4 deletions

diff --git a/src/device/Kconfig b/src/device/Kconfig
index 9c9ecd1973..2d2c6fffa7 100644
--- a/src/device/Kconfig
+++ b/src/device/Kconfig
@@ -994,11 +994,12 @@ config I2C_TRANSFER_TIMEOUT_US
 	  is aborted and an error returned.
 
 config RESOURCE_ALLOCATION_TOP_DOWN
-	bool "Allocate resources from top down"
-	default n
+	def_bool y
 	help
-	  Should be the default, but many platforms don't report resources
-	  correctly. Hence, the allocator might cause conflicts.
+	  Top-down allocation is required to place resources above 4G by
+	  default (i.e. even when there is still space below). On some
+	  platforms, it might make a difference because of conflicts with
+	  undeclared resources.
 
 config XHCI_UTILS
 	def_bool n