| Message ID | 20240821105839.2870293-1-sughosh.ganu@linaro.org |
|---|---|
| Headers | show |
| Series | Make LMB memory map global and persistent | expand |
On Wed, Aug 21, 2024 at 04:28:12PM +0530, Sughosh Ganu wrote: > This is a follow-up from an earlier RFC series [1] for making the LMB > and EFI memory allocations work together. This is a non-rfc version > with only the LMB part of the patches, for making the LMB memory map > global and persistent. > > This is part one of a set of patches which aim to have the LMB and EFI > memory allocations work together. This requires making the LMB memory > map global and persistent, instead of having local, caller specific > maps. This is being done keeping in mind the usage of LMB memory by > platforms where the same memory region can be used to load multiple > different images. What is not allowed is to overwrite memory that has > been allocated by the other module, currently the EFI memory > module. This is being achieved by introducing a new flag, > LMB_NOOVERWRITE, which represents memory which cannot be re-requested > once allocated. > > The data structures (alloced lists) required for maintaining the LMB > map are initialised during board init. The LMB module is enabled by > default for the main U-Boot image, while it needs to be enabled for > SPL. This version also uses a stack implementation, as suggested by > Simon Glass to temporarily store the lmb structure instance which is > used during normal operation when running lmb tests. This does away > with the need to run the lmb tests separately. > > The tests have been tweaked where needed because of these changes. > > The second part of the patches, to be sent subsequently, would work on > having the EFI allocations work with the LMB API's. This generally feels like the right direction, but for v4 can you please look at the assorted checkpatch.pl warnings? Don't worry so much about trying to use IS_ENABLED and so forth if it doesn't enhance the readability but there are "func (....)" and some other issues that should be fixed. Thanks!
On Thu, 22 Aug 2024 at 04:17, Tom Rini <trini@konsulko.com> wrote: > > On Wed, Aug 21, 2024 at 04:28:12PM +0530, Sughosh Ganu wrote: > > > This is a follow-up from an earlier RFC series [1] for making the LMB > > and EFI memory allocations work together. This is a non-rfc version > > with only the LMB part of the patches, for making the LMB memory map > > global and persistent. > > > > This is part one of a set of patches which aim to have the LMB and EFI > > memory allocations work together. This requires making the LMB memory > > map global and persistent, instead of having local, caller specific > > maps. This is being done keeping in mind the usage of LMB memory by > > platforms where the same memory region can be used to load multiple > > different images. What is not allowed is to overwrite memory that has > > been allocated by the other module, currently the EFI memory > > module. This is being achieved by introducing a new flag, > > LMB_NOOVERWRITE, which represents memory which cannot be re-requested > > once allocated. > > > > The data structures (alloced lists) required for maintaining the LMB > > map are initialised during board init. The LMB module is enabled by > > default for the main U-Boot image, while it needs to be enabled for > > SPL. This version also uses a stack implementation, as suggested by > > Simon Glass to temporarily store the lmb structure instance which is > > used during normal operation when running lmb tests. This does away > > with the need to run the lmb tests separately. > > > > The tests have been tweaked where needed because of these changes. > > > > The second part of the patches, to be sent subsequently, would work on > > having the EFI allocations work with the LMB API's. > > This generally feels like the right direction, but for v4 can you please > look at the assorted checkpatch.pl warnings? Don't worry so much about > trying to use IS_ENABLED and so forth if it doesn't enhance the > readability but there are "func (....)" and some other issues that > should be fixed. Thanks! Sure, will fix these issues. Will wait for a few days to see if there are any other comments on the patches. Thanks. -sughosh