summaryrefslogtreecommitdiffstats
path: root/src/device/resource_allocator_v4.c
Commit message (Collapse)AuthorAgeFilesLines
* allocator_v4: Make it explicit that we start with the highest alignmentNico Huber2022-06-271-9/+6
| | | | | | | | | | | | | As we walk the results of largest_resource(), we actually know that the condition can only be true for the first return value. So there's no need to keep track of the first loop iteration. Change-Id: I6d6b99e38706c0c70f3570222d97a1d71ba79744 Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/65401 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
* allocator_v4: Manually inline round()Nico Huber2022-06-271-14/+2
| | | | | | | | | | | | | | | While what this round() function does is documented, it still seems hard to follow what happens when reading a call. I tried to come up with a better name, but eventually reading an explicit ALIGN_UP() worked best. Change-Id: Ifd49270bbae0ee463a996643fc76bce1f97ec9b7 Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/65400 Reviewed-by: Elyes Haouas <ehaouas@noos.fr> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
* allocator_v4: Reflow and revise comment blocksNico Huber2022-06-271-155/+196
| | | | | | | | | | | | | | | | | | These comments are a very nice example of documented code. The comment blocks use the full, allowed line length, though. That is nice for code, but can make text blocks harder to read. So reflow the comments to a 72-char width (like we use in emails and commit messages). Also add some articles where they seemed missing and fix some smaller nits. Change-Id: If4cdbb383cf67f01200c8e4163fc3c576a5c3a87 Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/65399 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
* allocator_v4: Drop spurious rule from commentNico Huber2022-06-271-3/+0
| | | | | | | | | | | | | | | | The comment said special care needs to be taken if a resource cannot be allocated. However, the opposite seems true: There is nothing to be done, we simply leave the resource w/o the IORESOURCE_ASSIGNED flag. There's also no code to be found that would currently do some- thing special. allocate_child_resources() directly continues with the next resource after printing an error. Change-Id: I21acbc891ea4dfb62decf9abe0ace91016486116 Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/65412 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
* src/acpi to src/lib: Fix spelling errorsMartin Roth2021-10-051-1/+1
| | | | | | | | | | | | These issues were found and fixed by codespell, a useful tool for finding spelling errors. Signed-off-by: Martin Roth <martin@coreboot.org> Change-Id: I5b8ecdfe75d99028fee820a2034466a8ad1c5e63 Reviewed-on: https://review.coreboot.org/c/coreboot/+/58080 Reviewed-by: Felix Held <felix-coreboot@felixheld.de> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
* device/resource_allocator_v4: Only highlight log message with ===Paul Menzel2021-07-051-1/+1
| | | | | | | | | | | | | | | | | | | | Currently, four instead of three = are used in one log message. Done reading resources. ==== Resource allocator: DOMAIN: 0000 - Pass 1 (gathering requirements) === === Resource allocator: DOMAIN: 0000 - Pass 2 (allocating resources) === As the ending mark is `===` change it to `===` in the beginning. Done reading resources. === Resource allocator: DOMAIN: 0000 - Pass 1 (gathering requirements) === === Resource allocator: DOMAIN: 0000 - Pass 2 (allocating resources) === Change-Id: I40c3876e1f895b7f9771479234c9529cca2b97ba Signed-off-by: Paul Menzel <pmenzel@molgen.mpg.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/56045 Reviewed-by: Furquan Shaikh <furquan@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
* device/resource_allocator_v4: Improve the logging in resource allocatorFurquan Shaikh2020-05-281-21/+29
| | | | | | | | | | | | | | | | | | | This change makes the following improvements to debug logging in resource allocator: 1. Print depth is added to functions in pass 1 to better represent how the resource requirements of child devices impact the resource windows for parent bridge. 2. Device path is added to resource ranges to make it easier to understand what device the resouce ranges are associated with. 3. Prints in pass 2 (update constraints, resource ranges, resource assignment) are shifted left by 1 to make it easier to visualize resource allocation for each bridge including domain. Signed-off-by: Furquan Shaikh <furquan@google.com> Change-Id: I3356a7278060e281d1a57d253537b097472827a1 Reviewed-on: https://review.coreboot.org/c/coreboot/+/41478 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
* device/resource_allocator_v4: Change BIOS_SPEW to BIOS_DEBUGFurquan Shaikh2020-05-281-8/+8
| | | | | | | | | | | | | | | This change updates the log level for prints in resource allocator v4 to BIOS_DEBUG instead of BIOS_SPEW. These are critical in debugging issues and should be enabled at log level BIOS_DEBUG. Signed-off-by: Furquan Shaikh <furquan@google.com> Change-Id: Ib863619f5e1214e4fe6f05c52be6fa2de36e6c3b Reviewed-on: https://review.coreboot.org/c/coreboot/+/41477 Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr> Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
* device: Enable resource allocation above 4G boundary with allocator v4Furquan Shaikh2020-05-281-10/+135
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* resource_allocator_v4: Fix size of I/O hole at 0x3b0Furquan Shaikh2020-05-271-1/+1
| | | | | | | | | | | | | | | Addressing comment from CB:41443 that was received after the change landed. memranges_create_hole() takes size as the last parameter. So, the I/O hole created at 0x3b0 needs to set size as 0x3df - 0x3b0 + 1 as 0x3df is the upper limit of that hole. Change-Id: I08fca283436924427e12c6c69edced7e51db42a9 Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/41737 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
* device: Add support for resource allocator v4Furquan Shaikh2020-05-261-0/+552
This change adds back support for the resource allocator using multiple ranges as originally landed in CB:39486(commit hash 3b02006) and reverted in CB:41413(commit hash 6186cbc). The new resource allocator can be selected by Kconfig option RESOURCE_ALLOCATOR_V4. It was identified that there are some AMD chipsets in the tree that do not really work well with the dynamic resource allocation. Until these chipsets are fixed, old (v3) and new (v4) of the resource allocator need to live side-by-side in the tree. There were some other chipsets in the tree which originally demonstrated problems with the new resource allocator, but have been since fixed in the tree. This change picks up the same additions as performed in CB:39486 along with the following changes: 1. Changes to avoid fixed resources in the entire tree. Use of search_bus_resources() is replaced with a walk of the entire tree in avoid_fixed_resources(). This is required to ensure that all fixed resources added to any device (including domain) are taken into consideration to avoid overlap during dynamic resource allocation. 2. Changes to set up alignment for memranges when initializing them. This is done to ensure that the right granularity is used for IORESOURCE_IO(no special alignment) and IORESOURCE_MEM(4KiB) resource requests. 3. mark_resource_invalid() is dropped as the resource no longer needs to be marked in any special way if allocation is not being done. Instead setting of IORESOURCE_ASSIGNED flag is skipped in this case. 4. initialize_memranges() is updated to check IORESOURCE_ASSIGNED instead of base == limit. Original commit message: This change updates the resource allocator in coreboot to allow using multiple ranges for resource allocation rather than restricting available window to a single base/limit pair. This is done in preparation to allow 64-bit resource allocation. Following changes are made as part of this: a) Resource allocator still makes 2 passes at the entire tree. The first pass is to gather the resource requirements of each device under each domain. It walks recursively in DFS fashion to gather the requirements of the leaf devices and propagates this back up to the downstream bridges of the domain. Domain is special in the sense that it has fixed resource ranges. Hence, the resource requirements from the downstream devices have no effect on the domain resource windows. This results in domain resource limits being unmodified after the first pass. b) Once the requirements for all the devices under the domain are gathered, resource allocator walks a second time to allocate resources to downstream devices as per the requirements. Here, instead of maintaining a single window for allocating resources, it creates a list of memranges starting with the resource window at domain and then applying constraints to create holes for any fixed resources. This ensures that there is no overlap with fixed resources under the domain. c) Domain does not differentiate between mem and prefmem. Since they are allocated space from the same resource window at the domain level, it considers all resource requests from downstream devices of the domain independent of the prefetch type. d) Once resource allocation is done at the domain level, resource allocator walks down the downstream bridges and continues the same process until it reaches the leaves. Bridges have separate windows for mem and prefmem. Hence, unlike domain, the resource allocator at bridge level ensures that downstream requirements are satisfied by taking prefetch type into consideration. e) This whole 2-pass process is performed for every domain in the system under the assumption that domains do not have overlapping address spaces. Noticeable differences from previous resource allocator: a) Changes in print logs observed due to flows being slightly different. b) Base, limit and size of domain resources are no longer updated based on downstream requirements. c) Memranges are used instead of a single base/limit pair for determining resource allocation. d) Previously, if a resource request did not fit in the available base/limit window, then the resource would be allocated over DRAM or any other address space defeating the principle of "no overlap". With this change, any time a resource cannot fit in the available ranges, it complains and ensures that the resource is effectively disabled by setting base same as the limit. e) Resource allocator no longer looks at multiple links to determine the right bus for a resource. None of the current boards have multiple buses under any downstream device of the domain. The only device with multiple links seems to be the cpu cluster device for some AMD platforms. Change-Id: Ide4d98528197bb03850a8fb4d73c41cd2c0195aa Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/41443 Reviewed-by: Nico Huber <nico.h@gmx.de> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>