| Age | Commit message (Collapse) | Author |
|---|
|
There is no need to have two separate API's for freeing up memory. Use
a single API lmb_free() to achieve this.
Signed-off-by: Sughosh Ganu <[email protected]>
Reviewed-by: Ilias Apalodimas <[email protected]>
|
|
lmb_add_memory() is only called from the lmb module. Mark the function
as static.
Signed-off-by: Sughosh Ganu <[email protected]>
Reviewed-by: Ilias Apalodimas <[email protected]>
|
|
There currently are two API's for requesting memory from the LMB
module, lmb_alloc() and lmb_alloc_base(). The function which does the
actual allocation is the same. Use the earlier introduced API
lmb_alloc_mem() for both types of allocation requests.
Signed-off-by: Sughosh Ganu <[email protected]>
Acked-by: Ilias Apalodimas <[email protected]>
|
|
There currently are multiple allocation API's in the LMB module. There
are a couple of API's for allocating memory(lmb_alloc() and
lmb_alloc_base()), and then there are two for requesting a reservation
for a particular memory region (lmb_reserve() and
lmb_alloc_addr()). Introduce a single API lmb_alloc_mem() which will
cater to all types of allocation requests and replace lmb_reserve()
and lmb_alloc_addr() with the new API.
Moreover, the lmb_reserve() API is pretty similar to the
lmb_alloc_addr() API, with the one difference being that the
lmb_reserve() API allows for reserving any address passed to it --
the address need not be part of the LMB memory map. The
lmb_alloc_addr() does check that the address being requested is
actually part of the LMB memory map.
There is no need to support reserving memory regions which are outside
the LMB memory map. Remove the lmb_reserve() API functionality and use
the functionality provided by lmb_alloc_addr() instead. The
lmb_alloc_addr() will check if the requested address is part of the
LMB memory map and return an error if not.
Signed-off-by: Sughosh Ganu <[email protected]>
Acked-by: Ilias Apalodimas <[email protected]>
|
|
The LMB memory region attributes flags are used to specify the
behaviour of the memory regions with respect to allocations -- for
e.g. it is allowed to re-allocate a memory region already reserved
with the LMB_NONE flag. The flags use values with different bit
positions through the BIT() macro. Move the LMB_NOMAP value to bit
position 1, and also move the other flags accordingly. Using bit
position 0 for LMB_NOMAP results in the logic in
lmb_print_region_flags() to break, which prints an incorrect value for
the regions with LMB_NOMAP atribute.
Fixes: 3d56c06551d ("lmb: Move enum lmb_flags to a u32")
Signed-off-by: Sughosh Ganu <[email protected]>
|
|
Ben reports a failure to boot the kernel on hardware that starts its
physical memory from 0x0.
The reason is that lmb_alloc_addr(), which is supposed to reserve a
specific address, takes the address as the first argument, but then also
returns the address for success or failure and treats 0 as a failure.
Since we already know the address change the prototype to return an int.
Reported-by: Ben Schneider <[email protected]>
Signed-off-by: Ilias Apalodimas <[email protected]>
Tested-by: Ben Schneider <[email protected]>
Reviewed-by: Sughosh Ganu <[email protected]>
|
|
Instead of testing the value of parameter op at runtime use an enum to
ensure that only valid values are used.
Reviewed-by: Ilias Apalodimas <[email protected]>
Signed-off-by: Heinrich Schuchardt <[email protected]>
|
|
lmb_alloc_addr_flags() is a wrapper for _lmb_alloc_addr() and it's the
only function using it. Rename _lmb_alloc_addr() to lmb_alloc_addr_flags()
and remove the wrapper.
Reviewed-by: Sam Protsenko <[email protected]>
Tested-by: Sam Protsenko <[email protected]>
Signed-off-by: Ilias Apalodimas <[email protected]>
|
|
lmb_alloc_base() is just calling lmb_alloc_base_flags() with LMB_NONE.
There's not much we gain from this abstraction, so let's remove the
former add the flags argument to lmb_alloc_base() and make the code
a bit easier to follow.
Reviewed-by: Sam Protsenko <[email protected]>
Tested-by: Sam Protsenko <[email protected]>
Signed-off-by: Ilias Apalodimas <[email protected]>
|
|
lmb_alloc_addr() is just calling lmb_alloc_addr_flags() with LMB_NONE
There's not much we gain from this abstraction, so let's remove the
latter, add a flags argument to lmb_alloc_addr() and make the code a
bit easier to follow.
Reviewed-by: Sam Protsenko <[email protected]>
Tested-by: Sam Protsenko <[email protected]>
Signed-off-by: Ilias Apalodimas <[email protected]>
|
|
free_mem is a misnomer. We never update it with the free memory for
LMB. Instead, it describes all available memory and is checked against
used_mem to decide whether an area is free or not.
So let's rename this field to better match its usage.
Reviewed-by: Sam Protsenko <[email protected]>
Tested-by: Sam Protsenko <[email protected]>
Signed-off-by: Ilias Apalodimas <[email protected]>
|
|
lmb_reserve() is just calling lmb_reserve_flags() with LMB_NONE.
There's not much we gain from this abstraction.
So let's remove the latter, add the flags argument to lmb_reserve()
and make the code a bit easier to follow.
Reviewed-by: Tom Rini <[email protected]>
Reviewed-by: Sam Protsenko <[email protected]>
Tested-by: Sam Protsenko <[email protected]>
Signed-off-by: Ilias Apalodimas <[email protected]>
|
|
LMB flags is not an enum anymore. It's currently used as a bitmask
in various places of our code. So make it a u32 which is more
appropriate when dealing with masks.
Reviewed-by: Sam Protsenko <[email protected]>
Tested-by: Sam Protsenko <[email protected]>
Signed-off-by: Ilias Apalodimas <[email protected]>
|
|
Fix warnings from kernel-doc script. Improve and unify overall style of
kernel-doc comments in lmb source files. Move all kernel-doc comments
for public functions into the header, as recommended in U-Boot
documentation [1]:
Non-trivial functions should have a comment which describes what
they do. If it is an exported function, put the comment in the
header file so the API is in one place. If it is a static function,
put it in the C file.
This also takes care of existing duplication. While at it, do a bit of
cosmetic cleanups as well.
No functional change.
[1] doc/develop/codingstyle.rst
Signed-off-by: Sam Protsenko <[email protected]>
Acked-by: Ilias Apalodimas <[email protected]>
|
|
mem map changes"
Janne Grunau <[email protected]> says:
The changes in "Make LMB memory map global and persistent" [1] break
mapping DMA memory in the USB xHCI driver when using the apple_dart
iommu present on Apple silicon systems.
The IOVA space used by the u-boot driver (low 4GB) and physical memory
do not overlap. The physical memory on this systems starts depending on
the SoC either at 0x10_0000_0000 or 0x100_0000_0000. It make no sense to
manage these distinct regions in a single LMB map. In addition every
device has its own iommu and IO address space so sharing a single memory
map between all iommu instances is not necessary.
To fix this issue restore the used subset (add, alloc and free) of the
previous pointer based LMB interface with "io_" as prefix.
To ensure that low level lmb functions do not use the global LMB
variable reorder lib/lmb.c so that the variable is not visible.
Tested with patches from my "Fix device removal order for Apple dart
iommu" series [2] to fix a separate issue.
The cosmetic commit has two checkpatch warnings in existing code which I
ignored.
[1] https://lore.kernel.org/u-boot/[email protected]/
[2] https://lore.kernel.org/u-boot/[email protected]/
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Tom Rini <[email protected]>
|
|
These functions can be used with struct lmb pointers and will be used to
manage IOVA space in the apple_dart iommu driver. This restores part of
the pointer base struct lmb API from before commit ed17a33fed29 ("lmb:
make LMB memory map persistent and global").
io_lmb_add() and io_lmb_free() can trivially reuse exisiting lmb
functions. io_lmb_setup() is separate for unique error log messages.
io_lmb_alloc() is a simplified copy of _lmb_alloc_base() since the
later has unused features and internal use of the global LMB memory map.
Signed-off-by: Janne Grunau <[email protected]>
|
|
lmb_alloc_flags() & lmb_alloc_base_flags() are just a wrappers for
_lmb_alloc_base(). Since the only difference is the max address of the
allowed allocation which _lmb_alloc_base() already supports with the
LMB_ALLOC_ANYWHERE flag, remove one of them.
Keep the lmb_alloc_base_flags() which also prints an error on failures
and adjust efi_allocate_pages() to only use one of them.
While at it clean up the duplicate function description from the header
file.
Signed-off-by: Ilias Apalodimas <[email protected]>
|
|
Some architectures have special or unique aspects which need
consideration when adding memory ranges to the list of available
memory map. Enable this config in such scenarios which allow
architectures and boards to define their own memory map.
Signed-off-by: Sughosh Ganu <[email protected]>
|
|
In U-Boot, LMB and EFI are two primary modules who provide memory
allocation and reservation API's. Both these modules operate with the
same regions of memory for allocations. Use the LMB memory map update
event to notify other interested listeners about a change in it's
memory map. This can then be used by the other module to keep track of
available and used memory.
There is no need to send these notifications when the LMB module is
being unit-tested. Add a flag to the lmb structure to indicate if the
memory map is being used for tests, and suppress sending any
notifications when running these unit tests.
Signed-off-by: Sughosh Ganu <[email protected]>
|
|
Add a flag LMB_NONOTIFY that can be passed to the LMB API's for
reserving memory. This will then result in no notification being sent
from the LMB module for the changes to the LMB's memory map.
While here, also add a description of the memory attributes that the
flags signify.
Signed-off-by: Sughosh Ganu <[email protected]>
|
|
The LMB module is to be used as a backend for allocating and freeing
up memory requested from other modules like EFI. These memory requests
are different from the typical LMB reservations in that memory
required by the EFI module cannot be overwritten, or re-requested. Add
versions of the LMB API functions with flags for allocating and
freeing up memory. The caller can then use these API's for specifying
the type of memory that is required. For now, these functions will be
used by the EFI memory module.
Signed-off-by: Sughosh Ganu <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
Added LMB API to prevent SF command from overwriting reserved
memory areas. The current SPI code does not use LMB APIs for
loading data into memory addresses. To resolve this, LMB APIs
were added to check the load address of an SF command and ensure it
does not overwrite reserved memory addresses. Similar checks are
used in TFTP, serial load, and boot code to prevent overwriting
reserved memory.
Signed-off-by: Prasad Kummari <[email protected]>
Suggested-by: Sughosh Ganu <[email protected]>
|
|
The board_lmb_reserve() function is not being used, and currently
there is only an empty weak function defined. Remove this unused
function.
Signed-off-by: Sughosh Ganu <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
Reviewed-by: Ilias Apalodimas <[email protected]>
|
|
All of the current definitions of arch_lmb_reserve() are doing the
same thing -- reserve the region of memory occupied by U-Boot,
starting from the current stack address to the ram_top. Introduce a
function lmb_reserve_uboot_region() which does this, and do away with
the arch_lmb_reserve() function.
Instead of using the current value of stack pointer for starting the
reserved region, have a fixed value, considering the stack size config
value.
Signed-off-by: Sughosh Ganu <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
Acked-by: Ilias Apalodimas <[email protected]>
|
|
With the move to make the LMB allocations persistent and the common
memory regions being reserved during board init, there is no need for
an explicit reservation of a memory range. Remove the
lmb_init_and_reserve_range() function.
Signed-off-by: Sughosh Ganu <[email protected]>
Reviewed-by: Ilias Apalodimas <[email protected]>
Reviewed-by: Tom Rini <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
With the changes to make the LMB reservations persistent, the common
memory regions are being added during board init. Remove the
now superfluous lmb_init_and_reserve() function.
Signed-off-by: Sughosh Ganu <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
Reviewed-by: Ilias Apalodimas <[email protected]>
|
|
Introduce a function lmb_add_memory() to add available memory to the
LMB memory map. Call this function during board init once the LMB data
structures have been initialised.
Signed-off-by: Sughosh Ganu <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
Allow for resizing of LMB regions if the region attributes match. The
current code returns a failure status on detecting an overlapping
address. This worked up until now since the LMB calls were not
persistent and global -- the LMB memory map was specific and private
to a given caller of the LMB API's.
With the change in the LMB code to make the LMB reservations
persistent, there needs to be a check on whether the memory region can
be resized, and then do it if so. To distinguish between memory that
cannot be resized, add a new flag, LMB_NOOVERWRITE. Reserving a region
of memory with this attribute would indicate that the region cannot be
resized.
Signed-off-by: Sughosh Ganu <[email protected]>
|
|
The current LMB API's for allocating and reserving memory use a
per-caller based memory view. Memory allocated by a caller can then be
overwritten by another caller. Make these allocations and reservations
persistent using the alloced list data structure.
Two alloced lists are declared -- one for the available(free) memory,
and one for the used memory. Once full, the list can then be extended
at runtime.
[sjg: Use a stack to store pointer of lmb struct when running lmb tests]
Signed-off-by: Sughosh Ganu <[email protected]>
Signed-off-by: Simon Glass <[email protected]>
[sjg: Optimise the logic to add a region in lmb_add_region_flags()]
|
|
Use the BIT macro for assigning values to the LMB flags instead of
assigning random values to them.
Signed-off-by: Sughosh Ganu <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
Reviewed-by: Ilias Apalodimas <[email protected]>
|
|
The __lmb_alloc_base() function is only called from within the lmb
module. Moreover, the lmb_alloc() and lmb_alloc_base() API's are good
enough for the allocation API calls. Make the __lmb_alloc_base()
function static.
Signed-off-by: Sughosh Ganu <[email protected]>
Reviewed-by: Ilias Apalodimas <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
The lmb_is_reserved() API is not used. There is another API,
lmb_is_reserved_flags() which can be used to check if a particular
memory region is reserved. Remove the unused API.
Signed-off-by: Sughosh Ganu <[email protected]>
Reviewed-by: Ilias Apalodimas <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
* provide a description for function lmb_is_reserved()
* improve the description of funciton lmb_is_reserved_flags()
Signed-off-by: Heinrich Schuchardt <[email protected]>
|
|
Remove test on CONFIG_LMB_MEMORY_REGIONS introduced by commit
7c1860fce4e3 ("lmb: Fix lmb property's defination under struct lmb").
This code in lmb_init() is strange, because if CONFIG_LMB_USE_MAX_REGIONS
and CONFIG_LMB_MEMORY_REGIONS are not defined, the implicit #else is empty
and the required initialization is not done:
lmb->memory.max = ?
lmb->reserved.max = ?
But this setting is not possible:
- CONFIG_LMB_USE_MAX_REGIONS not defined
- CONFIG_LMB_MEMORY_REGIONS not defined
because CONFIG_LMB_MEMORY_REGIONS and CONFIG_LMB_RESERVED_REGIONS are
defined as soon as the CONFIG_LMB_USE_MAX_REGIONS is not defined.
This patch removes this impossible case #elif and I add some
explanation in lmb.h to explain why in the struct lmb {} the lmb
property is defined if CONFIG_LMB_MEMORY_REGIONS is NOT defined.
This patch also removes CONFIG_LMB_XXX dependency on CONFIG_LMB as these
defines are used in API file lmb.h and not only in library file.
Fixes: 5e2548c1d6e03 ("lmb: Fix LMB_MEMORY_REGIONS flag usage")
Reported-by: Mark Millard <[email protected]>
Signed-off-by: Patrick Delaunay <[email protected]>
Acked-by: Michal Simek <[email protected]>
|
|
This patch is fixing a broken boot observed on stm32mp157c-dk2 board.
IS_ENABLED macro should be used to check if a compilation flag is set
to "y" or "m".
LMB_MEMORY_REGIONS is set to a numerical value, IS_ENABLED macro is not
suitable in this case.
Fixes: 7c1860fce4e3 ("lmb: Fix lmb property's defination under struct lmb")
Signed-off-by: Patrice Chotard <[email protected]>
Acked-by: Michal Simek <[email protected]>
Reviewed-by: Tom Rini <[email protected]>
|
|
Under struct lmb {} the lmb property's should be defined only if
CONFIG_LMB_MEMORY_REGIONS is defined.
Signed-off-by: Ashok Reddy Soma <[email protected]>
Signed-off-by: Michal Simek <[email protected]>
Signed-off-by: Michal Simek <[email protected]>
Link: https://lore.kernel.org/r/c24a2b1d6f5db4eb65393f6a77fae129b30b6233.1657183534.git.michal.simek@amd.com
|
|
lmb_size_bytes() is unused.
Signed-off-by: Heinrich Schuchardt <[email protected]>
Acked-by: Ilias Apalodimas <[email protected]>
|
|
The extern keyword is not needed in include/lmb.h to declare functions.
Remove it.
Signed-off-by: Heinrich Schuchardt <[email protected]>
Acked-by: Ilias Apalodimas <[email protected]>
|
|
Correct Sphinx style comments in include/lmb.h
Add the logical memory block API to the HTML documentation.
Signed-off-by: Heinrich Schuchardt <[email protected]>
Acked-by: Ilias Apalodimas <[email protected]>
|
|
Defining static functions in includes should be avoided.
Function lmb_is_nomap() is only used in the unit test.
So move it to the unit test.
Signed-off-by: Heinrich Schuchardt <[email protected]>
Acked-by: Ilias Apalodimas <[email protected]>
|
|
The arc/arm/m68k/microblaze/mips/ppc arch_lmb_reserve() implementations
are all mostly the same, except for a couple of details. Implement a
generic arch_lmb_reserve_generic() function which can be parametrized
enough to cater for those differences between architectures. This can
also be parametrized enough so it can handle cases where U-Boot is not
relocated to the end of DRAM e.g. because there is some other reserved
memory past U-Boot (e.g. unmovable firmware for coprocessor), it is not
relocated at all, and other such use cases.
Signed-off-by: Marek Vasut <[email protected]>
Cc: Alexey Brodkin <[email protected]>
Cc: Angelo Dureghello <[email protected]>
Cc: Daniel Schwierzeck <[email protected]>
Cc: Eugeniy Paltsev <[email protected]>
Cc: Hai Pham <[email protected]>
Cc: Michal Simek <[email protected]>
Cc: Simon Goldschmidt <[email protected]>
Cc: Tom Rini <[email protected]>
Cc: Wolfgang Denk <[email protected]>
Reviewed-by: Tom Rini <[email protected]>
|
|
Add a new function lmb_is_reserved_flags to check if
an address is reserved with a specific flags.
This function can be used to check if an address was
reserved with no-map flags with:
lmb_is_reserved_flags(lmb, addr, LMB_NOMAP);
Signed-off-by: Patrick Delaunay <[email protected]>
|
|
Add "flags" in lmb_property to save the "no-map" property of
reserved region and a new function lmb_reserve_flags() to check
this flag.
The default allocation use flags = LMB_NONE.
The adjacent reserved memory region are merged only when they have
the same flags value.
This patch is partially based on flags support done in Linux kernel
mm/memblock .c (previously lmb.c); it is why LMB_NOMAP = 0x4, it is
aligned with MEMBLOCK_NOMAP value.
Signed-off-by: Patrick Delaunay <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
Add 2 configs CONFIG_LMB_MEMORY_REGIONS and CONFIG_LMB_RESERVED_REGIONS
to change independently the max number of the regions in lmb
library.
When CONFIG_LMB_USE_MAX_REGIONS=y, move the lmb property arrays to
struct lmb and manage the array size with the element 'max' of struct
lmb_region; their are still allocated in stack.
When CONFIG_LMB_USE_MAX_REGIONS=n, keep the current location in
struct lmb_region to allow compiler optimization.
Increase CONFIG_LMB_RESERVED_REGIONS is useful to avoid lmb errors in
bootm when the number of reserved regions (not adjacent) is reached:
+ 1 region for relocated U-Boot
+ 1 region for initrd
+ 1 region for relocated linux device tree
+ reserved memory regions present in Linux device tree.
The current limit of 8 regions is reached with only 5 reserved regions
in DT.
see Linux kernel commit bf23c51f1f49 ("memblock: Move memblock arrays
to static storage in memblock.c and make their size a variable")
Signed-off-by: Patrick Delaunay <[email protected]>
|
|
As in lmb_region, cnt < max and in the lmb library
use region[i] only with i in 0...cnt, this region array size
can be reduced by 1 element without overflow.
This patch allows to reduce the struct lmb size.
Signed-off-by: Patrick Delaunay <[email protected]>
|
|
Move MAX_LMB_REGIONS value in Kconfig, the max number of the regions
in lmb library.
Signed-off-by: Patrick Delaunay <[email protected]>
|
|
Add a max parameter in lmb_region struct to handle test
in lmb_add_region without using the MAX_LMB_REGIONS
define.
This patch allows to modify these size independently for
memory of reserved regions in the next patches.
Signed-off-by: Patrick Delaunay <[email protected]>
|
|
Remove the unused field size of struct lmb_region as it is initialized to 0
and never used after in lmb library.
See Linux kernel commit 4734b594c6ca ("memblock: Remove memblock_type.size
and add memblock.memory_size instead")
Signed-off-by: Patrick Delaunay <[email protected]>
|
|
Dump lmb status from the bdinfo command. This is useful for seeing the
reserved memory regions from the u-boot cmdline.
Signed-off-by: Tero Kristo <[email protected]>
|
|
The Linux coding style guide (Documentation/process/coding-style.rst)
clearly says:
It's a **mistake** to use typedef for structures and pointers.
Besides, using typedef for structures is annoying when you try to make
headers self-contained.
Let's say you have the following function declaration in a header:
void foo(bd_t *bd);
This is not self-contained since bd_t is not defined.
To tell the compiler what 'bd_t' is, you need to include <asm/u-boot.h>
#include <asm/u-boot.h>
void foo(bd_t *bd);
Then, the include direcective pulls in more bloat needlessly.
If you use 'struct bd_info' instead, it is enough to put a forward
declaration as follows:
struct bd_info;
void foo(struct bd_info *bd);
Right, typedef'ing bd_t is a mistake.
I used coccinelle to generate this commit.
The semantic patch that makes this change is as follows:
<smpl>
@@
typedef bd_t;
@@
-bd_t
+struct bd_info
</smpl>
Signed-off-by: Masahiro Yamada <[email protected]>
|
