devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Daniele Alessandrelli <daniele.alessandrelli@gmail.com>
To: Miles Chen <miles.chen@mediatek.com>
Cc: Rob Herring <robh+dt@kernel.org>,
	Frank Rowand <frowand.list@gmail.com>,
	devicetree@vger.kernel.org
Subject: Re: [RFC] MAX_RESERVED_REGIONS hard-coded value
Date: Wed, 8 Jan 2020 16:15:08 +0000	[thread overview]
Message-ID: <CAA2QUq+b4R=s1v-XU0y+R3PmFWXAXtFEAnU4pSW-0KAzRrzLFA@mail.gmail.com> (raw)
In-Reply-To: <1578465928.29698.21.camel@mtkswgap22>

Hi Rob, Miles,

Thank you both for your replies.

On Wed, Jan 8, 2020 at 6:45 AM Miles Chen <miles.chen@mediatek.com> wrote:
>
> Hi,
>
> On Tue, 2020-01-07 at 15:13 -0600, Rob Herring wrote:
> > On Mon, Jan 6, 2020 at 12:05 PM Daniele Alessandrelli
> > <daniele.alessandrelli@gmail.com> wrote:
> > >
> > > Hi,
> > >
> > > I'm using a Device Tree with more then 32 reserved memory regions and
> > > I'm seeing the following error while booting the Kernel:
> > > [    0.000000] OF: reserved mem: not enough space all defined regions.
> >
> > How many do you have? Is that DT available somewhere?

Unfortunately, the DT is not publicly available yet. Anyway, I
currently have 41 reserved memory regions.

> >
> > > My understanding is that this is due to the hard-coded value of
> > > MAX_RESERVED_REGIONS in drivers/of/of_reserved_mem.c
> > >
> > > Googling around, I found this old discussion [1] in which Miles
> > > suggests to add a CONFIG_MAX_OF_RESERVED_REGIONS kconfig option to
> > > configure MAX_RESERVED_REGIONS. Rob replied to Miles' email saying
> > > that he would prefer MAX_RESERVED_REGIONS to be dynamic. However,
> > > later in the thread, it looks like making MAX_RESERVED_REGIONS dynamic
> > > poses some implementation issues [2]. At that point the discussion
> > > seemed to have stopped.
> >
> > Not sure what the problem was as there's no code, but I'd guess the
> > array alloc and populating have to be done later (perhaps in
> > unflattening).
>
> I missed my draft patch.
>
> From what I recall, the problem I had that time is that
> early_init_fdt_scan_reserved_mem() is called before paging_init(). So I
> cannot allocate accessible memory in early_init_fdt_scan_reserved_mem().
>
> For example: aarch64 setup_arch()
> setup_arch()
> {
>     memblock_init(); /* early_init_fdt_scan_reserved_mem() is called */
>     paging_init(); /* map memory */
> }
>
> >
> > > Is there any chance for the patch proposed by Miles to be reconsidered?
> >
> > A kconfig option would still be my 3rd choice after dynamically
> > allocating the array or just growing the fixed array size.

I'm happy with just growing the fixed array size, but just out of
curiosity, why do you prefer it to the kconfig option?

>
> Not sure how many of reserve memory regions Daniele has. In my case,
> we grow the MAX_RESERVED_REGIONS to 64 (3x used) and we are still trying
> to suppress the amount of reserved memory to fit
> MAX_RESERVED_REGIONS=32.

64 would be a safe value for my case as well.

We are also trying to reduce the amount of memory regions, but it's
unlikely we will manage to stay below 32 :/

Regards,
Daniele

>
>
>
> thanks,
> Miles
> >
> > Rob
>

      reply	other threads:[~2020-01-08 16:15 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-06 18:05 [RFC] MAX_RESERVED_REGIONS hard-coded value Daniele Alessandrelli
2020-01-07 21:13 ` Rob Herring
2020-01-08  6:45   ` Miles Chen
2020-01-08 16:15     ` Daniele Alessandrelli [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAA2QUq+b4R=s1v-XU0y+R3PmFWXAXtFEAnU4pSW-0KAzRrzLFA@mail.gmail.com' \
    --to=daniele.alessandrelli@gmail.com \
    --cc=devicetree@vger.kernel.org \
    --cc=frowand.list@gmail.com \
    --cc=miles.chen@mediatek.com \
    --cc=robh+dt@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).