All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
To: Sascha Hauer <s.hauer@pengutronix.de>
Cc: barebox@lists.infradead.org
Subject: Re: [PATCH 2/5] ARM: mvebu: Simplify memory init order
Date: Wed, 17 Sep 2014 09:19:33 +0200	[thread overview]
Message-ID: <54193605.7000808@gmail.com> (raw)
In-Reply-To: <20140917064503.GM4992@pengutronix.de>

On 09/17/2014 08:45 AM, Sascha Hauer wrote:
> On Tue, Sep 16, 2014 at 10:05:44PM +0200, Sebastian Hesselbarth wrote:
>> On 09/15/2014 09:41 AM, Sascha Hauer wrote:
>>> The initialisation of the memory nodes on mvebu is a bit
>>> compilcated:
>>>
>>> pure_initcall(mvebu_memory_fixup_register)
>>> 	of_register_fixup(mvebu_memory_of_fixup, NULL)
>>> core_initcall(kirkwood_init_soc)
>>> 	mvebu_set_memory()
>>> core_initcall(of_arm_init)
>>> 	of_fix_tree()
>>> 		mvebu_memory_of_fixup()
>>>
>>> First a mvebu common of_fixup function is registered, then the SoC
>>> calls mvebu_set_memory which stores the memory base and size in global
>>> variables. Afterwards the of_fixup is executed which fixes the memory
>>> nodes according to the global variables.
>>>
>>> Instead register a SoC specific fixup which directly calls mvebu_set_memory
>>> with the memory base and size as arguments:
>>>
>>> pure_initcall(kirkwood_register_soc_fixup);
>>> 	of_register_fixup(kirkwood_init_soc, NULL);
>>> core_initcall(of_arm_init)
>>> 	of_fix_tree()
>>> 		kirkwood_init_soc()
>>> 			mvebu_set_memory(phys_base, phys_size);
>>>
>>> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
>>
>> Hmm, this breaks Armada 370 and most likely also Armada XP. Actually,
>> it breaks any SoC that has a DTB with internal regs set to 0xd0000000.
>>
>>> ---
>>>   arch/arm/mach-mvebu/armada-370-xp.c       |  9 ++++++--
>>>   arch/arm/mach-mvebu/common.c              | 34 ++++++++++---------------------
>>>   arch/arm/mach-mvebu/dove.c                |  9 ++++++--
>>>   arch/arm/mach-mvebu/include/mach/common.h |  2 +-
>>>   arch/arm/mach-mvebu/kirkwood.c            |  9 ++++++--
>>>   5 files changed, 33 insertions(+), 30 deletions(-)
>>>
>>> diff --git a/arch/arm/mach-mvebu/armada-370-xp.c b/arch/arm/mach-mvebu/armada-370-xp.c
>>> index 6251100..5c8499b 100644
>>> --- a/arch/arm/mach-mvebu/armada-370-xp.c
>>> +++ b/arch/arm/mach-mvebu/armada-370-xp.c
>>> @@ -52,7 +52,7 @@ static void __noreturn armada_370_xp_reset_cpu(unsigned long addr)
>>>   		;
>>>   }
>>>
>>> -static int armada_370_xp_init_soc(void)
>>> +static int armada_370_xp_init_soc(struct device_node *root, void *context)
>>>   {
>>>   	unsigned long phys_base, phys_size;
>>>   	u32 reg;
>>> @@ -74,4 +74,9 @@ static int armada_370_xp_init_soc(void)
>>
>> Because armada_370_xp_init_soc() does
>>
>> 	mvebu_mbus_add_range(0xf0, 0x01, MVEBU_REMAP_INT_REG_BASE);
>>
>> right above, which will add the range(s) required for internal register
>> of_fixup. Since this patch moved armada_370_xp_init_soc to the
>> of_fixups, we don't fix this up for the initial DT tree.
>>
>>>
>>>   	return 0;
>>>   }
>>> -core_initcall(armada_370_xp_init_soc);
>>> +
>>> +static int armada_370_register_soc_fixup(void)
>>> +{
>>
>> I guess moving mvebu_mbus_add_range() in here does not work, because
>> it will add the armada_370_xp range also for dove and kirkwood.
>
> Do we need a separate of_fixup registered for fixing up the mbus? Can't
> we just call mvebu_mbus_of_fixup() directly from mvebu_mbus_add_range()?
>
> This won't be very efficient for dove which calls mvebu_mbus_add_range()
> twice so it has to iterate over the device tree twice, but it should
> work, right?

It is not the number of iterations I am concerned about. In a Multi-SoC
environment, we add ranges for MBUS_ID(0xf0, 0x01) three times anyway
plus Dove's MBUS_ID(0xf0, 0x02).

Currently, we are lucky that MBUS_ID(0xf0, 0x01) is the same for all
SoCs and MBUS_ID(0xf0, 0x02) is exclusive for Dove. If we cross our
fingers and hope it will never change, we can just do:

static int dove_register_soc_fixup(void)
{
	mvebu_mbus_add_range(0xf0, 0x01, MVEBU_REMAP_INT_REG_BASE);
	mvebu_mbus_add_range(0xf0, 0x02, DOVE_REMAP_MC_REGS);
	return of_register_fixup(dove_init_soc, NULL);
}
pure_initcall(dove_register_soc_fixup);

and

static int armada_370_xp_register_soc_fixup(void)
{
	mvebu_mbus_add_range(0xf0, 0x01, MVEBU_REMAP_INT_REG_BASE);
	return of_register_fixup(armada_370_xp_init_soc, NULL);
}
pure_initcall(armada_370_xp_register_soc_fixup);

and the same for Kirkwood.

If we want to make it safe for any future SoC that might break the
MBUS_ID() assumptions above, we can add the machine_id compatible
to mvebu_mbus_add_range(), i.e.

static int armada_370_xp_register_soc_fixup(void)
{
	mvebu_mbus_add_range("marvell,armada-370-xp", 0xf0, 0x01, 
MVEBU_REMAP_INT_REG_BASE);
	return of_register_fixup(armada_370_xp_init_soc, NULL);
}
pure_initcall(armada_370_xp_register_soc_fixup);

If you put your current series into some branch I can pull, I can
add the required patches later today.

Sebastian

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

  reply	other threads:[~2014-09-17  7:20 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-15  7:41 mvebu multi SoC support Sascha Hauer
2014-09-15  7:41 ` [PATCH 1/5] ARM: mvebu: Add common reset_cpu function Sascha Hauer
2014-09-16 19:17   ` Sebastian Hesselbarth
2014-09-17  6:32     ` Sascha Hauer
2014-09-15  7:41 ` [PATCH 2/5] ARM: mvebu: Simplify memory init order Sascha Hauer
2014-09-16 20:05   ` Sebastian Hesselbarth
2014-09-17  6:45     ` Sascha Hauer
2014-09-17  7:19       ` Sebastian Hesselbarth [this message]
2014-09-17  7:29         ` Sascha Hauer
2014-09-15  7:41 ` [PATCH 3/5] ARM: mvebu: Check for correct SoC in of_fixup callback Sascha Hauer
2014-09-15  7:41 ` [PATCH 4/5] ARM: mvebu: Allow multiple SoCs Sascha Hauer
2014-09-15  8:00   ` Sebastian Hesselbarth
2014-09-15  9:13     ` Sascha Hauer
2014-09-15 21:12       ` Sebastian Hesselbarth
2014-09-16  6:00         ` Sascha Hauer
2014-09-15  7:41 ` [PATCH 5/5] ARM: Add mvebu_defconfig Sascha Hauer
2014-09-15 21:15   ` Sebastian Hesselbarth
2014-09-16  6:05     ` Sascha Hauer
2014-09-15  8:09 ` mvebu multi SoC support Ezequiel Garcia

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=54193605.7000808@gmail.com \
    --to=sebastian.hesselbarth@gmail.com \
    --cc=barebox@lists.infradead.org \
    --cc=s.hauer@pengutronix.de \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.