From: Scott Wood <scottwood@freescale•com>
To: Kevin Hao <haokexin@gmail•com>
Cc: linuxppc <linuxppc-dev@lists•ozlabs.org>
Subject: Re: [PATCH v2 6/8] powerpc: introduce early_get_first_memblock_info
Date: Mon, 5 Aug 2013 18:59:28 -0500 [thread overview]
Message-ID: <1375747168.13074.100.camel@snotra.buserror.net> (raw)
In-Reply-To: <20130804004531.GD19141@pek-khao-d1.corp.ad.wrs.com>
On Sun, 2013-08-04 at 08:45 +0800, Kevin Hao wrote:
> On Fri, Jul 26, 2013 at 07:18:01PM -0500, Scott Wood wrote:
> > >+ * This function run before early_init_devtree, so we have to init
> > >+ * initial_boot_params. Since early_init_dt_scan_memory_ppc will be
> > >+ * executed again in early_init_devtree, we have to reinitialize the
> > >+ * memblock data before return.
> > >+ */
> > >+void __init early_get_first_memblock_info(void *params,
> > >phys_addr_t *size)
> > >+{
> > >+ /* Setup flat device-tree pointer */
> > >+ initial_boot_params = params;
> > >+
> > >+ /* Scan memory nodes and rebuild MEMBLOCKs */
> > >+ of_scan_flat_dt(early_init_dt_scan_root, NULL);
> > >+ of_scan_flat_dt(early_init_dt_scan_memory_ppc, NULL);
> > >+
> > >+ if (size)
> > >+ *size = first_memblock_size;
> > >+
> > >+ /* Undo what early_init_dt_scan_memory_ppc does to memblock */
> > >+ memblock_reinit();
> > >+}
> > >+#endif
> >
> > Wouldn't it be simpler to set a flag so that
> > early_init_dt_add_memory_arch() doesn't mess with memblocks on the
> > first pass?
>
> Do you mean something like this?
>
> diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c
> index 9a69d2d..e861394 100644
> --- a/arch/powerpc/kernel/prom.c
> +++ b/arch/powerpc/kernel/prom.c
> @@ -523,6 +523,10 @@ static int __init early_init_dt_scan_memory_ppc(unsigned long node,
>
> void __init early_init_dt_add_memory_arch(u64 base, u64 size)
> {
> +#if defined(CONFIG_RELOCATABLE) && defined(CONFIG_FSL_BOOKE)
> + static int first_time = 1;
> +#endif
> +
> #ifdef CONFIG_PPC64
> if (iommu_is_off) {
> if (base >= 0x80000000ul)
> @@ -541,6 +545,13 @@ void __init early_init_dt_add_memory_arch(u64 base, u64 size)
> }
>
> /* Add the chunk to the MEMBLOCK list */
> +
> +#if defined(CONFIG_RELOCATABLE) && defined(CONFIG_FSL_BOOKE)
> + if (first_time) {
> + first_time = 0;
> + return;
> + }
> +#endif
> memblock_add(base, size);
> }
I think it'd be clearer for it to be an external variable that gets set
by the relocation code -- plus, the above wouldn't work if this gets
called twice due to having multiple memory regions.
-Scott
next prev parent reply other threads:[~2013-08-05 23:59 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-04 12:54 [PATCH v2 0/8] powerpc: enable the relocatable support for fsl booke 32bit kernel Kevin Hao
2013-07-04 12:54 ` [PATCH v2 1/8] powerpc/fsl_booke: protect the access to MAS7 with MMU_FTR_BIG_PHYS Kevin Hao
2013-07-26 23:14 ` Scott Wood
2013-08-04 0:30 ` Kevin Hao
2013-07-04 12:54 ` [PATCH v2 2/8] powerpc/fsl_booke: introduce get_phys_addr function Kevin Hao
2013-07-04 12:54 ` [PATCH v2 3/8] powerpc: enable the relocatable support for the fsl booke 32bit kernel Kevin Hao
2013-07-26 23:28 ` Scott Wood
2013-08-04 0:38 ` Kevin Hao
2013-07-04 12:54 ` [PATCH v2 4/8] powerpc/fsl_booke: set the tlb entry for the kernel address in AS1 Kevin Hao
2013-07-26 23:37 ` Scott Wood
2013-08-04 0:42 ` Kevin Hao
2013-07-04 12:54 ` [PATCH v2 5/8] memblock: introduce the memblock_reinit function Kevin Hao
2013-07-04 12:54 ` [PATCH v2 6/8] powerpc: introduce early_get_first_memblock_info Kevin Hao
2013-07-27 0:18 ` Scott Wood
2013-08-04 0:45 ` Kevin Hao
2013-08-05 23:59 ` Scott Wood [this message]
2013-08-06 1:21 ` Kevin Hao
2013-07-04 12:54 ` [PATCH v2 7/8] powerpc/fsl_booke: make sure PAGE_OFFSET map to memstart_addr for relocatable kernel Kevin Hao
2013-07-27 0:17 ` Scott Wood
2013-08-04 0:50 ` Kevin Hao
2013-08-06 0:10 ` Scott Wood
2013-08-06 1:23 ` Kevin Hao
2013-08-06 0:14 ` Scott Wood
2013-08-06 1:45 ` Kevin Hao
2013-07-04 12:54 ` [PATCH v2 8/8] powerpc/fsl_booke: enable the relocatable for the kdump kernel Kevin Hao
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=1375747168.13074.100.camel@snotra.buserror.net \
--to=scottwood@freescale$(echo .)com \
--cc=haokexin@gmail$(echo .)com \
--cc=linuxppc-dev@lists$(echo .)ozlabs.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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