From: Tony Lindgren <tony@atomide.com>
To: Nicolas Pitre <nico@fluxnic.net>
Cc: linux-omap@vger.kernel.org,
Santosh Shilimkar <santosh.shilimkar@ti.com>,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] arm: omap4: Fix omap_barriers_init for generic ioremap changes
Date: Thu, 12 Jan 2012 11:59:51 -0800 [thread overview]
Message-ID: <20120112195951.GB2287@atomide.com> (raw)
In-Reply-To: <alpine.LFD.2.02.1201121447270.2722@xanadu.home>
* Nicolas Pitre <nico@fluxnic.net> [120112 11:15]:
> On Thu, 12 Jan 2012, Nicolas Pitre wrote:
> >
> > Do you really need that return code?
> >
> > It was initially hooked to core_initcall() which requires a return code.
> > Now that you call it directly you could get rid of it.
>
> s/rid of it/rid of the return code/
Well memblock_alloc could fail there, but omap_barries_init
can be made void as there's already "failed to reserve 4Kbytes"
error there. So let's make it void. Updated patch below.
Tony
From: Tony Lindgren <tony@atomide.com>
Date: Thu, 12 Jan 2012 10:28:26 -0800
Subject: [PATCH] arm: omap4: Fix omap_barriers_init for generic ioremap changes
Commit 73829af71fdb8655e7ba4b5a2a6612ad34a75a11
(Merge branch 'vmalloc' of git://git.linaro.org/people/nico/linux
into devel-stable) merged generic ioremap changes.
Commit 137d105d50f6e6c373c1aa759f59045e6239cf66
(ARM: OMAP4: Fix errata i688 with MPU interconnect barriers)
added a workaround for omap4.
In order for the errata to work, we now need the following
patch or else we'll get:
kernel BUG at mm/vmalloc.c:1134!
Signed-off-by: Tony Lindgren <tony@atomide.com>
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -132,6 +132,7 @@ void omap3_map_io(void);
void am33xx_map_io(void);
void omap4_map_io(void);
void ti81xx_map_io(void);
+void omap_barriers_init(void);
/**
* omap_test_timeout - busy-loop, testing a condition
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -307,6 +307,7 @@ void __init omapam33xx_map_common_io(void)
void __init omap44xx_map_common_io(void)
{
iotable_init(omap44xx_io_desc, ARRAY_SIZE(omap44xx_io_desc));
+ omap_barriers_init();
}
#endif
--- a/arch/arm/mach-omap2/omap4-common.c
+++ b/arch/arm/mach-omap2/omap4-common.c
@@ -51,20 +51,20 @@ void omap_bus_sync(void)
}
}
-static int __init omap_barriers_init(void)
+void __init omap_barriers_init(void)
{
struct map_desc dram_io_desc[1];
phys_addr_t paddr;
u32 size;
if (!cpu_is_omap44xx())
- return -ENODEV;
+ return;
size = ALIGN(PAGE_SIZE, SZ_1M);
paddr = memblock_alloc(size, SZ_1M);
if (!paddr) {
pr_err("%s: failed to reserve 4 Kbytes\n", __func__);
- return -ENOMEM;
+ return;
}
memblock_free(paddr, size);
memblock_remove(paddr, size);
@@ -78,10 +78,11 @@ static int __init omap_barriers_init(void)
pr_info("OMAP4: Map 0x%08llx to 0x%08lx for dram barrier\n",
(long long) paddr, dram_io_desc[0].virtual);
-
- return 0;
}
-core_initcall(omap_barriers_init);
+#else
+void __init omap_barriers_init(void)
+{
+}
#endif
void __init gic_init_irq(void)
WARNING: multiple messages have this Message-ID (diff)
From: tony@atomide.com (Tony Lindgren)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] arm: omap4: Fix omap_barriers_init for generic ioremap changes
Date: Thu, 12 Jan 2012 11:59:51 -0800 [thread overview]
Message-ID: <20120112195951.GB2287@atomide.com> (raw)
In-Reply-To: <alpine.LFD.2.02.1201121447270.2722@xanadu.home>
* Nicolas Pitre <nico@fluxnic.net> [120112 11:15]:
> On Thu, 12 Jan 2012, Nicolas Pitre wrote:
> >
> > Do you really need that return code?
> >
> > It was initially hooked to core_initcall() which requires a return code.
> > Now that you call it directly you could get rid of it.
>
> s/rid of it/rid of the return code/
Well memblock_alloc could fail there, but omap_barries_init
can be made void as there's already "failed to reserve 4Kbytes"
error there. So let's make it void. Updated patch below.
Tony
From: Tony Lindgren <tony@atomide.com>
Date: Thu, 12 Jan 2012 10:28:26 -0800
Subject: [PATCH] arm: omap4: Fix omap_barriers_init for generic ioremap changes
Commit 73829af71fdb8655e7ba4b5a2a6612ad34a75a11
(Merge branch 'vmalloc' of git://git.linaro.org/people/nico/linux
into devel-stable) merged generic ioremap changes.
Commit 137d105d50f6e6c373c1aa759f59045e6239cf66
(ARM: OMAP4: Fix errata i688 with MPU interconnect barriers)
added a workaround for omap4.
In order for the errata to work, we now need the following
patch or else we'll get:
kernel BUG at mm/vmalloc.c:1134!
Signed-off-by: Tony Lindgren <tony@atomide.com>
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -132,6 +132,7 @@ void omap3_map_io(void);
void am33xx_map_io(void);
void omap4_map_io(void);
void ti81xx_map_io(void);
+void omap_barriers_init(void);
/**
* omap_test_timeout - busy-loop, testing a condition
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -307,6 +307,7 @@ void __init omapam33xx_map_common_io(void)
void __init omap44xx_map_common_io(void)
{
iotable_init(omap44xx_io_desc, ARRAY_SIZE(omap44xx_io_desc));
+ omap_barriers_init();
}
#endif
--- a/arch/arm/mach-omap2/omap4-common.c
+++ b/arch/arm/mach-omap2/omap4-common.c
@@ -51,20 +51,20 @@ void omap_bus_sync(void)
}
}
-static int __init omap_barriers_init(void)
+void __init omap_barriers_init(void)
{
struct map_desc dram_io_desc[1];
phys_addr_t paddr;
u32 size;
if (!cpu_is_omap44xx())
- return -ENODEV;
+ return;
size = ALIGN(PAGE_SIZE, SZ_1M);
paddr = memblock_alloc(size, SZ_1M);
if (!paddr) {
pr_err("%s: failed to reserve 4 Kbytes\n", __func__);
- return -ENOMEM;
+ return;
}
memblock_free(paddr, size);
memblock_remove(paddr, size);
@@ -78,10 +78,11 @@ static int __init omap_barriers_init(void)
pr_info("OMAP4: Map 0x%08llx to 0x%08lx for dram barrier\n",
(long long) paddr, dram_io_desc[0].virtual);
-
- return 0;
}
-core_initcall(omap_barriers_init);
+#else
+void __init omap_barriers_init(void)
+{
+}
#endif
void __init gic_init_irq(void)
next prev parent reply other threads:[~2012-01-12 19:59 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-12 18:42 [PATCH] arm: omap4: Fix omap_barriers_init for generic ioremap changes Tony Lindgren
2012-01-12 18:42 ` Tony Lindgren
2012-01-12 19:26 ` Shilimkar, Santosh
2012-01-12 19:26 ` Shilimkar, Santosh
2012-01-12 19:44 ` Nicolas Pitre
2012-01-12 19:44 ` Nicolas Pitre
2012-01-12 19:48 ` Nicolas Pitre
2012-01-12 19:48 ` Nicolas Pitre
2012-01-12 19:59 ` Tony Lindgren [this message]
2012-01-12 19:59 ` Tony Lindgren
2012-01-13 14:05 ` Russell King - ARM Linux
2012-01-13 14:05 ` Russell King - ARM Linux
2012-01-13 15:04 ` Russell King - ARM Linux
2012-01-13 15:04 ` Russell King - ARM Linux
2012-01-13 16:44 ` Tony Lindgren
2012-01-13 16:44 ` Tony Lindgren
2012-01-13 17:12 ` Felipe Contreras
2012-01-13 17:12 ` Felipe Contreras
2012-01-12 20:04 ` Russell King - ARM Linux
2012-01-12 20:04 ` Russell King - ARM Linux
2012-01-12 20:11 ` Russell King - ARM Linux
2012-01-12 20:11 ` Russell King - ARM Linux
2012-01-12 20:20 ` Shilimkar, Santosh
2012-01-12 20:20 ` Shilimkar, Santosh
2012-01-12 20:27 ` Russell King - ARM Linux
2012-01-12 20:27 ` Russell King - ARM Linux
2012-01-12 20:32 ` Shilimkar, Santosh
2012-01-12 20:32 ` Shilimkar, Santosh
2012-01-12 21:00 ` Russell King - ARM Linux
2012-01-12 21:00 ` Russell King - ARM Linux
2012-01-13 10:35 ` Shilimkar, Santosh
2012-01-13 10:35 ` Shilimkar, Santosh
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=20120112195951.GB2287@atomide.com \
--to=tony@atomide.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-omap@vger.kernel.org \
--cc=nico@fluxnic.net \
--cc=santosh.shilimkar@ti.com \
/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.