* OMAP baseline test results for v3.8-rc4
From: Matt Porter @ 2013-01-21 17:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <49ca66a84bb245ca9cfe4fd044c4d6f6@DFLE72.ent.ti.com>
On Mon, Jan 21, 2013 at 04:32:13PM +0000, Mark Jackson wrote:
> Vaibhav / Matt
>
> On 20/01/13 21:38, Paul Walmsley wrote:
> >
> > Here are some basic OMAP test results for Linux v3.8-rc4.
> > Logs and other details at:
> >
> > http://www.pwsan.com/omap/testlogs/test_v3.8-rc4/20130120122039/
>
> <snip>
>
> > Failing tests: needing investigation
> > ------------------------------------
> >
> > Boot tests:
> >
> > * am335xbone: hangs after "Starting kernel"
> > - Cause unknown
> > - http://www.mail-archive.com/linux-omap at vger.kernel.org/msg82297.html
>
> <snip>
>
> > Failing tests: needing local investigation (may be due to testbed issues)
> > -------------------------------------------------------------------------
> >
> > Boot tests:
> >
> > * AM335x Beaglebone: omap2plus_defconfig kernels don't boot
> > - May be fixed now, pending retest:
> > - http://marc.info/?l=linux-omap&m=135082257727502&w=2
> > - Not yet part of the automated test suite
> > - Nishanth Menon & Vaibhav Hiremath report that it works for them
> > * May be due to an old U-boot with FDT support problems used here?
> > Pending local investigation and re-test
>
> Does anyone know when the BeagleBone support is going to be fixed in mainline ?
Hi Mark,
I'm not sure what needs to be fixed. The only thing my edma dmaengine
series adds is new features (specifically, mmc and spi dma support).
I would suspect some boot problem specific to Paul's configuration
if it's hanging. I just booted current mainline with an
omap2plus_defconfig build on my bone a5 and it came up fine.
> I've just tried the latest linux-next git, and no joy.
>
> However, Matt's edma-dmaengine-am33xx-v5 branch on github seems to be working:-
>
>
> Uncompressing Linux... done, booting the kernel.
> [ 0.000000] Booting Linux on physical CPU 0x0
> [ 0.000000] Linux version 3.8.0-rc3-61978-g108da76-dirty (mpfj at mpfj-nanobone) (gcc version 4.5.4
> (Buildroot 2012.11-git-00497-ge48bf89) ) #7 SMP Mon Jan 21 15:52:14 GMT 2013
> [ 0.000000] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c53c7d
> [ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
> [ 0.000000] Machine: Generic AM33XX (Flattened Device Tree), model: TI AM335x BeagleBone
>
> Are we just waiting for Matt's DMA stuff to be accepted ?
For the features I listed above, yes. Also Mark Greer's crypto patches
for AM33xx depend on that series as does a patch series (not ready yet)
that I have to support the Bone audio capes.
There's a dependency I'm working through in a separate thread on lkml
since the dmaengine edma series requires the proposed
dma_get_channel_caps() api...still discussing that implementation.
-Matt
^ permalink raw reply
* [PATCH] ARM: tegra: DTS: seaboard: remove unnecessarily text
From: Stephen Warren @ 2013-01-21 17:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358588264-1860-1-git-send-email-ldewangan@nvidia.com>
On 01/19/2013 02:37 AM, Laxman Dewangan wrote:
> There is unnecessarily text in the keymap table. Removing this.
Thanks, I just squashed this into your original patch.
^ permalink raw reply
* [GIT PULL] arm-soc: Xilinx zynq timer changes for v3.9
From: Michal Simek @ 2013-01-21 17:14 UTC (permalink / raw)
To: linux-arm-kernel
Hi Arnd and Olof,
please pull these timer changes to your arm-soc tree.
I am aware about any dependency.
Please let me know if you have any problem with this patchset.
Thanks,
Michal
The following changes since commit 7d1f9aeff1ee4a20b1aeb377dd0f579fe9647619:
Linus Torvalds (1):
Linux 3.8-rc4
are available in the git repository at:
git://git.xilinx.com/linux-xlnx.git zynq/timer
Soren Brinkmann (7):
arm: zynq: timer: Replace PSS through PS
arm: zynq: timer: Remove unnecessary register write
arm: zynq: timer: Remove unused #defines
arm: zynq: timer: Align columns
arm: zynq: timer: Remove redundant #includes
arm: zynq: timer: Fix comment style
arm: zynq: timer: Set clock_event cpumask
arch/arm/mach-zynq/common.c | 6 +-
arch/arm/mach-zynq/common.h | 2 +-
arch/arm/mach-zynq/timer.c | 150 ++++++++++++++++++++----------------------
3 files changed, 75 insertions(+), 83 deletions(-)
^ permalink raw reply
* [PATCH v7 14/15] pinctrl: single: support generic pinconf
From: Tony Lindgren @ 2013-01-21 17:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358494279-16503-15-git-send-email-haojian.zhuang@linaro.org>
Hi,
* Haojian Zhuang <haojian.zhuang@linaro.org> [130117 23:35]:
> +static int pcs_parse_pinconf(struct pcs_device *pcs, struct device_node *np,
> + struct pcs_function *func,
> + struct pinctrl_map **map)
> +
> +{
> + struct pinctrl_map *m = *map;
> + int i = 0, nconfs = 0;
> + unsigned long *settings = NULL, *s = NULL;
> + struct pcs_conf_vals *conf = NULL;
> + struct pcs_conf_type prop2[] = {
> + { "pinctrl-single,power-source", PIN_CONFIG_POWER_SOURCE, },
> + { "pinctrl-single,slew-rate", PIN_CONFIG_SLEW_RATE, },
> + { "pinctrl-single,input-schmitt", PIN_CONFIG_INPUT_SCHMITT, },
> + };
The PIN_CONFIG_POWER_SOURCE should be split to PIN_CONFIG_POWER_ENABLE
and PIN_CONFIG_POWER_SOURCE. If you only have one bit for it, I guess then
you can just use PIN_CONFIG_POWER_ENABLE and make PIN_CONFIG_POWER_SOURCE
a NOP.
I also suggest we standardize on PIN_CONFIG_*_ENABLE on the naming instead
of PIN_CONFIG_*_DISABLE. Many of these features enable some input logic,
and by default they should be off to save power.
> + struct pcs_conf_type prop3[] = {
> + { "pinctrl-single,bias-disable", PIN_CONFIG_BIAS_DISABLE, },
> + { "pinctrl-single,bias-pullup", PIN_CONFIG_BIAS_PULL_UP, },
> + { "pinctrl-single,bias-pulldown", PIN_CONFIG_BIAS_PULL_DOWN, },
> + { "pinctrl-single,input-schmitt-disable",
> + PIN_CONFIG_INPUT_SCHMITT_DISABLE, },
> + };
I'm not aware of cases where we need both INPUT_SCHMITT and INPUT_SCHMITT_DISABLE,
so we may just want to have INPUT_SCHMITT_ENABLE if that works for you.
Other than that, looks good to me. I'll update my patches here and do
some tests against my pinctrl-single,bits testcase.
Regards,
Tony
^ permalink raw reply
* [PATCH 00/15] ARM build regressions in v3.8
From: Arnd Bergmann @ 2013-01-21 17:15 UTC (permalink / raw)
To: linux-arm-kernel
I know this comes late, but we have a number of broken
configurations in ARM in v3.8 that were still building
in v3.7, and I'd like to get them all fixed in the
final 3.8 release.
It would be nice if the respective maintainers could
have a look at these patches and apply them directly
when they are happy with them.
The first patch in the series is strictly speaking
not a build error but just a warning, but it is a
particularly annoying one that came in through the
latest binutils release rather than a kernel change.
The same binutils update also broke the samsung
and w90x900 platforms.
A few of the other changes are the result of the
imx multiplatform conversion. I'm not really fixing
those here, just picking up the pieces. It would
be much nicer if we could actually get those drivers
to work again with CONFIG_MULTIPLATFORM enabled
rather than just disabling them, but it may be
much too late for that. At least the drivers don't
seem to be too essential, as they are only built
in allyesconfig but not in any of the defconfigs.
Arnd
Arnd Bergmann (15):
ARM: compressed/head.S: work around new binutils warning
ARM: mvebu: build coherency_ll.S for arch=armv7-a
ARM: samsung: fix assembly syntax for new gas
ARM: w90x900: fix legacy assembly syntax
ASoC: fsl: fiq and dma cannot both be modules
clk: export __clk_get_name
drm/exynos: don't include plat/gpio-cfg.h
drm/exynos: fimd and ipp are broken on multiplatform
media: coda: don't build on multiplatform
mfd/vexpress: export vexpress_config_func_{put,get}
mtd: davinci_nand: fix OF support
USB: gadget/freescale: disable non-multiplatform drivers
USB: ehci: make orion and mxc bus glues coexist
samples/seccomp: be less stupid about cross compiling
staging/omapdrm: don't build on multiplatform
arch/arm/boot/compressed/Makefile | 2 +-
arch/arm/boot/compressed/head.S | 12 ++++++++++++
arch/arm/mach-mvebu/coherency_ll.S | 1 +
arch/arm/mach-s3c24xx/include/mach/debug-macro.S | 12 ++++++------
arch/arm/mach-s3c24xx/include/mach/entry-macro.S | 4 ++--
arch/arm/mach-s3c24xx/pm-h1940.S | 2 +-
arch/arm/mach-s3c24xx/sleep-s3c2410.S | 12 ++++++------
arch/arm/mach-s3c24xx/sleep-s3c2412.S | 12 ++++++------
arch/arm/mach-w90x900/include/mach/entry-macro.S | 4 ++--
arch/arm/plat-samsung/include/plat/debug-macro.S | 18 +++++++++---------
drivers/clk/clk.c | 1 +
drivers/gpu/drm/exynos/Kconfig | 4 ++--
drivers/gpu/drm/exynos/exynos_hdmi.c | 1 -
drivers/media/platform/Kconfig | 2 +-
drivers/mfd/vexpress-config.c | 3 ++-
drivers/mtd/nand/davinci_nand.c | 2 +-
drivers/staging/omapdrm/Kconfig | 2 +-
drivers/usb/gadget/Kconfig | 3 ++-
drivers/usb/host/ehci-hcd.c | 16 +++++++++++++++-
samples/seccomp/Makefile | 2 ++
sound/soc/fsl/Kconfig | 3 +++
21 files changed, 76 insertions(+), 42 deletions(-)
--
1.7.10.4
Cc: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Cc: Ben Dooks <ben-linux@fluff.org>
Cc: David Airlie <airlied@linux.ie>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: James Morris <james.l.morris@oracle.com>
Cc: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: Mauro Carvalho Chehab <mchehab@redhat.com>
Cc: Mike Turquette <mturquette@linaro.org>
Cc: Rob Clark <rob@ti.com>
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
Cc: Shawn Guo <shawn.guo@linaro.org>
Cc: alsa-devel at alsa-project.org
Cc: dri-devel at lists.freedesktop.org
Cc: linux-media at vger.kernel.org
Cc: linux-usb at vger.kernel.org
^ permalink raw reply
* [PATCH 01/15] ARM: compressed/head.S: work around new binutils warning
From: Arnd Bergmann @ 2013-01-21 17:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358788568-11137-1-git-send-email-arnd@arndb.de>
In August 2012, Matthew Gretton-Dann checked a change
into binutils labelled "Error on obsolete & warn on
deprecated registers", apparently as part of ARMv8
support. Apparently, this was supposed to emit
the message "Warning: This coprocessor register access
is deprecated in ARMv8" when using certain mcr/mrc
instructions and building for ARMv8. Unfortunately,
the message that is actually emitted appears to be
'(null)', which is less helpful in comparison.
Even more unfortunately, this is biting us on
every single kernel build with a new gas, because
arch/arm/boot/compressed/head.S and some other files
in that directory are built with -march=all since
kernel commit 80cec14a8 "[ARM] Add -march=all to
assembly file build in arch/arm/boot/compressed"
back in v2.6.28.
This patch reverts Russell's nice solution and
replaces it with a more complex one that sprinkles
.arch statements inside of the head.S file in
functions that are executed in different architecture
levels, which seems to solve the original problem
just as well, and gets rid of the new one, too.
Without this patch, building anything results in:
arch/arm/boot/compressed/head.S: Assembler messages:
arch/arm/boot/compressed/head.S:565: Warning: (null)
arch/arm/boot/compressed/head.S:676: Warning: (null)
arch/arm/boot/compressed/head.S:698: Warning: (null)
arch/arm/boot/compressed/head.S:722: Warning: (null)
arch/arm/boot/compressed/head.S:726: Warning: (null)
arch/arm/boot/compressed/head.S:957: Warning: (null)
arch/arm/boot/compressed/head.S:996: Warning: (null)
arch/arm/boot/compressed/head.S:997: Warning: (null)
arch/arm/boot/compressed/head.S:1027: Warning: (null)
arch/arm/boot/compressed/head.S:1035: Warning: (null)
arch/arm/boot/compressed/head.S:1046: Warning: (null)
arch/arm/boot/compressed/head.S:1060: Warning: (null)
arch/arm/boot/compressed/head.S:1092: Warning: (null)
arch/arm/boot/compressed/head.S:1094: Warning: (null)
arch/arm/boot/compressed/head.S:1095: Warning: (null)
arch/arm/boot/compressed/head.S:1102: Warning: (null)
arch/arm/boot/compressed/head.S:1134: Warning: (null)
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Matthew Gretton-Dann <matthew.gretton-dann@arm.com>
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
---
arch/arm/boot/compressed/Makefile | 2 +-
arch/arm/boot/compressed/head.S | 12 ++++++++++++
2 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/compressed/Makefile b/arch/arm/boot/compressed/Makefile
index 5cad8a6..dfe5687 100644
--- a/arch/arm/boot/compressed/Makefile
+++ b/arch/arm/boot/compressed/Makefile
@@ -121,7 +121,7 @@ KBUILD_CFLAGS = $(subst -pg, , $(ORIG_CFLAGS))
endif
ccflags-y := -fpic -fno-builtin -I$(obj)
-asflags-y := -Wa,-march=all -DZIMAGE
+asflags-y := -DZIMAGE
# Supply kernel BSS size to the decompressor via a linker symbol.
KBSS_SZ = $(shell $(CROSS_COMPILE)size $(obj)/../../../../vmlinux | \
diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S
index fe4d9c3..3b0b21a 100644
--- a/arch/arm/boot/compressed/head.S
+++ b/arch/arm/boot/compressed/head.S
@@ -548,6 +548,7 @@ cache_on: mov r3, #8 @ cache_on function
* to cover all 32bit address and cacheable and bufferable.
*/
__armv4_mpu_cache_on:
+ .arch armv4
mov r0, #0x3f @ 4G, the whole
mcr p15, 0, r0, c6, c7, 0 @ PR7 Area Setting
mcr p15, 0, r0, c6, c7, 1
@@ -655,6 +656,7 @@ ENDPROC(__setup_mmu)
@ Enable unaligned access on v6, to allow better code generation
@ for the decompressor C code:
__armv6_mmu_cache_on:
+ .arch armv6
mrc p15, 0, r0, c1, c0, 0 @ read SCTLR
bic r0, r0, #2 @ A (no unaligned access fault)
orr r0, r0, #1 << 22 @ U (v6 unaligned access model)
@@ -663,11 +665,13 @@ __armv6_mmu_cache_on:
__arm926ejs_mmu_cache_on:
#ifdef CONFIG_CPU_DCACHE_WRITETHROUGH
+ .arch armv5
mov r0, #4 @ put dcache in WT mode
mcr p15, 7, r0, c15, c0, 0
#endif
__armv4_mmu_cache_on:
+ .arch armv4
mov r12, lr
#ifdef CONFIG_MMU
mov r6, #CB_BITS | 0x12 @ U
@@ -688,6 +692,7 @@ __armv4_mmu_cache_on:
mov pc, r12
__armv7_mmu_cache_on:
+ .arch armv7-a
mov r12, lr
#ifdef CONFIG_MMU
mrc p15, 0, r11, c0, c1, 4 @ read ID_MMFR0
@@ -1031,6 +1036,7 @@ cache_clean_flush:
mov r3, #16
b call_cache_fn
+ .arch armv4
__armv4_mpu_cache_flush:
mov r2, #1
mov r3, #0
@@ -1056,6 +1062,7 @@ __fa526_cache_flush:
mov pc, lr
__armv6_mmu_cache_flush:
+ .arch armv6
mov r1, #0
mcr p15, 0, r1, c7, c14, 0 @ clean+invalidate D
mcr p15, 0, r1, c7, c5, 0 @ invalidate I+BTB
@@ -1063,6 +1070,7 @@ __armv6_mmu_cache_flush:
mcr p15, 0, r1, c7, c10, 4 @ drain WB
mov pc, lr
+ .arch armv7-a
__armv7_mmu_cache_flush:
mrc p15, 0, r10, c0, c1, 5 @ read ID_MMFR1
tst r10, #0xf << 16 @ hierarchical cache (ARMv7)
@@ -1123,6 +1131,7 @@ iflush:
mcr p15, 0, r10, c7, c5, 4 @ ISB
mov pc, lr
+ .arch armv5
__armv5tej_mmu_cache_flush:
1: mrc p15, 0, r15, c7, c14, 3 @ test,clean,invalidate D cache
bne 1b
@@ -1130,6 +1139,7 @@ __armv5tej_mmu_cache_flush:
mcr p15, 0, r0, c7, c10, 4 @ drain WB
mov pc, lr
+ .arch armv4
__armv4_mmu_cache_flush:
mov r2, #64*1024 @ default: 32K dcache size (*2)
mov r11, #32 @ default: 32 byte line size
@@ -1168,6 +1178,8 @@ __armv3_mpu_cache_flush:
mcr p15, 0, r1, c7, c0, 0 @ invalidate whole cache v3
mov pc, lr
+ .arch armv4
+
/*
* Various debugging routines for printing hex characters and
* memory, which again must be relocatable.
--
1.7.10.4
^ permalink raw reply related
* [PATCH 02/15] ARM: mvebu: build coherency_ll.S for arch=armv7-a
From: Arnd Bergmann @ 2013-01-21 17:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358788568-11137-1-git-send-email-arnd@arndb.de>
In a multiplatform kernel, one can enable mach-mvebu
together with one or more ARMv6 platforms, which leads
to all files being built for v6. The coherency_ll.S
uses the "dsb" instruction that is only available for
v7, causing a build error in this case. Since the
file is only used on v7 based machines, it is safe
to build it using an ".arch armv7-a" statement.
Without this patch, building allyesconfig results in:
arch/arm/mach-mvebu/coherency_ll.S: Assembler messages:
arch/arm/mach-mvebu/coherency_ll.S:45: Error: selected processor does not support ARM mode `dsb'
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Jason Cooper <jason@lakedaemon.net>
Cc: Andrew Lunn <andrew@lunn.ch>
Cc: Gregory Clement <gregory.clement@free-electrons.com>
---
arch/arm/mach-mvebu/coherency_ll.S | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-mvebu/coherency_ll.S b/arch/arm/mach-mvebu/coherency_ll.S
index 53e8391..7648bda 100644
--- a/arch/arm/mach-mvebu/coherency_ll.S
+++ b/arch/arm/mach-mvebu/coherency_ll.S
@@ -25,6 +25,7 @@
* r0: Coherency fabric base register address
* r1: HW CPU id
*/
+ .arch armv7-a
ENTRY(ll_set_cpu_coherent)
/* Create bit by cpu index */
mov r3, #(1 << 24)
--
1.7.10.4
^ permalink raw reply related
* [PATCH 03/15] ARM: samsung: fix assembly syntax for new gas
From: Arnd Bergmann @ 2013-01-21 17:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358788568-11137-1-git-send-email-arnd@arndb.de>
Recent assembler versions complain about extraneous
whitespace inside [] brackets. This fixes all of
these instances for the samsung platforms. We should
backport this to all kernels that might need to
be built with new binutils.
arch/arm/kernel/entry-armv.S: Assembler messages:
arch/arm/kernel/entry-armv.S:214: Error: ARM register expected -- `ldr r2,[ r6,#(0x10)]'
arch/arm/kernel/entry-armv.S:214: Error: ARM register expected -- `ldr r0,[ r6,#(0x14)]'
arch/arm/kernel/entry-armv.S:430: Error: ARM register expected -- `ldr r2,[ r6,#(0x10)]'
arch/arm/kernel/entry-armv.S:430: Error: ARM register expected -- `ldr r0,[ r6,#(0x14)]'
arch/arm/mach-s3c24xx/sleep-s3c2410.S: Assembler messages:
arch/arm/mach-s3c24xx/sleep-s3c2410.S:48: Error: ARM register expected -- `ldr r7,[ r4 ]'
arch/arm/mach-s3c24xx/sleep-s3c2410.S:49: Error: ARM register expected -- `ldr r8,[ r5 ]'
arch/arm/mach-s3c24xx/sleep-s3c2410.S:50: Error: ARM register expected -- `ldr r9,[ r6 ]'
arch/arm/mach-s3c24xx/sleep-s3c2410.S:64: Error: ARM register expected -- `streq r7,[ r4 ]'
arch/arm/mach-s3c24xx/sleep-s3c2410.S:65: Error: ARM register expected -- `streq r8,[ r5 ]'
arch/arm/mach-s3c24xx/sleep-s3c2410.S:66: Error: ARM register expected -- `streq r9,[ r6 ]'
arch/arm/kernel/debug.S: Assembler messages:
arch/arm/kernel/debug.S:83: Error: ARM register expected -- `ldr r2,[ r2,#((0x0B0)+(((0x56000000)-(0x50000000))+(0xF6000000+(0x01000000))))-((0)+(((0x56000000)-(0x50000000))+(0xF6000000+(0x01000000))))]'
arch/arm/kernel/debug.S:83: Error: ARM register expected -- `ldr r2,[ r3,#(0x18)]'
arch/arm/kernel/debug.S:85: Error: ARM register expected -- `ldr r2,[ r2,#((0x0B0)+(((0x56000000)-(0x50000000))+(0xF6000000+(0x01000000))))-((0)+(((0x56000000)-(0x50000000))+(0xF6000000+(0x01000000))))]'
arch/arm/kernel/debug.S:85: Error: ARM register expected -- `ldr r2,[ r3,#(0x18)]'
arch/arm/mach-s3c24xx/pm-h1940.S: Assembler messages:
arch/arm/mach-s3c24xx/pm-h1940.S:33: Error: ARM register expected -- `ldr pc,[ r0,#((0x0B8)+(((0x56000000)-(0x50000000))+(0xF6000000+(0x01000000))))-(((0x56000000)-(0x50000000))+(0xF6000000+(0x01000000)))]'
arch/arm/mach-s3c24xx/sleep-s3c2412.S: Assembler messages:
arch/arm/mach-s3c24xx/sleep-s3c2412.S:60: Error: ARM register expected -- `ldrne r9,[ r1 ]'
arch/arm/mach-s3c24xx/sleep-s3c2412.S:61: Error: ARM register expected -- `strne r9,[ r1 ]'
arch/arm/mach-s3c24xx/sleep-s3c2412.S:62: Error: ARM register expected -- `ldrne r9,[ r2 ]'
arch/arm/mach-s3c24xx/sleep-s3c2412.S:63: Error: ARM register expected -- `strne r9,[ r2 ]'
arch/arm/mach-s3c24xx/sleep-s3c2412.S:64: Error: ARM register expected -- `ldrne r9,[ r3 ]'
arch/arm/mach-s3c24xx/sleep-s3c2412.S:65: Error: ARM register expected -- `strne r9,[ r3 ]'
arch/arm/kernel/debug.S:83: Error: ARM register expected -- `ldr r2,[ r3,#(0x08)]'
arch/arm/kernel/debug.S:83: Error: ARM register expected -- `ldr r2,[ r3,#(0x18)]'
arch/arm/kernel/debug.S:83: Error: ARM register expected -- `ldr r2,[ r3,#(0x10)]'
arch/arm/kernel/debug.S:85: Error: ARM register expected -- `ldr r2,[ r3,#(0x08)]'
arch/arm/kernel/debug.S:85: Error: ARM register expected -- `ldr r2,[ r3,#(0x18)]'
arch/arm/kernel/debug.S:85: Error: ARM register expected -- `ldr r2,[ r3,#(0x10)]'
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Ben Dooks <ben-linux@fluff.org>
Cc: Kukjin Kim <kgene.kim@samsung.com>
Cc: stable at vger.kernel.org
---
arch/arm/mach-s3c24xx/include/mach/debug-macro.S | 12 ++++++------
arch/arm/mach-s3c24xx/include/mach/entry-macro.S | 4 ++--
arch/arm/mach-s3c24xx/pm-h1940.S | 2 +-
arch/arm/mach-s3c24xx/sleep-s3c2410.S | 12 ++++++------
arch/arm/mach-s3c24xx/sleep-s3c2412.S | 12 ++++++------
arch/arm/plat-samsung/include/plat/debug-macro.S | 18 +++++++++---------
6 files changed, 30 insertions(+), 30 deletions(-)
diff --git a/arch/arm/mach-s3c24xx/include/mach/debug-macro.S b/arch/arm/mach-s3c24xx/include/mach/debug-macro.S
index 4135de8..13ed33c 100644
--- a/arch/arm/mach-s3c24xx/include/mach/debug-macro.S
+++ b/arch/arm/mach-s3c24xx/include/mach/debug-macro.S
@@ -40,17 +40,17 @@
addeq \rd, \rx, #(S3C24XX_PA_GPIO - S3C24XX_PA_UART)
addne \rd, \rx, #(S3C24XX_VA_GPIO - S3C24XX_VA_UART)
bic \rd, \rd, #0xff000
- ldr \rd, [ \rd, # S3C2410_GSTATUS1 - S3C2410_GPIOREG(0) ]
+ ldr \rd, [\rd, # S3C2410_GSTATUS1 - S3C2410_GPIOREG(0)]
and \rd, \rd, #0x00ff0000
teq \rd, #0x00440000 @ is it 2440?
1004:
- ldr \rd, [ \rx, # S3C2410_UFSTAT ]
+ ldr \rd, [\rx, # S3C2410_UFSTAT]
moveq \rd, \rd, lsr #SHIFT_2440TXF
tst \rd, #S3C2410_UFSTAT_TXFULL
.endm
.macro fifo_full_s3c2410 rd, rx
- ldr \rd, [ \rx, # S3C2410_UFSTAT ]
+ ldr \rd, [\rx, # S3C2410_UFSTAT]
tst \rd, #S3C2410_UFSTAT_TXFULL
.endm
@@ -68,18 +68,18 @@
addeq \rd, \rx, #(S3C24XX_PA_GPIO - S3C24XX_PA_UART)
addne \rd, \rx, #(S3C24XX_VA_GPIO - S3C24XX_VA_UART)
bic \rd, \rd, #0xff000
- ldr \rd, [ \rd, # S3C2410_GSTATUS1 - S3C2410_GPIOREG(0) ]
+ ldr \rd, [\rd, # S3C2410_GSTATUS1 - S3C2410_GPIOREG(0)]
and \rd, \rd, #0x00ff0000
teq \rd, #0x00440000 @ is it 2440?
10000:
- ldr \rd, [ \rx, # S3C2410_UFSTAT ]
+ ldr \rd, [\rx, # S3C2410_UFSTAT]
andne \rd, \rd, #S3C2410_UFSTAT_TXMASK
andeq \rd, \rd, #S3C2440_UFSTAT_TXMASK
.endm
.macro fifo_level_s3c2410 rd, rx
- ldr \rd, [ \rx, # S3C2410_UFSTAT ]
+ ldr \rd, [\rx, # S3C2410_UFSTAT]
and \rd, \rd, #S3C2410_UFSTAT_TXMASK
.endm
diff --git a/arch/arm/mach-s3c24xx/include/mach/entry-macro.S b/arch/arm/mach-s3c24xx/include/mach/entry-macro.S
index 7615a14..6a21bee 100644
--- a/arch/arm/mach-s3c24xx/include/mach/entry-macro.S
+++ b/arch/arm/mach-s3c24xx/include/mach/entry-macro.S
@@ -31,10 +31,10 @@
@@ try the interrupt offset register, since it is there
- ldr \irqstat, [ \base, #INTPND ]
+ ldr \irqstat, [\base, #INTPND ]
teq \irqstat, #0
beq 1002f
- ldr \irqnr, [ \base, #INTOFFSET ]
+ ldr \irqnr, [\base, #INTOFFSET ]
mov \tmp, #1
tst \irqstat, \tmp, lsl \irqnr
bne 1001f
diff --git a/arch/arm/mach-s3c24xx/pm-h1940.S b/arch/arm/mach-s3c24xx/pm-h1940.S
index c93bf2d..6183a68 100644
--- a/arch/arm/mach-s3c24xx/pm-h1940.S
+++ b/arch/arm/mach-s3c24xx/pm-h1940.S
@@ -30,4 +30,4 @@
h1940_pm_return:
mov r0, #S3C2410_PA_GPIO
- ldr pc, [ r0, #S3C2410_GSTATUS3 - S3C24XX_VA_GPIO ]
+ ldr pc, [r0, #S3C2410_GSTATUS3 - S3C24XX_VA_GPIO]
diff --git a/arch/arm/mach-s3c24xx/sleep-s3c2410.S b/arch/arm/mach-s3c24xx/sleep-s3c2410.S
index dd5b638..65200ae 100644
--- a/arch/arm/mach-s3c24xx/sleep-s3c2410.S
+++ b/arch/arm/mach-s3c24xx/sleep-s3c2410.S
@@ -45,9 +45,9 @@ ENTRY(s3c2410_cpu_suspend)
ldr r4, =S3C2410_REFRESH
ldr r5, =S3C24XX_MISCCR
ldr r6, =S3C2410_CLKCON
- ldr r7, [ r4 ] @ get REFRESH (and ensure in TLB)
- ldr r8, [ r5 ] @ get MISCCR (and ensure in TLB)
- ldr r9, [ r6 ] @ get CLKCON (and ensure in TLB)
+ ldr r7, [r4] @ get REFRESH (and ensure in TLB)
+ ldr r8, [r5] @ get MISCCR (and ensure in TLB)
+ ldr r9, [r6] @ get CLKCON (and ensure in TLB)
orr r7, r7, #S3C2410_REFRESH_SELF @ SDRAM sleep command
orr r8, r8, #S3C2410_MISCCR_SDSLEEP @ SDRAM power-down signals
@@ -61,8 +61,8 @@ ENTRY(s3c2410_cpu_suspend)
@@ align next bit of code to cache line
.align 5
s3c2410_do_sleep:
- streq r7, [ r4 ] @ SDRAM sleep command
- streq r8, [ r5 ] @ SDRAM power-down config
- streq r9, [ r6 ] @ CPU sleep
+ streq r7, [r4] @ SDRAM sleep command
+ streq r8, [r5] @ SDRAM power-down config
+ streq r9, [r6] @ CPU sleep
1: beq 1b
mov pc, r14
diff --git a/arch/arm/mach-s3c24xx/sleep-s3c2412.S b/arch/arm/mach-s3c24xx/sleep-s3c2412.S
index c82418e..5adaceb 100644
--- a/arch/arm/mach-s3c24xx/sleep-s3c2412.S
+++ b/arch/arm/mach-s3c24xx/sleep-s3c2412.S
@@ -57,12 +57,12 @@ s3c2412_sleep_enter1:
* retry, as simply returning causes the system to lock.
*/
- ldrne r9, [ r1 ]
- strne r9, [ r1 ]
- ldrne r9, [ r2 ]
- strne r9, [ r2 ]
- ldrne r9, [ r3 ]
- strne r9, [ r3 ]
+ ldrne r9, [r1]
+ strne r9, [r1]
+ ldrne r9, [r2]
+ strne r9, [r2]
+ ldrne r9, [r3]
+ strne r9, [r3]
bne s3c2412_sleep_enter1
mov pc, r14
diff --git a/arch/arm/plat-samsung/include/plat/debug-macro.S b/arch/arm/plat-samsung/include/plat/debug-macro.S
index 207e275..f3a9cff 100644
--- a/arch/arm/plat-samsung/include/plat/debug-macro.S
+++ b/arch/arm/plat-samsung/include/plat/debug-macro.S
@@ -14,12 +14,12 @@
/* The S5PV210/S5PC110 implementations are as belows. */
.macro fifo_level_s5pv210 rd, rx
- ldr \rd, [ \rx, # S3C2410_UFSTAT ]
+ ldr \rd, [\rx, # S3C2410_UFSTAT]
and \rd, \rd, #S5PV210_UFSTAT_TXMASK
.endm
.macro fifo_full_s5pv210 rd, rx
- ldr \rd, [ \rx, # S3C2410_UFSTAT ]
+ ldr \rd, [\rx, # S3C2410_UFSTAT]
tst \rd, #S5PV210_UFSTAT_TXFULL
.endm
@@ -27,7 +27,7 @@
* most widely re-used */
.macro fifo_level_s3c2440 rd, rx
- ldr \rd, [ \rx, # S3C2410_UFSTAT ]
+ ldr \rd, [\rx, # S3C2410_UFSTAT]
and \rd, \rd, #S3C2440_UFSTAT_TXMASK
.endm
@@ -36,7 +36,7 @@
#endif
.macro fifo_full_s3c2440 rd, rx
- ldr \rd, [ \rx, # S3C2410_UFSTAT ]
+ ldr \rd, [\rx, # S3C2410_UFSTAT]
tst \rd, #S3C2440_UFSTAT_TXFULL
.endm
@@ -45,11 +45,11 @@
#endif
.macro senduart,rd,rx
- strb \rd, [\rx, # S3C2410_UTXH ]
+ strb \rd, [\rx, # S3C2410_UTXH]
.endm
.macro busyuart, rd, rx
- ldr \rd, [ \rx, # S3C2410_UFCON ]
+ ldr \rd, [\rx, # S3C2410_UFCON]
tst \rd, #S3C2410_UFCON_FIFOMODE @ fifo enabled?
beq 1001f @
@ FIFO enabled...
@@ -60,7 +60,7 @@
1001:
@ busy waiting for non fifo
- ldr \rd, [ \rx, # S3C2410_UTRSTAT ]
+ ldr \rd, [\rx, # S3C2410_UTRSTAT]
tst \rd, #S3C2410_UTRSTAT_TXFE
beq 1001b
@@ -68,7 +68,7 @@
.endm
.macro waituart,rd,rx
- ldr \rd, [ \rx, # S3C2410_UFCON ]
+ ldr \rd, [\rx, # S3C2410_UFCON]
tst \rd, #S3C2410_UFCON_FIFOMODE @ fifo enabled?
beq 1001f @
@ FIFO enabled...
@@ -79,7 +79,7 @@
b 1002f
1001:
@ idle waiting for non fifo
- ldr \rd, [ \rx, # S3C2410_UTRSTAT ]
+ ldr \rd, [\rx, # S3C2410_UTRSTAT]
tst \rd, #S3C2410_UTRSTAT_TXFE
beq 1001b
--
1.7.10.4
^ permalink raw reply related
* [PATCH 04/15] ARM: w90x900: fix legacy assembly syntax
From: Arnd Bergmann @ 2013-01-21 17:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358788568-11137-1-git-send-email-arnd@arndb.de>
New ARM binutils don't allow extraneous whitespace inside
of brackets, which causes this error on all mach-w90x900
defconfigs:
arch/arm/kernel/entry-armv.S: Assembler messages:
arch/arm/kernel/entry-armv.S:214: Error: ARM register expected -- `ldr r0,[ r6,#(0x10C)]'
arch/arm/kernel/entry-armv.S:214: Error: ARM register expected -- `ldr r0,[ r6,#(0x110)]'
arch/arm/kernel/entry-armv.S:430: Error: ARM register expected -- `ldr r0,[ r6,#(0x10C)]'
arch/arm/kernel/entry-armv.S:430: Error: ARM register expected -- `ldr r0,[ r6,#(0x110)]'
This removes the whitespace in order to build the kernel
again.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Wan ZongShun <mcuos.com@gmail.com>
---
arch/arm/mach-w90x900/include/mach/entry-macro.S | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-w90x900/include/mach/entry-macro.S b/arch/arm/mach-w90x900/include/mach/entry-macro.S
index e286dac..0ff612a 100644
--- a/arch/arm/mach-w90x900/include/mach/entry-macro.S
+++ b/arch/arm/mach-w90x900/include/mach/entry-macro.S
@@ -19,8 +19,8 @@
mov \base, #AIC_BA
- ldr \irqnr, [ \base, #AIC_IPER]
- ldr \irqnr, [ \base, #AIC_ISNR]
+ ldr \irqnr, [\base, #AIC_IPER]
+ ldr \irqnr, [\base, #AIC_ISNR]
cmp \irqnr, #0
.endm
--
1.7.10.4
^ permalink raw reply related
* [PATCH 05/15] ASoC: fsl: fiq and dma cannot both be modules
From: Arnd Bergmann @ 2013-01-21 17:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358788568-11137-1-git-send-email-arnd@arndb.de>
The dma and fiq portions of the imx-pcm driver both
have a module_init() call, of which there can be only
one in any given module. This changes Kconfig to enforce
either the driver to be built-in in the kernel, or
to have only one of the two when building imx-pcm as
a module.
Without this patch, we cannot build the ARM 'allmodconfig', or
we get this error:
sound/soc/fsl/imx-pcm-dma.o: In function `init_module':
sound/soc/fsl/imx-pcm-dma.c:177: multiple definition of `init_module'
sound/soc/fsl/imx-pcm-fiq.o:sound/soc/fsl/imx-pcm-fiq.c:334: first defined here
sound/soc/fsl/imx-pcm-dma.o: In function `cleanup_module':
sound/soc/fsl/imx-pcm-dma.c:177: multiple definition of `cleanup_module'
sound/soc/fsl/imx-pcm-fiq.o:sound/soc/fsl/imx-pcm-fiq.c:334: first defined here
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Liam Girdwood <lrg@ti.com>
Cc: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: Shawn Guo <shawn.guo@linaro.org>
Cc: alsa-devel at alsa-project.org
---
sound/soc/fsl/Kconfig | 3 +++
1 file changed, 3 insertions(+)
diff --git a/sound/soc/fsl/Kconfig b/sound/soc/fsl/Kconfig
index 3b98159..282b08e 100644
--- a/sound/soc/fsl/Kconfig
+++ b/sound/soc/fsl/Kconfig
@@ -127,6 +127,7 @@ config SND_SOC_IMX_AUDMUX
config SND_MXC_SOC_WM1133_EV1
tristate "Audio on the i.MX31ADS with WM1133-EV1 fitted"
depends on MACH_MX31ADS_WM1133_EV1
+ depends on !SND_SOC_IMX_PCM_DMA || SND_IMX_SOC=y
select SND_SOC_WM8350
select SND_SOC_IMX_PCM_FIQ
select SND_SOC_IMX_AUDMUX
@@ -149,6 +150,7 @@ config SND_SOC_MX27VIS_AIC32X4
config SND_SOC_PHYCORE_AC97
tristate "SoC Audio support for Phytec phyCORE (and phyCARD) boards"
depends on MACH_PCM043 || MACH_PCA100
+ depends on !SND_SOC_IMX_PCM_DMA || SND_IMX_SOC=y
select SND_SOC_AC97_BUS
select SND_SOC_WM9712
select SND_SOC_IMX_PCM_FIQ
@@ -165,6 +167,7 @@ config SND_SOC_EUKREA_TLV320
|| MACH_EUKREA_MBIMXSD35_BASEBOARD \
|| MACH_EUKREA_MBIMXSD51_BASEBOARD
depends on I2C
+ depends on !SND_SOC_IMX_PCM_DMA || SND_IMX_SOC=y
select SND_SOC_TLV320AIC23
select SND_SOC_IMX_PCM_FIQ
select SND_SOC_IMX_AUDMUX
--
1.7.10.4
^ permalink raw reply related
* [PATCH 06/15] clk: export __clk_get_name
From: Arnd Bergmann @ 2013-01-21 17:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358788568-11137-1-git-send-email-arnd@arndb.de>
The __clk_get_name is used by drivers that provide their
own clocks, which have traditionally all been built-in.
The new imx drm driver however provides clocks but can
be built as a module, so we need to export __clk_get_name.
While this is only a staging driver, it's likely that
there will be others like it in the future.
Without this patch, building ARM allmodconfig results in:
ERROR: "__clk_get_name" [drivers/staging/imx-drm/ipu-v3/imx-ipu-v3.ko] undefined!
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Sascha Hauer <s.hauer@pengutronix.de>
Cc: Mike Turquette <mturquette@linaro.org>
---
drivers/clk/clk.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index 251e45d..13b793e 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -263,6 +263,7 @@ inline const char *__clk_get_name(struct clk *clk)
{
return !clk ? NULL : clk->name;
}
+EXPORT_SYMBOL_GPL(__clk_get_name);
inline struct clk_hw *__clk_get_hw(struct clk *clk)
{
--
1.7.10.4
^ permalink raw reply related
* [PATCH 07/15] drm/exynos: don't include plat/gpio-cfg.h
From: Arnd Bergmann @ 2013-01-21 17:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358788568-11137-1-git-send-email-arnd@arndb.de>
Patch 9eb3e9e6f3 "drm/exynos: add support for ARCH_MULTIPLATFORM"
allowed building the exynos hdmi driver on non-samsung platforms,
which unfortunately broke compilation in combination with 22c4f42897
"drm: exynos: hdmi: add support for exynos5 hdmi", which added
an inclusion of the samsung-specific plat/gpio-cfg.h header file.
Fortunately, that header file is not required any more here, so
we can simply revert the inclusion in order to build the ARM
allyesconfig again without getting this error:
drivers/gpu/drm/exynos/exynos_hdmi.c:37:27: fatal error: plat/gpio-cfg.h: No such file or directory
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Rob Clark <rob@ti.com>
Cc: Inki Dae <inki.dae@samsung.com>
Cc: Kyungmin Park <kyungmin.park@samsung.com>
Cc: Rahul Sharma <rahul.sharma@samsung.com>
---
drivers/gpu/drm/exynos/exynos_hdmi.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 41ff79d..b5f5119 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -34,7 +34,6 @@
#include <linux/regulator/consumer.h>
#include <linux/io.h>
#include <linux/of_gpio.h>
-#include <plat/gpio-cfg.h>
#include <drm/exynos_drm.h>
--
1.7.10.4
^ permalink raw reply related
* [PATCH 08/15] drm/exynos: fimd and ipp are broken on multiplatform
From: Arnd Bergmann @ 2013-01-21 17:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358788568-11137-1-git-send-email-arnd@arndb.de>
While the exynos DRM support in principle can work on
multiplatform, the FIMD and IPP sections of it both
include the plat/map-base.h header file, which is
not available on multiplatform. Rather than disabling
the entire driver, we can just conditionally build
these two parts.
Without this patch, building allyesconfig results in:
drivers/gpu/drm/exynos/exynos_drm_fimc.c:19:27: fatal error: plat/map-base.h: No such file or directory
drivers/gpu/drm/exynos/exynos_drm_ipp.c:20:27: fatal error: plat/map-base.h: No such file or directory
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Joonyoung Shim <jy0922.shim@samsung.com>
Cc: Inki Dae <inki.dae@samsung.com>
Cc: Seung-Woo Kim <sw0312.kim@samsung.com>
Cc: Kyungmin Park <kyungmin.park@samsung.com>
Cc: David Airlie <airlied@linux.ie>
Cc: dri-devel at lists.freedesktop.org
---
drivers/gpu/drm/exynos/Kconfig | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index 1d1f1e5..046bcda 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -24,7 +24,7 @@ config DRM_EXYNOS_DMABUF
config DRM_EXYNOS_FIMD
bool "Exynos DRM FIMD"
- depends on DRM_EXYNOS && !FB_S3C
+ depends on DRM_EXYNOS && !FB_S3C && !ARCH_MULTIPLATFORM
help
Choose this option if you want to use Exynos FIMD for DRM.
@@ -48,7 +48,7 @@ config DRM_EXYNOS_G2D
config DRM_EXYNOS_IPP
bool "Exynos DRM IPP"
- depends on DRM_EXYNOS
+ depends on DRM_EXYNOS && !ARCH_MULTIPLATFORM
help
Choose this option if you want to use IPP feature for DRM.
--
1.7.10.4
^ permalink raw reply related
* [PATCH 09/15] media: coda: don't build on multiplatform
From: Arnd Bergmann @ 2013-01-21 17:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358788568-11137-1-git-send-email-arnd@arndb.de>
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
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Javier Martin <javier.martin@vista-silicon.com>
Cc: Fabio Estevam <fabio.estevam@freescale.com>
Cc: Sascha Hauer <kernel@pengutronix.de>
Cc: Shawn Guo <shawn.guo@linaro.org>
Cc: Mauro Carvalho Chehab <mchehab@redhat.com>
Cc: linux-media at vger.kernel.org
---
drivers/media/platform/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
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
select VIDEOBUF2_DMA_CONTIG
select V4L2_MEM2MEM_DEV
select IRAM_ALLOC if SOC_IMX53
--
1.7.10.4
^ permalink raw reply related
* [PATCH 10/15] mfd/vexpress: export vexpress_config_func_{put,get}
From: Arnd Bergmann @ 2013-01-21 17:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358788568-11137-1-git-send-email-arnd@arndb.de>
The newly introduced vexpress mfd driver in linux-3.8-rc
provides access to configuration functions, but the
interfaces are not exported to modules, which breaks
when the vexpress regulator driver tries to use them.
Without this patch, building allmodconfig results in:
ERROR: "__vexpress_config_func_get" [drivers/regulator/vexpress.ko] undefined!
ERROR: "vexpress_config_func_put" [drivers/regulator/vexpress.ko] undefined!
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Pawel Moll <pawel.moll@arm.com>
Cc: Samuel Ortiz <sameo@linux.intel.com>
Cc: Mark Brown <broonie@opensource.wolfsonmicro.com>
---
drivers/mfd/vexpress-config.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/mfd/vexpress-config.c b/drivers/mfd/vexpress-config.c
index fae15d8..3cb34aa 100644
--- a/drivers/mfd/vexpress-config.c
+++ b/drivers/mfd/vexpress-config.c
@@ -142,6 +142,7 @@ struct vexpress_config_func *__vexpress_config_func_get(struct device *dev,
return func;
}
+EXPORT_SYMBOL_GPL(__vexpress_config_func_get);
void vexpress_config_func_put(struct vexpress_config_func *func)
{
@@ -149,7 +150,7 @@ void vexpress_config_func_put(struct vexpress_config_func *func)
of_node_put(func->bridge->node);
kfree(func);
}
-
+EXPORT_SYMBOL_GPL(vexpress_config_func_put);
struct vexpress_config_trans {
struct vexpress_config_func *func;
--
1.7.10.4
^ permalink raw reply related
* [PATCH 11/15] mtd: davinci_nand: fix OF support
From: Arnd Bergmann @ 2013-01-21 17:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358788568-11137-1-git-send-email-arnd@arndb.de>
The patch cdeadd "mtd: nand: davinci: add OF support for
davinci nand controller" ironically causes a build error
when CONFIG_OF is enabled because of a missing ';'
character:
drivers/mtd/nand/davinci_nand.c:527:1: error: expected ',' or ';' before 'extern'
This is the obvious fix.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Heiko Schocher <hs@denx.de>
Cc: Sekhar Nori <nsekhar@ti.com>
Cc: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Cc: David Woodhouse <David.Woodhouse@intel.com>
---
drivers/mtd/nand/davinci_nand.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mtd/nand/davinci_nand.c b/drivers/mtd/nand/davinci_nand.c
index 3502606..feae55c 100644
--- a/drivers/mtd/nand/davinci_nand.c
+++ b/drivers/mtd/nand/davinci_nand.c
@@ -523,7 +523,7 @@ static struct nand_ecclayout hwecc4_2048 __initconst = {
static const struct of_device_id davinci_nand_of_match[] = {
{.compatible = "ti,davinci-nand", },
{},
-}
+};
MODULE_DEVICE_TABLE(of, davinci_nand_of_match);
static struct davinci_nand_pdata
--
1.7.10.4
^ permalink raw reply related
* [PATCH 12/15] USB: gadget/freescale: disable non-multiplatform drivers
From: Arnd Bergmann @ 2013-01-21 17:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358788568-11137-1-git-send-email-arnd@arndb.de>
Both the fsl_mxc gadget and the imx_udc gadget drivers fail to build
without the mach/hardware.h file that is not available when building
for multiplatform. Let's disable these drivers for v3.8 in combination
with CONFIG_ARCH_MULTIPLATFORM, and fix them properly in v3.9 unless
someone has an better solution.
Without this patch, building allyesconfig results in:
drivers/usb/gadget/fsl_mxc_udc.c:21:27: fatal error: mach/hardware.h: No such file or directory
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Felipe Balbi <balbi@ti.com>
Cc: Shawn Guo <shawn.guo@linaro.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: linux-usb at vger.kernel.org
---
drivers/usb/gadget/Kconfig | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/gadget/Kconfig b/drivers/usb/gadget/Kconfig
index 14625fd..ca57a6d 100644
--- a/drivers/usb/gadget/Kconfig
+++ b/drivers/usb/gadget/Kconfig
@@ -173,6 +173,7 @@ config USB_BCM63XX_UDC
config USB_FSL_USB2
tristate "Freescale Highspeed USB DR Peripheral Controller"
depends on FSL_SOC || ARCH_MXC
+ depends on !ARCH_MULTIPLATFORM
select USB_FSL_MPH_DR_OF if OF
help
Some of Freescale PowerPC and i.MX processors have a High Speed
@@ -280,7 +281,7 @@ config USB_S3C_HSOTG
config USB_IMX
tristate "Freescale i.MX1 USB Peripheral Controller"
- depends on ARCH_MXC
+ depends on ARCH_MXC && !ARCH_MULTIPLATFORM
help
Freescale's i.MX1 includes an integrated full speed
USB 1.1 device controller.
--
1.7.10.4
^ permalink raw reply related
* [PATCH 13/15] USB: ehci: make orion and mxc bus glues coexist
From: Arnd Bergmann @ 2013-01-21 17:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358788568-11137-1-git-send-email-arnd@arndb.de>
In linux-3.8-rc1 it became possible to build the imx and
mvebu platforms together in a single kernel, which clashes
in the ehci driver.
Manjunath Goudar is already working on a patch to convert
both the imx and the mvebu glue drivers (along with all
the other ARM specific ones) to the new probing method,
but that will be too late to fix v3.8. This patch instead
adds yet another hack like the existing ones to allow
the ehci driver to load both back-ends.
Without this patch, building allyesconfig results in:
drivers/usb/host/ehci-hcd.c:1285:0: error: "PLATFORM_DRIVER" redefined
drivers/usb/host/ehci-hcd.c:1255:0: note: this is the location of the previous definition
In file included from drivers/usb/host/ehci-hcd.c:1254:0:
drivers/usb/host/ehci-mxc.c:280:31: warning: 'ehci_mxc_driver' defined but not used
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: linux-usb at vger.kernel.org
Cc: Manjunath Goudar <manjunath.goudar@linaro.org>
Cc: Shawn Guo <shawn.guo@linaro.org>
Cc: Sascha Hauer <s.hauer@pengutronix.de>
Cc: Jason Cooper <jason@lakedaemon.net>
Cc: Andrew Lunn <andrew@lunn.ch>
Cc: Gregory Clement <gregory.clement@free-electrons.com>
---
drivers/usb/host/ehci-hcd.c | 16 +++++++++++++++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
index c97503b..92e7180 100644
--- a/drivers/usb/host/ehci-hcd.c
+++ b/drivers/usb/host/ehci-hcd.c
@@ -1282,7 +1282,7 @@ MODULE_LICENSE ("GPL");
#ifdef CONFIG_PLAT_ORION
#include "ehci-orion.c"
-#define PLATFORM_DRIVER ehci_orion_driver
+#define ORION_PLATFORM_DRIVER ehci_orion_driver
#endif
#ifdef CONFIG_USB_W90X900_EHCI
@@ -1353,6 +1353,7 @@ MODULE_LICENSE ("GPL");
#if !IS_ENABLED(CONFIG_USB_EHCI_PCI) && \
!IS_ENABLED(CONFIG_USB_EHCI_HCD_PLATFORM) && \
!defined(CONFIG_USB_CHIPIDEA_HOST) && \
+ !defined(ORION_PLATFORM_DRIVER) && \
!defined(PLATFORM_DRIVER) && \
!defined(PS3_SYSTEM_BUS_DRIVER) && \
!defined(OF_PLATFORM_DRIVER) && \
@@ -1393,6 +1394,12 @@ static int __init ehci_hcd_init(void)
goto clean0;
#endif
+#ifdef ORION_PLATFORM_DRIVER
+ retval = platform_driver_register(&ORION_PLATFORM_DRIVER);
+ if (retval < 0)
+ goto clean1;
+#endif
+
#ifdef PS3_SYSTEM_BUS_DRIVER
retval = ps3_ehci_driver_register(&PS3_SYSTEM_BUS_DRIVER);
if (retval < 0)
@@ -1424,6 +1431,10 @@ clean3:
ps3_ehci_driver_unregister(&PS3_SYSTEM_BUS_DRIVER);
clean2:
#endif
+#ifdef ORION_PLATFORM_DRIVER
+ platform_driver_unregister(&ORION_PLATFORM_DRIVER);
+clean1:
+#endif
#ifdef PLATFORM_DRIVER
platform_driver_unregister(&PLATFORM_DRIVER);
clean0:
@@ -1446,6 +1457,9 @@ static void __exit ehci_hcd_cleanup(void)
#ifdef OF_PLATFORM_DRIVER
platform_driver_unregister(&OF_PLATFORM_DRIVER);
#endif
+#ifdef ORION_PLATFORM_DRIVER
+ platform_driver_unregister(&ORION_PLATFORM_DRIVER);
+#endif
#ifdef PLATFORM_DRIVER
platform_driver_unregister(&PLATFORM_DRIVER);
#endif
--
1.7.10.4
^ permalink raw reply related
* [PATCH 14/15] samples/seccomp: be less stupid about cross compiling
From: Arnd Bergmann @ 2013-01-21 17:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358788568-11137-1-git-send-email-arnd@arndb.de>
The seccomp filters are currently built for the build
host, not for the machine that they are going to run
on, but they are also built for with the -m32 flag
if the kernel is built for a 32 bit machine, both
of which seems rather odd.
It broke allyesconfig on my machine, which is x86-64, but
building for 32 bit ARM, with this error message:
In file included from /usr/include/stdio.h:28:0,
from samples/seccomp/bpf-fancy.c:15:
/usr/include/features.h:324:26: fatal error: bits/predefs.h: No such file or directory
because there are no 32 bit libc headers installed on
this machine. We should really be building all the
samples for the target machine rather than the build
host, but since the infrastructure for that appears
to be missing right now, let's be a little bit smarter
and not pass the '-m32' flag to the HOSTCC when cross-
compiling.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: James Morris <james.l.morris@oracle.com>
---
samples/seccomp/Makefile | 2 ++
1 file changed, 2 insertions(+)
diff --git a/samples/seccomp/Makefile b/samples/seccomp/Makefile
index bbbd276..7203e66 100644
--- a/samples/seccomp/Makefile
+++ b/samples/seccomp/Makefile
@@ -19,6 +19,7 @@ bpf-direct-objs := bpf-direct.o
# Try to match the kernel target.
ifndef CONFIG_64BIT
+ifndef CROSS_COMPILE
# s390 has -m31 flag to build 31 bit binaries
ifndef CONFIG_S390
@@ -35,6 +36,7 @@ HOSTLOADLIBES_bpf-direct += $(MFLAG)
HOSTLOADLIBES_bpf-fancy += $(MFLAG)
HOSTLOADLIBES_dropper += $(MFLAG)
endif
+endif
# Tell kbuild to always build the programs
always := $(hostprogs-y)
--
1.7.10.4
^ permalink raw reply related
* [PATCH 15/15] staging/omapdrm: don't build on multiplatform
From: Arnd Bergmann @ 2013-01-21 17:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358788568-11137-1-git-send-email-arnd@arndb.de>
The omapdrm driver is incorrectly flagged to allow building
on non-omap platforms, when ARCH_MULTIPLATFORM is set.
This does not work, because it unconditionally selects
the OMAP2_DSS symbol that only works on OMAP.
The problem was introduced in 5e3b087499 "staging:
drm/omap: add support for ARCH_MULTIPLATFORM", which this
patch partly reverts.
Without this patch, building allyesconfig results in:
warning: (VIDEO_OMAP2_VOUT && DRM_OMAP) selects OMAP2_DSS which has unmet direct dependencies (HAS_IOMEM && ARCH_OMAP2PLUS)
warning: (VIDEO_OMAP2_VOUT && DRM_OMAP) selects OMAP2_DSS which has unmet direct dependencies (HAS_IOMEM && ARCH_OMAP2PLUS)
drivers/video/omap2/dss/dss.c: In function 'dss_calc_clock_div':
drivers/video/omap2/dss/dss.c:572:20: error: 'CONFIG_OMAP2_DSS_MIN_FCK_PER_PCK' undeclared (first use in this function)
drivers/video/omap2/dss/dss.c:572:20: note: each undeclared identifier is reported only once for each function it appears in
drivers/staging/omapdrm/omap_connector.c: In function 'omap_connector_dpms':
drivers/staging/omapdrm/omap_connector.c:116:8: error: 'OMAP_DSS_DISPLAY_SUSPENDED' undeclared (first use in this function)
drivers/staging/omapdrm/omap_connector.c:116:8: note: each undeclared identifier is reported only once for each function it appears in
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Rob Clark <rob@ti.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/staging/omapdrm/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/omapdrm/Kconfig b/drivers/staging/omapdrm/Kconfig
index b724a41..81a7cba 100644
--- a/drivers/staging/omapdrm/Kconfig
+++ b/drivers/staging/omapdrm/Kconfig
@@ -2,7 +2,7 @@
config DRM_OMAP
tristate "OMAP DRM"
depends on DRM && !CONFIG_FB_OMAP2
- depends on ARCH_OMAP2PLUS || ARCH_MULTIPLATFORM
+ depends on ARCH_OMAP2PLUS
select DRM_KMS_HELPER
select OMAP2_DSS
select FB_SYS_FILLRECT
--
1.7.10.4
^ permalink raw reply related
* [PATCH] ARM: tegra114: cpuidle: add ARM_CPUIDLE_WFI_STATE support
From: Stephen Warren @ 2013-01-21 17:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358761746-13118-1-git-send-email-josephl@nvidia.com>
On 01/21/2013 02:49 AM, Joseph Lo wrote:
> Adding the generic ARM_CPUIDLE_WFI_STATE support for Tegra114.
This of course depends on Hiroshi's Tegra114 patches, right; you should
explicitly point out any dependencies when posting patches.
The code changes look reasonable, but of course I'll hold off applying
it until the Tegra114 support is checked in.
^ permalink raw reply
* [GIT PULL] arm-soc: Xilinx zynq serial changes for v3.9
From: Michal Simek @ 2013-01-21 17:19 UTC (permalink / raw)
To: linux-arm-kernel
Hi Arnd, Olof and Greg,
I have two patches for xilinx uartps serial driver (the second one fix
one issue in the first one).
These patches has been sent to arm mailing list and also to
device-tree mailing list.
There is a change in zynq dtsi that's why I think it can go through
arm-soc tree.
Please let me know if this should go through Greg serial tree.
Thanks,
Michal
The following changes since commit 7d1f9aeff1ee4a20b1aeb377dd0f579fe9647619:
Linus Torvalds (1):
Linux 3.8-rc4
are available in the git repository at:
git://git.xilinx.com/linux-xlnx.git zynq/serial
Josh Cartwright (1):
serial: xilinx_uartps: get clock rate info from dts
Wei Yongjun (1):
serial: xilinx_uartps: fix return value check in xuartps_probe()
arch/arm/boot/dts/zynq-7000.dtsi | 4 ++--
drivers/tty/serial/xilinx_uartps.c | 34 +++++++++++++++++++---------------
2 files changed, 21 insertions(+), 17 deletions(-)
^ permalink raw reply
* [PATCH] ARM: architected timers: allow dt based discovery using clocksource_of_init
From: Stephen Warren @ 2013-01-21 17:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358731326-2979-1-git-send-email-thomas.abraham@linaro.org>
On 01/20/2013 06:22 PM, Thomas Abraham wrote:
> Add an entry in __clksrc_of_table so that ARMv7 architected timer is
> discoverable using call to clocksource_of_init.
> diff --git a/arch/arm/kernel/arch_timer.c b/arch/arm/kernel/arch_timer.c
> +#ifdef CONFIG_CLKSRC_OF
> +CLOCKSOURCE_OF_DECLARE(armv7_timer, "arm,armv7-timer", arch_timer_of_register)
> +#endif
I wonder if we shouldn't enhance include/linux/clocksource.h to define
CLOCKSOURCE_OF_DECLARE even when !CONFIG_CLKSRC_OF; that way, drivers
wouldn't need that ifdef.
^ permalink raw reply
* [PATCH 02/33] ARM: Convert to devm_ioremap_resource()
From: Arnd Bergmann @ 2013-01-21 17:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130121161611.GS23505@n2100.arm.linux.org.uk>
On Monday 21 January 2013, Russell King - ARM Linux wrote:
> On Mon, Jan 21, 2013 at 05:05:47PM +0100, Thierry Reding wrote:
> > On Mon, Jan 21, 2013 at 03:58:46PM +0000, Russell King - ARM Linux wrote:
> > > On Mon, Jan 21, 2013 at 11:08:55AM +0100, Thierry Reding wrote:
> > > > Convert all uses of devm_request_and_ioremap() to the newly introduced
> > > > devm_ioremap_resource() which provides more consistent error handling.
> > >
> > > Does this include the resource part of the handling too?
> >
> > I'm not sure I understand your question. devm_ioremap_resource() does a
> > devm_request_mem_region() internally if that's what you were asking.
>
> Ah, that's fine then. The function name is a little misleading, and as
> it doesn't exist in mainline at present, it is not something I know about.
The usual problem with long patch series like this: The introductory mail
PATCH 0/xx explains this nicely, but it's not possible to put everyone
on Cc because then it gets rejected by vger for overly long mail headers.
We had a discussion about the function name earlier, but could not come
up with one that isn't too bulky but still carries the same meaning
as devm_request_and_ioremap() with a different symbol.
Arnd
^ permalink raw reply
* [PATCH 10/15] mfd/vexpress: export vexpress_config_func_{put,get}
From: Pawel Moll @ 2013-01-21 17:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358788568-11137-11-git-send-email-arnd@arndb.de>
On Mon, 2013-01-21 at 17:16 +0000, Arnd Bergmann wrote:
> The newly introduced vexpress mfd driver in linux-3.8-rc
> provides access to configuration functions, but the
> interfaces are not exported to modules, which breaks
> when the vexpress regulator driver tries to use them.
>
> Without this patch, building allmodconfig results in:
>
> ERROR: "__vexpress_config_func_get" [drivers/regulator/vexpress.ko] undefined!
> ERROR: "vexpress_config_func_put" [drivers/regulator/vexpress.ko] undefined!
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Pawel Moll <pawel.moll@arm.com>
> Cc: Samuel Ortiz <sameo@linux.intel.com>
> Cc: Mark Brown <broonie@opensource.wolfsonmicro.com>
You are the third person noticing that. My bad :-(
In fact some other ones, like the *_bridge_register could do with
exporting as well... I'll get all the patches merged in my fixes branch
and send a pull request this week.
Thanks!
Pawe?
^ permalink raw reply
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