* [PATCH] arm: omap: Fix build break in drm.c
From: Archit Taneja @ 2013-01-22 8:28 UTC (permalink / raw)
To: linux-arm-kernel
Building omapdrm leads to a build break because of a missing include needed
for the macro GET_OMAP_REVISION(). Add the missing inlclude.
Signed-off-by: Archit Taneja <archit@ti.com>
---
arch/arm/mach-omap2/drm.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-omap2/drm.c b/arch/arm/mach-omap2/drm.c
index 4c7566c..6b1a8df 100644
--- a/arch/arm/mach-omap2/drm.c
+++ b/arch/arm/mach-omap2/drm.c
@@ -25,6 +25,7 @@
#include <linux/dma-mapping.h>
#include <linux/platform_data/omap_drm.h>
+#include "soc.h"
#include "omap_device.h"
#include "omap_hwmod.h"
--
1.7.9.5
^ permalink raw reply related
* One of these things (CONFIG_HZ) is not like the others..
From: Arnd Bergmann @ 2013-01-22 8:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130121224449.GZ23505@n2100.arm.linux.org.uk>
On Monday 21 January 2013, Russell King - ARM Linux wrote:
> In this particular case, EBSA110 is not a candidate for multi-arch
> build anyway, because it's ARMv4 and we're only really bothering with
> ARMv6 and better.
>
> Not only that, but the IO stuff on it is sufficiently obscure and
> non-standard...
Right, no point worrying about EBSA110. We need to work out OMAP and
Exynos/S5P though: As long as OMAP needs 128HZ and Exynos needs 200HZ,
we can never have them in the same kernel.
Arnd
^ permalink raw reply
* [PATCH V2 0/5] W1: Support onewire master on i.MX53
From: Sascha Hauer @ 2013-01-22 8:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130116145749.24249.678.stgit@localhost>
On Wed, Jan 16, 2013 at 03:57:49PM +0100, Martin Fuzzey wrote:
> W1: Support onewire master on i.MX53
> * Add device tree and pinctrl support to the MXC master driver
> * Convert to use devm_
> * Add i.MX53 clocks
> * Add i.MX53 device tree entries
>
> Changes since V1
> * Applied comments from Sascha Hauer:
> * Move patch converting driver to devm_ before the one adding devm_ based pinctrl
> * Fix existing unbalanced clk_prepare_enable/clk_disable_unprepare
> in probe error path
>
> * Place DT patch last since it includes pinctrls for driver.
This looks good now.
Acked-by: Sascha Hauer <s.hauer@pengutronix.de>
You might have to send this again in two series, one for the w1
maintainer and one for arm-soc. Both series should be sufficiently
orthogonal.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* [PATCH] arm: plat-samsung: check soc ids before l2x0 cache restoration in resume
From: Inderpal Singh @ 2013-01-22 8:25 UTC (permalink / raw)
To: linux-arm-kernel
Only exynos4 based platforms have l2x0 cache controller. Hence check
the same before restoring the cache in resume.
This is needed for single kernel image.
Signed-off-by: Inderpal Singh <inderpal.singh@linaro.org>
---
arch/arm/mach-exynos/common.c | 2 ++
arch/arm/plat-samsung/include/plat/pm.h | 1 +
arch/arm/plat-samsung/s5p-sleep.S | 28 ++++++++++++++++++++++++++++
3 files changed, 31 insertions(+)
diff --git a/arch/arm/mach-exynos/common.c b/arch/arm/mach-exynos/common.c
index cdaa55f..ab7ca00 100644
--- a/arch/arm/mach-exynos/common.c
+++ b/arch/arm/mach-exynos/common.c
@@ -796,6 +796,8 @@ static int __init exynos4_l2x0_cache_init(void)
if (soc_is_exynos5250() || soc_is_exynos5440())
return 0;
+ s5p_cpu = samsung_cpu_id & EXYNOS4_CPU_MASK;
+
ret = l2x0_of_init(L2_AUX_VAL, L2_AUX_MASK);
if (!ret) {
l2x0_regs_phys = virt_to_phys(&l2x0_saved_regs);
diff --git a/arch/arm/plat-samsung/include/plat/pm.h b/arch/arm/plat-samsung/include/plat/pm.h
index 887a0c9..285c8c8 100644
--- a/arch/arm/plat-samsung/include/plat/pm.h
+++ b/arch/arm/plat-samsung/include/plat/pm.h
@@ -190,3 +190,4 @@ extern void samsung_pm_save_gpios(void);
extern void s3c_pm_save_core(void);
extern void s3c_pm_restore_core(void);
+extern unsigned long s5p_cpu;
diff --git a/arch/arm/plat-samsung/s5p-sleep.S b/arch/arm/plat-samsung/s5p-sleep.S
index bdf6dad..006d35f 100644
--- a/arch/arm/plat-samsung/s5p-sleep.S
+++ b/arch/arm/plat-samsung/s5p-sleep.S
@@ -25,6 +25,15 @@
#include <asm/asm-offsets.h>
#include <asm/hardware/cache-l2x0.h>
+#define EXYNOS4210_CPU_ID 0x43210000
+#define EXYNOS4212_CPU_ID 0x43220000
+#define EXYNOS4412_CPU_ID 0xE4412200
+#define EXYNOS4_CPU_MASK 0xFFFE0000
+
+#define EXYNOS4210_CPU (EXYNOS4210_CPU_ID & EXYNOS4_CPU_MASK)
+#define EXYNOS4212_CPU (EXYNOS4212_CPU_ID & EXYNOS4_CPU_MASK)
+#define EXYNOS4412_CPU (EXYNOS4412_CPU_ID & EXYNOS4_CPU_MASK)
+
/*
* The following code is located into the .data section. This is to
* allow l2x0_regs_phys to be accessed with a relative load while we
@@ -51,6 +60,22 @@
ENTRY(s3c_cpu_resume)
#ifdef CONFIG_CACHE_L2X0
+ adr r0, s5p_cpu
+ ldr r1, [r0]
+
+ ldr r0, =EXYNOS4210_CPU
+ cmp r1, r0
+ beq continue
+
+ ldr r0, =EXYNOS4212_CPU
+ cmp r1, r0
+ beq continue
+
+ ldr r0, =EXYNOS4412_CPU
+ cmp r1, r0
+ bne resume_l2on
+
+continue:
adr r0, l2x0_regs_phys
ldr r0, [r0]
ldr r1, [r0, #L2X0_R_PHY_BASE]
@@ -77,4 +102,7 @@ ENDPROC(s3c_cpu_resume)
.globl l2x0_regs_phys
l2x0_regs_phys:
.long 0
+ .globl s5p_cpu
+s5p_cpu:
+ .long 0
#endif
--
1.7.9.5
^ permalink raw reply related
* [GIT PULL] i.MX fixes for -rc
From: Olof Johansson @ 2013-01-22 8:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130122081656.GI1906@pengutronix.de>
On Tue, Jan 22, 2013 at 12:16 AM, Sascha Hauer <s.hauer@pengutronix.de> wrote:
> Hi Arnd, Olof,
>
> Please pull the following fix for -rc.
>
> Sascha
>
> The following changes since commit d1c3ed669a2d452cacfb48c2d171a1f364dae2ed:
>
> Linux 3.8-rc2 (2013-01-02 18:13:21 -0800)
>
> are available in the git repository at:
>
> git://git.pengutronix.de/git/imx/linux-2.6.git tags/imx-fixes-rc
Pulled, thanks.
-Olof
^ permalink raw reply
* [PATCH 09/15] media: coda: don't build on multiplatform
From: Sascha Hauer @ 2013-01-22 8:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358788568-11137-10-git-send-email-arnd@arndb.de>
On Mon, Jan 21, 2013 at 05:16:02PM +0000, Arnd Bergmann wrote:
> The coda video codec driver depends on a mach-imx or mach-mxs specific
> header file "mach/iram.h". This is not available when building for
> multiplatform, so let us disable this driver for v3.8 when building
> multiplatform, and hopefully find a proper fix for v3.9.
>
> drivers/media/platform/coda.c:27:23: fatal error: mach/iram.h: No such file or directory
I just sent a pull request for this with a proper fix.
>
> diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
> index 3dcfea6..049d2b2 100644
> --- a/drivers/media/platform/Kconfig
> +++ b/drivers/media/platform/Kconfig
> @@ -142,7 +142,7 @@ if V4L_MEM2MEM_DRIVERS
>
> config VIDEO_CODA
> tristate "Chips&Media Coda multi-standard codec IP"
> - depends on VIDEO_DEV && VIDEO_V4L2 && ARCH_MXC
> + depends on VIDEO_DEV && VIDEO_V4L2 && ARCH_MXC && !ARCH_MULTIPLATFORM
This breakage is not multiplatform related at all, it won't compile
without multiplatform support either. So depends on BROKEN would be
more appropriate if you want to go this way.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* [GIT PULL] Renesas ARM-based SoC v3.9
From: Olof Johansson @ 2013-01-22 8:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2682612.QaV0caZ3tv@avalon>
On Mon, Jan 21, 2013 at 04:31:43PM +0100, Laurent Pinchart wrote:
> Hi Olof,
>
> On Wednesday 16 January 2013 15:43:10 Olof Johansson wrote:
> > On Wed, Jan 16, 2013 at 03:37:53PM +0900, Simon Horman wrote:
> > > Hi Olof, Hi Arnd,
> > >
> > > I have some complex dependencies for mach-shmobile for v3.9 and as such I
> > > am sending this email outline the dependencies of branches on each other.
> > > I have also included the multiple pull requests below though I am happy to
> > > post them individually including the patches they comprise if you have no
> > > objections to the way the branch dependencies are arranged.
> > >
> > > I would also be happy to supply a single branch with all changes with or
> > > without merge commits.
> >
> > Hmm, complex indeed.
> >
> > Is there any way to avoid this sequence of ARM -> sh/pinctrl -> ARM ->
> > sh/pinctrl dependencies? That's what really makes things look complicated
> > here. If you could move the final cleanup/code removal pieces out of
> > the sh/pinctrl branches such that you have a less iterative chain of:
> >
> > sh/pinctrl -> ARM -> final sh/pinctrl cleanup (removal of struct members,
> > etc)
> >
> > ... but I haven't looked in detail at the per-patch dependencies to see how
> > tough that would be to arrange.
> >
> > > All branches are present in the renesas tree
> > > git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git
> > >
> > > 1. Branch: sh-soc
> > >
> > > Description: Pre-requisites for pfc changes for SH SoCs
> > > Based on: v3.8-rc1
> > >
> > > 2. Branch: clocksource
> > >
> > > Description: Pre-requisite clocksource change for soc branch
> > > Based on: v3.8-rc1
> > >
> > > 3. Branch: pfc
> > >
> > > Description: PFC Updates
> > > Based on: sh-soc
> > >
> > > 4. Branch: sh-soc2
> > >
> > > Description: Further PFC changes for SH SoCs
> > > Based on: pfc
> > >
> > > 5. Branch: soc
> > >
> > > Description: shmobile (ARM) SoCs updates, including PFC changes.
> > > Based on: a merge of clocksource and pfc
> > >
> > > 6. Branch: boards
> > >
> > > Description: Board changes, including PFC changes.
> > > Based on: A merge of timer/cleanup (present in the arm-soc tree) and
> > > soc
> > >
> > > 7. Branch: pfc2
> > >
> > > Description: Further PFC changes which depend on SoC changes
> > > Based on: A merge of sh-soc2 and soc
> > >
> > > 8. Branch: sh-soc3
> > >
> > > Description: Further PFC changes for SH SoCs
> > > Based on: pfc2
> > >
> > > 9. Branch: soc2
> > >
> > > Description: Further PFC changes for shmobile (ARM) SoCs
> > > Based on: A merge of timer/cleanup (present in the arm-soc tree) and
> > > pfc2
> > >
> > > 10. Branch: pfc3
> > >
> > > Description: Description: Further PFC changes which depend on SoC
> > > changes
> > > Based on: A merge of sh-soc3 and soc2
> >
> > Looking at it from the end here, 10 contains only arch/sh and global
> > changes, and depends on 8 and 9. 8 also contains only sh changes. So it
> > looks like 8 and 10 could be pruned from this pull request and go through
> > either SH or pinctrl.
> >
> > What pieces from branch 7 are stronly needed? A couple of the added pinctrl
> > modules are used by mach-shmobile boards, it seems. And the structure rename
> > might also be needed.
>
> 7 prepares for the move of PFC data from board code to drivers/. The branch
> mostly adds a pinctrl module for each of the supported SoCs, to allow later
> removal of PFC data from board code (in branches 8 and 9).
>
> > Not having to pull in the bulk of 7, 8 and 10 would make a pretty big
> > difference.
>
> One way or the other all patches will need to be pulled. If they go through
> multiple trees we'll have to synchronize the multiple pull requests during the
> merge window, which looks pretty error-prone to me (but I might be wrong on
> this).
>
> Sure, we could push 1-6 through the ARM tree, wait until it reaches mainline,
> then push 7 through the pinctrl tree, wait until it reaches mainline, push 8
> through the SH tree and 9 through the ARM tree, wait until they reach
> mainline, and finally push 10 through the pinctrl tree again. We could even
> push each branch through the tree it belongs to, but I doubt we'll be able to
> push everything during a single merge window.
>
> I might be able to move 1 after 7, in which case we would have a single branch
> that would combine both and touch pinctrl only. The other dependencies seem
> pretty difficult to avoid.
>
> What are the main issues with merging the branches in their current state (or
> possibly with 5 and 6 moved aside) through the ARM tree ?
Ah, ok -- you're suggesting bringing it _all_ in through arm-soc. We
can do so, I was of the initial impression from Simon's cover letter
that the arch/sh branches would also go through the SH tree.
This seems to be a particularly hairy conversion, given that it touches two
architectures that need to be updated in lockstep. I guess we might be just as
well off pulling it in as-is (with below exceptions) to get it in.
If you need the same contents in the SH tree due to dependencies and
later development, let me know and we can agree on a stable branch that
we both pick up in either tree that has all contents.
> > For branch 2 (clocksource include order), I'd like to see an ack from John
> > or Thomas. Does it really make sense to base that on an ifdef instead of
> > always initialize early?
> >
> > Branch 4 seems to be mostly sh-specific updates. With some of the later
> > dependencies avoided, maybe this branch can be dropped too, not sure?
>
> 4 moves platform device registration from the sh-pfc module to board code.
> Later pinctrl patches then remove platform device registration from the sh-pfc
> module completely and continue with the rework of the sh-pfc code. 7 thus
> strongly depends on 4.
Ok.
> > About half of branch 5 looks like it's generic SoC-updates unrelated
> > to the pinctrl rework, and branch 6 looks like mostly regular
> > patches/updates, is that stronly dependent on all the pinctrl
> > rework? Doesn't look like it should be?
>
> You're right here. The non-pinctrl patches in 5 could go through a separate
> branch, they shouldn't depend on the pinctrl rework. 6 also has no dependency
> on the pinctrl rework.
Simon, based on the above, would you mind splitting off the non-pinctrl updates
to separate branches?
I'll likely pick this up as a standalone branch, and not try to fit it into the
usual arm-soc categories, so feel free to use the pinctrl branch contents as
a base for the other branches if you have to, but maybe you can avoid it
alltogether if there aren't any substantial conflicts between the pinctrl
restructuring and the other patches mentioned above.
-Olof
^ permalink raw reply
* [PATCH 05/15] ASoC: fsl: fiq and dma cannot both be modules
From: Arnd Bergmann @ 2013-01-22 8:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130122063331.GA1766@opensource.wolfsonmicro.com>
On Tuesday 22 January 2013, Mark Brown wrote:
> On Tue, Jan 22, 2013 at 11:50:30AM +0800, Shawn Guo wrote:
> > I sent a fix [1] for that queued by Mark.
Right, that patch looks good, too.
> > Is the patch on the way to 3.8-rc?
>
> Yes, should be.
Ok, thanks!
Arnd
^ permalink raw reply
* [GIT PULL] i.MX fixes for -rc
From: Sascha Hauer @ 2013-01-22 8:16 UTC (permalink / raw)
To: linux-arm-kernel
Hi Arnd, Olof,
Please pull the following fix for -rc.
Sascha
The following changes since commit d1c3ed669a2d452cacfb48c2d171a1f364dae2ed:
Linux 3.8-rc2 (2013-01-02 18:13:21 -0800)
are available in the git repository at:
git://git.pengutronix.de/git/imx/linux-2.6.git tags/imx-fixes-rc
for you to fetch changes up to e909c682d04e55e77a3c9d158e7dc36027195493:
[media] coda: Fix build due to iram.h rename (2013-01-08 09:44:06 +0100)
----------------------------------------------------------------
ARM i.MX fixes for -rc.
This contains a single compilation fix for the CODA driver.
----------------------------------------------------------------
Sascha Hauer (1):
[media] coda: Fix build due to iram.h rename
arch/arm/mach-imx/iram_alloc.c | 3 +--
drivers/media/platform/coda.c | 2 +-
arch/arm/mach-imx/iram.h => include/linux/platform_data/imx-iram.h | 0
3 files changed, 2 insertions(+), 3 deletions(-)
rename arch/arm/mach-imx/iram.h => include/linux/platform_data/imx-iram.h (100%)
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* [PATCH 2/7] ARM: sunxi: Add pinctrl driver for Allwinner SoCs
From: Olof Johansson @ 2013-01-22 8:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdb8xLeP+RB+JfuEQu=MQ0yO6tVFasVrMsOE4FSfJHrOiw@mail.gmail.com>
On Mon, Jan 21, 2013 at 11:09:07PM +0100, Linus Walleij wrote:
> On Fri, Jan 18, 2013 at 10:30 PM, Maxime Ripard
> <maxime.ripard@free-electrons.com> wrote:
> > The Allwinner SoCs have an IP module that handle both the muxing and the
> > GPIOs.
> >
> > This IP has 8 banks of 32 bits, with a number of pins actually useful
> > for each of these banks varying from one to another, and depending on
> > the SoC used on the board.
> >
> > This driver only implements the pinctrl part, the gpio part will come
> > eventually.
> >
> > Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
>
> Patch title says "ARM: " but all changed except one line is to the pinctrl
> tree so I have applied it to the pinctrl tree on a separate allwinner
> branch for now (will merge it to devel when deemde stable).
>
> ARM SoC boys: can I have an ACK on this oneliner?
Acked-by: Olof Johansson <olof@lixom.net>
-Olof
^ permalink raw reply
* [PATCH v2 1/2] ARM: shmobile: sh73a0: Use generic irqchip_init()
From: Simon Horman @ 2013-01-22 8:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130122072912.GD25783@quad.lixom.net>
On Mon, Jan 21, 2013 at 11:29:12PM -0800, Olof Johansson wrote:
> On Mon, Jan 21, 2013 at 08:03:01AM +0100, Thierry Reding wrote:
> > On Mon, Jan 21, 2013 at 09:54:39AM +0900, Simon Horman wrote:
> > > On Fri, Jan 18, 2013 at 08:16:12AM +0100, Thierry Reding wrote:
> > > > The asm/hardware/gic.h header does no longer exist and the corresponding
> > > > functionality was moved to linux/irqchip.h and linux/irqchip/arm-gic.h
> > > > respectively. gic_handle_irq() and of_irq_init() are no longer available
> > > > either and have been replaced by irqchip_init().
> > >
> > > asm/hardware/gic.h Seems to still exist in Linus's tree.
> > > Could you let me know which tree of which branch I should depend on
> > > in order to apply this change?
> >
> > I found this when doing an automated build over all ARM defconfigs on
> > linux-next.
> >
> > Commit 520f7bd73354f003a9a59937b28e4903d985c420 "irqchip: Move ARM gic.h
> > to include/linux/irqchip/arm-gic.h" moved the file and was merged
> > through Olof Johansson's next/cleanup and for-next branches.
> >
> > Adding Olof on Cc since I'm not quite sure myself about how this is
> > handled.
>
> The way to handle this is to base the branch you are adding new shmobile code
> in, on top of the cleanup branches that changes the underlying infrastructure.
> This is why we merge it early during the release, so that new code for various
> platforms can be based on it to avoid a bunch of conflicts in the end.
>
> In this case, you might need to base your branch onto a merge of both
> the irqchip/gic-vic-move and timer/cleanup branches from arm-soc.
Thanks, I'll take a look at rebasing accordingly.
^ permalink raw reply
* [PATCH v2] ARM: remove redundant 'select GENERIC_GPIO'
From: Olof Johansson @ 2013-01-22 8:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358499506-9790-1-git-send-email-shawn.guo@linaro.org>
On Fri, Jan 18, 2013 at 04:58:26PM +0800, Shawn Guo wrote:
> In drivers/gpio/Kcong, ARCH_REQUIRE_GPIOLIB selects GPIOLIB which in
> turn selects GENERIC_GPIO. So GENERIC_GPIO will be selected
> automatically for those platforms that select ARCH_REQUIRE_GPIOLIB.
>
> Remove the redundant 'select GENERIC_GPIO' for platforms that already
> select ARCH_REQUIRE_GPIOLIB at either mach or plat level.
>
> Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
> Acked-by: Linus Walleij <linus.walleij@linaro.org>
> ---
> Changes since v1:
> - Update commit log to better explain why the select is unncessary
Applied to next/cleanup. Thanks!
-Olof
^ permalink raw reply
* [GIT PULL v3] Renesas ARM-based SoC defconfig for v3.9
From: Olof Johansson @ 2013-01-22 7:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358316146-12579-1-git-send-email-horms+renesas@verge.net.au>
On Wed, Jan 16, 2013 at 03:02:21PM +0900, Simon Horman wrote:
> Hi Olof, Hi Arnd,
>
> please consider the following defconfig enhancements for 3.9.
>
> ----------------------------------------------------------------
> The following changes since commit a49f0d1ea3ec94fc7cf33a7c36a16343b74bd565:
>
> Linux 3.8-rc1 (2012-12-21 17:19:00 -0800)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git defconfig
Thanks, pulled as renesas/defconfig and included in next/boards.
-Olof
^ permalink raw reply
* [PATCH] crypto: fix FTBFS with ARM SHA1-asm and THUMB2_KERNEL
From: Jussi Kivilinna @ 2013-01-22 7:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130122094614.79031aq5ddrgr2zo@www.dalek.fi>
Quoting Jussi Kivilinna <jussi.kivilinna@mbnet.fi>:
> Quoting Matt Sealey <matt@genesi-usa.com>:
>
>> This question is to the implementor/committer (Dave McCullough), how
>> exactly did you measure the benchmark and can we reproduce it on some
>> other ARM box?
>>
>> If it's long and laborious and not so important to test the IPsec
>> tunnel use-case, what would be the simplest possible benchmark to see
>> if the C vs. assembly version is faster for a particular ARM device? I
>> can get hold of pretty much any Cortex-A8 or Cortex-A9 that matters, I
>> have access to a Chromebook for A15, and maybe an i.MX27 or i.MX35 and
>> a couple Marvell boards (ARMv6) if I set my mind to it... that much
>> testing implies we find a pretty concise benchmark though with a
>> fairly common kernel version we can spread around (i.MX, OMAP and the
>> Chromebook, I can handle, the rest I'm a little wary of bothering to
>> spend too much time on). I think that could cover a good swath of
>> not-ARMv5 use cases from lower speeds to quad core monsters.. but I
>> might stick to i.MX to start with..
>
> There is 'tcrypt' module in crypto/ for quick benchmarking.
> 'modprobe tcrypt mode=500 sec=1' tests AES in various cipher-modes,
> using different buffer sizes and outputs results to kernel log.
>
Actually mode=200 might be better, as mode=500 is for asynchronous
implementations and might use hardware crypto if such device/module is
available.
-Jussi
^ permalink raw reply
* [PATCH 3/7] ARM i.MX6q: Add GPU, VPU, IPU, and OpenVG resets to System Reset Controller (SRC)
From: Shawn Guo @ 2013-01-22 7:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKGA1bmkyU_LEJt17SvUwUUh0wXG-2o_5nOGaW8RWDV45g3bVg@mail.gmail.com>
On Mon, Jan 21, 2013 at 11:47:12AM -0600, Matt Sealey wrote:
> > Yes, maybe the module reset part of the SRC should be implemented as a
> > proper device driver in drivers/reset. Then we could use the interrupt
> > functionality and WARN_ON(timeout), as you suggest.
>
> That would be ideal. Maybe Shawn or Fabio can bug a hardware guy to
> shed some light on what a reasonable timeout might actually be for a
> module to cause such a warning. I think it should definitely cause
> one.. as I said, I was using 5 seconds, you used 1 second, I don't
> think a shorter delay would be unreasonable, but maybe it could take
> up to 10 seconds, or maybe I am wrong - maybe it is in fact impossible
> in hardware for a reset to "fail" at least visibly because the
> interrupt will always fire making the warning a never-traveled path.
> It is certainly not something that would be documented, so without a
> view of the RTL logic here, we wouldn't know.
>
> Shawn, Fabio?
>
Just talked to hardware people, the reset should finish in a few
clock cycles, so even 1 millisecond should be enough.
Shawn
^ permalink raw reply
* [PATCH] crypto: fix FTBFS with ARM SHA1-asm and THUMB2_KERNEL
From: Jussi Kivilinna @ 2013-01-22 7:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKGA1bkQ9e8gmSPz_4csJWjEOKj3ZVqSLijSTRWxgDSaZoYqCA@mail.gmail.com>
Quoting Matt Sealey <matt@genesi-usa.com>:
> This question is to the implementor/committer (Dave McCullough), how
> exactly did you measure the benchmark and can we reproduce it on some
> other ARM box?
>
> If it's long and laborious and not so important to test the IPsec
> tunnel use-case, what would be the simplest possible benchmark to see
> if the C vs. assembly version is faster for a particular ARM device? I
> can get hold of pretty much any Cortex-A8 or Cortex-A9 that matters, I
> have access to a Chromebook for A15, and maybe an i.MX27 or i.MX35 and
> a couple Marvell boards (ARMv6) if I set my mind to it... that much
> testing implies we find a pretty concise benchmark though with a
> fairly common kernel version we can spread around (i.MX, OMAP and the
> Chromebook, I can handle, the rest I'm a little wary of bothering to
> spend too much time on). I think that could cover a good swath of
> not-ARMv5 use cases from lower speeds to quad core monsters.. but I
> might stick to i.MX to start with..
There is 'tcrypt' module in crypto/ for quick benchmarking. 'modprobe
tcrypt mode=500 sec=1' tests AES in various cipher-modes, using
different buffer sizes and outputs results to kernel log.
-Jussi
^ permalink raw reply
* [PATCH v5 45/45] Documentation/cpu-hotplug: Remove references to stop_machine()
From: Srivatsa S. Bhat @ 2013-01-22 7:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130122073210.13822.50434.stgit@srivatsabhat.in.ibm.com>
Since stop_machine() is no longer used in the CPU offline path, we cannot
disable CPU hotplug using preempt_disable()/local_irq_disable() etc. We
need to use the newly introduced get/put_online_cpus_atomic() APIs.
Reflect this in the documentation.
Cc: Rob Landley <rob@landley.net>
Cc: linux-doc at vger.kernel.org
Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
---
Documentation/cpu-hotplug.txt | 17 +++++++++++------
1 file changed, 11 insertions(+), 6 deletions(-)
diff --git a/Documentation/cpu-hotplug.txt b/Documentation/cpu-hotplug.txt
index 9f40135..7f907ec 100644
--- a/Documentation/cpu-hotplug.txt
+++ b/Documentation/cpu-hotplug.txt
@@ -113,13 +113,15 @@ Never use anything other than cpumask_t to represent bitmap of CPUs.
#include <linux/cpu.h>
get_online_cpus() and put_online_cpus():
-The above calls are used to inhibit cpu hotplug operations. While the
+The above calls are used to inhibit cpu hotplug operations, when invoked from
+non-atomic context (because the above functions can sleep). While the
cpu_hotplug.refcount is non zero, the cpu_online_mask will not change.
-If you merely need to avoid cpus going away, you could also use
-preempt_disable() and preempt_enable() for those sections.
-Just remember the critical section cannot call any
-function that can sleep or schedule this process away. The preempt_disable()
-will work as long as stop_machine_run() is used to take a cpu down.
+
+However, if you are executing in atomic context (ie., you can't afford to
+sleep), and you merely need to avoid cpus going offline, you can use
+get_online_cpus_atomic() and put_online_cpus_atomic() for those sections.
+Just remember the critical section cannot call any function that can sleep or
+schedule this process away.
CPU Hotplug - Frequently Asked Questions.
@@ -360,6 +362,9 @@ A: There are two ways. If your code can be run in interrupt context, use
return err;
}
+ If my_func_on_cpu() itself cannot block, use get/put_online_cpus_atomic()
+ instead of get/put_online_cpus() to prevent CPUs from going offline.
+
Q: How do we determine how many CPUs are available for hotplug.
A: There is no clear spec defined way from ACPI that can give us that
information today. Based on some input from Natalie of Unisys,
^ permalink raw reply related
* [PATCH v5 44/45] CPU hotplug, stop_machine: Decouple CPU hotplug from stop_machine() in Kconfig
From: Srivatsa S. Bhat @ 2013-01-22 7:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130122073210.13822.50434.stgit@srivatsabhat.in.ibm.com>
... and also cleanup a comment that refers to CPU hotplug being dependent on
stop_machine().
Cc: David Howells <dhowells@redhat.com>
Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
---
include/linux/stop_machine.h | 2 +-
init/Kconfig | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/linux/stop_machine.h b/include/linux/stop_machine.h
index 3b5e910..ce2d3c4 100644
--- a/include/linux/stop_machine.h
+++ b/include/linux/stop_machine.h
@@ -120,7 +120,7 @@ int stop_machine(int (*fn)(void *), void *data, const struct cpumask *cpus);
* @cpus: the cpus to run the @fn() on (NULL = any online cpu)
*
* Description: This is a special version of the above, which assumes cpus
- * won't come or go while it's being called. Used by hotplug cpu.
+ * won't come or go while it's being called.
*/
int __stop_machine(int (*fn)(void *), void *data, const struct cpumask *cpus);
diff --git a/init/Kconfig b/init/Kconfig
index be8b7f5..048a0c5 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -1711,7 +1711,7 @@ config INIT_ALL_POSSIBLE
config STOP_MACHINE
bool
default y
- depends on (SMP && MODULE_UNLOAD) || HOTPLUG_CPU
+ depends on (SMP && MODULE_UNLOAD)
help
Need stop_machine() primitive.
^ permalink raw reply related
* [PATCH v5 43/45] cpu: No more __stop_machine() in _cpu_down()
From: Srivatsa S. Bhat @ 2013-01-22 7:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130122073210.13822.50434.stgit@srivatsabhat.in.ibm.com>
From: Paul E. McKenney <paul.mckenney@linaro.org>
The _cpu_down() function invoked as part of the CPU-hotplug offlining
process currently invokes __stop_machine(), which is slow and inflicts
substantial real-time latencies on the entire system. This patch
substitutes stop_one_cpu() for __stop_machine() in order to improve
both performance and real-time latency.
There were a number of uses of preempt_disable() or local_irq_disable()
that were intended to block CPU-hotplug offlining. These were fixed by
using get/put_online_cpus_atomic(), which is the new synchronization
primitive to prevent CPU offline, while invoking from atomic context.
Signed-off-by: Paul E. McKenney <paul.mckenney@linaro.org>
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
[ srivatsa.bhat at linux.vnet.ibm.com: Refer to the new sync primitives for
readers (in the changelog); s/stop_cpus/stop_one_cpu and fix comment
referring to stop_machine in the code]
Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
---
kernel/cpu.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/kernel/cpu.c b/kernel/cpu.c
index 1c84138..7a51fb6 100644
--- a/kernel/cpu.c
+++ b/kernel/cpu.c
@@ -337,7 +337,7 @@ static int __ref _cpu_down(unsigned int cpu, int tasks_frozen)
}
smpboot_park_threads(cpu);
- err = __stop_machine(take_cpu_down, &tcd_param, cpumask_of(cpu));
+ err = stop_one_cpu(cpu, take_cpu_down, &tcd_param);
if (err) {
/* CPU didn't die: tell everyone. Can't complain. */
smpboot_unpark_threads(cpu);
@@ -349,7 +349,7 @@ static int __ref _cpu_down(unsigned int cpu, int tasks_frozen)
/*
* The migration_call() CPU_DYING callback will have removed all
* runnable tasks from the cpu, there's only the idle task left now
- * that the migration thread is done doing the stop_machine thing.
+ * that the migration thread is done doing the stop_one_cpu() thing.
*
* Wait for the stop thread to go away.
*/
^ permalink raw reply related
* [PATCH v5 42/45] tile: Use get/put_online_cpus_atomic() to prevent CPU offline
From: Srivatsa S. Bhat @ 2013-01-22 7:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130122073210.13822.50434.stgit@srivatsabhat.in.ibm.com>
Once stop_machine() is gone from the CPU offline path, we won't be able to
depend on preempt_disable() or local_irq_disable() to prevent CPUs from
going offline from under us.
Use the get/put_online_cpus_atomic() APIs to prevent CPUs from going offline,
while invoking from atomic context.
Cc: Chris Metcalf <cmetcalf@tilera.com>
Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
---
arch/tile/kernel/smp.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/tile/kernel/smp.c b/arch/tile/kernel/smp.c
index cbc73a8..fb30624 100644
--- a/arch/tile/kernel/smp.c
+++ b/arch/tile/kernel/smp.c
@@ -15,6 +15,7 @@
*/
#include <linux/smp.h>
+#include <linux/cpu.h>
#include <linux/interrupt.h>
#include <linux/io.h>
#include <linux/irq.h>
@@ -82,9 +83,12 @@ void send_IPI_many(const struct cpumask *mask, int tag)
void send_IPI_allbutself(int tag)
{
struct cpumask mask;
+
+ get_online_cpus_atomic();
cpumask_copy(&mask, cpu_online_mask);
cpumask_clear_cpu(smp_processor_id(), &mask);
send_IPI_many(&mask, tag);
+ put_online_cpus_atomic();
}
/*
^ permalink raw reply related
* [PATCH v5 41/45] sparc: Use get/put_online_cpus_atomic() to prevent CPU offline
From: Srivatsa S. Bhat @ 2013-01-22 7:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130122073210.13822.50434.stgit@srivatsabhat.in.ibm.com>
Once stop_machine() is gone from the CPU offline path, we won't be able to
depend on preempt_disable() or local_irq_disable() to prevent CPUs from
going offline from under us.
Use the get/put_online_cpus_atomic() APIs to prevent CPUs from going offline,
while invoking from atomic context.
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Sam Ravnborg <sam@ravnborg.org>
Cc: sparclinux at vger.kernel.org
Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
---
arch/sparc/kernel/leon_smp.c | 2 ++
arch/sparc/kernel/smp_64.c | 9 +++++----
arch/sparc/kernel/sun4d_smp.c | 2 ++
arch/sparc/kernel/sun4m_smp.c | 3 +++
4 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/arch/sparc/kernel/leon_smp.c b/arch/sparc/kernel/leon_smp.c
index 0f3fb6d..441d3ac 100644
--- a/arch/sparc/kernel/leon_smp.c
+++ b/arch/sparc/kernel/leon_smp.c
@@ -420,6 +420,7 @@ static void leon_cross_call(smpfunc_t func, cpumask_t mask, unsigned long arg1,
unsigned long flags;
spin_lock_irqsave(&cross_call_lock, flags);
+ get_online_cpus_atomic();
{
/* If you make changes here, make sure gcc generates proper code... */
@@ -476,6 +477,7 @@ static void leon_cross_call(smpfunc_t func, cpumask_t mask, unsigned long arg1,
} while (++i <= high);
}
+ put_online_cpus_atomic();
spin_unlock_irqrestore(&cross_call_lock, flags);
}
}
diff --git a/arch/sparc/kernel/smp_64.c b/arch/sparc/kernel/smp_64.c
index 537eb66..e1d7300 100644
--- a/arch/sparc/kernel/smp_64.c
+++ b/arch/sparc/kernel/smp_64.c
@@ -894,7 +894,8 @@ void smp_flush_dcache_page_impl(struct page *page, int cpu)
atomic_inc(&dcpage_flushes);
#endif
- this_cpu = get_cpu();
+ get_online_cpus_atomic();
+ this_cpu = smp_processor_id();
if (cpu == this_cpu) {
__local_flush_dcache_page(page);
@@ -920,7 +921,7 @@ void smp_flush_dcache_page_impl(struct page *page, int cpu)
}
}
- put_cpu();
+ put_online_cpus_atomic();
}
void flush_dcache_page_all(struct mm_struct *mm, struct page *page)
@@ -931,7 +932,7 @@ void flush_dcache_page_all(struct mm_struct *mm, struct page *page)
if (tlb_type == hypervisor)
return;
- preempt_disable();
+ get_online_cpus_atomic();
#ifdef CONFIG_DEBUG_DCFLUSH
atomic_inc(&dcpage_flushes);
@@ -956,7 +957,7 @@ void flush_dcache_page_all(struct mm_struct *mm, struct page *page)
}
__local_flush_dcache_page(page);
- preempt_enable();
+ put_online_cpus_atomic();
}
void __irq_entry smp_new_mmu_context_version_client(int irq, struct pt_regs *regs)
diff --git a/arch/sparc/kernel/sun4d_smp.c b/arch/sparc/kernel/sun4d_smp.c
index ddaea31..1fa7ff2 100644
--- a/arch/sparc/kernel/sun4d_smp.c
+++ b/arch/sparc/kernel/sun4d_smp.c
@@ -300,6 +300,7 @@ static void sun4d_cross_call(smpfunc_t func, cpumask_t mask, unsigned long arg1,
unsigned long flags;
spin_lock_irqsave(&cross_call_lock, flags);
+ get_online_cpus_atomic();
{
/*
@@ -356,6 +357,7 @@ static void sun4d_cross_call(smpfunc_t func, cpumask_t mask, unsigned long arg1,
} while (++i <= high);
}
+ put_online_cpus_atomic();
spin_unlock_irqrestore(&cross_call_lock, flags);
}
}
diff --git a/arch/sparc/kernel/sun4m_smp.c b/arch/sparc/kernel/sun4m_smp.c
index 128af73..5599548 100644
--- a/arch/sparc/kernel/sun4m_smp.c
+++ b/arch/sparc/kernel/sun4m_smp.c
@@ -192,6 +192,7 @@ static void sun4m_cross_call(smpfunc_t func, cpumask_t mask, unsigned long arg1,
unsigned long flags;
spin_lock_irqsave(&cross_call_lock, flags);
+ get_online_cpus_atomic();
/* Init function glue. */
ccall_info.func = func;
@@ -238,6 +239,8 @@ static void sun4m_cross_call(smpfunc_t func, cpumask_t mask, unsigned long arg1,
barrier();
} while (++i < ncpus);
}
+
+ put_online_cpus_atomic();
spin_unlock_irqrestore(&cross_call_lock, flags);
}
^ permalink raw reply related
* [PATCH v5 40/45] sh: Use get/put_online_cpus_atomic() to prevent CPU offline
From: Srivatsa S. Bhat @ 2013-01-22 7:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130122073210.13822.50434.stgit@srivatsabhat.in.ibm.com>
Once stop_machine() is gone from the CPU offline path, we won't be able to
depend on preempt_disable() or local_irq_disable() to prevent CPUs from
going offline from under us.
Use the get/put_online_cpus_atomic() APIs to prevent CPUs from going offline,
while invoking from atomic context.
Cc: Paul Mundt <lethal@linux-sh.org>
Cc: linux-sh at vger.kernel.org
Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
---
arch/sh/kernel/smp.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/sh/kernel/smp.c b/arch/sh/kernel/smp.c
index 2062aa8..232fabe 100644
--- a/arch/sh/kernel/smp.c
+++ b/arch/sh/kernel/smp.c
@@ -357,7 +357,7 @@ static void flush_tlb_mm_ipi(void *mm)
*/
void flush_tlb_mm(struct mm_struct *mm)
{
- preempt_disable();
+ get_online_cpus_atomic();
if ((atomic_read(&mm->mm_users) != 1) || (current->mm != mm)) {
smp_call_function(flush_tlb_mm_ipi, (void *)mm, 1);
@@ -369,7 +369,7 @@ void flush_tlb_mm(struct mm_struct *mm)
}
local_flush_tlb_mm(mm);
- preempt_enable();
+ put_online_cpus_atomic();
}
struct flush_tlb_data {
@@ -390,7 +390,7 @@ void flush_tlb_range(struct vm_area_struct *vma,
{
struct mm_struct *mm = vma->vm_mm;
- preempt_disable();
+ get_online_cpus_atomic();
if ((atomic_read(&mm->mm_users) != 1) || (current->mm != mm)) {
struct flush_tlb_data fd;
@@ -405,7 +405,7 @@ void flush_tlb_range(struct vm_area_struct *vma,
cpu_context(i, mm) = 0;
}
local_flush_tlb_range(vma, start, end);
- preempt_enable();
+ put_online_cpus_atomic();
}
static void flush_tlb_kernel_range_ipi(void *info)
@@ -433,7 +433,7 @@ static void flush_tlb_page_ipi(void *info)
void flush_tlb_page(struct vm_area_struct *vma, unsigned long page)
{
- preempt_disable();
+ get_online_cpus_atomic();
if ((atomic_read(&vma->vm_mm->mm_users) != 1) ||
(current->mm != vma->vm_mm)) {
struct flush_tlb_data fd;
@@ -448,7 +448,7 @@ void flush_tlb_page(struct vm_area_struct *vma, unsigned long page)
cpu_context(i, vma->vm_mm) = 0;
}
local_flush_tlb_page(vma, page);
- preempt_enable();
+ put_online_cpus_atomic();
}
static void flush_tlb_one_ipi(void *info)
^ permalink raw reply related
* [PATCH v5 39/45] powerpc: Use get/put_online_cpus_atomic() to prevent CPU offline
From: Srivatsa S. Bhat @ 2013-01-22 7:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130122073210.13822.50434.stgit@srivatsabhat.in.ibm.com>
Once stop_machine() is gone from the CPU offline path, we won't be able to
depend on preempt_disable() or local_irq_disable() to prevent CPUs from
going offline from under us.
Use the get/put_online_cpus_atomic() APIs to prevent CPUs from going offline,
while invoking from atomic context.
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: linuxppc-dev at lists.ozlabs.org
Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
---
arch/powerpc/mm/mmu_context_nohash.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/powerpc/mm/mmu_context_nohash.c b/arch/powerpc/mm/mmu_context_nohash.c
index e779642..29f58cf 100644
--- a/arch/powerpc/mm/mmu_context_nohash.c
+++ b/arch/powerpc/mm/mmu_context_nohash.c
@@ -196,6 +196,7 @@ void switch_mmu_context(struct mm_struct *prev, struct mm_struct *next)
/* No lockless fast path .. yet */
raw_spin_lock(&context_lock);
+ get_online_cpus_atomic();
pr_hard("[%d] activating context for mm @%p, active=%d, id=%d",
cpu, next, next->context.active, next->context.id);
@@ -279,6 +280,7 @@ void switch_mmu_context(struct mm_struct *prev, struct mm_struct *next)
/* Flick the MMU and release lock */
pr_hardcont(" -> %d\n", id);
set_context(id, next->pgd);
+ put_online_cpus_atomic();
raw_spin_unlock(&context_lock);
}
^ permalink raw reply related
* [PATCH v5 38/45] parisc: Use get/put_online_cpus_atomic() to prevent CPU offline
From: Srivatsa S. Bhat @ 2013-01-22 7:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130122073210.13822.50434.stgit@srivatsabhat.in.ibm.com>
Once stop_machine() is gone from the CPU offline path, we won't be able to
depend on preempt_disable() or local_irq_disable() to prevent CPUs from
going offline from under us.
Use the get/put_online_cpus_atomic() APIs to prevent CPUs from going offline,
while invoking from atomic context.
Cc: "James E.J. Bottomley" <jejb@parisc-linux.org>
Cc: linux-parisc at vger.kernel.org
Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
---
arch/parisc/kernel/smp.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/parisc/kernel/smp.c b/arch/parisc/kernel/smp.c
index 6266730..f7851b7 100644
--- a/arch/parisc/kernel/smp.c
+++ b/arch/parisc/kernel/smp.c
@@ -229,11 +229,13 @@ static inline void
send_IPI_allbutself(enum ipi_message_type op)
{
int i;
-
+
+ get_online_cpus_atomic();
for_each_online_cpu(i) {
if (i != smp_processor_id())
send_IPI_single(i, op);
}
+ put_online_cpus_atomic();
}
^ permalink raw reply related
* [PATCH v5 37/45] mn10300: Use get/put_online_cpus_atomic() to prevent CPU offline
From: Srivatsa S. Bhat @ 2013-01-22 7:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130122073210.13822.50434.stgit@srivatsabhat.in.ibm.com>
Once stop_machine() is gone from the CPU offline path, we won't be able to
depend on preempt_disable() or local_irq_disable() to prevent CPUs from
going offline from under us.
Use the get/put_online_cpus_atomic() APIs to prevent CPUs from going offline,
while invoking from atomic context.
Cc: David Howells <dhowells@redhat.com>
Cc: Koichi Yasutake <yasutake.koichi@jp.panasonic.com>
Cc: linux-am33-list at redhat.com
Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
---
arch/mn10300/kernel/smp.c | 2 ++
arch/mn10300/mm/cache-smp.c | 5 +++++
arch/mn10300/mm/tlb-smp.c | 15 +++++++++------
3 files changed, 16 insertions(+), 6 deletions(-)
diff --git a/arch/mn10300/kernel/smp.c b/arch/mn10300/kernel/smp.c
index 5d7e152..9dfa172 100644
--- a/arch/mn10300/kernel/smp.c
+++ b/arch/mn10300/kernel/smp.c
@@ -349,9 +349,11 @@ void send_IPI_allbutself(int irq)
{
cpumask_t cpumask;
+ get_online_cpus_atomic();
cpumask_copy(&cpumask, cpu_online_mask);
cpumask_clear_cpu(smp_processor_id(), &cpumask);
send_IPI_mask(&cpumask, irq);
+ put_online_cpus_atomic();
}
void arch_send_call_function_ipi_mask(const struct cpumask *mask)
diff --git a/arch/mn10300/mm/cache-smp.c b/arch/mn10300/mm/cache-smp.c
index 2d23b9e..47ca1c9 100644
--- a/arch/mn10300/mm/cache-smp.c
+++ b/arch/mn10300/mm/cache-smp.c
@@ -13,6 +13,7 @@
#include <linux/mman.h>
#include <linux/threads.h>
#include <linux/interrupt.h>
+#include <linux/cpu.h>
#include <asm/page.h>
#include <asm/pgtable.h>
#include <asm/processor.h>
@@ -94,6 +95,8 @@ void smp_cache_call(unsigned long opr_mask,
smp_cache_mask = opr_mask;
smp_cache_start = start;
smp_cache_end = end;
+
+ get_online_cpus_atomic();
cpumask_copy(&smp_cache_ipi_map, cpu_online_mask);
cpumask_clear_cpu(smp_processor_id(), &smp_cache_ipi_map);
@@ -102,4 +105,6 @@ void smp_cache_call(unsigned long opr_mask,
while (!cpumask_empty(&smp_cache_ipi_map))
/* nothing. lockup detection does not belong here */
mb();
+
+ put_online_cpus_atomic();
}
diff --git a/arch/mn10300/mm/tlb-smp.c b/arch/mn10300/mm/tlb-smp.c
index 3e57faf..d47304d 100644
--- a/arch/mn10300/mm/tlb-smp.c
+++ b/arch/mn10300/mm/tlb-smp.c
@@ -23,6 +23,7 @@
#include <linux/sched.h>
#include <linux/profile.h>
#include <linux/smp.h>
+#include <linux/cpu.h>
#include <asm/tlbflush.h>
#include <asm/bitops.h>
#include <asm/processor.h>
@@ -105,6 +106,7 @@ static void flush_tlb_others(cpumask_t cpumask, struct mm_struct *mm,
BUG_ON(cpumask_empty(&cpumask));
BUG_ON(cpumask_test_cpu(smp_processor_id(), &cpumask));
+ get_online_cpus_atomic();
cpumask_and(&tmp, &cpumask, cpu_online_mask);
BUG_ON(!cpumask_equal(&cpumask, &tmp));
@@ -134,6 +136,7 @@ static void flush_tlb_others(cpumask_t cpumask, struct mm_struct *mm,
flush_mm = NULL;
flush_va = 0;
spin_unlock(&tlbstate_lock);
+ put_online_cpus_atomic();
}
/**
@@ -144,7 +147,7 @@ void flush_tlb_mm(struct mm_struct *mm)
{
cpumask_t cpu_mask;
- preempt_disable();
+ get_online_cpus_atomic();
cpumask_copy(&cpu_mask, mm_cpumask(mm));
cpumask_clear_cpu(smp_processor_id(), &cpu_mask);
@@ -152,7 +155,7 @@ void flush_tlb_mm(struct mm_struct *mm)
if (!cpumask_empty(&cpu_mask))
flush_tlb_others(cpu_mask, mm, FLUSH_ALL);
- preempt_enable();
+ put_online_cpus_atomic();
}
/**
@@ -163,7 +166,7 @@ void flush_tlb_current_task(void)
struct mm_struct *mm = current->mm;
cpumask_t cpu_mask;
- preempt_disable();
+ get_online_cpus_atomic();
cpumask_copy(&cpu_mask, mm_cpumask(mm));
cpumask_clear_cpu(smp_processor_id(), &cpu_mask);
@@ -171,7 +174,7 @@ void flush_tlb_current_task(void)
if (!cpumask_empty(&cpu_mask))
flush_tlb_others(cpu_mask, mm, FLUSH_ALL);
- preempt_enable();
+ put_online_cpus_atomic();
}
/**
@@ -184,7 +187,7 @@ void flush_tlb_page(struct vm_area_struct *vma, unsigned long va)
struct mm_struct *mm = vma->vm_mm;
cpumask_t cpu_mask;
- preempt_disable();
+ get_online_cpus_atomic();
cpumask_copy(&cpu_mask, mm_cpumask(mm));
cpumask_clear_cpu(smp_processor_id(), &cpu_mask);
@@ -192,7 +195,7 @@ void flush_tlb_page(struct vm_area_struct *vma, unsigned long va)
if (!cpumask_empty(&cpu_mask))
flush_tlb_others(cpu_mask, mm, va);
- preempt_enable();
+ put_online_cpus_atomic();
}
/**
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox