* [PATCH v4] ARM: cache-l2x0: add resume entry for l2 in secure mode
From: Russell King - ARM Linux @ 2011-10-01 15:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1317375773-7229-1-git-send-email-Barry.Song@csr.com>
On Fri, Sep 30, 2011 at 02:42:53AM -0700, Barry Song wrote:
> From: Barry Song <Baohua.Song@csr.com>
>
> we save the l2x0 registers at the first initialization, and platform codes
> can get them to restore l2x0 status after wakeup.
>
> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> Signed-off-by: Barry Song <Baohua.Song@csr.com>
> Reviewed-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> Tested-by: Shawn Guo <shawn.guo@linaro.org>
This looks fine, thanks Barry.
The one remaining issue is whether we use this or use Lorenzo's patches.
I feel that Barry's version is a lot simpler and easier to use, so this
is my preference. Anyone else got another opinion between the two?
^ permalink raw reply
* [PATCH v4 3/7] arm/imx: add gic_handle_irq function
From: Russell King - ARM Linux @ 2011-10-01 15:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110929140804.GJ19318@S2100-06.ap.freescale.net>
On Thu, Sep 29, 2011 at 10:08:05PM +0800, Shawn Guo wrote:
> Can you please share your position on Marc's PPI and GIC
> MULTI_IRQ_HANDLER series? Are you possibly going to merge them in the
> coming merge window? If you are, I would directly move my imx6q onto
> those series and save the local gic_handle_irq(). Otherwise, I may
> have to add a wrapper for do_IPI() and do_local_timer() to work around
> the pt_regs issue you pointed out here.
My personal opinion of Marc's PPI patches hasn't changed: I think
integrating them into genirq just makes the whole thing a lot more
complicated (and error-prone) than it otherwise needs to be.
For example, it is completely invalid to call any of the existing
genirq APIs for a PPI interrupt, because there is no sane way to ensure
that the intended CPU is targetted - unless we're operating from a thread
which is bound specifically to a single CPU.
However, Marc has been working with Thomas to produce something more
generic (and not ARM specific) and I don't have an opinion on that.
This addresses the issues (like the one I mention above) but I've not
been following it any further than that.
^ permalink raw reply
* [PATCH 1/2] ARM: CLKDEV: Add Common Macro for clk_lookup
From: Russell King - ARM Linux @ 2011-10-01 15:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1317381097-2691-2-git-send-email-padma.v@samsung.com>
On Fri, Sep 30, 2011 at 04:41:36PM +0530, Padmavathi Venna wrote:
> +#define CLKDEV_INIT(d, n, c) \
> + { \
> + .dev_id = d, \
> + .con_id = n, \
> + .clk = &c, \
> + },
> +
As Heartley says, the trailing , and the end should not be there - it
should be with each use of CLKDEV_INIT(). The reasoning is that it
makes the use of macros much more conventional and consistent throughout
the kernel:
struct cl_lookup foo_lookups[] = {
CLKDEV_INIT(...),
CLKDEV_INIT(...),
};
struct cl_lookup bar_lookup = CLKDEV_INIT(...);
Could you re-spin with that change please?
Thanks.
^ permalink raw reply
* [PATCH 2/2] ARM: Switch to using CLKDEV_INIT macro for creating clk_lookup instance
From: Russell King - ARM Linux @ 2011-10-01 15:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110930112633.GB9046@local>
On Fri, Sep 30, 2011 at 01:26:33PM +0200, Hans J. Koch wrote:
> On Fri, Sep 30, 2011 at 04:41:37PM +0530, Padmavathi Venna wrote:
> > Replace platform specific macros that creates struct clk_lookup
> > instance with the new common CLKDEV_INIT macro
>
> Well, for mach-tcc8k, it only saves 7 lines, but it's surely a good idea to
> have one common macro for all arm subarchs.
The savings are of course likely to be small, but it had two advantages:
1. We're not having one initializer per platform or SoC
2. We have something common which can be grepped for, or sed'd (or whatever
your favourite in-place editing program) should it need to be changed.
^ permalink raw reply
* [GIT PULL] ux500-timers
From: Arnd Bergmann @ 2011-10-01 16:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201109302228.46572.arnd@arndb.de>
On Friday 30 September 2011 22:28:46 Arnd Bergmann wrote:
>
> > The following changes since commit d93dc5c4478c1fd5de85a3e8aece9aad7bbae044:
> >
> > Linux 3.1-rc7 (2011-09-21 16:58:15 -0700)
> >
> > are available in the git repository at:
> > git://git.linaro.org/people/triad/linux-stericsson.git ux500-nomadik-timers
>
> pulled into a new top-level next/timer branch.
Hi Linus,
It caused a few build regressions:
- missing include of errno.h
- clksrc_dbx500_prcmu_init stub needs to be static inline, or it causes a
link failure.
- clksrc_dbx500_timer_base may be initialized when it's not actually linked in
For the last one, I think it would actually be best to make the timer
a platform_device and pass the address in platform_data or device tree
property, or alternatively make it an argument to clksrc_dbx500_prcmu_init
and make the variable static.
Please send a new pull request with these things fixed, either with
patches on top or replacing the original ones, whichever you prefer.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
diff --git a/arch/arm/mach-ux500/timer.c b/arch/arm/mach-ux500/timer.c
index 08c55a5..fbbbe0b 100644
--- a/arch/arm/mach-ux500/timer.c
+++ b/arch/arm/mach-ux500/timer.c
@@ -5,6 +5,7 @@
* Author: Mattias Wallin <mattias.wallin@stericsson.com> for ST-Ericsson
*/
#include <linux/io.h>
+#include <linux/errno.h>
#include <linux/clksrc-dbx500-prcmu.h>
#include <asm/localtimer.h>
@@ -14,6 +15,8 @@
#include <mach/setup.h>
#include <mach/hardware.h>
+void __iomem *clksrc_dbx500_timer_base;
+
static void __init ux500_timer_init(void)
{
if (cpu_is_u5500()) {
diff --git a/drivers/clocksource/clksrc-dbx500-prcmu.c b/drivers/clocksource/clksrc-dbx500-prcmu.c
index 0ac5093..d5f7847 100644
--- a/drivers/clocksource/clksrc-dbx500-prcmu.c
+++ b/drivers/clocksource/clksrc-dbx500-prcmu.c
@@ -31,8 +31,6 @@
#define SCHED_CLOCK_MIN_WRAP 131072 /* 2^32 / 32768 */
-void __iomem *clksrc_dbx500_timer_base;
-
static cycle_t clksrc_dbx500_prcmu_read(struct clocksource *cs)
{
u32 count, count2;
diff --git a/include/linux/clksrc-dbx500-prcmu.h b/include/linux/clksrc-dbx500-prcmu.h
index d1e9504..9f733cb 100644
--- a/include/linux/clksrc-dbx500-prcmu.h
+++ b/include/linux/clksrc-dbx500-prcmu.h
@@ -16,7 +16,7 @@ extern void __iomem *clksrc_dbx500_timer_base;
#ifdef CONFIG_CLKSRC_DBX500_PRCMU
void __init clksrc_dbx500_prcmu_init(void);
#else
-void __init clksrc_dbx500_prcmu_init(void) {}
+static inline void __init clksrc_dbx500_prcmu_init(void) {}
#endif
#endif
^ permalink raw reply related
* [PATCH 1/4] mmc: mmci: Bugfix in pio read for small packets
From: Russell King - ARM Linux @ 2011-10-01 16:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1317109568-17905-1-git-send-email-ulf.hansson@stericsson.com>
On Tue, Sep 27, 2011 at 09:46:08AM +0200, Ulf Hansson wrote:
> From: Stefan Nilsson XK <stefan.xk.nilsson@stericsson.com>
>
> Corrects a bug in pio read when reading packets < 4 bytes. These
> small packets are only relevant for SDIO transfers.
Does this even work? From the MMCI spec, I see no way for the MMCI
peripheral to know the size of the read/write on the APB bus.
The APB bus signals the MMCI uses are:
PCLK - APB bus clock
PRESETn - APB bus reset
PADDR[11:2] - APB bus address
PSEL - APB bus peripheral select
PENABLE - APB bus enable
PWRITE - APB bus write signal
PWDATA[31:0] - APB bus write data
PRDATA[31:0] - APB bus read data
As you can see, nothing in that set indicates whether it's an 8-bit,
16-bit or 32-bit access.
Moreover, if you read the MMCIFifoCnt register writeup:
The MMCIFifoCnt register contains the remaining number of words to be
written to or read from the FIFO. The FIFO counter loads the value
from the data length register (see Data length register, MMCIDataLength
on page 3-11) when the Enable bit is set in the data control register.
If the data length is not word aligned (multiple of 4), the remaining
1 to 3 bytes are regarded as a word.
This suggests that we should be reading a 32-bit word and then storing
the relevant bytes from it.
The other thing which concerns me is that the MMCI (ARM Ltd one at least)
only supports power-of-two block sizes. So requesting a transfer of a
single block with a block size of 3 bytes is not supported by the ARM Ltd
MMCI. (The way you end up with 1 to 3 bytes being received with ARM's
MMCI is if you're using a streaming transfer.)
The last thing I don't like about this patch is that this code is in a
really hot path - one which is absolutely critical for things to work -
and the need for the condition to be dealt with is only at the end of a
transfer, not each time the FIFO needs emptying.
Bear in mind that there are platforms with the ARM MMCI which must read
the data within a certain time or suffer overruns, and which have either
totally broken and useless DMA or no DMA capability at all (which are
the only platforms I have with a MMCI on.)
^ permalink raw reply
* [PATCH 4/4] mmc: mmci: Fix incorrect handling of HW flow control for SDIO
From: Russell King - ARM Linux @ 2011-10-01 16:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1317109616-18010-1-git-send-email-ulf.hansson@stericsson.com>
On Tue, Sep 27, 2011 at 09:46:56AM +0200, Ulf Hansson wrote:
> /* The ST Micro variants has a special bit to enable SDIO */
> if (variant->sdio && host->mmc->card)
> - if (mmc_card_sdio(host->mmc->card))
> + if (mmc_card_sdio(host->mmc->card)) {
> + /*
> + * The ST Micro variants has a special bit
> + * to enable SDIO.
> + */
> datactrl |= MCI_ST_DPSM_SDIOEN;
>
> + /*
> + * The ST Micro variant for SDIO transfer sizes
> + * less then or equal to 8 bytes needs to have clock
> + * H/W flow control disabled. Since flow control is
> + * not really needed for anything that fits in the
> + * FIFO, we can disable it for any write smaller
> + * than the FIFO size.
> + */
> + if ((host->size <= variant->fifosize) &&
> + (data->flags & MMC_DATA_WRITE))
> + writel(readl(host->base + MMCICLOCK) &
> + ~variant->clkreg_enable,
> + host->base + MMCICLOCK);
> + else
> + writel(readl(host->base + MMCICLOCK) |
> + variant->clkreg_enable,
> + host->base + MMCICLOCK);
> + }
Shouldn't this also re-enable the ST hardware flow control for non-SDIO
cards?
^ permalink raw reply
* nr_cpus cmdline parameter not working
From: Russell King - ARM Linux @ 2011-10-01 16:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1317224117.2580.84.camel@deneb.redhat.com>
On Wed, Sep 28, 2011 at 11:35:16AM -0400, Mark Salter wrote:
> I noticed that nr_cpus=1 doesn't appear to have any effect on a
> pandaboard (and probably others from the looks of things). This
> changes seems to be needed, but I'm not really sure if this is
> the right thing or not.
>
> diff --git a/arch/arm/mach-omap2/omap-smp.c b/arch/arm/mach-omap2/omap-smp.c
> index ce65e93..a1198ac 100644
> --- a/arch/arm/mach-omap2/omap-smp.c
> +++ b/arch/arm/mach-omap2/omap-smp.c
> @@ -117,6 +117,9 @@ void __init smp_init_cpus(void)
> ncores = NR_CPUS;
> }
>
> + if (ncores > nr_cpu_ids)
> + ncores = nr_cpu_ids;
> +
This potentially affects all SMP platforms, so the patch needs to be
bigger than this.
Also, I think the test above should be modified to use nr_cpu_ids
rather than NR_CPUS, to be inline with what x86 does:
/* nr_cpu_ids could be reduced via nr_cpus= */
if (possible > nr_cpu_ids) {
printk(KERN_WARNING
"%d Processors exceeds NR_CPUS limit of %d\n",
possible, nr_cpu_ids);
possible = nr_cpu_ids;
}
(This is essentially the same check that we're doing.)
Could you have a look at this and cook up another patch covering the
other SMP platforms please?
Thanks.
^ permalink raw reply
* [PATCH] Add missing include of linux/ftrace.h
From: Russell King - ARM Linux @ 2011-10-01 16:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1317309202-1001-1-git-send-email-jamie@jamieiles.com>
On Thu, Sep 29, 2011 at 04:13:22PM +0100, Jamie Iles wrote:
> __exception_irq_entry uses __irq_entry which is defined in
> linux/ftrace.h.
>
> Reported-by: Zoltan Devai <zdevai@gmail.com>
> Cc: Rabin Vincent <rabin@rab.in>
> Signed-off-by: Jamie Iles <jamie@jamieiles.com>
This introduces a circular dependency:
linux/ftrace.h -> linux/kallsyms.h -> linux/kernel.h -> linux/bitops.h
-> asm/bitops.h -> asm/system.h -> linux/ftrace.h
This is not good as it means that we end up with indeterminant effects
happening depending on where in that cycle the first include happens.
^ permalink raw reply
* [PATCH] ARM: localtimer: add header linux/errno.h explicitly
From: Russell King - ARM Linux @ 2011-10-01 16:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110930020208.GA19807@S2100-06.ap.freescale.net>
On Fri, Sep 30, 2011 at 10:02:10AM +0800, Shawn Guo wrote:
> Hi Russell,
>
> Do you have any comment on this patch? Otherwise, I will put it into
> patch tracker.
Only that the include should be towards the top of the file rather
than conditionally included. That avoids potential surprise compile
errors caused by changes in configuration. (Ok, you may argue that
they shouldn't happen but with the amount of includes we have it's
very difficult to ensure that everything explicitly includes everything
it actually needs.)
^ permalink raw reply
* [PATCH v2 0/5] ARM: pxa: move gpio driver into drivers directory
From: Russell King - ARM Linux @ 2011-10-01 16:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1317377960-11063-1-git-send-email-haojian.zhuang@marvell.com>
On Fri, Sep 30, 2011 at 06:19:15PM +0800, Haojian Zhuang wrote:
> Changelog:
> v2:
> 1. Remove gpio.c from mach-pxa & mach-mmp that is introduced from v1.
> 2. Remove init function in gpio.c. Move the platfrom_device_register()
> into platform driver.
> 3. Initialize pxa_gpio_regs in gpio-pxa.c
> 4. Simplify code of identifing pxa gpio series or mmp gpio series.
> 5. Use linux/io.h instead of asm/io.h.
This series looks fine to me. You don't mention what it's based upon -
should I assume my gpio patch series? If so, it looks fine to be
submitted to the patch system.
It would be nice to have a few acks from people against it first though.
Thanks.
^ permalink raw reply
* [GIT PULL] dmtimer changes for v3.2 merge window
From: Arnd Bergmann @ 2011-10-01 16:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201109302213.42435.arnd@arndb.de>
On Friday 30 September 2011 22:13:42 Arnd Bergmann wrote:
> On Thursday 29 September 2011, Tony Lindgren wrote:
> > Please pull omap dmtimer changes from:
> >
> > git://github.com/tmlind/linux.git dmtimer
> >
> > This series completes the system timer separation from the
> > driver like features. It also adds support for v2 ip that is
> > available for some timers starting with omap4.
> >
> > After this series arch/arm/plat-omap/dmtimer.c could be
> > moved to live under drivers somewhere, but there is still
> > discussion going on which features should be supported in
> > a generic way.
> >
> > This series depends on the cleanup you pulled earlier.
> > As this series adds some new features like runtime PM suppport,
> > I've kept it separate from cleanup.
>
> Looks really nice. I've put it into another top-level branch
> named next/dmtimer for now. I'm open for suggestions on whether
> I should generally push branches like this separately Linuswards
> or better aggregate multiple standalone features into a single
> branch.
I'm adding the patch below to fix a trivial randconfig build regression
in this series.
Arnd
8<---
Subject: [PATCH] ARM: omap: use __devexit_p in dmtimer driver
The omap_dm_timer_remove function gets discarded when
CONFIG_HOTPLUG is not set, so we must not reference it
unconditionally.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c
index de7896f..2def4e1 100644
--- a/arch/arm/plat-omap/dmtimer.c
+++ b/arch/arm/plat-omap/dmtimer.c
@@ -723,7 +723,7 @@ static int __devexit omap_dm_timer_remove(struct platform_device *pdev)
static struct platform_driver omap_dm_timer_driver = {
.probe = omap_dm_timer_probe,
- .remove = omap_dm_timer_remove,
+ .remove = __devexit_p(omap_dm_timer_remove),
.driver = {
.name = "omap_timer",
},
^ permalink raw reply related
* [RFC PATCH 0/3] ARM: amba: defining module aliases for AMBA driver autoloading
From: Russell King - ARM Linux @ 2011-10-01 16:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1317401802-24362-1-git-send-email-dave.martin@linaro.org>
On Fri, Sep 30, 2011 at 05:56:39PM +0100, Dave Martin wrote:
> Issues:
>
> * Do new module alises need to be globally agreed/registered
> somewhere?
I don't think there is. Having the bus prefix in there is definitely a
good thing.
> * Because a driver's ID table is in match-and-mask format whereas
> udev uses string pattern matching, we effectively have to
> maintain two ID tables per driver, containing the same
> information in different formats. The patch to mmci.c gives an
> example.
>
> I predict that maintenance of those duplicated tables will be
> somewhat painful and error-prone. However, the necessary
> transformations, while simple, are beyond the scope of the C
> preprocessor.
>
> In order to avoid this duplication of information, an extra
> (but simple) bit of build-time infrastructure would be needed.
>
> I think this effort would be worth it -- does anyone have
> strong views on this?
I think there is some support for udev to use PCI ID tables directly.
I don't know how that works - I suspect it requires module tools
support though. Might be worth investigating.
^ permalink raw reply
* [PATCH v2 0/5] ARM: pxa: move gpio driver into drivers directory
From: Russell King - ARM Linux @ 2011-10-01 16:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111001164241.GK11710@n2100.arm.linux.org.uk>
On Sat, Oct 01, 2011 at 05:42:41PM +0100, Russell King - ARM Linux wrote:
> On Fri, Sep 30, 2011 at 06:19:15PM +0800, Haojian Zhuang wrote:
> > Changelog:
> > v2:
> > 1. Remove gpio.c from mach-pxa & mach-mmp that is introduced from v1.
> > 2. Remove init function in gpio.c. Move the platfrom_device_register()
> > into platform driver.
> > 3. Initialize pxa_gpio_regs in gpio-pxa.c
> > 4. Simplify code of identifing pxa gpio series or mmp gpio series.
> > 5. Use linux/io.h instead of asm/io.h.
>
> This series looks fine to me. You don't mention what it's based upon -
> should I assume my gpio patch series? If so, it looks fine to be
> submitted to the patch system.
>
> It would be nice to have a few acks from people against it first though.
I assume this clashes with patches 7103/1 and 7104/1 in the patch system.
Should I ignore those two for the meantime?
^ permalink raw reply
* [PATCH] Add missing include of linux/ftrace.h
From: Jamie Iles @ 2011-10-01 17:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111001163511.GI11710@n2100.arm.linux.org.uk>
On Sat, Oct 01, 2011 at 05:35:11PM +0100, Russell King - ARM Linux wrote:
> On Thu, Sep 29, 2011 at 04:13:22PM +0100, Jamie Iles wrote:
> > __exception_irq_entry uses __irq_entry which is defined in
> > linux/ftrace.h.
> >
> > Reported-by: Zoltan Devai <zdevai@gmail.com>
> > Cc: Rabin Vincent <rabin@rab.in>
> > Signed-off-by: Jamie Iles <jamie@jamieiles.com>
>
> This introduces a circular dependency:
>
> linux/ftrace.h -> linux/kallsyms.h -> linux/kernel.h -> linux/bitops.h
> -> asm/bitops.h -> asm/system.h -> linux/ftrace.h
>
> This is not good as it means that we end up with indeterminant effects
> happening depending on where in that cycle the first include happens.
Crap. I don't think having users of __exception_irq_entry include
linux/ftrace.h is great, so how about this instead?
Jamie
8<----
From: Jamie Iles <jamie@jamieiles.com>
Subject: [PATCH] move __exception and friends to asm/exception.h
The definition of __exception_irq_entry for
CONFIG_FUNCTION_GRAPH_TRACER=y needs linux/ftrace.h, but this creates a
circular dependency with it's current home in asm/system.h. Create
asm/exception.h and update all current users.
Reported-by: Zoltan Devai <zdevai@gmail.com>
Signed-off-by: Jamie Iles <jamie@jamieiles.com>
---
arch/arm/include/asm/exception.h | 13 +++++++++++++
arch/arm/include/asm/system.h | 7 -------
arch/arm/kernel/irq.c | 1 +
arch/arm/kernel/smp.c | 1 +
arch/arm/kernel/traps.c | 1 +
arch/arm/mach-pxa/irq.c | 2 ++
arch/arm/mm/fault.c | 1 +
7 files changed, 19 insertions(+), 7 deletions(-)
create mode 100644 arch/arm/include/asm/exception.h
diff --git a/arch/arm/include/asm/exception.h b/arch/arm/include/asm/exception.h
new file mode 100644
index 0000000..7d6fd97
--- /dev/null
+++ b/arch/arm/include/asm/exception.h
@@ -0,0 +1,13 @@
+#ifndef __ASM_ARM_EXCEPTION_H
+#define __ASM_ARM_EXCEPTION_H
+
+#include <linux/ftrace.h>
+
+#define __exception __attribute__((section(".exception.text")))
+#ifdef CONFIG_FUNCTION_GRAPH_TRACER
+#define __exception_irq_entry __irq_entry
+#else
+#define __exception_irq_entry __exception
+#endif
+
+#endif /* __ASM_ARM_EXCEPTION_H */
diff --git a/arch/arm/include/asm/system.h b/arch/arm/include/asm/system.h
index 832888d..ed6b049 100644
--- a/arch/arm/include/asm/system.h
+++ b/arch/arm/include/asm/system.h
@@ -62,13 +62,6 @@
#include <asm/outercache.h>
-#define __exception __attribute__((section(".exception.text")))
-#ifdef CONFIG_FUNCTION_GRAPH_TRACER
-#define __exception_irq_entry __irq_entry
-#else
-#define __exception_irq_entry __exception
-#endif
-
struct thread_info;
struct task_struct;
diff --git a/arch/arm/kernel/irq.c b/arch/arm/kernel/irq.c
index de3dcab..61c1468 100644
--- a/arch/arm/kernel/irq.c
+++ b/arch/arm/kernel/irq.c
@@ -37,6 +37,7 @@
#include <linux/proc_fs.h>
#include <linux/ftrace.h>
+#include <asm/exception.h>
#include <asm/system.h>
#include <asm/mach/arch.h>
#include <asm/mach/irq.h>
diff --git a/arch/arm/kernel/smp.c b/arch/arm/kernel/smp.c
index d88ff02..1122faf 100644
--- a/arch/arm/kernel/smp.c
+++ b/arch/arm/kernel/smp.c
@@ -31,6 +31,7 @@
#include <asm/cacheflush.h>
#include <asm/cpu.h>
#include <asm/cputype.h>
+#include <asm/exception.h>
#include <asm/mmu_context.h>
#include <asm/pgtable.h>
#include <asm/pgalloc.h>
diff --git a/arch/arm/kernel/traps.c b/arch/arm/kernel/traps.c
index bc9f9da..2103825 100644
--- a/arch/arm/kernel/traps.c
+++ b/arch/arm/kernel/traps.c
@@ -27,6 +27,7 @@
#include <linux/atomic.h>
#include <asm/cacheflush.h>
+#include <asm/exception.h>
#include <asm/system.h>
#include <asm/unistd.h>
#include <asm/traps.h>
diff --git a/arch/arm/mach-pxa/irq.c b/arch/arm/mach-pxa/irq.c
index b09e848..ca60757 100644
--- a/arch/arm/mach-pxa/irq.c
+++ b/arch/arm/mach-pxa/irq.c
@@ -19,6 +19,8 @@
#include <linux/io.h>
#include <linux/irq.h>
+#include <asm/exception.h>
+
#include <mach/hardware.h>
#include <mach/irqs.h>
#include <mach/gpio.h>
diff --git a/arch/arm/mm/fault.c b/arch/arm/mm/fault.c
index 3b5ea68..aa33949 100644
--- a/arch/arm/mm/fault.c
+++ b/arch/arm/mm/fault.c
@@ -20,6 +20,7 @@
#include <linux/highmem.h>
#include <linux/perf_event.h>
+#include <asm/exception.h>
#include <asm/system.h>
#include <asm/pgtable.h>
#include <asm/tlbflush.h>
--
1.7.4.1
^ permalink raw reply related
* [PATCH] Add platform driver support to the CS890x driver
From: Russell King - ARM Linux @ 2011-10-01 17:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGzjT4fkjs7j=a0P=EcPcx-KJpZsMy=cmpYd2STO3Mk8yhoT_Q@mail.gmail.com>
On Fri, Sep 30, 2011 at 11:01:10AM +0200, Jaccon Bastiaansen wrote:
> Hello Domenico,
>
> 2011/9/28 Domenico Andreoli <cavokz@gmail.com>:
> > Hi Jaccon,
> >
> > On Mon, Sep 12, 2011 at 12:52:52PM +0200, Jaccon Bastiaansen wrote:
> >>
> >> Ok, so you would like to see the #ifdefs for the IXDP2351, IXDP2X01,
> >> QQ2440 and MX31ADS in the cs890x driver replaced by platform_device
> >> definitions in the platform specific code of those platforms (in the
> >> same way as I have done for the i.MX21ADS platform)? Is this correct?
> >
> > Feel free to completely dump the QQ2440 thing, the QQ2440 board support
> > is not in mainline and will not until it can be implemented mostly with
> > DT, I guess. ?At that time I will be happy to use your platform device
> > conversion - with the OF initialization that sombody will write ;)
I don't have Domenico's original mail...
The QQ2440 thing got submitted into the patch system while the consolidation
push was going on earlier in the year, so I ignored it (along with the other
platforms which people submitted without regard to Linus' rant.)
It's now up to the SoC maintainers whether they want to accept this stuff,
and if so how to get it into mainline (probably via Arnd) - be that in
their current form or if they think that a DT based implementation is
better.
I'll be discarding the four 'new' platforms (of which QQ2440 is one) which
have been sitting in the patch system since March in the next few days.
^ permalink raw reply
* [PATCH] Add missing include of linux/ftrace.h
From: Russell King - ARM Linux @ 2011-10-01 17:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111001171202.GA13684@gallagher>
On Sat, Oct 01, 2011 at 06:12:02PM +0100, Jamie Iles wrote:
> On Sat, Oct 01, 2011 at 05:35:11PM +0100, Russell King - ARM Linux wrote:
> > On Thu, Sep 29, 2011 at 04:13:22PM +0100, Jamie Iles wrote:
> > > __exception_irq_entry uses __irq_entry which is defined in
> > > linux/ftrace.h.
> > >
> > > Reported-by: Zoltan Devai <zdevai@gmail.com>
> > > Cc: Rabin Vincent <rabin@rab.in>
> > > Signed-off-by: Jamie Iles <jamie@jamieiles.com>
> >
> > This introduces a circular dependency:
> >
> > linux/ftrace.h -> linux/kallsyms.h -> linux/kernel.h -> linux/bitops.h
> > -> asm/bitops.h -> asm/system.h -> linux/ftrace.h
> >
> > This is not good as it means that we end up with indeterminant effects
> > happening depending on where in that cycle the first include happens.
>
> Crap. I don't think having users of __exception_irq_entry include
> linux/ftrace.h is great, so how about this instead?
This looks much better - and won't involve any circular dependencies.
It might be worth adding a comment in the new header file that this
should only be used on functions called from the low level entry code
and not from intervening C code.
Finally, could you stick it in the patch system please?
Thanks.
^ permalink raw reply
* [PATCH] Add missing include of linux/ftrace.h
From: Rabin Vincent @ 2011-10-01 19:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111001171202.GA13684@gallagher>
On Sat, Oct 1, 2011 at 22:42, Jamie Iles <jamie@jamieiles.com> wrote:
> diff --git a/arch/arm/kernel/irq.c b/arch/arm/kernel/irq.c
> index de3dcab..61c1468 100644
> --- a/arch/arm/kernel/irq.c
> +++ b/arch/arm/kernel/irq.c
> @@ -37,6 +37,7 @@
> ?#include <linux/proc_fs.h>
> ?#include <linux/ftrace.h>
You can probably git rid of this inclusion of ftrace.h from
here and from smp.c, because they were added only for
__exception_irq_entry.
>
> +#include <asm/exception.h>
> ?#include <asm/system.h>
> ?#include <asm/mach/arch.h>
> ?#include <asm/mach/irq.h>
^ permalink raw reply
* [PATCH 00/11] Generic ARM fixes for randconfig
From: Arnd Bergmann @ 2011-10-01 19:21 UTC (permalink / raw)
To: linux-arm-kernel
Hi Russell,
This is a set of patches that I've been sitting on for a while
without ever getting them ready for inclusion. Out of the total
~150 patches I have to make 'make randconfig' work for a
number of ARM platforms, these are the ones that mostly for
common code within the ARM architecture.
I've now started going through the whole set and split them up
by topic so I can reduce the number of patches that are required.
Please pull these into your tree, or alternatively cherry-pick the
ones that you are happy with if you disagree with some of them.
This branch is available from
git pull git://git.linaro.org/people/arnd/arm-soc.git randconfig/arm
For reference, I have another branch "for-next+randconfig" that
contains my entire set of patches merged with the arm-soc for-next
branch, and the individual branches are available at
git://git.linaro.org/people/arnd/linux.git
Arnd Bergmann (11):
ARM: export rtc_lock for nvram driver
ARM: SMP depends on MMU
ARM: always use ARM_UNWIND for thumb2 kernels
ARM: allow building alignment.c without PROC_FS
ARM: vfp: use -mfloat-abi=soft to build vfp
ARM: pm: let platforms select cpu_suspend support
ARM: limit CONFIG_HAVE_IDE to platforms that do
ARM: add io{read,write}{16,32}be functions
ARM: pci: always export pcibios_bus_to_resource
ARM: OC_ETM should not select ARM_AMBA
ARM: common/vic: use proper __iomem annotations
arch/arm/Kconfig | 12 +++++++++++-
arch/arm/Kconfig.debug | 2 +-
arch/arm/common/vic.c | 3 ++-
arch/arm/include/asm/io.h | 6 ++++++
arch/arm/kernel/Makefile | 2 +-
arch/arm/kernel/bios32.c | 9 ++++-----
arch/arm/kernel/time.c | 6 ++----
arch/arm/mach-exynos4/Kconfig | 1 +
arch/arm/mach-omap2/Kconfig | 2 ++
arch/arm/mm/alignment.c | 20 ++++++++++----------
arch/arm/mm/proc-v7.S | 2 +-
arch/arm/plat-omap/Kconfig | 1 +
arch/arm/vfp/Makefile | 2 +-
lib/Kconfig.debug | 4 ++--
14 files changed, 45 insertions(+), 27 deletions(-)
--
1.7.5.4
^ permalink raw reply
* [PATCH 01/11] ARM: export rtc_lock for nvram driver
From: Arnd Bergmann @ 2011-10-01 19:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1317496920-7764-1-git-send-email-arnd@arndb.de>
The rtc_lock is used by both the nvram and rtc drivers, so
we need to export it if at least one of the two is built,
not just for the rtc driver.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
arch/arm/kernel/time.c | 6 ++----
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/arch/arm/kernel/time.c b/arch/arm/kernel/time.c
index cb634c3..5a54b95 100644
--- a/arch/arm/kernel/time.c
+++ b/arch/arm/kernel/time.c
@@ -39,13 +39,11 @@
*/
static struct sys_timer *system_timer;
-#if defined(CONFIG_RTC_DRV_CMOS) || defined(CONFIG_RTC_DRV_CMOS_MODULE)
+#if defined(CONFIG_RTC_DRV_CMOS) || defined(CONFIG_RTC_DRV_CMOS_MODULE) || \
+ defined(CONFIG_NVRAM) || defined(CONFIG_NVRAM_MODULE)
/* this needs a better home */
DEFINE_SPINLOCK(rtc_lock);
-
-#ifdef CONFIG_RTC_DRV_CMOS_MODULE
EXPORT_SYMBOL(rtc_lock);
-#endif
#endif /* pc-style 'CMOS' RTC support */
/* change this if you have some constant time drift */
--
1.7.5.4
^ permalink raw reply related
* [PATCH 02/11] ARM: SMP depends on MMU
From: Arnd Bergmann @ 2011-10-01 19:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1317496920-7764-1-git-send-email-arnd@arndb.de>
The SMP implementation on ARM heavily depends on MMU-only code.
As long as nobody is interested in fixing this, let's disable the
SMP option when building for nommu.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
arch/arm/Kconfig | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 5ebc5d9..4e1eee0c 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1349,6 +1349,7 @@ config SMP
MACH_REALVIEW_PB11MP || MACH_REALVIEW_PBX || ARCH_OMAP4 || \
ARCH_EXYNOS4 || ARCH_TEGRA || ARCH_U8500 || ARCH_VEXPRESS_CA9X4 || \
ARCH_MSM_SCORPIONMP || ARCH_SHMOBILE
+ depends on MMU
select USE_GENERIC_SMP_HELPERS
select HAVE_ARM_SCU if !ARCH_MSM_SCORPIONMP
help
--
1.7.5.4
^ permalink raw reply related
* [PATCH 03/11] ARM: always use ARM_UNWIND for thumb2 kernels
From: Arnd Bergmann @ 2011-10-01 19:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1317496920-7764-1-git-send-email-arnd@arndb.de>
Thumb2 kernels cannot be built with frame pointers, but can use the
ARM_UNWIND feature for unwinding instead. This makes sure that all
features that rely on unwinding includeing CONFIG_LATENCYTOP and
FAULT_INJECTION_STACKTRACE_FILTER do not enable frame pointers
when the unwinder is already selected, and we always build with
the unwinder when we want a thumb2 kernel, to make sure we do not
get the frame pointers instead.
A different option would be to redefine the CONFIG_FRAME_POINTERS
option on ARM to mean builing with either frame pointers or
the unwinder, and then select which one to use based on the
CPU architecture or another user option. That would still allow
building thumb2 kernels without the unwinder but would also be
more confusing.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
arch/arm/Kconfig | 1 +
lib/Kconfig.debug | 4 ++--
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 4e1eee0c..497af51 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1457,6 +1457,7 @@ config THUMB2_KERNEL
depends on CPU_V7 && !CPU_V6 && !CPU_V6K && EXPERIMENTAL
select AEABI
select ARM_ASM_UNIFIED
+ select ARM_UNWIND
help
By enabling this option, the kernel will be compiled in
Thumb-2 mode. A compiler/assembler that understand the unified
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index c0cb9c4..103c171 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -1081,7 +1081,7 @@ config FAULT_INJECTION_STACKTRACE_FILTER
depends on FAULT_INJECTION_DEBUG_FS && STACKTRACE_SUPPORT
depends on !X86_64
select STACKTRACE
- select FRAME_POINTER if !PPC && !S390 && !MICROBLAZE
+ select FRAME_POINTER if !PPC && !S390 && !MICROBLAZE && !ARM_UNWIND
help
Provide stacktrace filter for fault-injection capabilities
@@ -1091,7 +1091,7 @@ config LATENCYTOP
depends on DEBUG_KERNEL
depends on STACKTRACE_SUPPORT
depends on PROC_FS
- select FRAME_POINTER if !MIPS && !PPC && !S390 && !MICROBLAZE
+ select FRAME_POINTER if !MIPS && !PPC && !S390 && !MICROBLAZE && !ARM_UNWIND
select KALLSYMS
select KALLSYMS_ALL
select STACKTRACE
--
1.7.5.4
^ permalink raw reply related
* [PATCH 04/11] ARM: allow building alignment.c without PROC_FS
From: Arnd Bergmann @ 2011-10-01 19:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1317496920-7764-1-git-send-email-arnd@arndb.de>
The two functions cpu_is_v6_unaligned and safe_usermode
are only defined when CONFIG_PROC_FS is enabled, but
are used outside of the #ifdef.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Dave Martin <dave.martin@linaro.org>
---
arch/arm/mm/alignment.c | 20 ++++++++++----------
1 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mm/alignment.c b/arch/arm/mm/alignment.c
index cfbcf8b..c335c76 100644
--- a/arch/arm/mm/alignment.c
+++ b/arch/arm/mm/alignment.c
@@ -86,16 +86,6 @@ core_param(alignment, ai_usermode, int, 0600);
#define UM_FIXUP (1 << 1)
#define UM_SIGNAL (1 << 2)
-#ifdef CONFIG_PROC_FS
-static const char *usermode_action[] = {
- "ignored",
- "warn",
- "fixup",
- "fixup+warn",
- "signal",
- "signal+warn"
-};
-
/* Return true if and only if the ARMv6 unaligned access model is in use. */
static bool cpu_is_v6_unaligned(void)
{
@@ -123,6 +113,16 @@ static int safe_usermode(int new_usermode, bool warn)
return new_usermode;
}
+#ifdef CONFIG_PROC_FS
+static const char *usermode_action[] = {
+ "ignored",
+ "warn",
+ "fixup",
+ "fixup+warn",
+ "signal",
+ "signal+warn"
+};
+
static int alignment_proc_show(struct seq_file *m, void *v)
{
seq_printf(m, "User:\t\t%lu\n", ai_user);
--
1.7.5.4
^ permalink raw reply related
* [PATCH 05/11] ARM: vfp: use -mfloat-abi=soft to build vfp
From: Arnd Bergmann @ 2011-10-01 19:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1317496920-7764-1-git-send-email-arnd@arndb.de>
Distros are starting to ship with toolchains defaulting to
hardfloat. Using such a compiler to build the kernel fails
in the VFP directory with
arch/arm/vfp/entry.S:1:0: sorry, unimplemented: -mfloat-abi=hard and VFP
Adding -mfloat-abi=soft to the gcc command line fixes this.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
arch/arm/vfp/Makefile | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/vfp/Makefile b/arch/arm/vfp/Makefile
index 6de73aa..a81404c 100644
--- a/arch/arm/vfp/Makefile
+++ b/arch/arm/vfp/Makefile
@@ -7,7 +7,7 @@
# ccflags-y := -DDEBUG
# asflags-y := -DDEBUG
-KBUILD_AFLAGS :=$(KBUILD_AFLAGS:-msoft-float=-Wa,-mfpu=softvfp+vfp)
+KBUILD_AFLAGS :=$(KBUILD_AFLAGS:-msoft-float=-Wa,-mfpu=softvfp+vfp -mfloat-abi=soft)
LDFLAGS +=--no-warn-mismatch
obj-y += vfp.o
--
1.7.5.4
^ permalink raw reply related
* [PATCH 06/11] ARM: pm: let platforms select cpu_suspend support
From: Arnd Bergmann @ 2011-10-01 19:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1317496920-7764-1-git-send-email-arnd@arndb.de>
Support for the cpu_suspend functions is only built-in
when CONFIG_PM_SLEEP is enabled, but omap3/4, exynos4
and pxa always call cpu_suspend when CONFIG_PM is enabled.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
arch/arm/Kconfig | 4 ++++
arch/arm/kernel/Makefile | 2 +-
arch/arm/mach-exynos4/Kconfig | 1 +
arch/arm/mach-omap2/Kconfig | 2 ++
arch/arm/mm/proc-v7.S | 2 +-
5 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 497af51..3445f50 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -631,6 +631,7 @@ config ARCH_PXA
select SPARSE_IRQ
select AUTO_ZRELADDR
select MULTI_IRQ_HANDLER
+ select ARM_CPU_SUSPEND if PM
help
Support for Intel/Marvell's PXA2xx/PXA3xx processor line.
@@ -2077,6 +2078,9 @@ config ARCH_SUSPEND_POSSIBLE
CPU_V6 || CPU_V6K || CPU_V7 || CPU_XSC3 || CPU_XSCALE
def_bool y
+config ARM_CPU_SUSPEND
+ def_bool PM_SLEEP
+
endmenu
source "net/Kconfig"
diff --git a/arch/arm/kernel/Makefile b/arch/arm/kernel/Makefile
index f7887dc..4ce3303 100644
--- a/arch/arm/kernel/Makefile
+++ b/arch/arm/kernel/Makefile
@@ -29,7 +29,7 @@ obj-$(CONFIG_MODULES) += armksyms.o module.o
obj-$(CONFIG_ARTHUR) += arthur.o
obj-$(CONFIG_ISA_DMA) += dma-isa.o
obj-$(CONFIG_PCI) += bios32.o isa.o
-obj-$(CONFIG_PM_SLEEP) += sleep.o
+obj-$(CONFIG_ARM_CPU_SUSPEND) += sleep.o
obj-$(CONFIG_HAVE_SCHED_CLOCK) += sched_clock.o
obj-$(CONFIG_SMP) += smp.o smp_tlb.o
obj-$(CONFIG_HAVE_ARM_SCU) += smp_scu.o
diff --git a/arch/arm/mach-exynos4/Kconfig b/arch/arm/mach-exynos4/Kconfig
index 0c77ab9..fc1f92d 100644
--- a/arch/arm/mach-exynos4/Kconfig
+++ b/arch/arm/mach-exynos4/Kconfig
@@ -12,6 +12,7 @@ if ARCH_EXYNOS4
config CPU_EXYNOS4210
bool
select S3C_PL330_DMA
+ select ARM_CPU_SUSPEND if PM
help
Enable EXYNOS4210 CPU support
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 57b66d5..89bfb49 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -36,6 +36,7 @@ config ARCH_OMAP3
select ARM_L1_CACHE_SHIFT_6 if !ARCH_OMAP4
select ARCH_HAS_OPP
select PM_OPP if PM
+ select ARM_CPU_SUSPEND if PM
config ARCH_OMAP4
bool "TI OMAP4"
@@ -50,6 +51,7 @@ config ARCH_OMAP4
select ARCH_HAS_OPP
select PM_OPP if PM
select USB_ARCH_HAS_EHCI
+ select ARM_CPU_SUSPEND if PM
comment "OMAP Core Type"
depends on ARCH_OMAP2
diff --git a/arch/arm/mm/proc-v7.S b/arch/arm/mm/proc-v7.S
index a30e785..591accd 100644
--- a/arch/arm/mm/proc-v7.S
+++ b/arch/arm/mm/proc-v7.S
@@ -217,7 +217,7 @@ ENDPROC(cpu_v7_set_pte_ext)
/* Suspend/resume support: derived from arch/arm/mach-s5pv210/sleep.S */
.globl cpu_v7_suspend_size
.equ cpu_v7_suspend_size, 4 * 9
-#ifdef CONFIG_PM_SLEEP
+#ifdef CONFIG_ARM_CPU_SUSPEND
ENTRY(cpu_v7_do_suspend)
stmfd sp!, {r4 - r11, lr}
mrc p15, 0, r4, c13, c0, 0 @ FCSE/PID
--
1.7.5.4
^ 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