diff mbox

[6/6] ARM: integrator: ensure ap_syscon_base is initialised when !CONFIG_MMU

Message ID 1359556069-28289-7-git-send-email-will.deacon@arm.com (mailing list archive)
State New, archived
Headers show

Commit Message

Will Deacon Jan. 30, 2013, 2:27 p.m. UTC
When running on Integrator/AP using atags, ap_syscon_base is initialised
in ->map_io, which isn't called for !MMU platforms.

Instead, initialise the pointer in ->machine_init, as we do when booting
with device-tree.

Cc: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Will Deacon <will.deacon@arm.com>
---
 arch/arm/mach-integrator/integrator_ap.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Comments

Linus Walleij Jan. 31, 2013, 8:21 p.m. UTC | #1
On Wed, Jan 30, 2013 at 3:27 PM, Will Deacon <will.deacon@arm.com> wrote:

> When running on Integrator/AP using atags, ap_syscon_base is initialised
> in ->map_io, which isn't called for !MMU platforms.

Oh hm. Haha apparently there is one guy with more bizarre hobbies
than myself, you're making me feel un-geeky... ;-)

> Instead, initialise the pointer in ->machine_init, as we do when booting
> with device-tree.

I was trying to figure out if there is some case where we need it earlier
but apparently not so.

Acked-by: Linus Walleij <linus.walleij@linaro.org>

Maybe you should send this oneliner directly to the ARM SoC
people?

Yours,
Linus Walleij
Will Deacon Jan. 31, 2013, 10:34 p.m. UTC | #2
Hi Linus,

On Thu, Jan 31, 2013 at 08:21:04PM +0000, Linus Walleij wrote:
> On Wed, Jan 30, 2013 at 3:27 PM, Will Deacon <will.deacon@arm.com> wrote:
> 
> > When running on Integrator/AP using atags, ap_syscon_base is initialised
> > in ->map_io, which isn't called for !MMU platforms.
> 
> Oh hm. Haha apparently there is one guy with more bizarre hobbies
> than myself, you're making me feel un-geeky... ;-)

Ha! Unfortunately, I only have one core-tile otherwise you could have one to
help you feel less left-out :)

> > Instead, initialise the pointer in ->machine_init, as we do when booting
> > with device-tree.
> 
> I was trying to figure out if there is some case where we need it earlier
> but apparently not so.
> 
> Acked-by: Linus Walleij <linus.walleij@linaro.org>

Cheers!

> Maybe you should send this oneliner directly to the ARM SoC
> people?

[adding Olof and Arnd] Is it worth sending a pull request containing a
single patch, or can this patch just be picked directly?

Cheers,

Will
Olof Johansson Jan. 31, 2013, 10:56 p.m. UTC | #3
On Thu, Jan 31, 2013 at 10:34:17PM +0000, Will Deacon wrote:
> Hi Linus,
> 
> On Thu, Jan 31, 2013 at 08:21:04PM +0000, Linus Walleij wrote:
> > On Wed, Jan 30, 2013 at 3:27 PM, Will Deacon <will.deacon@arm.com> wrote:
> > 
> > > When running on Integrator/AP using atags, ap_syscon_base is initialised
> > > in ->map_io, which isn't called for !MMU platforms.
> > 
> > Oh hm. Haha apparently there is one guy with more bizarre hobbies
> > than myself, you're making me feel un-geeky... ;-)
> 
> Ha! Unfortunately, I only have one core-tile otherwise you could have one to
> help you feel less left-out :)
> 
> > > Instead, initialise the pointer in ->machine_init, as we do when booting
> > > with device-tree.
> > 
> > I was trying to figure out if there is some case where we need it earlier
> > but apparently not so.
> > 
> > Acked-by: Linus Walleij <linus.walleij@linaro.org>
> 
> Cheers!
> 
> > Maybe you should send this oneliner directly to the ARM SoC
> > people?
> 
> [adding Olof and Arnd] Is it worth sending a pull request containing a
> single patch, or can this patch just be picked directly?

Definitely ok to just send the patch like this. However -- where was
the breakage introduced, i.e.  what should we apply the fix to?


-Olof
Will Deacon Feb. 3, 2013, 11:48 a.m. UTC | #4
On Thu, Jan 31, 2013 at 10:56:30PM +0000, Olof Johansson wrote:
> On Thu, Jan 31, 2013 at 10:34:17PM +0000, Will Deacon wrote:
> > [adding Olof and Arnd] Is it worth sending a pull request containing a
> > single patch, or can this patch just be picked directly?
> 
> Definitely ok to just send the patch like this. However -- where was
> the breakage introduced, i.e.  what should we apply the fix to?

I think it's been broken for a little while as it only affects !MMU
configurations, which aren't especially popular. My guess is that
83feba511e5d ("ARM: integrator: remove static AP syscon mapping") is what
caused the breakage.

The fix should apply against mainline.

Cheers,

Will
Arnd Bergmann Feb. 4, 2013, 9:49 p.m. UTC | #5
On Sunday 03 February 2013, Will Deacon wrote:
> On Thu, Jan 31, 2013 at 10:56:30PM +0000, Olof Johansson wrote:
> > On Thu, Jan 31, 2013 at 10:34:17PM +0000, Will Deacon wrote:
> > > [adding Olof and Arnd] Is it worth sending a pull request containing a
> > > single patch, or can this patch just be picked directly?
> > 
> > Definitely ok to just send the patch like this. However -- where was
> > the breakage introduced, i.e.  what should we apply the fix to?
> 
> I think it's been broken for a little while as it only affects !MMU
> configurations, which aren't especially popular. My guess is that
> 83feba511e5d ("ARM: integrator: remove static AP syscon mapping") is what
> caused the breakage.
> 
> The fix should apply against mainline.

Sounds like a candidate for stable as well then. I'm not sure if anyone
cares about !MMU stable kernels, but it's totally possible with the
LTSI kernels.

	Arnd
diff mbox

Patch

diff --git a/arch/arm/mach-integrator/integrator_ap.c b/arch/arm/mach-integrator/integrator_ap.c
index 11e2a41..26762bf 100644
--- a/arch/arm/mach-integrator/integrator_ap.c
+++ b/arch/arm/mach-integrator/integrator_ap.c
@@ -613,7 +613,6 @@  static struct map_desc ap_io_desc_atag[] __initdata = {
 static void __init ap_map_io_atag(void)
 {
 	iotable_init(ap_io_desc_atag, ARRAY_SIZE(ap_io_desc_atag));
-	ap_syscon_base = __io_address(INTEGRATOR_SC_BASE);
 	ap_map_io();
 }
 
@@ -685,6 +684,7 @@  static void __init ap_init(void)
 
 	platform_device_register(&cfi_flash_device);
 
+	ap_syscon_base = __io_address(INTEGRATOR_SC_BASE);
 	sc_dec = readl(ap_syscon_base + INTEGRATOR_SC_DEC_OFFSET);
 	for (i = 0; i < 4; i++) {
 		struct lm_device *lmdev;