[PATCH] lmb: Default to not-LMB_USE_MAX_REGIONS

[Philippe Schenker]

On Wed, 2023-02-08 at 09:54 -0500, Tom Rini wrote:
> On Wed, Feb 08, 2023 at 02:33:58PM +0000, Philippe Schenker wrote:
> 
> > Hi Tom,
> > 
> > We currently face an issue on our apalis-imx8 machine, that is not
> > able
> > to boot with a ramdisk. What happens is that there are all 8 of 8
> > LMBs
> > reserved and fdt tries to allocate one more, probably for
> > relocation.
> > 
> > I now stumbled on this recent patch and noticed that in my
> > understanding
> > this is introducing a regression to all the boards you remove
> > `CONFIG_LMB_MAX_REGIONS=64` isn't it? Or do I miss something?
> > 
> > For the other question this raises to me is it in general safe to
> > just
> > increase this limit, let's say to 16?
> > 
> > And since it was quite an effort debugging this issue I thought of
> > adding a debug print if the MAX cnt in lmb.c is being hit to ease
> > that
> > pain for other devs, would you be fine with something like this?
> 
> Right, so with the late in the cycle change to make EFI use LMBs as
> well, a lot of platforms hit the 8 of 8 LMBs now in use problem. The
> change here switches from a static allocation of a maximum number of
> LMBs to dynamically allocating as many of them as needed.


But since you no longer enable LMB_USE_MAX_REGIONS then theres the two
limits (default=8)

LMB_MEMORY_REGIONS=8
LMB_RESERVED_REGIONS=8

that are limiting the maximum LMB numbers. So in my view this commit
does create a regression for all boards you delete
`CONFIG_LMB_MAX_REGIONS=64`.

At least for me rgn->max is still set to 8 and also after this commit I
hit that limit. [1]

[1] https://source.denx.de/u-boot/u-boot/-/blob/master/lib/lmb.c#L288