* [PATCH 00/15] ARM build regressions in v3.8
@ 2013-01-21 17:15 ` Arnd Bergmann
0 siblings, 0 replies; 155+ messages in thread
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 [flat|nested] 155+ messages in thread* [PATCH 01/15] ARM: compressed/head.S: work around new binutils warning
2013-01-21 17:15 ` Arnd Bergmann
@ 2013-01-21 17:15 ` Arnd Bergmann
-1 siblings, 0 replies; 155+ messages in thread
From: Arnd Bergmann @ 2013-01-21 17:15 UTC (permalink / raw)
To: linux-arm-kernel
Cc: linux-kernel, arm, Arnd Bergmann, Matthew Gretton-Dann, Russell King
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 [flat|nested] 155+ messages in thread
* [PATCH 01/15] ARM: compressed/head.S: work around new binutils warning
@ 2013-01-21 17:15 ` Arnd Bergmann
0 siblings, 0 replies; 155+ messages in thread
From: Arnd Bergmann @ 2013-01-21 17:15 UTC (permalink / raw)
To: linux-arm-kernel
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 [flat|nested] 155+ messages in thread
* [PATCH 02/15] ARM: mvebu: build coherency_ll.S for arch=armv7-a
2013-01-21 17:15 ` Arnd Bergmann
@ 2013-01-21 17:15 ` Arnd Bergmann
-1 siblings, 0 replies; 155+ messages in thread
From: Arnd Bergmann @ 2013-01-21 17:15 UTC (permalink / raw)
To: linux-arm-kernel
Cc: linux-kernel, arm, Arnd Bergmann, Jason Cooper, Andrew Lunn,
Gregory Clement
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 [flat|nested] 155+ messages in thread
* [PATCH 02/15] ARM: mvebu: build coherency_ll.S for arch=armv7-a
@ 2013-01-21 17:15 ` Arnd Bergmann
0 siblings, 0 replies; 155+ messages in thread
From: Arnd Bergmann @ 2013-01-21 17:15 UTC (permalink / raw)
To: linux-arm-kernel
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 [flat|nested] 155+ messages in thread
* Re: [PATCH 02/15] ARM: mvebu: build coherency_ll.S for arch=armv7-a
2013-01-21 17:15 ` Arnd Bergmann
@ 2013-01-21 19:03 ` Tony Lindgren
-1 siblings, 0 replies; 155+ messages in thread
From: Tony Lindgren @ 2013-01-21 19:03 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-arm-kernel, linux-kernel, arm, Jason Cooper, Andrew Lunn,
Gregory Clement
* Arnd Bergmann <arnd@arndb.de> [130121 09:23]:
> 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'
This should be already fixed by 72533b (arm: mvebu: Fix compile for
multiplatform when ARMv6 is selected) in arm-soc fixes branch.
Regards,
Tony
> 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
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 155+ messages in thread
* [PATCH 02/15] ARM: mvebu: build coherency_ll.S for arch=armv7-a
@ 2013-01-21 19:03 ` Tony Lindgren
0 siblings, 0 replies; 155+ messages in thread
From: Tony Lindgren @ 2013-01-21 19:03 UTC (permalink / raw)
To: linux-arm-kernel
* Arnd Bergmann <arnd@arndb.de> [130121 09:23]:
> 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'
This should be already fixed by 72533b (arm: mvebu: Fix compile for
multiplatform when ARMv6 is selected) in arm-soc fixes branch.
Regards,
Tony
> 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
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [PATCH 02/15] ARM: mvebu: build coherency_ll.S for arch=armv7-a
2013-01-21 19:03 ` Tony Lindgren
@ 2013-01-21 20:16 ` Arnd Bergmann
-1 siblings, 0 replies; 155+ messages in thread
From: Arnd Bergmann @ 2013-01-21 20:16 UTC (permalink / raw)
To: Tony Lindgren
Cc: linux-arm-kernel, linux-kernel, arm, Jason Cooper, Andrew Lunn,
Gregory Clement
On Monday 21 January 2013, Tony Lindgren wrote:
> >
> > 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'
>
> This should be already fixed by 72533b (arm: mvebu: Fix compile for
> multiplatform when ARMv6 is selected) in arm-soc fixes branch.
>
Ok, silly me, I forgot to check my own tree :)
Thanks for looking into it!
Arnd
^ permalink raw reply [flat|nested] 155+ messages in thread
* [PATCH 02/15] ARM: mvebu: build coherency_ll.S for arch=armv7-a
@ 2013-01-21 20:16 ` Arnd Bergmann
0 siblings, 0 replies; 155+ messages in thread
From: Arnd Bergmann @ 2013-01-21 20:16 UTC (permalink / raw)
To: linux-arm-kernel
On Monday 21 January 2013, Tony Lindgren wrote:
> >
> > 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'
>
> This should be already fixed by 72533b (arm: mvebu: Fix compile for
> multiplatform when ARMv6 is selected) in arm-soc fixes branch.
>
Ok, silly me, I forgot to check my own tree :)
Thanks for looking into it!
Arnd
^ permalink raw reply [flat|nested] 155+ messages in thread
* [PATCH 03/15] ARM: samsung: fix assembly syntax for new gas
2013-01-21 17:15 ` Arnd Bergmann
@ 2013-01-21 17:15 ` Arnd Bergmann
-1 siblings, 0 replies; 155+ messages in thread
From: Arnd Bergmann @ 2013-01-21 17:15 UTC (permalink / raw)
To: linux-arm-kernel
Cc: linux-kernel, arm, Arnd Bergmann, Ben Dooks, Kukjin Kim, stable
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@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 [flat|nested] 155+ messages in thread
* [PATCH 03/15] ARM: samsung: fix assembly syntax for new gas
@ 2013-01-21 17:15 ` Arnd Bergmann
0 siblings, 0 replies; 155+ messages in thread
From: Arnd Bergmann @ 2013-01-21 17:15 UTC (permalink / raw)
To: linux-arm-kernel
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 [flat|nested] 155+ messages in thread
* [PATCH 04/15] ARM: w90x900: fix legacy assembly syntax
2013-01-21 17:15 ` Arnd Bergmann
@ 2013-01-21 17:15 ` Arnd Bergmann
-1 siblings, 0 replies; 155+ messages in thread
From: Arnd Bergmann @ 2013-01-21 17:15 UTC (permalink / raw)
To: linux-arm-kernel; +Cc: linux-kernel, arm, Arnd Bergmann, Wan ZongShun
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 [flat|nested] 155+ messages in thread
* [PATCH 04/15] ARM: w90x900: fix legacy assembly syntax
@ 2013-01-21 17:15 ` Arnd Bergmann
0 siblings, 0 replies; 155+ messages in thread
From: Arnd Bergmann @ 2013-01-21 17:15 UTC (permalink / raw)
To: linux-arm-kernel
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 [flat|nested] 155+ messages in thread
* [PATCH 05/15] ASoC: fsl: fiq and dma cannot both be modules
2013-01-21 17:15 ` Arnd Bergmann
(?)
@ 2013-01-21 17:15 ` Arnd Bergmann
-1 siblings, 0 replies; 155+ messages in thread
From: Arnd Bergmann @ 2013-01-21 17:15 UTC (permalink / raw)
To: linux-arm-kernel
Cc: linux-kernel, arm, Arnd Bergmann, Liam Girdwood, Mark Brown,
Shawn Guo, alsa-devel
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@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 [flat|nested] 155+ messages in thread
* [PATCH 05/15] ASoC: fsl: fiq and dma cannot both be modules
@ 2013-01-21 17:15 ` Arnd Bergmann
0 siblings, 0 replies; 155+ messages in thread
From: Arnd Bergmann @ 2013-01-21 17:15 UTC (permalink / raw)
To: linux-arm-kernel
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 [flat|nested] 155+ messages in thread
* [PATCH 05/15] ASoC: fsl: fiq and dma cannot both be modules
@ 2013-01-21 17:15 ` Arnd Bergmann
0 siblings, 0 replies; 155+ messages in thread
From: Arnd Bergmann @ 2013-01-21 17:15 UTC (permalink / raw)
To: linux-arm-kernel
Cc: alsa-devel, Arnd Bergmann, Mark Brown, linux-kernel, arm,
Shawn Guo, Liam Girdwood
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@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 [flat|nested] 155+ messages in thread
* Re: [PATCH 05/15] ASoC: fsl: fiq and dma cannot both be modules
2013-01-21 17:15 ` Arnd Bergmann
(?)
@ 2013-01-22 3:50 ` Shawn Guo
-1 siblings, 0 replies; 155+ messages in thread
From: Shawn Guo @ 2013-01-22 3:50 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-arm-kernel, linux-kernel, arm, Liam Girdwood, Mark Brown,
alsa-devel
On Mon, Jan 21, 2013 at 05:15:58PM +0000, Arnd Bergmann wrote:
> 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@alsa-project.org
I sent a fix [1] for that queued by Mark.
Mark,
Is the patch on the way to 3.8-rc?
Shawn
[1] http://thread.gmane.org/gmane.linux.alsa.devel/104434
^ permalink raw reply [flat|nested] 155+ messages in thread
* [PATCH 05/15] ASoC: fsl: fiq and dma cannot both be modules
@ 2013-01-22 3:50 ` Shawn Guo
0 siblings, 0 replies; 155+ messages in thread
From: Shawn Guo @ 2013-01-22 3:50 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, Jan 21, 2013 at 05:15:58PM +0000, Arnd Bergmann wrote:
> 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
I sent a fix [1] for that queued by Mark.
Mark,
Is the patch on the way to 3.8-rc?
Shawn
[1] http://thread.gmane.org/gmane.linux.alsa.devel/104434
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [PATCH 05/15] ASoC: fsl: fiq and dma cannot both be modules
@ 2013-01-22 3:50 ` Shawn Guo
0 siblings, 0 replies; 155+ messages in thread
From: Shawn Guo @ 2013-01-22 3:50 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-arm-kernel, linux-kernel, arm, Liam Girdwood, Mark Brown,
alsa-devel
On Mon, Jan 21, 2013 at 05:15:58PM +0000, Arnd Bergmann wrote:
> 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@alsa-project.org
I sent a fix [1] for that queued by Mark.
Mark,
Is the patch on the way to 3.8-rc?
Shawn
[1] http://thread.gmane.org/gmane.linux.alsa.devel/104434
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [PATCH 05/15] ASoC: fsl: fiq and dma cannot both be modules
2013-01-22 3:50 ` Shawn Guo
@ 2013-01-22 6:33 ` Mark Brown
-1 siblings, 0 replies; 155+ messages in thread
From: Mark Brown @ 2013-01-22 6:33 UTC (permalink / raw)
To: Shawn Guo
Cc: Arnd Bergmann, linux-arm-kernel, linux-kernel, arm,
Liam Girdwood, alsa-devel
[-- Attachment #1: Type: text/plain, Size: 767 bytes --]
On Tue, Jan 22, 2013 at 11:50:30AM +0800, Shawn Guo wrote:
> On Mon, Jan 21, 2013 at 05:15:58PM +0000, Arnd Bergmann wrote:
> > 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
> I sent a fix [1] for that queued by Mark.
> Mark,
> Is the patch on the way to 3.8-rc?
Yes, should be.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 155+ messages in thread
* [PATCH 05/15] ASoC: fsl: fiq and dma cannot both be modules
@ 2013-01-22 6:33 ` Mark Brown
0 siblings, 0 replies; 155+ messages in thread
From: Mark Brown @ 2013-01-22 6:33 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Jan 22, 2013 at 11:50:30AM +0800, Shawn Guo wrote:
> On Mon, Jan 21, 2013 at 05:15:58PM +0000, Arnd Bergmann wrote:
> > 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
> I sent a fix [1] for that queued by Mark.
> Mark,
> Is the patch on the way to 3.8-rc?
Yes, should be.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130122/831a9df6/attachment.sig>
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [PATCH 05/15] ASoC: fsl: fiq and dma cannot both be modules
2013-01-22 6:33 ` Mark Brown
@ 2013-01-22 8:21 ` Arnd Bergmann
-1 siblings, 0 replies; 155+ messages in thread
From: Arnd Bergmann @ 2013-01-22 8:21 UTC (permalink / raw)
To: Mark Brown
Cc: Shawn Guo, linux-arm-kernel, linux-kernel, arm, Liam Girdwood,
alsa-devel
On Tuesday 22 January 2013, Mark Brown wrote:
> On Tue, Jan 22, 2013 at 11:50:30AM +0800, Shawn Guo wrote:
> > I sent a fix [1] for that queued by Mark.
Right, that patch looks good, too.
> > Is the patch on the way to 3.8-rc?
>
> Yes, should be.
Ok, thanks!
Arnd
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [PATCH 05/15] ASoC: fsl: fiq and dma cannot both be modules
2013-01-22 6:33 ` Mark Brown
@ 2013-02-05 16:21 ` Arnd Bergmann
-1 siblings, 0 replies; 155+ messages in thread
From: Arnd Bergmann @ 2013-02-05 16:21 UTC (permalink / raw)
To: Mark Brown
Cc: Shawn Guo, linux-arm-kernel, linux-kernel, arm, Liam Girdwood,
alsa-devel
On Tuesday 22 January 2013, Mark Brown wrote:
> Show Details
> On Tue, Jan 22, 2013 at 11:50:30AM +0800, Shawn Guo wrote:
> > On Mon, Jan 21, 2013 at 05:15:58PM +0000, Arnd Bergmann wrote:
>
> > > 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
>
> > I sent a fix [1] for that queued by Mark.
>
> > Mark,
>
> > Is the patch on the way to 3.8-rc?
>
> Yes, should be.
>
Hmm, I tried building 3.8-rc again, which contains the fix to make
'make allmodconfig' work with this code, but it broke 'make allyesconfig', which
was working before :(
8<----------
Subject: [PATCH] ASoC: fsl: fix allyesconfig build for imx-pcm
Patch 25b8d314 "ASoC: fsl: fix multiple definition of init_module changed
the Makefile for imx-pcm.ko to build two modules that both contain the
imx-pcm.c file, which nicely solves the problem of building both versions
of the driver as modules, but it causes two new problems:
1. Since imx-pcm.c is now used in two different modules, Kbuild no longer
sets the KBUILD_MODNAME symbol when building the object file, which makes
it impossible to use dynamic pr_debug code, resulting in this error
sound/soc/fsl/imx-pcm.c: In function 'snd_imx_pcm_mmap':
sound/soc/fsl/imx-pcm.c:28:121: error: 'KBUILD_MODNAME' undeclared (first use in this function)
sound/soc/fsl/imx-pcm.c:28:121: note: each undeclared identifier is reported only once for each function it appears insound/soc/fsl/snd-soc-imx-pcm-dma.o: In function `imx_pcm_free':
2. If we don't use the dynamic debug code, we get a link error since we now
try to link together the same file into built-in.o twice:
sound/soc/fsl/imx-pcm.c:80: multiple definition of `imx_pcm_free'
sound/soc/fsl/snd-soc-imx-pcm-fiq.o:/sound/soc/fsl/imx-pcm.c:80: first defined here
sound/soc/fsl/snd-soc-imx-pcm-dma.o: In function `snd_imx_pcm_mmap':
sound/soc/fsl/imx-pcm.c:21: multiple definition of `snd_imx_pcm_mmap'
sound/soc/fsl/snd-soc-imx-pcm-fiq.o:/sound/soc/fsl/imx-pcm.c:21: first defined here
sound/soc/fsl/snd-soc-imx-pcm-dma.o: In function `imx_pcm_new':
sound/soc/fsl/imx-pcm.c:52: multiple definition of `imx_pcm_new'
sound/soc/fsl/snd-soc-imx-pcm-fiq.o:/sound/soc/fsl/imx-pcm.c:52: first defined here
I originally suggested disallowing the selection of both the DMA and FIQ
code in the same kernel. That is not very nice, but it resolves the
build error for both built-in and modular code.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
diff --git a/sound/soc/fsl/Kconfig b/sound/soc/fsl/Kconfig
index e24e417..3f20cb7 100644
--- a/sound/soc/fsl/Kconfig
+++ b/sound/soc/fsl/Kconfig
@@ -122,7 +122,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
+ depends on !SND_SOC_IMX_PCM_DMA
select SND_SOC_WM8350
select SND_SOC_IMX_PCM_FIQ
select SND_SOC_IMX_AUDMUX
@@ -145,7 +145,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
+ depends on !SND_SOC_IMX_PCM_DMA
select SND_SOC_AC97_BUS
select SND_SOC_WM9712
select SND_SOC_IMX_PCM_FIQ
@@ -162,7 +162,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
+ depends on !SND_SOC_IMX_PCM_DMA
select SND_SOC_TLV320AIC23
select SND_SOC_IMX_PCM_FIQ
select SND_SOC_IMX_AUDMUX
diff --git a/sound/soc/fsl/Makefile b/sound/soc/fsl/Makefile
index ec14579..ddd9076 100644
--- a/sound/soc/fsl/Makefile
+++ b/sound/soc/fsl/Makefile
@@ -30,13 +30,6 @@ obj-$(CONFIG_SND_MPC52xx_SOC_EFIKA) += efika-audio-fabric.o
# i.MX Platform Support
snd-soc-imx-ssi-objs := imx-ssi.o
snd-soc-imx-audmux-objs := imx-audmux.o
-snd-soc-imx-pcm-objs := imx-pcm.o
-ifneq ($(CONFIG_SND_SOC_IMX_PCM_FIQ),)
- snd-soc-imx-pcm-objs += imx-pcm-fiq.o
-endif
-ifneq ($(CONFIG_SND_SOC_IMX_PCM_DMA),)
- snd-soc-imx-pcm-objs += imx-pcm-dma.o
-endif
obj-$(CONFIG_SND_SOC_IMX_SSI) += snd-soc-imx-ssi.o
obj-$(CONFIG_SND_SOC_IMX_AUDMUX) += snd-soc-imx-audmux.o
^ permalink raw reply related [flat|nested] 155+ messages in thread
* [PATCH 05/15] ASoC: fsl: fiq and dma cannot both be modules
@ 2013-02-05 16:21 ` Arnd Bergmann
0 siblings, 0 replies; 155+ messages in thread
From: Arnd Bergmann @ 2013-02-05 16:21 UTC (permalink / raw)
To: linux-arm-kernel
On Tuesday 22 January 2013, Mark Brown wrote:
> Show Details
> On Tue, Jan 22, 2013 at 11:50:30AM +0800, Shawn Guo wrote:
> > On Mon, Jan 21, 2013 at 05:15:58PM +0000, Arnd Bergmann wrote:
>
> > > 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
>
> > I sent a fix [1] for that queued by Mark.
>
> > Mark,
>
> > Is the patch on the way to 3.8-rc?
>
> Yes, should be.
>
Hmm, I tried building 3.8-rc again, which contains the fix to make
'make allmodconfig' work with this code, but it broke 'make allyesconfig', which
was working before :(
8<----------
Subject: [PATCH] ASoC: fsl: fix allyesconfig build for imx-pcm
Patch 25b8d314 "ASoC: fsl: fix multiple definition of init_module changed
the Makefile for imx-pcm.ko to build two modules that both contain the
imx-pcm.c file, which nicely solves the problem of building both versions
of the driver as modules, but it causes two new problems:
1. Since imx-pcm.c is now used in two different modules, Kbuild no longer
sets the KBUILD_MODNAME symbol when building the object file, which makes
it impossible to use dynamic pr_debug code, resulting in this error
sound/soc/fsl/imx-pcm.c: In function 'snd_imx_pcm_mmap':
sound/soc/fsl/imx-pcm.c:28:121: error: 'KBUILD_MODNAME' undeclared (first use in this function)
sound/soc/fsl/imx-pcm.c:28:121: note: each undeclared identifier is reported only once for each function it appears insound/soc/fsl/snd-soc-imx-pcm-dma.o: In function `imx_pcm_free':
2. If we don't use the dynamic debug code, we get a link error since we now
try to link together the same file into built-in.o twice:
sound/soc/fsl/imx-pcm.c:80: multiple definition of `imx_pcm_free'
sound/soc/fsl/snd-soc-imx-pcm-fiq.o:/sound/soc/fsl/imx-pcm.c:80: first defined here
sound/soc/fsl/snd-soc-imx-pcm-dma.o: In function `snd_imx_pcm_mmap':
sound/soc/fsl/imx-pcm.c:21: multiple definition of `snd_imx_pcm_mmap'
sound/soc/fsl/snd-soc-imx-pcm-fiq.o:/sound/soc/fsl/imx-pcm.c:21: first defined here
sound/soc/fsl/snd-soc-imx-pcm-dma.o: In function `imx_pcm_new':
sound/soc/fsl/imx-pcm.c:52: multiple definition of `imx_pcm_new'
sound/soc/fsl/snd-soc-imx-pcm-fiq.o:/sound/soc/fsl/imx-pcm.c:52: first defined here
I originally suggested disallowing the selection of both the DMA and FIQ
code in the same kernel. That is not very nice, but it resolves the
build error for both built-in and modular code.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
diff --git a/sound/soc/fsl/Kconfig b/sound/soc/fsl/Kconfig
index e24e417..3f20cb7 100644
--- a/sound/soc/fsl/Kconfig
+++ b/sound/soc/fsl/Kconfig
@@ -122,7 +122,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
+ depends on !SND_SOC_IMX_PCM_DMA
select SND_SOC_WM8350
select SND_SOC_IMX_PCM_FIQ
select SND_SOC_IMX_AUDMUX
@@ -145,7 +145,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
+ depends on !SND_SOC_IMX_PCM_DMA
select SND_SOC_AC97_BUS
select SND_SOC_WM9712
select SND_SOC_IMX_PCM_FIQ
@@ -162,7 +162,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
+ depends on !SND_SOC_IMX_PCM_DMA
select SND_SOC_TLV320AIC23
select SND_SOC_IMX_PCM_FIQ
select SND_SOC_IMX_AUDMUX
diff --git a/sound/soc/fsl/Makefile b/sound/soc/fsl/Makefile
index ec14579..ddd9076 100644
--- a/sound/soc/fsl/Makefile
+++ b/sound/soc/fsl/Makefile
@@ -30,13 +30,6 @@ obj-$(CONFIG_SND_MPC52xx_SOC_EFIKA) += efika-audio-fabric.o
# i.MX Platform Support
snd-soc-imx-ssi-objs := imx-ssi.o
snd-soc-imx-audmux-objs := imx-audmux.o
-snd-soc-imx-pcm-objs := imx-pcm.o
-ifneq ($(CONFIG_SND_SOC_IMX_PCM_FIQ),)
- snd-soc-imx-pcm-objs += imx-pcm-fiq.o
-endif
-ifneq ($(CONFIG_SND_SOC_IMX_PCM_DMA),)
- snd-soc-imx-pcm-objs += imx-pcm-dma.o
-endif
obj-$(CONFIG_SND_SOC_IMX_SSI) += snd-soc-imx-ssi.o
obj-$(CONFIG_SND_SOC_IMX_AUDMUX) += snd-soc-imx-audmux.o
^ permalink raw reply related [flat|nested] 155+ messages in thread
* [PATCH] ASoC: fsl: fix allyesconfig build for imx-pcm
2013-02-05 16:21 ` Arnd Bergmann
@ 2013-02-05 16:42 ` Arnd Bergmann
-1 siblings, 0 replies; 155+ messages in thread
From: Arnd Bergmann @ 2013-02-05 16:42 UTC (permalink / raw)
To: Mark Brown
Cc: Shawn Guo, linux-arm-kernel, linux-kernel, arm, Liam Girdwood,
alsa-devel
Patch 25b8d314 "ASoC: fsl: fix multiple definition of init_module changed
the Makefile for imx-pcm.ko to build two modules that both contain the
imx-pcm.c file, which nicely solves the problem of building both versions
of the driver as modules, but it causes two new problems:
1. Since imx-pcm.c is now used in two different modules, Kbuild no longer
sets the KBUILD_MODNAME symbol when building the object file, which makes
it impossible to use dynamic pr_debug code, resulting in this error
sound/soc/fsl/imx-pcm.c: In function 'snd_imx_pcm_mmap':
sound/soc/fsl/imx-pcm.c:28:121: error: 'KBUILD_MODNAME' undeclared (first use in this function)
sound/soc/fsl/imx-pcm.c:28:121: note: each undeclared identifier is reported only once for each function it appears insound/soc/fsl/snd-soc-imx-pcm-dma.o: In function `imx_pcm_free':
2. If we don't use the dynamic debug code, we get a link error since we now
try to link together the same file into built-in.o twice:
sound/soc/fsl/imx-pcm.c:80: multiple definition of `imx_pcm_free'
sound/soc/fsl/snd-soc-imx-pcm-fiq.o:/sound/soc/fsl/imx-pcm.c:80: first defined here
sound/soc/fsl/snd-soc-imx-pcm-dma.o: In function `snd_imx_pcm_mmap':
sound/soc/fsl/imx-pcm.c:21: multiple definition of `snd_imx_pcm_mmap'
sound/soc/fsl/snd-soc-imx-pcm-fiq.o:/sound/soc/fsl/imx-pcm.c:21: first defined here
sound/soc/fsl/snd-soc-imx-pcm-dma.o: In function `imx_pcm_new':
sound/soc/fsl/imx-pcm.c:52: multiple definition of `imx_pcm_new'
sound/soc/fsl/snd-soc-imx-pcm-fiq.o:/sound/soc/fsl/imx-pcm.c:52: first defined here
I originally suggested disallowing the selection of both the DMA and FIQ
code in the same kernel. That is not very nice, but it resolves the
build error for both built-in and modular code.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
----
Sorry, the previous version did not apply, it was on top of my older patch accidentally
diff --git a/sound/soc/fsl/Kconfig b/sound/soc/fsl/Kconfig
index a210c8d..3f20cb7 100644
--- a/sound/soc/fsl/Kconfig
+++ b/sound/soc/fsl/Kconfig
@@ -122,6 +122,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
select SND_SOC_WM8350
select SND_SOC_IMX_PCM_FIQ
select SND_SOC_IMX_AUDMUX
@@ -144,6 +145,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
select SND_SOC_AC97_BUS
select SND_SOC_WM9712
select SND_SOC_IMX_PCM_FIQ
@@ -160,6 +162,7 @@ config SND_SOC_EUKREA_TLV320
|| MACH_EUKREA_MBIMXSD35_BASEBOARD \
|| MACH_EUKREA_MBIMXSD51_BASEBOARD
depends on I2C
+ depends on !SND_SOC_IMX_PCM_DMA
select SND_SOC_TLV320AIC23
select SND_SOC_IMX_PCM_FIQ
select SND_SOC_IMX_AUDMUX
diff --git a/sound/soc/fsl/Makefile b/sound/soc/fsl/Makefile
index ec14579..ddd9076 100644
--- a/sound/soc/fsl/Makefile
+++ b/sound/soc/fsl/Makefile
@@ -30,13 +30,6 @@ obj-$(CONFIG_SND_MPC52xx_SOC_EFIKA) += efika-audio-fabric.o
# i.MX Platform Support
snd-soc-imx-ssi-objs := imx-ssi.o
snd-soc-imx-audmux-objs := imx-audmux.o
-snd-soc-imx-pcm-objs := imx-pcm.o
-ifneq ($(CONFIG_SND_SOC_IMX_PCM_FIQ),)
- snd-soc-imx-pcm-objs += imx-pcm-fiq.o
-endif
-ifneq ($(CONFIG_SND_SOC_IMX_PCM_DMA),)
- snd-soc-imx-pcm-objs += imx-pcm-dma.o
-endif
obj-$(CONFIG_SND_SOC_IMX_SSI) += snd-soc-imx-ssi.o
obj-$(CONFIG_SND_SOC_IMX_AUDMUX) += snd-soc-imx-audmux.o
^ permalink raw reply related [flat|nested] 155+ messages in thread
* [PATCH] ASoC: fsl: fix allyesconfig build for imx-pcm
@ 2013-02-05 16:42 ` Arnd Bergmann
0 siblings, 0 replies; 155+ messages in thread
From: Arnd Bergmann @ 2013-02-05 16:42 UTC (permalink / raw)
To: linux-arm-kernel
Patch 25b8d314 "ASoC: fsl: fix multiple definition of init_module changed
the Makefile for imx-pcm.ko to build two modules that both contain the
imx-pcm.c file, which nicely solves the problem of building both versions
of the driver as modules, but it causes two new problems:
1. Since imx-pcm.c is now used in two different modules, Kbuild no longer
sets the KBUILD_MODNAME symbol when building the object file, which makes
it impossible to use dynamic pr_debug code, resulting in this error
sound/soc/fsl/imx-pcm.c: In function 'snd_imx_pcm_mmap':
sound/soc/fsl/imx-pcm.c:28:121: error: 'KBUILD_MODNAME' undeclared (first use in this function)
sound/soc/fsl/imx-pcm.c:28:121: note: each undeclared identifier is reported only once for each function it appears insound/soc/fsl/snd-soc-imx-pcm-dma.o: In function `imx_pcm_free':
2. If we don't use the dynamic debug code, we get a link error since we now
try to link together the same file into built-in.o twice:
sound/soc/fsl/imx-pcm.c:80: multiple definition of `imx_pcm_free'
sound/soc/fsl/snd-soc-imx-pcm-fiq.o:/sound/soc/fsl/imx-pcm.c:80: first defined here
sound/soc/fsl/snd-soc-imx-pcm-dma.o: In function `snd_imx_pcm_mmap':
sound/soc/fsl/imx-pcm.c:21: multiple definition of `snd_imx_pcm_mmap'
sound/soc/fsl/snd-soc-imx-pcm-fiq.o:/sound/soc/fsl/imx-pcm.c:21: first defined here
sound/soc/fsl/snd-soc-imx-pcm-dma.o: In function `imx_pcm_new':
sound/soc/fsl/imx-pcm.c:52: multiple definition of `imx_pcm_new'
sound/soc/fsl/snd-soc-imx-pcm-fiq.o:/sound/soc/fsl/imx-pcm.c:52: first defined here
I originally suggested disallowing the selection of both the DMA and FIQ
code in the same kernel. That is not very nice, but it resolves the
build error for both built-in and modular code.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
----
Sorry, the previous version did not apply, it was on top of my older patch accidentally
diff --git a/sound/soc/fsl/Kconfig b/sound/soc/fsl/Kconfig
index a210c8d..3f20cb7 100644
--- a/sound/soc/fsl/Kconfig
+++ b/sound/soc/fsl/Kconfig
@@ -122,6 +122,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
select SND_SOC_WM8350
select SND_SOC_IMX_PCM_FIQ
select SND_SOC_IMX_AUDMUX
@@ -144,6 +145,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
select SND_SOC_AC97_BUS
select SND_SOC_WM9712
select SND_SOC_IMX_PCM_FIQ
@@ -160,6 +162,7 @@ config SND_SOC_EUKREA_TLV320
|| MACH_EUKREA_MBIMXSD35_BASEBOARD \
|| MACH_EUKREA_MBIMXSD51_BASEBOARD
depends on I2C
+ depends on !SND_SOC_IMX_PCM_DMA
select SND_SOC_TLV320AIC23
select SND_SOC_IMX_PCM_FIQ
select SND_SOC_IMX_AUDMUX
diff --git a/sound/soc/fsl/Makefile b/sound/soc/fsl/Makefile
index ec14579..ddd9076 100644
--- a/sound/soc/fsl/Makefile
+++ b/sound/soc/fsl/Makefile
@@ -30,13 +30,6 @@ obj-$(CONFIG_SND_MPC52xx_SOC_EFIKA) += efika-audio-fabric.o
# i.MX Platform Support
snd-soc-imx-ssi-objs := imx-ssi.o
snd-soc-imx-audmux-objs := imx-audmux.o
-snd-soc-imx-pcm-objs := imx-pcm.o
-ifneq ($(CONFIG_SND_SOC_IMX_PCM_FIQ),)
- snd-soc-imx-pcm-objs += imx-pcm-fiq.o
-endif
-ifneq ($(CONFIG_SND_SOC_IMX_PCM_DMA),)
- snd-soc-imx-pcm-objs += imx-pcm-dma.o
-endif
obj-$(CONFIG_SND_SOC_IMX_SSI) += snd-soc-imx-ssi.o
obj-$(CONFIG_SND_SOC_IMX_AUDMUX) += snd-soc-imx-audmux.o
^ permalink raw reply related [flat|nested] 155+ messages in thread
* Re: [PATCH] ASoC: fsl: fix allyesconfig build for imx-pcm
2013-02-05 16:42 ` Arnd Bergmann
(?)
@ 2013-02-06 4:02 ` Shawn Guo
-1 siblings, 0 replies; 155+ messages in thread
From: Shawn Guo @ 2013-02-06 4:02 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Mark Brown, linux-arm-kernel, linux-kernel, arm, Liam Girdwood,
alsa-devel
On Tue, Feb 05, 2013 at 04:42:25PM +0000, Arnd Bergmann wrote:
> Patch 25b8d314 "ASoC: fsl: fix multiple definition of init_module changed
> the Makefile for imx-pcm.ko to build two modules that both contain the
> imx-pcm.c file, which nicely solves the problem of building both versions
> of the driver as modules, but it causes two new problems:
>
It's my fault, Arnd. The patch 25b8d314 is a crap. Instead of making
the Kconfig even complexer, I chose to revert the patch and do a little
surgery on the code to make it match the Kconfig rational. The fix[1]
should be on the way to mainline now.
I'm sorry for messing thing up during -rc time.
Shawn
[1] http://thread.gmane.org/gmane.linux.alsa.devel/105018
^ permalink raw reply [flat|nested] 155+ messages in thread
* [PATCH] ASoC: fsl: fix allyesconfig build for imx-pcm
@ 2013-02-06 4:02 ` Shawn Guo
0 siblings, 0 replies; 155+ messages in thread
From: Shawn Guo @ 2013-02-06 4:02 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Feb 05, 2013 at 04:42:25PM +0000, Arnd Bergmann wrote:
> Patch 25b8d314 "ASoC: fsl: fix multiple definition of init_module changed
> the Makefile for imx-pcm.ko to build two modules that both contain the
> imx-pcm.c file, which nicely solves the problem of building both versions
> of the driver as modules, but it causes two new problems:
>
It's my fault, Arnd. The patch 25b8d314 is a crap. Instead of making
the Kconfig even complexer, I chose to revert the patch and do a little
surgery on the code to make it match the Kconfig rational. The fix[1]
should be on the way to mainline now.
I'm sorry for messing thing up during -rc time.
Shawn
[1] http://thread.gmane.org/gmane.linux.alsa.devel/105018
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [PATCH] ASoC: fsl: fix allyesconfig build for imx-pcm
@ 2013-02-06 4:02 ` Shawn Guo
0 siblings, 0 replies; 155+ messages in thread
From: Shawn Guo @ 2013-02-06 4:02 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Mark Brown, linux-arm-kernel, linux-kernel, arm, Liam Girdwood,
alsa-devel
On Tue, Feb 05, 2013 at 04:42:25PM +0000, Arnd Bergmann wrote:
> Patch 25b8d314 "ASoC: fsl: fix multiple definition of init_module changed
> the Makefile for imx-pcm.ko to build two modules that both contain the
> imx-pcm.c file, which nicely solves the problem of building both versions
> of the driver as modules, but it causes two new problems:
>
It's my fault, Arnd. The patch 25b8d314 is a crap. Instead of making
the Kconfig even complexer, I chose to revert the patch and do a little
surgery on the code to make it match the Kconfig rational. The fix[1]
should be on the way to mainline now.
I'm sorry for messing thing up during -rc time.
Shawn
[1] http://thread.gmane.org/gmane.linux.alsa.devel/105018
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [PATCH] ASoC: fsl: fix allyesconfig build for imx-pcm
2013-02-06 4:02 ` Shawn Guo
@ 2013-02-06 8:58 ` Arnd Bergmann
-1 siblings, 0 replies; 155+ messages in thread
From: Arnd Bergmann @ 2013-02-06 8:58 UTC (permalink / raw)
To: Shawn Guo
Cc: Mark Brown, linux-arm-kernel, linux-kernel, arm, Liam Girdwood,
alsa-devel
On Wednesday 06 February 2013, Shawn Guo wrote:
> On Tue, Feb 05, 2013 at 04:42:25PM +0000, Arnd Bergmann wrote:
> > Patch 25b8d314 "ASoC: fsl: fix multiple definition of init_module changed
> > the Makefile for imx-pcm.ko to build two modules that both contain the
> > imx-pcm.c file, which nicely solves the problem of building both versions
> > of the driver as modules, but it causes two new problems:
> >
> It's my fault, Arnd. The patch 25b8d314 is a crap. Instead of making
> the Kconfig even complexer, I chose to revert the patch and do a little
> surgery on the code to make it match the Kconfig rational. The fix[1]
> should be on the way to mainline now.
>
> I'm sorry for messing thing up during -rc time.
>
> Shawn
>
> [1] http://thread.gmane.org/gmane.linux.alsa.devel/105018
>
Ok, again you were faster than I was at finding a solution, and the
new one looks good to me.
Thanks for taking care of this already,
Arnd
^ permalink raw reply [flat|nested] 155+ messages in thread
* [PATCH] ASoC: fsl: fix allyesconfig build for imx-pcm
@ 2013-02-06 8:58 ` Arnd Bergmann
0 siblings, 0 replies; 155+ messages in thread
From: Arnd Bergmann @ 2013-02-06 8:58 UTC (permalink / raw)
To: linux-arm-kernel
On Wednesday 06 February 2013, Shawn Guo wrote:
> On Tue, Feb 05, 2013 at 04:42:25PM +0000, Arnd Bergmann wrote:
> > Patch 25b8d314 "ASoC: fsl: fix multiple definition of init_module changed
> > the Makefile for imx-pcm.ko to build two modules that both contain the
> > imx-pcm.c file, which nicely solves the problem of building both versions
> > of the driver as modules, but it causes two new problems:
> >
> It's my fault, Arnd. The patch 25b8d314 is a crap. Instead of making
> the Kconfig even complexer, I chose to revert the patch and do a little
> surgery on the code to make it match the Kconfig rational. The fix[1]
> should be on the way to mainline now.
>
> I'm sorry for messing thing up during -rc time.
>
> Shawn
>
> [1] http://thread.gmane.org/gmane.linux.alsa.devel/105018
>
Ok, again you were faster than I was at finding a solution, and the
new one looks good to me.
Thanks for taking care of this already,
Arnd
^ permalink raw reply [flat|nested] 155+ messages in thread
* [PATCH 06/15] clk: export __clk_get_name
2013-01-21 17:15 ` Arnd Bergmann
@ 2013-01-21 17:15 ` Arnd Bergmann
-1 siblings, 0 replies; 155+ messages in thread
From: Arnd Bergmann @ 2013-01-21 17:15 UTC (permalink / raw)
To: linux-arm-kernel
Cc: linux-kernel, arm, Arnd Bergmann, Sascha Hauer, Mike Turquette
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 [flat|nested] 155+ messages in thread* [PATCH 06/15] clk: export __clk_get_name
@ 2013-01-21 17:15 ` Arnd Bergmann
0 siblings, 0 replies; 155+ messages in thread
From: Arnd Bergmann @ 2013-01-21 17:15 UTC (permalink / raw)
To: linux-arm-kernel
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 [flat|nested] 155+ messages in thread* Re: [PATCH 06/15] clk: export __clk_get_name
2013-01-21 17:15 ` Arnd Bergmann
@ 2013-01-21 20:51 ` Ulf Hansson
-1 siblings, 0 replies; 155+ messages in thread
From: Ulf Hansson @ 2013-01-21 20:51 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-arm-kernel, linux-kernel, arm, Sascha Hauer, Mike Turquette
On 21 January 2013 18:15, Arnd Bergmann <arnd@arndb.de> wrote:
> 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
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
Acked-by: Ulf Hansson <ulf.hansson@linaro.org>
^ permalink raw reply [flat|nested] 155+ messages in thread* [PATCH 06/15] clk: export __clk_get_name
@ 2013-01-21 20:51 ` Ulf Hansson
0 siblings, 0 replies; 155+ messages in thread
From: Ulf Hansson @ 2013-01-21 20:51 UTC (permalink / raw)
To: linux-arm-kernel
On 21 January 2013 18:15, Arnd Bergmann <arnd@arndb.de> wrote:
> 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
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
Acked-by: Ulf Hansson <ulf.hansson@linaro.org>
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [PATCH 06/15] clk: export __clk_get_name
2013-01-21 17:15 ` Arnd Bergmann
@ 2013-01-22 10:54 ` Fabio Estevam
-1 siblings, 0 replies; 155+ messages in thread
From: Fabio Estevam @ 2013-01-22 10:54 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-arm-kernel, Sascha Hauer, arm, Mike Turquette, linux-kernel
On Mon, Jan 21, 2013 at 3:15 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> 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>
A fix from Niels de Vos has already been applied into clk-next:
https://patchwork.kernel.org/patch/1871981/
^ permalink raw reply [flat|nested] 155+ messages in thread
* [PATCH 06/15] clk: export __clk_get_name
@ 2013-01-22 10:54 ` Fabio Estevam
0 siblings, 0 replies; 155+ messages in thread
From: Fabio Estevam @ 2013-01-22 10:54 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, Jan 21, 2013 at 3:15 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> 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>
A fix from Niels de Vos has already been applied into clk-next:
https://patchwork.kernel.org/patch/1871981/
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [PATCH 06/15] clk: export __clk_get_name
2013-01-22 10:54 ` Fabio Estevam
@ 2013-01-22 15:43 ` Arnd Bergmann
-1 siblings, 0 replies; 155+ messages in thread
From: Arnd Bergmann @ 2013-01-22 15:43 UTC (permalink / raw)
To: Fabio Estevam
Cc: linux-arm-kernel, Sascha Hauer, arm, Mike Turquette, linux-kernel
On Tuesday 22 January 2013, Fabio Estevam wrote:
> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > Cc: Sascha Hauer <s.hauer@pengutronix.de>
> > Cc: Mike Turquette <mturquette@linaro.org>
>
> A fix from Niels de Vos has already been applied into clk-next:
> https://patchwork.kernel.org/patch/1871981/
Ok, very good. Mike, I saw that the patch is over
a month old. Any reason it hasn't made it into v3.8.rc yet?
Arnd
^ permalink raw reply [flat|nested] 155+ messages in thread
* [PATCH 06/15] clk: export __clk_get_name
@ 2013-01-22 15:43 ` Arnd Bergmann
0 siblings, 0 replies; 155+ messages in thread
From: Arnd Bergmann @ 2013-01-22 15:43 UTC (permalink / raw)
To: linux-arm-kernel
On Tuesday 22 January 2013, Fabio Estevam wrote:
> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > Cc: Sascha Hauer <s.hauer@pengutronix.de>
> > Cc: Mike Turquette <mturquette@linaro.org>
>
> A fix from Niels de Vos has already been applied into clk-next:
> https://patchwork.kernel.org/patch/1871981/
Ok, very good. Mike, I saw that the patch is over
a month old. Any reason it hasn't made it into v3.8.rc yet?
Arnd
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [PATCH 06/15] clk: export __clk_get_name
2013-01-22 15:43 ` Arnd Bergmann
@ 2013-02-14 17:41 ` Arnd Bergmann
-1 siblings, 0 replies; 155+ messages in thread
From: Arnd Bergmann @ 2013-02-14 17:41 UTC (permalink / raw)
To: Fabio Estevam
Cc: linux-arm-kernel, Sascha Hauer, arm, Mike Turquette, linux-kernel
On Tuesday 22 January 2013, Arnd Bergmann wrote:
> On Tuesday 22 January 2013, Fabio Estevam wrote:
> > > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > > Cc: Sascha Hauer <s.hauer@pengutronix.de>
> > > Cc: Mike Turquette <mturquette@linaro.org>
> >
> > A fix from Niels de Vos has already been applied into clk-next:
> > https://patchwork.kernel.org/patch/1871981/
>
> Ok, very good. Mike, I saw that the patch is over
> a month old. Any reason it hasn't made it into v3.8.rc yet?
>
I guess we missed this one for 3.8 then, meaning we have no
working allmodconfig :(
Arnd
^ permalink raw reply [flat|nested] 155+ messages in thread
* [PATCH 06/15] clk: export __clk_get_name
@ 2013-02-14 17:41 ` Arnd Bergmann
0 siblings, 0 replies; 155+ messages in thread
From: Arnd Bergmann @ 2013-02-14 17:41 UTC (permalink / raw)
To: linux-arm-kernel
On Tuesday 22 January 2013, Arnd Bergmann wrote:
> On Tuesday 22 January 2013, Fabio Estevam wrote:
> > > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > > Cc: Sascha Hauer <s.hauer@pengutronix.de>
> > > Cc: Mike Turquette <mturquette@linaro.org>
> >
> > A fix from Niels de Vos has already been applied into clk-next:
> > https://patchwork.kernel.org/patch/1871981/
>
> Ok, very good. Mike, I saw that the patch is over
> a month old. Any reason it hasn't made it into v3.8.rc yet?
>
I guess we missed this one for 3.8 then, meaning we have no
working allmodconfig :(
Arnd
^ permalink raw reply [flat|nested] 155+ messages in thread
* [PATCH 07/15] drm/exynos: don't include plat/gpio-cfg.h
2013-01-21 17:15 ` Arnd Bergmann
@ 2013-01-21 17:16 ` Arnd Bergmann
-1 siblings, 0 replies; 155+ messages in thread
From: Arnd Bergmann @ 2013-01-21 17:16 UTC (permalink / raw)
To: linux-arm-kernel
Cc: linux-kernel, arm, Arnd Bergmann, Rob Clark, Inki Dae,
Kyungmin Park, Rahul Sharma
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 [flat|nested] 155+ messages in thread
* [PATCH 07/15] drm/exynos: don't include plat/gpio-cfg.h
@ 2013-01-21 17:16 ` Arnd Bergmann
0 siblings, 0 replies; 155+ messages in thread
From: Arnd Bergmann @ 2013-01-21 17:16 UTC (permalink / raw)
To: linux-arm-kernel
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 [flat|nested] 155+ messages in thread
* [PATCH 08/15] drm/exynos: fimd and ipp are broken on multiplatform
2013-01-21 17:15 ` Arnd Bergmann
(?)
@ 2013-01-21 17:16 ` Arnd Bergmann
-1 siblings, 0 replies; 155+ messages in thread
From: Arnd Bergmann @ 2013-01-21 17:16 UTC (permalink / raw)
To: linux-arm-kernel
Cc: linux-kernel, arm, Arnd Bergmann, Joonyoung Shim, Inki Dae,
Seung-Woo Kim, Kyungmin Park, David Airlie, dri-devel
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@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 [flat|nested] 155+ messages in thread
* [PATCH 08/15] drm/exynos: fimd and ipp are broken on multiplatform
@ 2013-01-21 17:16 ` Arnd Bergmann
0 siblings, 0 replies; 155+ messages in thread
From: Arnd Bergmann @ 2013-01-21 17:16 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Arnd Bergmann, Seung-Woo Kim, linux-kernel, dri-devel,
Kyungmin Park, arm
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@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 [flat|nested] 155+ messages in thread
* [PATCH 08/15] drm/exynos: fimd and ipp are broken on multiplatform
@ 2013-01-21 17:16 ` Arnd Bergmann
0 siblings, 0 replies; 155+ messages in thread
From: Arnd Bergmann @ 2013-01-21 17:16 UTC (permalink / raw)
To: linux-arm-kernel
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 [flat|nested] 155+ messages in thread
* Re: [PATCH 08/15] drm/exynos: fimd and ipp are broken on multiplatform
2013-01-21 17:16 ` Arnd Bergmann
@ 2013-01-22 1:26 ` Inki Dae
-1 siblings, 0 replies; 155+ messages in thread
From: Inki Dae @ 2013-01-22 1:26 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-arm-kernel, Seung-Woo Kim, linux-kernel, dri-devel,
Kyungmin Park, arm
Checked it out and applied. For ARCH_MULTIPLATFORM support, Such
header files shouldn't be included. And for this, we are planning on
supporting device tree for ipp driver.
Thanks,
Inki Dae
2013/1/22 Arnd Bergmann <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@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
>
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 155+ messages in thread
* [PATCH 08/15] drm/exynos: fimd and ipp are broken on multiplatform
@ 2013-01-22 1:26 ` Inki Dae
0 siblings, 0 replies; 155+ messages in thread
From: Inki Dae @ 2013-01-22 1:26 UTC (permalink / raw)
To: linux-arm-kernel
Checked it out and applied. For ARCH_MULTIPLATFORM support, Such
header files shouldn't be included. And for this, we are planning on
supporting device tree for ipp driver.
Thanks,
Inki Dae
2013/1/22 Arnd Bergmann <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
>
> _______________________________________________
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 155+ messages in thread
* [PATCH 09/15] media: coda: don't build on multiplatform
2013-01-21 17:15 ` Arnd Bergmann
@ 2013-01-21 17:16 ` Arnd Bergmann
-1 siblings, 0 replies; 155+ messages in thread
From: Arnd Bergmann @ 2013-01-21 17:16 UTC (permalink / raw)
To: linux-arm-kernel
Cc: linux-kernel, arm, Arnd Bergmann, Javier Martin, Fabio Estevam,
Sascha Hauer, Shawn Guo, Mauro Carvalho Chehab, linux-media
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@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 [flat|nested] 155+ messages in thread
* [PATCH 09/15] media: coda: don't build on multiplatform
@ 2013-01-21 17:16 ` Arnd Bergmann
0 siblings, 0 replies; 155+ messages in thread
From: Arnd Bergmann @ 2013-01-21 17:16 UTC (permalink / raw)
To: linux-arm-kernel
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 [flat|nested] 155+ messages in thread
* Re: [PATCH 09/15] media: coda: don't build on multiplatform
2013-01-21 17:16 ` Arnd Bergmann
@ 2013-01-22 3:54 ` Shawn Guo
-1 siblings, 0 replies; 155+ messages in thread
From: Shawn Guo @ 2013-01-22 3:54 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-arm-kernel, linux-kernel, arm, Javier Martin,
Fabio Estevam, Sascha Hauer, Mauro Carvalho Chehab, linux-media
On Mon, Jan 21, 2013 at 05:16:02PM +0000, Arnd Bergmann wrote:
> The coda video codec driver depends on a mach-imx or mach-mxs specific
> header file "mach/iram.h". This is not available when building for
> multiplatform, so let us disable this driver for v3.8 when building
> multiplatform, and hopefully find a proper fix for v3.9.
>
> drivers/media/platform/coda.c:27:23: fatal error: mach/iram.h: No such file or directory
>
> 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>
Acked-by: Shawn Guo <shawn.guo@linaro.org>
> Cc: Mauro Carvalho Chehab <mchehab@redhat.com>
> Cc: linux-media@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
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 155+ messages in thread
* [PATCH 09/15] media: coda: don't build on multiplatform
@ 2013-01-22 3:54 ` Shawn Guo
0 siblings, 0 replies; 155+ messages in thread
From: Shawn Guo @ 2013-01-22 3:54 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, Jan 21, 2013 at 05:16:02PM +0000, Arnd Bergmann wrote:
> The coda video codec driver depends on a mach-imx or mach-mxs specific
> header file "mach/iram.h". This is not available when building for
> multiplatform, so let us disable this driver for v3.8 when building
> multiplatform, and hopefully find a proper fix for v3.9.
>
> drivers/media/platform/coda.c:27:23: fatal error: mach/iram.h: No such file or directory
>
> 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>
Acked-by: 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
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [PATCH 09/15] media: coda: don't build on multiplatform
2013-01-22 3:54 ` Shawn Guo
@ 2013-01-22 12:32 ` Mauro Carvalho Chehab
-1 siblings, 0 replies; 155+ messages in thread
From: Mauro Carvalho Chehab @ 2013-01-22 12:32 UTC (permalink / raw)
To: Shawn Guo
Cc: Arnd Bergmann, linux-arm-kernel, linux-kernel, arm,
Javier Martin, Fabio Estevam, Sascha Hauer, linux-media
Em Tue, 22 Jan 2013 11:54:04 +0800
Shawn Guo <shawn.guo@linaro.org> escreveu:
> On Mon, Jan 21, 2013 at 05:16:02PM +0000, Arnd Bergmann wrote:
> > The coda video codec driver depends on a mach-imx or mach-mxs specific
> > header file "mach/iram.h". This is not available when building for
> > multiplatform, so let us disable this driver for v3.8 when building
> > multiplatform, and hopefully find a proper fix for v3.9.
> >
> > drivers/media/platform/coda.c:27:23: fatal error: mach/iram.h: No such file or directory
> >
> > 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>
>
> Acked-by: Shawn Guo <shawn.guo@linaro.org>
>
> > Cc: Mauro Carvalho Chehab <mchehab@redhat.com>
Acked-by: Mauro Carvalho Chehab <mchehab@redhat.com>
> > Cc: linux-media@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
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at http://www.tux.org/lkml/
>
--
Cheers,
Mauro
^ permalink raw reply [flat|nested] 155+ messages in thread
* [PATCH 09/15] media: coda: don't build on multiplatform
@ 2013-01-22 12:32 ` Mauro Carvalho Chehab
0 siblings, 0 replies; 155+ messages in thread
From: Mauro Carvalho Chehab @ 2013-01-22 12:32 UTC (permalink / raw)
To: linux-arm-kernel
Em Tue, 22 Jan 2013 11:54:04 +0800
Shawn Guo <shawn.guo@linaro.org> escreveu:
> On Mon, Jan 21, 2013 at 05:16:02PM +0000, Arnd Bergmann wrote:
> > The coda video codec driver depends on a mach-imx or mach-mxs specific
> > header file "mach/iram.h". This is not available when building for
> > multiplatform, so let us disable this driver for v3.8 when building
> > multiplatform, and hopefully find a proper fix for v3.9.
> >
> > drivers/media/platform/coda.c:27:23: fatal error: mach/iram.h: No such file or directory
> >
> > 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>
>
> Acked-by: Shawn Guo <shawn.guo@linaro.org>
>
> > Cc: Mauro Carvalho Chehab <mchehab@redhat.com>
Acked-by: 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
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to majordomo at vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at http://www.tux.org/lkml/
>
--
Cheers,
Mauro
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [PATCH 09/15] media: coda: don't build on multiplatform
2013-01-22 12:32 ` Mauro Carvalho Chehab
@ 2013-01-22 12:34 ` Mauro Carvalho Chehab
-1 siblings, 0 replies; 155+ messages in thread
From: Mauro Carvalho Chehab @ 2013-01-22 12:34 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Shawn Guo, Arnd Bergmann, linux-arm-kernel, linux-kernel, arm,
Javier Martin, Fabio Estevam, Sascha Hauer, linux-media
Em Tue, 22 Jan 2013 10:32:22 -0200
Mauro Carvalho Chehab <mchehab@redhat.com> escreveu:
> Em Tue, 22 Jan 2013 11:54:04 +0800
> Shawn Guo <shawn.guo@linaro.org> escreveu:
>
> > On Mon, Jan 21, 2013 at 05:16:02PM +0000, Arnd Bergmann wrote:
> > > The coda video codec driver depends on a mach-imx or mach-mxs specific
> > > header file "mach/iram.h". This is not available when building for
> > > multiplatform, so let us disable this driver for v3.8 when building
> > > multiplatform, and hopefully find a proper fix for v3.9.
> > >
> > > drivers/media/platform/coda.c:27:23: fatal error: mach/iram.h: No such file or directory
> > >
> > > 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>
> >
> > Acked-by: Shawn Guo <shawn.guo@linaro.org>
> >
> > > Cc: Mauro Carvalho Chehab <mchehab@redhat.com>
>
> Acked-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Err... actually, as Sascha has a proper fix for it, it should be used,
instead. So:
Nacked-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Regards,
Mauro
^ permalink raw reply [flat|nested] 155+ messages in thread
* [PATCH 09/15] media: coda: don't build on multiplatform
@ 2013-01-22 12:34 ` Mauro Carvalho Chehab
0 siblings, 0 replies; 155+ messages in thread
From: Mauro Carvalho Chehab @ 2013-01-22 12:34 UTC (permalink / raw)
To: linux-arm-kernel
Em Tue, 22 Jan 2013 10:32:22 -0200
Mauro Carvalho Chehab <mchehab@redhat.com> escreveu:
> Em Tue, 22 Jan 2013 11:54:04 +0800
> Shawn Guo <shawn.guo@linaro.org> escreveu:
>
> > On Mon, Jan 21, 2013 at 05:16:02PM +0000, Arnd Bergmann wrote:
> > > The coda video codec driver depends on a mach-imx or mach-mxs specific
> > > header file "mach/iram.h". This is not available when building for
> > > multiplatform, so let us disable this driver for v3.8 when building
> > > multiplatform, and hopefully find a proper fix for v3.9.
> > >
> > > drivers/media/platform/coda.c:27:23: fatal error: mach/iram.h: No such file or directory
> > >
> > > 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>
> >
> > Acked-by: Shawn Guo <shawn.guo@linaro.org>
> >
> > > Cc: Mauro Carvalho Chehab <mchehab@redhat.com>
>
> Acked-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Err... actually, as Sascha has a proper fix for it, it should be used,
instead. So:
Nacked-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Regards,
Mauro
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [PATCH 09/15] media: coda: don't build on multiplatform
2013-01-21 17:16 ` Arnd Bergmann
@ 2013-01-22 8:21 ` Sascha Hauer
-1 siblings, 0 replies; 155+ messages in thread
From: Sascha Hauer @ 2013-01-22 8:21 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-arm-kernel, linux-kernel, arm, Javier Martin,
Fabio Estevam, Sascha Hauer, Shawn Guo, Mauro Carvalho Chehab,
linux-media
On Mon, Jan 21, 2013 at 05:16:02PM +0000, Arnd Bergmann wrote:
> The coda video codec driver depends on a mach-imx or mach-mxs specific
> header file "mach/iram.h". This is not available when building for
> multiplatform, so let us disable this driver for v3.8 when building
> multiplatform, and hopefully find a proper fix for v3.9.
>
> drivers/media/platform/coda.c:27:23: fatal error: mach/iram.h: No such file or directory
I just sent a pull request for this with a proper fix.
>
> diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
> index 3dcfea6..049d2b2 100644
> --- a/drivers/media/platform/Kconfig
> +++ b/drivers/media/platform/Kconfig
> @@ -142,7 +142,7 @@ if V4L_MEM2MEM_DRIVERS
>
> config VIDEO_CODA
> tristate "Chips&Media Coda multi-standard codec IP"
> - depends on VIDEO_DEV && VIDEO_V4L2 && ARCH_MXC
> + depends on VIDEO_DEV && VIDEO_V4L2 && ARCH_MXC && !ARCH_MULTIPLATFORM
This breakage is not multiplatform related at all, it won't compile
without multiplatform support either. So depends on BROKEN would be
more appropriate if you want to go this way.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply [flat|nested] 155+ messages in thread
* [PATCH 09/15] media: coda: don't build on multiplatform
@ 2013-01-22 8:21 ` Sascha Hauer
0 siblings, 0 replies; 155+ messages in thread
From: Sascha Hauer @ 2013-01-22 8:21 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, Jan 21, 2013 at 05:16:02PM +0000, Arnd Bergmann wrote:
> The coda video codec driver depends on a mach-imx or mach-mxs specific
> header file "mach/iram.h". This is not available when building for
> multiplatform, so let us disable this driver for v3.8 when building
> multiplatform, and hopefully find a proper fix for v3.9.
>
> drivers/media/platform/coda.c:27:23: fatal error: mach/iram.h: No such file or directory
I just sent a pull request for this with a proper fix.
>
> diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
> index 3dcfea6..049d2b2 100644
> --- a/drivers/media/platform/Kconfig
> +++ b/drivers/media/platform/Kconfig
> @@ -142,7 +142,7 @@ if V4L_MEM2MEM_DRIVERS
>
> config VIDEO_CODA
> tristate "Chips&Media Coda multi-standard codec IP"
> - depends on VIDEO_DEV && VIDEO_V4L2 && ARCH_MXC
> + depends on VIDEO_DEV && VIDEO_V4L2 && ARCH_MXC && !ARCH_MULTIPLATFORM
This breakage is not multiplatform related at all, it won't compile
without multiplatform support either. So depends on BROKEN would be
more appropriate if you want to go this way.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [PATCH 09/15] media: coda: don't build on multiplatform
2013-01-22 8:21 ` Sascha Hauer
@ 2013-01-22 15:41 ` Arnd Bergmann
-1 siblings, 0 replies; 155+ messages in thread
From: Arnd Bergmann @ 2013-01-22 15:41 UTC (permalink / raw)
To: Sascha Hauer
Cc: linux-arm-kernel, linux-kernel, arm, Javier Martin,
Fabio Estevam, Sascha Hauer, Shawn Guo, Mauro Carvalho Chehab,
linux-media
On Tuesday 22 January 2013, Sascha Hauer wrote:
> On Mon, Jan 21, 2013 at 05:16:02PM +0000, Arnd Bergmann wrote:
> > The coda video codec driver depends on a mach-imx or mach-mxs specific
> > header file "mach/iram.h". This is not available when building for
> > multiplatform, so let us disable this driver for v3.8 when building
> > multiplatform, and hopefully find a proper fix for v3.9.
> >
> > drivers/media/platform/coda.c:27:23: fatal error: mach/iram.h: No such file or directory
>
> I just sent a pull request for this with a proper fix.
Ok, even better. Thanks for taking care of it!
Arnd
^ permalink raw reply [flat|nested] 155+ messages in thread
* [PATCH 09/15] media: coda: don't build on multiplatform
@ 2013-01-22 15:41 ` Arnd Bergmann
0 siblings, 0 replies; 155+ messages in thread
From: Arnd Bergmann @ 2013-01-22 15:41 UTC (permalink / raw)
To: linux-arm-kernel
On Tuesday 22 January 2013, Sascha Hauer wrote:
> On Mon, Jan 21, 2013 at 05:16:02PM +0000, Arnd Bergmann wrote:
> > The coda video codec driver depends on a mach-imx or mach-mxs specific
> > header file "mach/iram.h". This is not available when building for
> > multiplatform, so let us disable this driver for v3.8 when building
> > multiplatform, and hopefully find a proper fix for v3.9.
> >
> > drivers/media/platform/coda.c:27:23: fatal error: mach/iram.h: No such file or directory
>
> I just sent a pull request for this with a proper fix.
Ok, even better. Thanks for taking care of it!
Arnd
^ permalink raw reply [flat|nested] 155+ messages in thread
* [PATCH 10/15] mfd/vexpress: export vexpress_config_func_{put,get}
2013-01-21 17:15 ` Arnd Bergmann
@ 2013-01-21 17:16 ` Arnd Bergmann
-1 siblings, 0 replies; 155+ messages in thread
From: Arnd Bergmann @ 2013-01-21 17:16 UTC (permalink / raw)
To: linux-arm-kernel
Cc: linux-kernel, arm, Arnd Bergmann, Pawel Moll, Samuel Ortiz, Mark Brown
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 [flat|nested] 155+ messages in thread* [PATCH 10/15] mfd/vexpress: export vexpress_config_func_{put,get}
@ 2013-01-21 17:16 ` Arnd Bergmann
0 siblings, 0 replies; 155+ messages in thread
From: Arnd Bergmann @ 2013-01-21 17:16 UTC (permalink / raw)
To: linux-arm-kernel
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 [flat|nested] 155+ messages in thread* Re: [PATCH 10/15] mfd/vexpress: export vexpress_config_func_{put,get}
2013-01-21 17:16 ` Arnd Bergmann
@ 2013-01-21 17:23 ` Pawel Moll
-1 siblings, 0 replies; 155+ messages in thread
From: Pawel Moll @ 2013-01-21 17:23 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-arm-kernel, linux-kernel, arm, Samuel Ortiz, Mark Brown
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 [flat|nested] 155+ messages in thread* [PATCH 10/15] mfd/vexpress: export vexpress_config_func_{put,get}
@ 2013-01-21 17:23 ` Pawel Moll
0 siblings, 0 replies; 155+ messages in thread
From: Pawel Moll @ 2013-01-21 17:23 UTC (permalink / raw)
To: linux-arm-kernel
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 [flat|nested] 155+ messages in thread
* [PATCH 11/15] mtd: davinci_nand: fix OF support
2013-01-21 17:15 ` Arnd Bergmann
@ 2013-01-21 17:16 ` Arnd Bergmann
-1 siblings, 0 replies; 155+ messages in thread
From: Arnd Bergmann @ 2013-01-21 17:16 UTC (permalink / raw)
To: linux-arm-kernel
Cc: linux-kernel, arm, Arnd Bergmann, Heiko Schocher, Sekhar Nori,
Artem Bityutskiy, David Woodhouse
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 [flat|nested] 155+ messages in thread* [PATCH 11/15] mtd: davinci_nand: fix OF support
@ 2013-01-21 17:16 ` Arnd Bergmann
0 siblings, 0 replies; 155+ messages in thread
From: Arnd Bergmann @ 2013-01-21 17:16 UTC (permalink / raw)
To: linux-arm-kernel
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 [flat|nested] 155+ messages in thread* Re: [PATCH 11/15] mtd: davinci_nand: fix OF support
2013-01-21 17:16 ` Arnd Bergmann
@ 2013-01-21 21:37 ` Heiko Schocher
-1 siblings, 0 replies; 155+ messages in thread
From: Heiko Schocher @ 2013-01-21 21:37 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-arm-kernel, linux-kernel, arm, Sekhar Nori,
Artem Bityutskiy, David Woodhouse
Hello Arnd,
On 21.01.2013 18:16, Arnd Bergmann wrote:
> 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(-)
Already fixed here:
http://lists.infradead.org/pipermail/linux-mtd/2013-January/045366.html
bye,
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
^ permalink raw reply [flat|nested] 155+ messages in thread
* [PATCH 11/15] mtd: davinci_nand: fix OF support
@ 2013-01-21 21:37 ` Heiko Schocher
0 siblings, 0 replies; 155+ messages in thread
From: Heiko Schocher @ 2013-01-21 21:37 UTC (permalink / raw)
To: linux-arm-kernel
Hello Arnd,
On 21.01.2013 18:16, Arnd Bergmann wrote:
> 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(-)
Already fixed here:
http://lists.infradead.org/pipermail/linux-mtd/2013-January/045366.html
bye,
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [PATCH 11/15] mtd: davinci_nand: fix OF support
2013-01-21 21:37 ` Heiko Schocher
@ 2013-01-21 21:50 ` Arnd Bergmann
-1 siblings, 0 replies; 155+ messages in thread
From: Arnd Bergmann @ 2013-01-21 21:50 UTC (permalink / raw)
To: Heiko Schocher
Cc: linux-arm-kernel, linux-kernel, arm, Sekhar Nori,
Artem Bityutskiy, David Woodhouse
On Monday 21 January 2013, Heiko Schocher wrote:
> Already fixed here:
> http://lists.infradead.org/pipermail/linux-mtd/2013-January/045366.html
>
Ok, thanks for the confirmation. I had only checked -rc4, not any newer
snapshot.
Arnd
^ permalink raw reply [flat|nested] 155+ messages in thread
* [PATCH 12/15] USB: gadget/freescale: disable non-multiplatform drivers
2013-01-21 17:15 ` Arnd Bergmann
@ 2013-01-21 17:16 ` Arnd Bergmann
-1 siblings, 0 replies; 155+ messages in thread
From: Arnd Bergmann @ 2013-01-21 17:16 UTC (permalink / raw)
To: linux-arm-kernel
Cc: linux-kernel, arm, Arnd Bergmann, Felipe Balbi, Shawn Guo,
Greg Kroah-Hartman, linux-usb
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@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 [flat|nested] 155+ messages in thread
* [PATCH 12/15] USB: gadget/freescale: disable non-multiplatform drivers
@ 2013-01-21 17:16 ` Arnd Bergmann
0 siblings, 0 replies; 155+ messages in thread
From: Arnd Bergmann @ 2013-01-21 17:16 UTC (permalink / raw)
To: linux-arm-kernel
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 [flat|nested] 155+ messages in thread
* Re: [PATCH 12/15] USB: gadget/freescale: disable non-multiplatform drivers
2013-01-21 17:16 ` Arnd Bergmann
@ 2013-01-21 18:41 ` Felipe Balbi
-1 siblings, 0 replies; 155+ messages in thread
From: Felipe Balbi @ 2013-01-21 18:41 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-arm-kernel, linux-kernel, arm, Felipe Balbi, Shawn Guo,
Greg Kroah-Hartman, linux-usb
[-- Attachment #1: Type: text/plain, Size: 1016 bytes --]
Hi,
On Mon, Jan 21, 2013 at 05:16:05PM +0000, Arnd Bergmann wrote:
> 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@vger.kernel.org
NAK, I prefer to see a real fix for the problem (which in fact is
already in my fixes branch).
Next time, before enabling something by default, check that
allyesconfig, allmodconfig and allnoconfig builds fine, please.
--
balbi
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 155+ messages in thread
* [PATCH 12/15] USB: gadget/freescale: disable non-multiplatform drivers
@ 2013-01-21 18:41 ` Felipe Balbi
0 siblings, 0 replies; 155+ messages in thread
From: Felipe Balbi @ 2013-01-21 18:41 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
On Mon, Jan 21, 2013 at 05:16:05PM +0000, Arnd Bergmann wrote:
> 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
NAK, I prefer to see a real fix for the problem (which in fact is
already in my fixes branch).
Next time, before enabling something by default, check that
allyesconfig, allmodconfig and allnoconfig builds fine, please.
--
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130121/e2036f1b/attachment.sig>
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [PATCH 12/15] USB: gadget/freescale: disable non-multiplatform drivers
2013-01-21 18:41 ` Felipe Balbi
@ 2013-01-21 18:57 ` Greg Kroah-Hartman
-1 siblings, 0 replies; 155+ messages in thread
From: Greg Kroah-Hartman @ 2013-01-21 18:57 UTC (permalink / raw)
To: Felipe Balbi
Cc: Arnd Bergmann, linux-arm-kernel, linux-kernel, arm, Shawn Guo, linux-usb
On Mon, Jan 21, 2013 at 08:41:38PM +0200, Felipe Balbi wrote:
> Hi,
>
> On Mon, Jan 21, 2013 at 05:16:05PM +0000, Arnd Bergmann wrote:
> > 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@vger.kernel.org
>
> NAK, I prefer to see a real fix for the problem (which in fact is
> already in my fixes branch).
I'll pull that branch now, sorry for the delay.
greg k-h
^ permalink raw reply [flat|nested] 155+ messages in thread
* [PATCH 12/15] USB: gadget/freescale: disable non-multiplatform drivers
@ 2013-01-21 18:57 ` Greg Kroah-Hartman
0 siblings, 0 replies; 155+ messages in thread
From: Greg Kroah-Hartman @ 2013-01-21 18:57 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, Jan 21, 2013 at 08:41:38PM +0200, Felipe Balbi wrote:
> Hi,
>
> On Mon, Jan 21, 2013 at 05:16:05PM +0000, Arnd Bergmann wrote:
> > 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
>
> NAK, I prefer to see a real fix for the problem (which in fact is
> already in my fixes branch).
I'll pull that branch now, sorry for the delay.
greg k-h
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [PATCH 12/15] USB: gadget/freescale: disable non-multiplatform drivers
2013-01-21 18:57 ` Greg Kroah-Hartman
@ 2013-01-21 19:00 ` Felipe Balbi
-1 siblings, 0 replies; 155+ messages in thread
From: Felipe Balbi @ 2013-01-21 19:00 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Felipe Balbi, Arnd Bergmann, linux-arm-kernel, linux-kernel, arm,
Shawn Guo, linux-usb
[-- Attachment #1: Type: text/plain, Size: 1179 bytes --]
On Mon, Jan 21, 2013 at 10:57:16AM -0800, Greg Kroah-Hartman wrote:
> On Mon, Jan 21, 2013 at 08:41:38PM +0200, Felipe Balbi wrote:
> > Hi,
> >
> > On Mon, Jan 21, 2013 at 05:16:05PM +0000, Arnd Bergmann wrote:
> > > 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@vger.kernel.org
> >
> > NAK, I prefer to see a real fix for the problem (which in fact is
> > already in my fixes branch).
>
> I'll pull that branch now, sorry for the delay.
no problem ;-)
--
balbi
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 155+ messages in thread
* [PATCH 12/15] USB: gadget/freescale: disable non-multiplatform drivers
@ 2013-01-21 19:00 ` Felipe Balbi
0 siblings, 0 replies; 155+ messages in thread
From: Felipe Balbi @ 2013-01-21 19:00 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, Jan 21, 2013 at 10:57:16AM -0800, Greg Kroah-Hartman wrote:
> On Mon, Jan 21, 2013 at 08:41:38PM +0200, Felipe Balbi wrote:
> > Hi,
> >
> > On Mon, Jan 21, 2013 at 05:16:05PM +0000, Arnd Bergmann wrote:
> > > 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
> >
> > NAK, I prefer to see a real fix for the problem (which in fact is
> > already in my fixes branch).
>
> I'll pull that branch now, sorry for the delay.
no problem ;-)
--
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130121/351a1fcb/attachment.sig>
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [PATCH 12/15] USB: gadget/freescale: disable non-multiplatform drivers
2013-01-21 18:57 ` Greg Kroah-Hartman
@ 2013-01-21 20:15 ` Arnd Bergmann
-1 siblings, 0 replies; 155+ messages in thread
From: Arnd Bergmann @ 2013-01-21 20:15 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Felipe Balbi, linux-arm-kernel, linux-kernel, arm, Shawn Guo, linux-usb
On Monday 21 January 2013, Greg Kroah-Hartman wrote:
> On Mon, Jan 21, 2013 at 08:41:38PM +0200, Felipe Balbi wrote:
>
> > NAK, I prefer to see a real fix for the problem (which in fact is
> > already in my fixes branch).
>
> I'll pull that branch now, sorry for the delay.
>
Ok, great! Thanks a lot, both of you,
Arnd
^ permalink raw reply [flat|nested] 155+ messages in thread
* [PATCH 12/15] USB: gadget/freescale: disable non-multiplatform drivers
@ 2013-01-21 20:15 ` Arnd Bergmann
0 siblings, 0 replies; 155+ messages in thread
From: Arnd Bergmann @ 2013-01-21 20:15 UTC (permalink / raw)
To: linux-arm-kernel
On Monday 21 January 2013, Greg Kroah-Hartman wrote:
> On Mon, Jan 21, 2013 at 08:41:38PM +0200, Felipe Balbi wrote:
>
> > NAK, I prefer to see a real fix for the problem (which in fact is
> > already in my fixes branch).
>
> I'll pull that branch now, sorry for the delay.
>
Ok, great! Thanks a lot, both of you,
Arnd
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [PATCH 12/15] USB: gadget/freescale: disable non-multiplatform drivers
2013-01-21 18:57 ` Greg Kroah-Hartman
@ 2013-02-05 16:27 ` Arnd Bergmann
-1 siblings, 0 replies; 155+ messages in thread
From: Arnd Bergmann @ 2013-02-05 16:27 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Felipe Balbi, linux-arm-kernel, linux-kernel, arm, Shawn Guo, linux-usb
On Monday 21 January 2013, Greg Kroah-Hartman wrote:
> On Mon, Jan 21, 2013 at 08:41:38PM +0200, Felipe Balbi wrote:
> > Hi,
> >
> > On Mon, Jan 21, 2013 at 05:16:05PM +0000, Arnd Bergmann wrote:
> > > 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@vger.kernel.org
> >
> > NAK, I prefer to see a real fix for the problem (which in fact is
> > already in my fixes branch).
>
> I'll pull that branch now, sorry for the delay.
Apparently it hasn't made it into the upstream kernel yet, and it also doesn't
seem to be in linux-next. Maybe this got lost while you were travelling?
Arnd
^ permalink raw reply [flat|nested] 155+ messages in thread
* [PATCH 12/15] USB: gadget/freescale: disable non-multiplatform drivers
@ 2013-02-05 16:27 ` Arnd Bergmann
0 siblings, 0 replies; 155+ messages in thread
From: Arnd Bergmann @ 2013-02-05 16:27 UTC (permalink / raw)
To: linux-arm-kernel
On Monday 21 January 2013, Greg Kroah-Hartman wrote:
> On Mon, Jan 21, 2013 at 08:41:38PM +0200, Felipe Balbi wrote:
> > Hi,
> >
> > On Mon, Jan 21, 2013 at 05:16:05PM +0000, Arnd Bergmann wrote:
> > > 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
> >
> > NAK, I prefer to see a real fix for the problem (which in fact is
> > already in my fixes branch).
>
> I'll pull that branch now, sorry for the delay.
Apparently it hasn't made it into the upstream kernel yet, and it also doesn't
seem to be in linux-next. Maybe this got lost while you were travelling?
Arnd
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [PATCH 12/15] USB: gadget/freescale: disable non-multiplatform drivers
2013-02-05 16:27 ` Arnd Bergmann
@ 2013-02-05 17:00 ` Greg Kroah-Hartman
-1 siblings, 0 replies; 155+ messages in thread
From: Greg Kroah-Hartman @ 2013-02-05 17:00 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Felipe Balbi, linux-arm-kernel, linux-kernel, arm, Shawn Guo, linux-usb
On Tue, Feb 05, 2013 at 04:27:18PM +0000, Arnd Bergmann wrote:
> On Monday 21 January 2013, Greg Kroah-Hartman wrote:
> > On Mon, Jan 21, 2013 at 08:41:38PM +0200, Felipe Balbi wrote:
> > > Hi,
> > >
> > > On Mon, Jan 21, 2013 at 05:16:05PM +0000, Arnd Bergmann wrote:
> > > > 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@vger.kernel.org
> > >
> > > NAK, I prefer to see a real fix for the problem (which in fact is
> > > already in my fixes branch).
> >
> > I'll pull that branch now, sorry for the delay.
>
> Apparently it hasn't made it into the upstream kernel yet, and it also doesn't
> seem to be in linux-next. Maybe this got lost while you were travelling?
Hm, no, I thought I got Felipe's fixes branch up into Linus's tree
already. Felipe, did I miss something from you? If so, please resend
or let me know, as I don't have anything pending on my side.
thanks,
greg k-h
^ permalink raw reply [flat|nested] 155+ messages in thread
* [PATCH 12/15] USB: gadget/freescale: disable non-multiplatform drivers
@ 2013-02-05 17:00 ` Greg Kroah-Hartman
0 siblings, 0 replies; 155+ messages in thread
From: Greg Kroah-Hartman @ 2013-02-05 17:00 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Feb 05, 2013 at 04:27:18PM +0000, Arnd Bergmann wrote:
> On Monday 21 January 2013, Greg Kroah-Hartman wrote:
> > On Mon, Jan 21, 2013 at 08:41:38PM +0200, Felipe Balbi wrote:
> > > Hi,
> > >
> > > On Mon, Jan 21, 2013 at 05:16:05PM +0000, Arnd Bergmann wrote:
> > > > 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
> > >
> > > NAK, I prefer to see a real fix for the problem (which in fact is
> > > already in my fixes branch).
> >
> > I'll pull that branch now, sorry for the delay.
>
> Apparently it hasn't made it into the upstream kernel yet, and it also doesn't
> seem to be in linux-next. Maybe this got lost while you were travelling?
Hm, no, I thought I got Felipe's fixes branch up into Linus's tree
already. Felipe, did I miss something from you? If so, please resend
or let me know, as I don't have anything pending on my side.
thanks,
greg k-h
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [PATCH 12/15] USB: gadget/freescale: disable non-multiplatform drivers
2013-02-05 17:00 ` Greg Kroah-Hartman
@ 2013-02-05 21:37 ` Felipe Balbi
-1 siblings, 0 replies; 155+ messages in thread
From: Felipe Balbi @ 2013-02-05 21:37 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Arnd Bergmann, Felipe Balbi, linux-arm-kernel, linux-kernel, arm,
Shawn Guo, linux-usb, Sascha Hauer
[-- Attachment #1: Type: text/plain, Size: 3279 bytes --]
Hi,
On Tue, Feb 05, 2013 at 09:00:27AM -0800, Greg Kroah-Hartman wrote:
> On Tue, Feb 05, 2013 at 04:27:18PM +0000, Arnd Bergmann wrote:
> > On Monday 21 January 2013, Greg Kroah-Hartman wrote:
> > > On Mon, Jan 21, 2013 at 08:41:38PM +0200, Felipe Balbi wrote:
> > > > Hi,
> > > >
> > > > On Mon, Jan 21, 2013 at 05:16:05PM +0000, Arnd Bergmann wrote:
> > > > > 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@vger.kernel.org
> > > >
> > > > NAK, I prefer to see a real fix for the problem (which in fact is
> > > > already in my fixes branch).
> > >
> > > I'll pull that branch now, sorry for the delay.
> >
> > Apparently it hasn't made it into the upstream kernel yet, and it also doesn't
> > seem to be in linux-next. Maybe this got lost while you were travelling?
>
> Hm, no, I thought I got Felipe's fixes branch up into Linus's tree
> already. Felipe, did I miss something from you? If so, please resend
> or let me know, as I don't have anything pending on my side.
I don't have anything pending in my fixes branch:
$ git log fixes ^linus/master
$ git show-branch linus/master
[linus/master] Merge branch 'fix-max-write' of git://git.kernel.org/pub/scm/linux/kernel/git/teigland/linux-dlm
It's building find for me:
$ crossmake drivers/usb/gadget/fsl_udc_core.o \
drivers/usb/gadget/fsl_mxc_udc.o > /dev/null
(crossmake is an alias to make ARCH=arm)
Arnd, are you maybe missing a merge of v3.8-rc6 ?
I can see that imx_udc.c is broken still, but there are no maintainers
for that driver. I'm adding Sascha to Cc list, maybe he knows someone
who can help, but if this driver isn't fixed in 2 merge windows, I will
schedule for removal from tree and someone else will have to
re-introduce it later without all the bogus includes.
---- build breaks ---
sound/soc/fsl/imx-pcm.c: In function 'snd_imx_pcm_mmap':
sound/soc/fsl/imx-pcm.c:28:2: error: 'KBUILD_MODNAME' undeclared (first use in this function)
sound/soc/fsl/imx-pcm.c:28:2: note: each undeclared identifier is
reported only once for each function it appears in
make[3]: *** [sound/soc/fsl/imx-pcm.o] Error 1
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
make[4]: *** [drivers/video/omap2/dss/dss.o] Error 1
--
balbi
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 155+ messages in thread
* [PATCH 12/15] USB: gadget/freescale: disable non-multiplatform drivers
@ 2013-02-05 21:37 ` Felipe Balbi
0 siblings, 0 replies; 155+ messages in thread
From: Felipe Balbi @ 2013-02-05 21:37 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
On Tue, Feb 05, 2013 at 09:00:27AM -0800, Greg Kroah-Hartman wrote:
> On Tue, Feb 05, 2013 at 04:27:18PM +0000, Arnd Bergmann wrote:
> > On Monday 21 January 2013, Greg Kroah-Hartman wrote:
> > > On Mon, Jan 21, 2013 at 08:41:38PM +0200, Felipe Balbi wrote:
> > > > Hi,
> > > >
> > > > On Mon, Jan 21, 2013 at 05:16:05PM +0000, Arnd Bergmann wrote:
> > > > > 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
> > > >
> > > > NAK, I prefer to see a real fix for the problem (which in fact is
> > > > already in my fixes branch).
> > >
> > > I'll pull that branch now, sorry for the delay.
> >
> > Apparently it hasn't made it into the upstream kernel yet, and it also doesn't
> > seem to be in linux-next. Maybe this got lost while you were travelling?
>
> Hm, no, I thought I got Felipe's fixes branch up into Linus's tree
> already. Felipe, did I miss something from you? If so, please resend
> or let me know, as I don't have anything pending on my side.
I don't have anything pending in my fixes branch:
$ git log fixes ^linus/master
$ git show-branch linus/master
[linus/master] Merge branch 'fix-max-write' of git://git.kernel.org/pub/scm/linux/kernel/git/teigland/linux-dlm
It's building find for me:
$ crossmake drivers/usb/gadget/fsl_udc_core.o \
drivers/usb/gadget/fsl_mxc_udc.o > /dev/null
(crossmake is an alias to make ARCH=arm)
Arnd, are you maybe missing a merge of v3.8-rc6 ?
I can see that imx_udc.c is broken still, but there are no maintainers
for that driver. I'm adding Sascha to Cc list, maybe he knows someone
who can help, but if this driver isn't fixed in 2 merge windows, I will
schedule for removal from tree and someone else will have to
re-introduce it later without all the bogus includes.
---- build breaks ---
sound/soc/fsl/imx-pcm.c: In function 'snd_imx_pcm_mmap':
sound/soc/fsl/imx-pcm.c:28:2: error: 'KBUILD_MODNAME' undeclared (first use in this function)
sound/soc/fsl/imx-pcm.c:28:2: note: each undeclared identifier is
reported only once for each function it appears in
make[3]: *** [sound/soc/fsl/imx-pcm.o] Error 1
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
make[4]: *** [drivers/video/omap2/dss/dss.o] Error 1
--
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130205/aa5f5683/attachment.sig>
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [PATCH 12/15] USB: gadget/freescale: disable non-multiplatform drivers
2013-02-05 21:37 ` Felipe Balbi
@ 2013-02-05 22:54 ` Arnd Bergmann
-1 siblings, 0 replies; 155+ messages in thread
From: Arnd Bergmann @ 2013-02-05 22:54 UTC (permalink / raw)
To: balbi
Cc: Greg Kroah-Hartman, linux-arm-kernel, linux-kernel, arm,
Shawn Guo, linux-usb, Sascha Hauer
On Tuesday 05 February 2013, Felipe Balbi wrote:
> [linus/master] Merge branch 'fix-max-write' of git://git.kernel.org/pub/scm/linux/kernel/git/teigland/linux-dlm
>
> It's building find for me:
>
> $ crossmake drivers/usb/gadget/fsl_udc_core.o \
> drivers/usb/gadget/fsl_mxc_udc.o > /dev/null
>
> (crossmake is an alias to make ARCH=arm)
>
> Arnd, are you maybe missing a merge of v3.8-rc6 ?
>
> I can see that imx_udc.c is broken still, but there are no maintainers
> for that driver. I'm adding Sascha to Cc list, maybe he knows someone
> who can help, but if this driver isn't fixed in 2 merge windows, I will
> schedule for removal from tree and someone else will have to
> re-introduce it later without all the bogus includes.
Ah, I see what happened now: I submitted a patch that lumped together
two patches, disabling both fsl_mxc_udc and imx_udc. You already had
a fix for the first one, so I dropped my patch, but now I see the
build error for the second one that my patch was avoiding.
The last patch to imx_udc that seems to have seen more than just
build testing was probably "USB: gadget: imx_udc: don't queue more
data when zlp is to be sent", while fsl_mxc_udc looks actively
maintained. It's not completely clear to me whether these
are actually two drivers for the same hardware, of whether
imx_udc is the i.mx1 variant and fsl_mxc_udc is the i.mx2 variant.
What I can say is that no platform in the kernel currently defines
an "imx_udc" platform_device, so it is certainly unused, and has
been since at least e08300043e in 2010.
I would suggest that we mark the imx_udc driver as 'depends on
BROKEN' right away, since no in-tree user needs it, and any
out of tree user is already broken in 3.8. I also wouldn't
mind removing the driver unless the imx maintainers have
a plan for it.
> ---- build breaks ---
>
> sound/soc/fsl/imx-pcm.c: In function 'snd_imx_pcm_mmap':
> sound/soc/fsl/imx-pcm.c:28:2: error: 'KBUILD_MODNAME' undeclared (first use in this function)
> sound/soc/fsl/imx-pcm.c:28:2: note: each undeclared identifier is
> reported only once for each function it appears in
> make[3]: *** [sound/soc/fsl/imx-pcm.o] Error 1
>
> 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
> make[4]: *** [drivers/video/omap2/dss/dss.o] Error 1
Yes, I submitted patches for these, too, and like this case, we decided
to drop my patch in favor of a better fix, which has not yet gone
in. Today I sent emails about these as well, in the hope that we
can find a solution.
Arnd
^ permalink raw reply [flat|nested] 155+ messages in thread
* [PATCH 12/15] USB: gadget/freescale: disable non-multiplatform drivers
@ 2013-02-05 22:54 ` Arnd Bergmann
0 siblings, 0 replies; 155+ messages in thread
From: Arnd Bergmann @ 2013-02-05 22:54 UTC (permalink / raw)
To: linux-arm-kernel
On Tuesday 05 February 2013, Felipe Balbi wrote:
> [linus/master] Merge branch 'fix-max-write' of git://git.kernel.org/pub/scm/linux/kernel/git/teigland/linux-dlm
>
> It's building find for me:
>
> $ crossmake drivers/usb/gadget/fsl_udc_core.o \
> drivers/usb/gadget/fsl_mxc_udc.o > /dev/null
>
> (crossmake is an alias to make ARCH=arm)
>
> Arnd, are you maybe missing a merge of v3.8-rc6 ?
>
> I can see that imx_udc.c is broken still, but there are no maintainers
> for that driver. I'm adding Sascha to Cc list, maybe he knows someone
> who can help, but if this driver isn't fixed in 2 merge windows, I will
> schedule for removal from tree and someone else will have to
> re-introduce it later without all the bogus includes.
Ah, I see what happened now: I submitted a patch that lumped together
two patches, disabling both fsl_mxc_udc and imx_udc. You already had
a fix for the first one, so I dropped my patch, but now I see the
build error for the second one that my patch was avoiding.
The last patch to imx_udc that seems to have seen more than just
build testing was probably "USB: gadget: imx_udc: don't queue more
data when zlp is to be sent", while fsl_mxc_udc looks actively
maintained. It's not completely clear to me whether these
are actually two drivers for the same hardware, of whether
imx_udc is the i.mx1 variant and fsl_mxc_udc is the i.mx2 variant.
What I can say is that no platform in the kernel currently defines
an "imx_udc" platform_device, so it is certainly unused, and has
been since at least e08300043e in 2010.
I would suggest that we mark the imx_udc driver as 'depends on
BROKEN' right away, since no in-tree user needs it, and any
out of tree user is already broken in 3.8. I also wouldn't
mind removing the driver unless the imx maintainers have
a plan for it.
> ---- build breaks ---
>
> sound/soc/fsl/imx-pcm.c: In function 'snd_imx_pcm_mmap':
> sound/soc/fsl/imx-pcm.c:28:2: error: 'KBUILD_MODNAME' undeclared (first use in this function)
> sound/soc/fsl/imx-pcm.c:28:2: note: each undeclared identifier is
> reported only once for each function it appears in
> make[3]: *** [sound/soc/fsl/imx-pcm.o] Error 1
>
> 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
> make[4]: *** [drivers/video/omap2/dss/dss.o] Error 1
Yes, I submitted patches for these, too, and like this case, we decided
to drop my patch in favor of a better fix, which has not yet gone
in. Today I sent emails about these as well, in the hope that we
can find a solution.
Arnd
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [PATCH 12/15] USB: gadget/freescale: disable non-multiplatform drivers
2013-02-05 22:54 ` Arnd Bergmann
@ 2013-02-06 1:55 ` Greg Kroah-Hartman
-1 siblings, 0 replies; 155+ messages in thread
From: Greg Kroah-Hartman @ 2013-02-06 1:55 UTC (permalink / raw)
To: Arnd Bergmann
Cc: balbi, linux-arm-kernel, linux-kernel, arm, Shawn Guo, linux-usb,
Sascha Hauer
On Tue, Feb 05, 2013 at 10:54:00PM +0000, Arnd Bergmann wrote:
> On Tuesday 05 February 2013, Felipe Balbi wrote:
> > [linus/master] Merge branch 'fix-max-write' of git://git.kernel.org/pub/scm/linux/kernel/git/teigland/linux-dlm
> >
> > It's building find for me:
> >
> > $ crossmake drivers/usb/gadget/fsl_udc_core.o \
> > drivers/usb/gadget/fsl_mxc_udc.o > /dev/null
> >
> > (crossmake is an alias to make ARCH=arm)
> >
> > Arnd, are you maybe missing a merge of v3.8-rc6 ?
> >
> > I can see that imx_udc.c is broken still, but there are no maintainers
> > for that driver. I'm adding Sascha to Cc list, maybe he knows someone
> > who can help, but if this driver isn't fixed in 2 merge windows, I will
> > schedule for removal from tree and someone else will have to
> > re-introduce it later without all the bogus includes.
>
> Ah, I see what happened now: I submitted a patch that lumped together
> two patches, disabling both fsl_mxc_udc and imx_udc. You already had
> a fix for the first one, so I dropped my patch, but now I see the
> build error for the second one that my patch was avoiding.
>
> The last patch to imx_udc that seems to have seen more than just
> build testing was probably "USB: gadget: imx_udc: don't queue more
> data when zlp is to be sent", while fsl_mxc_udc looks actively
> maintained. It's not completely clear to me whether these
> are actually two drivers for the same hardware, of whether
> imx_udc is the i.mx1 variant and fsl_mxc_udc is the i.mx2 variant.
>
> What I can say is that no platform in the kernel currently defines
> an "imx_udc" platform_device, so it is certainly unused, and has
> been since at least e08300043e in 2010.
>
> I would suggest that we mark the imx_udc driver as 'depends on
> BROKEN' right away, since no in-tree user needs it, and any
> out of tree user is already broken in 3.8. I also wouldn't
> mind removing the driver unless the imx maintainers have
> a plan for it.
Sure, someone just send me a patch for that and I'll be glad to mark it
BROKEN.
thanks,
greg k-h
^ permalink raw reply [flat|nested] 155+ messages in thread
* [PATCH 12/15] USB: gadget/freescale: disable non-multiplatform drivers
@ 2013-02-06 1:55 ` Greg Kroah-Hartman
0 siblings, 0 replies; 155+ messages in thread
From: Greg Kroah-Hartman @ 2013-02-06 1:55 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Feb 05, 2013 at 10:54:00PM +0000, Arnd Bergmann wrote:
> On Tuesday 05 February 2013, Felipe Balbi wrote:
> > [linus/master] Merge branch 'fix-max-write' of git://git.kernel.org/pub/scm/linux/kernel/git/teigland/linux-dlm
> >
> > It's building find for me:
> >
> > $ crossmake drivers/usb/gadget/fsl_udc_core.o \
> > drivers/usb/gadget/fsl_mxc_udc.o > /dev/null
> >
> > (crossmake is an alias to make ARCH=arm)
> >
> > Arnd, are you maybe missing a merge of v3.8-rc6 ?
> >
> > I can see that imx_udc.c is broken still, but there are no maintainers
> > for that driver. I'm adding Sascha to Cc list, maybe he knows someone
> > who can help, but if this driver isn't fixed in 2 merge windows, I will
> > schedule for removal from tree and someone else will have to
> > re-introduce it later without all the bogus includes.
>
> Ah, I see what happened now: I submitted a patch that lumped together
> two patches, disabling both fsl_mxc_udc and imx_udc. You already had
> a fix for the first one, so I dropped my patch, but now I see the
> build error for the second one that my patch was avoiding.
>
> The last patch to imx_udc that seems to have seen more than just
> build testing was probably "USB: gadget: imx_udc: don't queue more
> data when zlp is to be sent", while fsl_mxc_udc looks actively
> maintained. It's not completely clear to me whether these
> are actually two drivers for the same hardware, of whether
> imx_udc is the i.mx1 variant and fsl_mxc_udc is the i.mx2 variant.
>
> What I can say is that no platform in the kernel currently defines
> an "imx_udc" platform_device, so it is certainly unused, and has
> been since at least e08300043e in 2010.
>
> I would suggest that we mark the imx_udc driver as 'depends on
> BROKEN' right away, since no in-tree user needs it, and any
> out of tree user is already broken in 3.8. I also wouldn't
> mind removing the driver unless the imx maintainers have
> a plan for it.
Sure, someone just send me a patch for that and I'll be glad to mark it
BROKEN.
thanks,
greg k-h
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [PATCH 12/15] USB: gadget/freescale: disable non-multiplatform drivers
2013-02-06 1:55 ` Greg Kroah-Hartman
@ 2013-02-06 7:06 ` Felipe Balbi
-1 siblings, 0 replies; 155+ messages in thread
From: Felipe Balbi @ 2013-02-06 7:06 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Arnd Bergmann, balbi, linux-arm-kernel, linux-kernel, arm,
Shawn Guo, linux-usb, Sascha Hauer
[-- Attachment #1: Type: text/plain, Size: 2273 bytes --]
On Tue, Feb 05, 2013 at 05:55:11PM -0800, Greg Kroah-Hartman wrote:
> On Tue, Feb 05, 2013 at 10:54:00PM +0000, Arnd Bergmann wrote:
> > On Tuesday 05 February 2013, Felipe Balbi wrote:
> > > [linus/master] Merge branch 'fix-max-write' of git://git.kernel.org/pub/scm/linux/kernel/git/teigland/linux-dlm
> > >
> > > It's building find for me:
> > >
> > > $ crossmake drivers/usb/gadget/fsl_udc_core.o \
> > > drivers/usb/gadget/fsl_mxc_udc.o > /dev/null
> > >
> > > (crossmake is an alias to make ARCH=arm)
> > >
> > > Arnd, are you maybe missing a merge of v3.8-rc6 ?
> > >
> > > I can see that imx_udc.c is broken still, but there are no maintainers
> > > for that driver. I'm adding Sascha to Cc list, maybe he knows someone
> > > who can help, but if this driver isn't fixed in 2 merge windows, I will
> > > schedule for removal from tree and someone else will have to
> > > re-introduce it later without all the bogus includes.
> >
> > Ah, I see what happened now: I submitted a patch that lumped together
> > two patches, disabling both fsl_mxc_udc and imx_udc. You already had
> > a fix for the first one, so I dropped my patch, but now I see the
> > build error for the second one that my patch was avoiding.
> >
> > The last patch to imx_udc that seems to have seen more than just
> > build testing was probably "USB: gadget: imx_udc: don't queue more
> > data when zlp is to be sent", while fsl_mxc_udc looks actively
> > maintained. It's not completely clear to me whether these
> > are actually two drivers for the same hardware, of whether
> > imx_udc is the i.mx1 variant and fsl_mxc_udc is the i.mx2 variant.
> >
> > What I can say is that no platform in the kernel currently defines
> > an "imx_udc" platform_device, so it is certainly unused, and has
> > been since at least e08300043e in 2010.
> >
> > I would suggest that we mark the imx_udc driver as 'depends on
> > BROKEN' right away, since no in-tree user needs it, and any
> > out of tree user is already broken in 3.8. I also wouldn't
> > mind removing the driver unless the imx maintainers have
> > a plan for it.
>
> Sure, someone just send me a patch for that and I'll be glad to mark it
> BROKEN.
coming in a minute
--
balbi
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 155+ messages in thread
* [PATCH 12/15] USB: gadget/freescale: disable non-multiplatform drivers
@ 2013-02-06 7:06 ` Felipe Balbi
0 siblings, 0 replies; 155+ messages in thread
From: Felipe Balbi @ 2013-02-06 7:06 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Feb 05, 2013 at 05:55:11PM -0800, Greg Kroah-Hartman wrote:
> On Tue, Feb 05, 2013 at 10:54:00PM +0000, Arnd Bergmann wrote:
> > On Tuesday 05 February 2013, Felipe Balbi wrote:
> > > [linus/master] Merge branch 'fix-max-write' of git://git.kernel.org/pub/scm/linux/kernel/git/teigland/linux-dlm
> > >
> > > It's building find for me:
> > >
> > > $ crossmake drivers/usb/gadget/fsl_udc_core.o \
> > > drivers/usb/gadget/fsl_mxc_udc.o > /dev/null
> > >
> > > (crossmake is an alias to make ARCH=arm)
> > >
> > > Arnd, are you maybe missing a merge of v3.8-rc6 ?
> > >
> > > I can see that imx_udc.c is broken still, but there are no maintainers
> > > for that driver. I'm adding Sascha to Cc list, maybe he knows someone
> > > who can help, but if this driver isn't fixed in 2 merge windows, I will
> > > schedule for removal from tree and someone else will have to
> > > re-introduce it later without all the bogus includes.
> >
> > Ah, I see what happened now: I submitted a patch that lumped together
> > two patches, disabling both fsl_mxc_udc and imx_udc. You already had
> > a fix for the first one, so I dropped my patch, but now I see the
> > build error for the second one that my patch was avoiding.
> >
> > The last patch to imx_udc that seems to have seen more than just
> > build testing was probably "USB: gadget: imx_udc: don't queue more
> > data when zlp is to be sent", while fsl_mxc_udc looks actively
> > maintained. It's not completely clear to me whether these
> > are actually two drivers for the same hardware, of whether
> > imx_udc is the i.mx1 variant and fsl_mxc_udc is the i.mx2 variant.
> >
> > What I can say is that no platform in the kernel currently defines
> > an "imx_udc" platform_device, so it is certainly unused, and has
> > been since at least e08300043e in 2010.
> >
> > I would suggest that we mark the imx_udc driver as 'depends on
> > BROKEN' right away, since no in-tree user needs it, and any
> > out of tree user is already broken in 3.8. I also wouldn't
> > mind removing the driver unless the imx maintainers have
> > a plan for it.
>
> Sure, someone just send me a patch for that and I'll be glad to mark it
> BROKEN.
coming in a minute
--
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130206/e23c0aa1/attachment.sig>
^ permalink raw reply [flat|nested] 155+ messages in thread
* [PATCH 13/15] USB: ehci: make orion and mxc bus glues coexist
2013-01-21 17:15 ` Arnd Bergmann
@ 2013-01-21 17:16 ` Arnd Bergmann
-1 siblings, 0 replies; 155+ messages in thread
From: Arnd Bergmann @ 2013-01-21 17:16 UTC (permalink / raw)
To: linux-arm-kernel
Cc: linux-kernel, arm, Arnd Bergmann, Alan Stern, Greg Kroah-Hartman,
linux-usb, Manjunath Goudar, Shawn Guo, Sascha Hauer,
Jason Cooper, Andrew Lunn, Gregory Clement
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@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 [flat|nested] 155+ messages in thread* [PATCH 13/15] USB: ehci: make orion and mxc bus glues coexist
@ 2013-01-21 17:16 ` Arnd Bergmann
0 siblings, 0 replies; 155+ messages in thread
From: Arnd Bergmann @ 2013-01-21 17:16 UTC (permalink / raw)
To: linux-arm-kernel
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 [flat|nested] 155+ messages in thread* Re: [PATCH 13/15] USB: ehci: make orion and mxc bus glues coexist
2013-01-21 17:16 ` Arnd Bergmann
@ 2013-01-21 18:42 ` Felipe Balbi
-1 siblings, 0 replies; 155+ messages in thread
From: Felipe Balbi @ 2013-01-21 18:42 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-arm-kernel, linux-kernel, arm, Alan Stern,
Greg Kroah-Hartman, linux-usb, Manjunath Goudar, Shawn Guo,
Sascha Hauer, Jason Cooper, Andrew Lunn, Gregory Clement
[-- Attachment #1: Type: text/plain, Size: 1553 bytes --]
On Mon, Jan 21, 2013 at 05:16:06PM +0000, Arnd Bergmann wrote:
> 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@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>
NAK, should be converted to the new usage of ehci library driver. Alan
Stern already implemented for a few drivers, help is very welcome.
--
balbi
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 155+ messages in thread
* [PATCH 13/15] USB: ehci: make orion and mxc bus glues coexist
@ 2013-01-21 18:42 ` Felipe Balbi
0 siblings, 0 replies; 155+ messages in thread
From: Felipe Balbi @ 2013-01-21 18:42 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, Jan 21, 2013 at 05:16:06PM +0000, Arnd Bergmann wrote:
> 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>
NAK, should be converted to the new usage of ehci library driver. Alan
Stern already implemented for a few drivers, help is very welcome.
--
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130121/bb62631b/attachment-0001.sig>
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [PATCH 13/15] USB: ehci: make orion and mxc bus glues coexist
2013-01-21 18:42 ` Felipe Balbi
@ 2013-01-21 20:11 ` Alan Stern
-1 siblings, 0 replies; 155+ messages in thread
From: Alan Stern @ 2013-01-21 20:11 UTC (permalink / raw)
To: Felipe Balbi
Cc: Arnd Bergmann, linux-arm-kernel, linux-kernel, arm,
Greg Kroah-Hartman, linux-usb, Manjunath Goudar, Shawn Guo,
Sascha Hauer, Jason Cooper, Andrew Lunn, Gregory Clement
On Mon, 21 Jan 2013, Felipe Balbi wrote:
> On Mon, Jan 21, 2013 at 05:16:06PM +0000, Arnd Bergmann wrote:
> > 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.
Pardon me for being confused. Is this about imx and mvebu (as
mentioned here) or about orion and mxc (as described in the patch
title, the error messages below, and the patch itself)?
> > 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
Was the point here to fix the build error or to allow the two drivers
to coexist? The first would be eaiser than the second.
> > 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@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>
>
> NAK, should be converted to the new usage of ehci library driver. Alan
> Stern already implemented for a few drivers, help is very welcome.
Arnd, please take a look at
http://marc.info/?l=linux-usb&m=135843716515529&w=2
I can't test it easily, not being set up for cross compilation. I'm
waiting to hear from anybody whether it works before submitting it.
(There's also a report of memory corruption involving a similar patch
for ehci-omap; it hasn't been tracked down yet.)
Alan Stern
^ permalink raw reply [flat|nested] 155+ messages in thread
* [PATCH 13/15] USB: ehci: make orion and mxc bus glues coexist
@ 2013-01-21 20:11 ` Alan Stern
0 siblings, 0 replies; 155+ messages in thread
From: Alan Stern @ 2013-01-21 20:11 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, 21 Jan 2013, Felipe Balbi wrote:
> On Mon, Jan 21, 2013 at 05:16:06PM +0000, Arnd Bergmann wrote:
> > 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.
Pardon me for being confused. Is this about imx and mvebu (as
mentioned here) or about orion and mxc (as described in the patch
title, the error messages below, and the patch itself)?
> > 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
Was the point here to fix the build error or to allow the two drivers
to coexist? The first would be eaiser than the second.
> > 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>
>
> NAK, should be converted to the new usage of ehci library driver. Alan
> Stern already implemented for a few drivers, help is very welcome.
Arnd, please take a look at
http://marc.info/?l=linux-usb&m=135843716515529&w=2
I can't test it easily, not being set up for cross compilation. I'm
waiting to hear from anybody whether it works before submitting it.
(There's also a report of memory corruption involving a similar patch
for ehci-omap; it hasn't been tracked down yet.)
Alan Stern
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [PATCH 13/15] USB: ehci: make orion and mxc bus glues coexist
2013-01-21 20:11 ` Alan Stern
@ 2013-01-21 21:37 ` Arnd Bergmann
-1 siblings, 0 replies; 155+ messages in thread
From: Arnd Bergmann @ 2013-01-21 21:37 UTC (permalink / raw)
To: Alan Stern
Cc: Felipe Balbi, linux-arm-kernel, linux-kernel, arm,
Greg Kroah-Hartman, linux-usb, Manjunath Goudar, Shawn Guo,
Sascha Hauer, Jason Cooper, Andrew Lunn, Gregory Clement
On Monday 21 January 2013, Alan Stern wrote:
> On Mon, 21 Jan 2013, Felipe Balbi wrote:
>
> > On Mon, Jan 21, 2013 at 05:16:06PM +0000, Arnd Bergmann wrote:
> > > 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.
>
> Pardon me for being confused. Is this about imx and mvebu (as
> mentioned here) or about orion and mxc (as described in the patch
> title, the error messages below, and the patch itself)?
mxc is the old name for imx: the platform got removed, but some
of the drivers still carry the old name. Similarly, orion was
used before as the name for the superset of various Marvell platforms,
and mvebu is the superset of that and some of the newer ones.
Sorry for the confusion.
> > > 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
>
> Was the point here to fix the build error or to allow the two drivers
> to coexist? The first would be eaiser than the second.
Fixing the build error is probably the more important part here, but
we also really want this to work, since people are migrating towards
multiplatform kernels now, and mvebu/orion and imx/mxc are two of the
more important ones.
> > NAK, should be converted to the new usage of ehci library driver. Alan
> > Stern already implemented for a few drivers, help is very welcome.
>
> Arnd, please take a look at
>
> http://marc.info/?l=linux-usb&m=135843716515529&w=2
>
> I can't test it easily, not being set up for cross compilation. I'm
> waiting to hear from anybody whether it works before submitting it.
> (There's also a report of memory corruption involving a similar patch
> for ehci-omap; it hasn't been tracked down yet.)
Your patch looks good to me, but it also seems to do some other
changes that are not required to fix the problem but could wait
for 3.9 instead. You definitely have my Ack if you are willing
to take it for 3.8 though.
Shawn or Sascha should be able to test it.
Arnd
^ permalink raw reply [flat|nested] 155+ messages in thread
* [PATCH 13/15] USB: ehci: make orion and mxc bus glues coexist
@ 2013-01-21 21:37 ` Arnd Bergmann
0 siblings, 0 replies; 155+ messages in thread
From: Arnd Bergmann @ 2013-01-21 21:37 UTC (permalink / raw)
To: linux-arm-kernel
On Monday 21 January 2013, Alan Stern wrote:
> On Mon, 21 Jan 2013, Felipe Balbi wrote:
>
> > On Mon, Jan 21, 2013 at 05:16:06PM +0000, Arnd Bergmann wrote:
> > > 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.
>
> Pardon me for being confused. Is this about imx and mvebu (as
> mentioned here) or about orion and mxc (as described in the patch
> title, the error messages below, and the patch itself)?
mxc is the old name for imx: the platform got removed, but some
of the drivers still carry the old name. Similarly, orion was
used before as the name for the superset of various Marvell platforms,
and mvebu is the superset of that and some of the newer ones.
Sorry for the confusion.
> > > 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
>
> Was the point here to fix the build error or to allow the two drivers
> to coexist? The first would be eaiser than the second.
Fixing the build error is probably the more important part here, but
we also really want this to work, since people are migrating towards
multiplatform kernels now, and mvebu/orion and imx/mxc are two of the
more important ones.
> > NAK, should be converted to the new usage of ehci library driver. Alan
> > Stern already implemented for a few drivers, help is very welcome.
>
> Arnd, please take a look at
>
> http://marc.info/?l=linux-usb&m=135843716515529&w=2
>
> I can't test it easily, not being set up for cross compilation. I'm
> waiting to hear from anybody whether it works before submitting it.
> (There's also a report of memory corruption involving a similar patch
> for ehci-omap; it hasn't been tracked down yet.)
Your patch looks good to me, but it also seems to do some other
changes that are not required to fix the problem but could wait
for 3.9 instead. You definitely have my Ack if you are willing
to take it for 3.8 though.
Shawn or Sascha should be able to test it.
Arnd
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [PATCH 13/15] USB: ehci: make orion and mxc bus glues coexist
2013-01-21 21:37 ` Arnd Bergmann
@ 2013-01-22 6:11 ` Shawn Guo
-1 siblings, 0 replies; 155+ messages in thread
From: Shawn Guo @ 2013-01-22 6:11 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Alan Stern, Felipe Balbi, linux-arm-kernel, linux-kernel, arm,
Greg Kroah-Hartman, linux-usb, Manjunath Goudar, Sascha Hauer,
Jason Cooper, Andrew Lunn, Gregory Clement
On Mon, Jan 21, 2013 at 09:37:42PM +0000, Arnd Bergmann wrote:
> > Arnd, please take a look at
> >
> > http://marc.info/?l=linux-usb&m=135843716515529&w=2
> >
> > I can't test it easily, not being set up for cross compilation. I'm
> > waiting to hear from anybody whether it works before submitting it.
> > (There's also a report of memory corruption involving a similar patch
> > for ehci-omap; it hasn't been tracked down yet.)
>
> Your patch looks good to me, but it also seems to do some other
> changes that are not required to fix the problem but could wait
> for 3.9 instead. You definitely have my Ack if you are willing
> to take it for 3.8 though.
>
> Shawn or Sascha should be able to test it.
>
Alan,
Thanks for the patch. I just gave it try. The USB Host port still
works for me with a couple of fixes on your changes integrated (one
for compiling and the other for probing). So you have my ACK with
the changes below rolled into your patch.
Acked-by: Shawn Guo <shawn.guo@linaro.org>
---8<----
diff --git a/drivers/usb/host/ehci-mxc.c b/drivers/usb/host/ehci-mxc.c
index 177b354..a685945 100644
--- a/drivers/usb/host/ehci-mxc.c
+++ b/drivers/usb/host/ehci-mxc.c
@@ -37,7 +37,7 @@
#define DRIVER_DESC "Freescale On-Chip EHCI Host driver"
-static const char hcd_name[] = "ehci-mxc";
+static const char hcd_name[] = "mxc-ehci";
#define ULPI_VIEWPORT_OFFSET 0x170
@@ -48,7 +48,7 @@ struct ehci_mxc_priv {
static struct hc_driver __read_mostly ehci_mxc_hc_driver;
static const struct ehci_driver_overrides ehci_mxc_overrides __initdata = {
- .extra_priv_size = sizeof(struct ehci_mxc_priv);
+ .extra_priv_size = sizeof(struct ehci_mxc_priv),
};
static int ehci_mxc_drv_probe(struct platform_device *pdev)
^ permalink raw reply related [flat|nested] 155+ messages in thread* [PATCH 13/15] USB: ehci: make orion and mxc bus glues coexist
@ 2013-01-22 6:11 ` Shawn Guo
0 siblings, 0 replies; 155+ messages in thread
From: Shawn Guo @ 2013-01-22 6:11 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, Jan 21, 2013 at 09:37:42PM +0000, Arnd Bergmann wrote:
> > Arnd, please take a look at
> >
> > http://marc.info/?l=linux-usb&m=135843716515529&w=2
> >
> > I can't test it easily, not being set up for cross compilation. I'm
> > waiting to hear from anybody whether it works before submitting it.
> > (There's also a report of memory corruption involving a similar patch
> > for ehci-omap; it hasn't been tracked down yet.)
>
> Your patch looks good to me, but it also seems to do some other
> changes that are not required to fix the problem but could wait
> for 3.9 instead. You definitely have my Ack if you are willing
> to take it for 3.8 though.
>
> Shawn or Sascha should be able to test it.
>
Alan,
Thanks for the patch. I just gave it try. The USB Host port still
works for me with a couple of fixes on your changes integrated (one
for compiling and the other for probing). So you have my ACK with
the changes below rolled into your patch.
Acked-by: Shawn Guo <shawn.guo@linaro.org>
---8<----
diff --git a/drivers/usb/host/ehci-mxc.c b/drivers/usb/host/ehci-mxc.c
index 177b354..a685945 100644
--- a/drivers/usb/host/ehci-mxc.c
+++ b/drivers/usb/host/ehci-mxc.c
@@ -37,7 +37,7 @@
#define DRIVER_DESC "Freescale On-Chip EHCI Host driver"
-static const char hcd_name[] = "ehci-mxc";
+static const char hcd_name[] = "mxc-ehci";
#define ULPI_VIEWPORT_OFFSET 0x170
@@ -48,7 +48,7 @@ struct ehci_mxc_priv {
static struct hc_driver __read_mostly ehci_mxc_hc_driver;
static const struct ehci_driver_overrides ehci_mxc_overrides __initdata = {
- .extra_priv_size = sizeof(struct ehci_mxc_priv);
+ .extra_priv_size = sizeof(struct ehci_mxc_priv),
};
static int ehci_mxc_drv_probe(struct platform_device *pdev)
^ permalink raw reply related [flat|nested] 155+ messages in thread* Re: [PATCH 13/15] USB: ehci: make orion and mxc bus glues coexist
2013-01-22 6:11 ` Shawn Guo
@ 2013-01-22 6:14 ` Shawn Guo
-1 siblings, 0 replies; 155+ messages in thread
From: Shawn Guo @ 2013-01-22 6:14 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Alan Stern, Felipe Balbi, linux-arm-kernel, linux-kernel, arm,
Greg Kroah-Hartman, linux-usb, Manjunath Goudar, Sascha Hauer,
Jason Cooper, Andrew Lunn, Gregory Clement
On Tue, Jan 22, 2013 at 02:11:18PM +0800, Shawn Guo wrote:
> Alan,
>
> Thanks for the patch. I just gave it try. The USB Host port still
> works for me with a couple of fixes on your changes integrated (one
> for compiling and the other for probing). So you have my ACK with
> the changes below rolled into your patch.
>
> Acked-by: Shawn Guo <shawn.guo@linaro.org>
>
Sorry. I meant a Test tag.
Tested-by: Shawn Guo <shawn.guo@linaro.org>
^ permalink raw reply [flat|nested] 155+ messages in thread
* [PATCH 13/15] USB: ehci: make orion and mxc bus glues coexist
@ 2013-01-22 6:14 ` Shawn Guo
0 siblings, 0 replies; 155+ messages in thread
From: Shawn Guo @ 2013-01-22 6:14 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Jan 22, 2013 at 02:11:18PM +0800, Shawn Guo wrote:
> Alan,
>
> Thanks for the patch. I just gave it try. The USB Host port still
> works for me with a couple of fixes on your changes integrated (one
> for compiling and the other for probing). So you have my ACK with
> the changes below rolled into your patch.
>
> Acked-by: Shawn Guo <shawn.guo@linaro.org>
>
Sorry. I meant a Test tag.
Tested-by: Shawn Guo <shawn.guo@linaro.org>
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [PATCH 13/15] USB: ehci: make orion and mxc bus glues coexist
2013-01-22 6:11 ` Shawn Guo
@ 2013-01-22 15:30 ` Alan Stern
-1 siblings, 0 replies; 155+ messages in thread
From: Alan Stern @ 2013-01-22 15:30 UTC (permalink / raw)
To: Shawn Guo
Cc: Arnd Bergmann, Felipe Balbi, linux-arm-kernel, linux-kernel, arm,
Greg Kroah-Hartman, linux-usb, Manjunath Goudar, Sascha Hauer,
Jason Cooper, Andrew Lunn, Gregory Clement
On Tue, 22 Jan 2013, Shawn Guo wrote:
> On Mon, Jan 21, 2013 at 09:37:42PM +0000, Arnd Bergmann wrote:
> > > Arnd, please take a look at
> > >
> > > http://marc.info/?l=linux-usb&m=135843716515529&w=2
> > >
> > > I can't test it easily, not being set up for cross compilation. I'm
> > > waiting to hear from anybody whether it works before submitting it.
> > > (There's also a report of memory corruption involving a similar patch
> > > for ehci-omap; it hasn't been tracked down yet.)
> >
> > Your patch looks good to me, but it also seems to do some other
> > changes that are not required to fix the problem but could wait
> > for 3.9 instead. You definitely have my Ack if you are willing
> > to take it for 3.8 though.
I think it's not too late to submit this for 3.8. Thanks for the Ack.
> > Shawn or Sascha should be able to test it.
> >
> Alan,
>
> Thanks for the patch. I just gave it try. The USB Host port still
> works for me with a couple of fixes on your changes integrated (one
> for compiling and the other for probing). So you have my ACK with
> the changes below rolled into your patch.
Right, I have merged your changes into the patch. Will submit shortly.
Alan Stern
^ permalink raw reply [flat|nested] 155+ messages in thread
* [PATCH 13/15] USB: ehci: make orion and mxc bus glues coexist
@ 2013-01-22 15:30 ` Alan Stern
0 siblings, 0 replies; 155+ messages in thread
From: Alan Stern @ 2013-01-22 15:30 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, 22 Jan 2013, Shawn Guo wrote:
> On Mon, Jan 21, 2013 at 09:37:42PM +0000, Arnd Bergmann wrote:
> > > Arnd, please take a look at
> > >
> > > http://marc.info/?l=linux-usb&m=135843716515529&w=2
> > >
> > > I can't test it easily, not being set up for cross compilation. I'm
> > > waiting to hear from anybody whether it works before submitting it.
> > > (There's also a report of memory corruption involving a similar patch
> > > for ehci-omap; it hasn't been tracked down yet.)
> >
> > Your patch looks good to me, but it also seems to do some other
> > changes that are not required to fix the problem but could wait
> > for 3.9 instead. You definitely have my Ack if you are willing
> > to take it for 3.8 though.
I think it's not too late to submit this for 3.8. Thanks for the Ack.
> > Shawn or Sascha should be able to test it.
> >
> Alan,
>
> Thanks for the patch. I just gave it try. The USB Host port still
> works for me with a couple of fixes on your changes integrated (one
> for compiling and the other for probing). So you have my ACK with
> the changes below rolled into your patch.
Right, I have merged your changes into the patch. Will submit shortly.
Alan Stern
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [PATCH 13/15] USB: ehci: make orion and mxc bus glues coexist
2013-01-21 18:42 ` Felipe Balbi
@ 2013-01-21 20:14 ` Arnd Bergmann
-1 siblings, 0 replies; 155+ messages in thread
From: Arnd Bergmann @ 2013-01-21 20:14 UTC (permalink / raw)
To: balbi
Cc: linux-arm-kernel, linux-kernel, arm, Alan Stern,
Greg Kroah-Hartman, linux-usb, Manjunath Goudar, Shawn Guo,
Sascha Hauer, Jason Cooper, Andrew Lunn, Gregory Clement
On Monday 21 January 2013, Felipe Balbi wrote:
> On Mon, Jan 21, 2013 at 05:16:06PM +0000, Arnd Bergmann wrote:
> > 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.
>
> NAK, should be converted to the new usage of ehci library driver. Alan
> Stern already implemented for a few drivers, help is very welcome.
As I explained above, Manjunath already has a patch [1] for that, but I
think it's too late to include that in v3.8 given the regression
potential and size of the patch. Once he submits that patch for 3.9,
my change would get taken out anyway, but it lets us build important
configurations (including allyesconfig build tests) on 3.8.
Arnd
[1] http://git.linaro.org/gitweb?p=people/manjunathgoudar/usb-refactoring.git;a=commitdiff;h=d9f28dba727212d022605c955796a3a83b3978ae
^ permalink raw reply [flat|nested] 155+ messages in thread
* [PATCH 13/15] USB: ehci: make orion and mxc bus glues coexist
@ 2013-01-21 20:14 ` Arnd Bergmann
0 siblings, 0 replies; 155+ messages in thread
From: Arnd Bergmann @ 2013-01-21 20:14 UTC (permalink / raw)
To: linux-arm-kernel
On Monday 21 January 2013, Felipe Balbi wrote:
> On Mon, Jan 21, 2013 at 05:16:06PM +0000, Arnd Bergmann wrote:
> > 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.
>
> NAK, should be converted to the new usage of ehci library driver. Alan
> Stern already implemented for a few drivers, help is very welcome.
As I explained above, Manjunath already has a patch [1] for that, but I
think it's too late to include that in v3.8 given the regression
potential and size of the patch. Once he submits that patch for 3.9,
my change would get taken out anyway, but it lets us build important
configurations (including allyesconfig build tests) on 3.8.
Arnd
[1] http://git.linaro.org/gitweb?p=people/manjunathgoudar/usb-refactoring.git;a=commitdiff;h=d9f28dba727212d022605c955796a3a83b3978ae
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [PATCH 13/15] USB: ehci: make orion and mxc bus glues coexist
2013-01-21 20:14 ` Arnd Bergmann
@ 2013-01-21 20:35 ` Alan Stern
-1 siblings, 0 replies; 155+ messages in thread
From: Alan Stern @ 2013-01-21 20:35 UTC (permalink / raw)
To: Arnd Bergmann
Cc: balbi, linux-arm-kernel, linux-kernel, arm, Greg Kroah-Hartman,
linux-usb, Manjunath Goudar, Shawn Guo, Sascha Hauer,
Jason Cooper, Andrew Lunn, Gregory Clement
On Mon, 21 Jan 2013, Arnd Bergmann wrote:
> On Monday 21 January 2013, Felipe Balbi wrote:
> > On Mon, Jan 21, 2013 at 05:16:06PM +0000, Arnd Bergmann wrote:
> > > 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.
> >
> > NAK, should be converted to the new usage of ehci library driver. Alan
> > Stern already implemented for a few drivers, help is very welcome.
>
> As I explained above, Manjunath already has a patch [1] for that, but I
> think it's too late to include that in v3.8 given the regression
> potential and size of the patch. Once he submits that patch for 3.9,
> my change would get taken out anyway, but it lets us build important
> configurations (including allyesconfig build tests) on 3.8.
>
> Arnd
>
> [1] http://git.linaro.org/gitweb?p=people/manjunathgoudar/usb-refactoring.git;a=commitdiff;h=d9f28dba727212d022605c955796a3a83b3978ae
Is Manjunath aware of the first patch attached to this email message?
http://marc.info/?l=linux-usb&m=135843902916416&w=2
Alan Stern
^ permalink raw reply [flat|nested] 155+ messages in thread
* [PATCH 13/15] USB: ehci: make orion and mxc bus glues coexist
@ 2013-01-21 20:35 ` Alan Stern
0 siblings, 0 replies; 155+ messages in thread
From: Alan Stern @ 2013-01-21 20:35 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, 21 Jan 2013, Arnd Bergmann wrote:
> On Monday 21 January 2013, Felipe Balbi wrote:
> > On Mon, Jan 21, 2013 at 05:16:06PM +0000, Arnd Bergmann wrote:
> > > 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.
> >
> > NAK, should be converted to the new usage of ehci library driver. Alan
> > Stern already implemented for a few drivers, help is very welcome.
>
> As I explained above, Manjunath already has a patch [1] for that, but I
> think it's too late to include that in v3.8 given the regression
> potential and size of the patch. Once he submits that patch for 3.9,
> my change would get taken out anyway, but it lets us build important
> configurations (including allyesconfig build tests) on 3.8.
>
> Arnd
>
> [1] http://git.linaro.org/gitweb?p=people/manjunathgoudar/usb-refactoring.git;a=commitdiff;h=d9f28dba727212d022605c955796a3a83b3978ae
Is Manjunath aware of the first patch attached to this email message?
http://marc.info/?l=linux-usb&m=135843902916416&w=2
Alan Stern
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [PATCH 13/15] USB: ehci: make orion and mxc bus glues coexist
2013-01-21 20:35 ` Alan Stern
@ 2013-01-21 21:49 ` Arnd Bergmann
-1 siblings, 0 replies; 155+ messages in thread
From: Arnd Bergmann @ 2013-01-21 21:49 UTC (permalink / raw)
To: Alan Stern
Cc: balbi, linux-arm-kernel, linux-kernel, arm, Greg Kroah-Hartman,
linux-usb, Manjunath Goudar, Shawn Guo, Sascha Hauer,
Jason Cooper, Andrew Lunn, Gregory Clement
On Monday 21 January 2013, Alan Stern wrote:
> Is Manjunath aware of the first patch attached to this email message?
>
> http://marc.info/?l=linux-usb&m=135843902916416&w=2
>
I would not expect so. Manjunath is still learning about the open
source processes, but he has also done a similar patch in his tree,
and one for most of the other ARM based platforms.
Manjunath: following up on the discussions we've had, I would suggest
you take a look at that patch, and do a comparison with your version
(apply it on the same base, then use git-diff to show the differences
between the version) and thing about whether your they are significant
or not. Since Alan posted his version on the mailing list first, that's
the one that should get merged, but there might be something in it that
you can learn from it and that I did not see.
Alan, one comment about your version: You keep maintaining the
'#if IS_ENABLED' list in the main driver, which I think can actually
get removed now. Since the base driver can be built independent of
the presence of platform glue drivers, there is no need to forbid
it any more, and the #if block will cause merge conflicts for each
patch that converts or adds another platform. I think we can actually
get the same results by turning the Kconfig logic around and making
the platform glue drivers 'select USB_EHCI_HCD' than depending on
it.
Arnd
^ permalink raw reply [flat|nested] 155+ messages in thread
* [PATCH 13/15] USB: ehci: make orion and mxc bus glues coexist
@ 2013-01-21 21:49 ` Arnd Bergmann
0 siblings, 0 replies; 155+ messages in thread
From: Arnd Bergmann @ 2013-01-21 21:49 UTC (permalink / raw)
To: linux-arm-kernel
On Monday 21 January 2013, Alan Stern wrote:
> Is Manjunath aware of the first patch attached to this email message?
>
> http://marc.info/?l=linux-usb&m=135843902916416&w=2
>
I would not expect so. Manjunath is still learning about the open
source processes, but he has also done a similar patch in his tree,
and one for most of the other ARM based platforms.
Manjunath: following up on the discussions we've had, I would suggest
you take a look at that patch, and do a comparison with your version
(apply it on the same base, then use git-diff to show the differences
between the version) and thing about whether your they are significant
or not. Since Alan posted his version on the mailing list first, that's
the one that should get merged, but there might be something in it that
you can learn from it and that I did not see.
Alan, one comment about your version: You keep maintaining the
'#if IS_ENABLED' list in the main driver, which I think can actually
get removed now. Since the base driver can be built independent of
the presence of platform glue drivers, there is no need to forbid
it any more, and the #if block will cause merge conflicts for each
patch that converts or adds another platform. I think we can actually
get the same results by turning the Kconfig logic around and making
the platform glue drivers 'select USB_EHCI_HCD' than depending on
it.
Arnd
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [PATCH 13/15] USB: ehci: make orion and mxc bus glues coexist
2013-01-21 21:49 ` Arnd Bergmann
@ 2013-01-22 3:39 ` Alan Stern
-1 siblings, 0 replies; 155+ messages in thread
From: Alan Stern @ 2013-01-22 3:39 UTC (permalink / raw)
To: Arnd Bergmann
Cc: balbi, linux-arm-kernel, linux-kernel, arm, Greg Kroah-Hartman,
linux-usb, Manjunath Goudar, Shawn Guo, Sascha Hauer,
Jason Cooper, Andrew Lunn, Gregory Clement
On Mon, 21 Jan 2013, Arnd Bergmann wrote:
> Alan, one comment about your version: You keep maintaining the
> '#if IS_ENABLED' list in the main driver, which I think can actually
> get removed now.
I considered doing that. The benefit of keeping it is that it warns
about configs where the main driver is built but can never be used.
Still, you're right that its purpose is becoming less important. I had
planned to remove it when all the glue driver had been converted, but
in fact it could be removed at any time.
> Since the base driver can be built independent of
> the presence of platform glue drivers, there is no need to forbid
> it any more, and the #if block will cause merge conflicts for each
> patch that converts or adds another platform.
If the patches are done independently. There are likely to be some
context conflicts anyway.
> I think we can actually
> get the same results by turning the Kconfig logic around and making
> the platform glue drivers 'select USB_EHCI_HCD' than depending on
> it.
That's a good idea. The Kconfig changes would have to be done
carefully to make sure that the dependency on USB_ARCH_HAS_EHCI still
applies to all the platform drivers.
Manjunath, would you like to send a patch to do this?
Alan Stern
^ permalink raw reply [flat|nested] 155+ messages in thread
* [PATCH 13/15] USB: ehci: make orion and mxc bus glues coexist
@ 2013-01-22 3:39 ` Alan Stern
0 siblings, 0 replies; 155+ messages in thread
From: Alan Stern @ 2013-01-22 3:39 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, 21 Jan 2013, Arnd Bergmann wrote:
> Alan, one comment about your version: You keep maintaining the
> '#if IS_ENABLED' list in the main driver, which I think can actually
> get removed now.
I considered doing that. The benefit of keeping it is that it warns
about configs where the main driver is built but can never be used.
Still, you're right that its purpose is becoming less important. I had
planned to remove it when all the glue driver had been converted, but
in fact it could be removed at any time.
> Since the base driver can be built independent of
> the presence of platform glue drivers, there is no need to forbid
> it any more, and the #if block will cause merge conflicts for each
> patch that converts or adds another platform.
If the patches are done independently. There are likely to be some
context conflicts anyway.
> I think we can actually
> get the same results by turning the Kconfig logic around and making
> the platform glue drivers 'select USB_EHCI_HCD' than depending on
> it.
That's a good idea. The Kconfig changes would have to be done
carefully to make sure that the dependency on USB_ARCH_HAS_EHCI still
applies to all the platform drivers.
Manjunath, would you like to send a patch to do this?
Alan Stern
^ permalink raw reply [flat|nested] 155+ messages in thread
* [PATCH 13/15] USB: ehci: make orion and mxc bus glues coexist
2013-01-22 3:39 ` Alan Stern
(?)
@ 2013-01-22 4:13 ` Manjunath Goudar
2013-01-22 15:19 ` Alan Stern
-1 siblings, 1 reply; 155+ messages in thread
From: Manjunath Goudar @ 2013-01-22 4:13 UTC (permalink / raw)
To: linux-arm-kernel
On 22 January 2013 09:09, Alan Stern <stern@rowland.harvard.edu> wrote:
> On Mon, 21 Jan 2013, Arnd Bergmann wrote:
>
> > Alan, one comment about your version: You keep maintaining the
> > '#if IS_ENABLED' list in the main driver, which I think can actually
> > get removed now.
>
> I considered doing that. The benefit of keeping it is that it warns
> about configs where the main driver is built but can never be used.
>
> Still, you're right that its purpose is becoming less important. I had
> planned to remove it when all the glue driver had been converted, but
> in fact it could be removed at any time.
>
> > Since the base driver can be built independent of
> > the presence of platform glue drivers, there is no need to forbid
> > it any more, and the #if block will cause merge conflicts for each
> > patch that converts or adds another platform.
>
> If the patches are done independently. There are likely to be some
> context conflicts anyway.
>
> > I think we can actually
> > get the same results by turning the Kconfig logic around and making
> > the platform glue drivers 'select USB_EHCI_HCD' than depending on
> > it.
>
> That's a good idea. The Kconfig changes would have to be done
> carefully to make sure that the dependency on USB_ARCH_HAS_EHCI still
> applies to all the platform drivers.
>
> Manjunath, would you like to send a patch to do this?
>
> Alan Stern
>
> Ya sure,could you explain little bit briefly about the Kconfig changes.
Thanks
MAnjunath Goudar
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130122/18a62ca8/attachment-0001.html>
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [PATCH 13/15] USB: ehci: make orion and mxc bus glues coexist
2013-01-22 4:13 ` Manjunath Goudar
@ 2013-01-22 15:19 ` Alan Stern
0 siblings, 0 replies; 155+ messages in thread
From: Alan Stern @ 2013-01-22 15:19 UTC (permalink / raw)
To: Manjunath Goudar
Cc: Arnd Bergmann, balbi, linux-arm-kernel, linux-kernel, arm,
Greg Kroah-Hartman, linux-usb, Shawn Guo, Sascha Hauer,
Jason Cooper, Andrew Lunn, Gregory Clement
On Tue, 22 Jan 2013, Manjunath Goudar wrote:
> > > I think we can actually
> > > get the same results by turning the Kconfig logic around and making
> > > the platform glue drivers 'select USB_EHCI_HCD' than depending on
> > > it.
> >
> > That's a good idea. The Kconfig changes would have to be done
> > carefully to make sure that the dependency on USB_ARCH_HAS_EHCI still
> > applies to all the platform drivers.
> >
> > Manjunath, would you like to send a patch to do this?
> >
> > Alan Stern
> >
> > Ya sure,could you explain little bit briefly about the Kconfig changes.
Suppose you do exactly what Arnd proposed: add "select USB_EHCI_HCD" to
the Kconfig entries for each of the platform glue drivers. Then
consider what would happen in a build where USB_ARCH_HAS_EHCI is "n"
but one of those glue drivers is enabled. There would be conflicting
requirements on USB_EHCI_HCD: The new "select" would force it to be on,
but the existing "depends on USB && USB_ARCH_HAS_EHCI" would force it
to be off. The build would fail.
In order to prevent this, you have to make sure that each glue driver
depends on USB_ARCH_HAS_EHCI. A simple way to do this is to surround
the Kconfig entries for those drivers with "if USB &&
USB_ARCH_HAS_EHCI" ... "endif".
Come to think of it, the "if USB" part really should protect the entire
file.
Alan Stern
^ permalink raw reply [flat|nested] 155+ messages in thread
* [PATCH 13/15] USB: ehci: make orion and mxc bus glues coexist
@ 2013-01-22 15:19 ` Alan Stern
0 siblings, 0 replies; 155+ messages in thread
From: Alan Stern @ 2013-01-22 15:19 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, 22 Jan 2013, Manjunath Goudar wrote:
> > > I think we can actually
> > > get the same results by turning the Kconfig logic around and making
> > > the platform glue drivers 'select USB_EHCI_HCD' than depending on
> > > it.
> >
> > That's a good idea. The Kconfig changes would have to be done
> > carefully to make sure that the dependency on USB_ARCH_HAS_EHCI still
> > applies to all the platform drivers.
> >
> > Manjunath, would you like to send a patch to do this?
> >
> > Alan Stern
> >
> > Ya sure,could you explain little bit briefly about the Kconfig changes.
Suppose you do exactly what Arnd proposed: add "select USB_EHCI_HCD" to
the Kconfig entries for each of the platform glue drivers. Then
consider what would happen in a build where USB_ARCH_HAS_EHCI is "n"
but one of those glue drivers is enabled. There would be conflicting
requirements on USB_EHCI_HCD: The new "select" would force it to be on,
but the existing "depends on USB && USB_ARCH_HAS_EHCI" would force it
to be off. The build would fail.
In order to prevent this, you have to make sure that each glue driver
depends on USB_ARCH_HAS_EHCI. A simple way to do this is to surround
the Kconfig entries for those drivers with "if USB &&
USB_ARCH_HAS_EHCI" ... "endif".
Come to think of it, the "if USB" part really should protect the entire
file.
Alan Stern
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [PATCH 13/15] USB: ehci: make orion and mxc bus glues coexist
2013-01-22 15:19 ` Alan Stern
@ 2013-01-22 15:38 ` Arnd Bergmann
-1 siblings, 0 replies; 155+ messages in thread
From: Arnd Bergmann @ 2013-01-22 15:38 UTC (permalink / raw)
To: Alan Stern
Cc: Manjunath Goudar, balbi, linux-arm-kernel, linux-kernel, arm,
Greg Kroah-Hartman, linux-usb, Shawn Guo, Sascha Hauer,
Jason Cooper, Andrew Lunn, Gregory Clement
On Tuesday 22 January 2013, Alan Stern wrote:
> In order to prevent this, you have to make sure that each glue driver
> depends on USB_ARCH_HAS_EHCI. A simple way to do this is to surround
> the Kconfig entries for those drivers with "if USB &&
> USB_ARCH_HAS_EHCI" ... "endif".
I was actually thinking we could remove the use of USB_ARCH_HAS_EHCI
as well once we have inverted the logic for selecting USB_EHCI_HCD,
but there is another problem with that, because then we still need
something to select USB_ARCH_HAS_HCD, or kill that symbol as well.
Arnd
^ permalink raw reply [flat|nested] 155+ messages in thread
* [PATCH 13/15] USB: ehci: make orion and mxc bus glues coexist
@ 2013-01-22 15:38 ` Arnd Bergmann
0 siblings, 0 replies; 155+ messages in thread
From: Arnd Bergmann @ 2013-01-22 15:38 UTC (permalink / raw)
To: linux-arm-kernel
On Tuesday 22 January 2013, Alan Stern wrote:
> In order to prevent this, you have to make sure that each glue driver
> depends on USB_ARCH_HAS_EHCI. A simple way to do this is to surround
> the Kconfig entries for those drivers with "if USB &&
> USB_ARCH_HAS_EHCI" ... "endif".
I was actually thinking we could remove the use of USB_ARCH_HAS_EHCI
as well once we have inverted the logic for selecting USB_EHCI_HCD,
but there is another problem with that, because then we still need
something to select USB_ARCH_HAS_HCD, or kill that symbol as well.
Arnd
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [PATCH 13/15] USB: ehci: make orion and mxc bus glues coexist
2013-01-22 15:38 ` Arnd Bergmann
@ 2013-01-22 21:00 ` Sascha Hauer
-1 siblings, 0 replies; 155+ messages in thread
From: Sascha Hauer @ 2013-01-22 21:00 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Alan Stern, Manjunath Goudar, balbi, linux-arm-kernel,
linux-kernel, arm, Greg Kroah-Hartman, linux-usb, Shawn Guo,
Jason Cooper, Andrew Lunn, Gregory Clement
On Tue, Jan 22, 2013 at 03:38:55PM +0000, Arnd Bergmann wrote:
> On Tuesday 22 January 2013, Alan Stern wrote:
> > In order to prevent this, you have to make sure that each glue driver
> > depends on USB_ARCH_HAS_EHCI. A simple way to do this is to surround
> > the Kconfig entries for those drivers with "if USB &&
> > USB_ARCH_HAS_EHCI" ... "endif".
>
> I was actually thinking we could remove the use of USB_ARCH_HAS_EHCI
> as well once we have inverted the logic for selecting USB_EHCI_HCD,
> but there is another problem with that, because then we still need
> something to select USB_ARCH_HAS_HCD, or kill that symbol as well.
+1 for killing it. Such symbols get more and more meaningless anyway
with multiarch kernels-
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply [flat|nested] 155+ messages in thread
* [PATCH 13/15] USB: ehci: make orion and mxc bus glues coexist
@ 2013-01-22 21:00 ` Sascha Hauer
0 siblings, 0 replies; 155+ messages in thread
From: Sascha Hauer @ 2013-01-22 21:00 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Jan 22, 2013 at 03:38:55PM +0000, Arnd Bergmann wrote:
> On Tuesday 22 January 2013, Alan Stern wrote:
> > In order to prevent this, you have to make sure that each glue driver
> > depends on USB_ARCH_HAS_EHCI. A simple way to do this is to surround
> > the Kconfig entries for those drivers with "if USB &&
> > USB_ARCH_HAS_EHCI" ... "endif".
>
> I was actually thinking we could remove the use of USB_ARCH_HAS_EHCI
> as well once we have inverted the logic for selecting USB_EHCI_HCD,
> but there is another problem with that, because then we still need
> something to select USB_ARCH_HAS_HCD, or kill that symbol as well.
+1 for killing it. Such symbols get more and more meaningless anyway
with multiarch kernels-
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [PATCH 13/15] USB: ehci: make orion and mxc bus glues coexist
2013-01-22 21:00 ` Sascha Hauer
@ 2013-01-23 15:22 ` Alan Stern
-1 siblings, 0 replies; 155+ messages in thread
From: Alan Stern @ 2013-01-23 15:22 UTC (permalink / raw)
To: Sascha Hauer
Cc: Arnd Bergmann, Manjunath Goudar, balbi, linux-arm-kernel,
linux-kernel, arm, Greg Kroah-Hartman, linux-usb, Shawn Guo,
Jason Cooper, Andrew Lunn, Gregory Clement
On Tue, 22 Jan 2013, Sascha Hauer wrote:
> On Tue, Jan 22, 2013 at 03:38:55PM +0000, Arnd Bergmann wrote:
> > On Tuesday 22 January 2013, Alan Stern wrote:
> > > In order to prevent this, you have to make sure that each glue driver
> > > depends on USB_ARCH_HAS_EHCI. A simple way to do this is to surround
> > > the Kconfig entries for those drivers with "if USB &&
> > > USB_ARCH_HAS_EHCI" ... "endif".
> >
> > I was actually thinking we could remove the use of USB_ARCH_HAS_EHCI
> > as well once we have inverted the logic for selecting USB_EHCI_HCD,
> > but there is another problem with that, because then we still need
> > something to select USB_ARCH_HAS_HCD, or kill that symbol as well.
>
> +1 for killing it. Such symbols get more and more meaningless anyway
> with multiarch kernels-
I tend to agree. Anyway, the symbols are named badly. _Any_
architecture with HAS_IOMEM can in theory aupport host-side USB.
Maybe some of the platforms don't, but that has nothing to do with the
CPU's architecture.
Furthermore, even platforms that don't support USB host controllers
can use things like dummy-hcd and usbip, which provide virtual host
controllers.
Anybody think these symbols should be retained?
Alan Stern
^ permalink raw reply [flat|nested] 155+ messages in thread
* [PATCH 13/15] USB: ehci: make orion and mxc bus glues coexist
@ 2013-01-23 15:22 ` Alan Stern
0 siblings, 0 replies; 155+ messages in thread
From: Alan Stern @ 2013-01-23 15:22 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, 22 Jan 2013, Sascha Hauer wrote:
> On Tue, Jan 22, 2013 at 03:38:55PM +0000, Arnd Bergmann wrote:
> > On Tuesday 22 January 2013, Alan Stern wrote:
> > > In order to prevent this, you have to make sure that each glue driver
> > > depends on USB_ARCH_HAS_EHCI. A simple way to do this is to surround
> > > the Kconfig entries for those drivers with "if USB &&
> > > USB_ARCH_HAS_EHCI" ... "endif".
> >
> > I was actually thinking we could remove the use of USB_ARCH_HAS_EHCI
> > as well once we have inverted the logic for selecting USB_EHCI_HCD,
> > but there is another problem with that, because then we still need
> > something to select USB_ARCH_HAS_HCD, or kill that symbol as well.
>
> +1 for killing it. Such symbols get more and more meaningless anyway
> with multiarch kernels-
I tend to agree. Anyway, the symbols are named badly. _Any_
architecture with HAS_IOMEM can in theory aupport host-side USB.
Maybe some of the platforms don't, but that has nothing to do with the
CPU's architecture.
Furthermore, even platforms that don't support USB host controllers
can use things like dummy-hcd and usbip, which provide virtual host
controllers.
Anybody think these symbols should be retained?
Alan Stern
^ permalink raw reply [flat|nested] 155+ messages in thread
* [PATCH 14/15] samples/seccomp: be less stupid about cross compiling
2013-01-21 17:15 ` Arnd Bergmann
@ 2013-01-21 17:16 ` Arnd Bergmann
-1 siblings, 0 replies; 155+ messages in thread
From: Arnd Bergmann @ 2013-01-21 17:16 UTC (permalink / raw)
To: linux-arm-kernel
Cc: linux-kernel, arm, Arnd Bergmann, Heiko Carstens, Kees Cook,
James Morris
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 [flat|nested] 155+ messages in thread* [PATCH 14/15] samples/seccomp: be less stupid about cross compiling
@ 2013-01-21 17:16 ` Arnd Bergmann
0 siblings, 0 replies; 155+ messages in thread
From: Arnd Bergmann @ 2013-01-21 17:16 UTC (permalink / raw)
To: linux-arm-kernel
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 [flat|nested] 155+ messages in thread* Re: [PATCH 14/15] samples/seccomp: be less stupid about cross compiling
2013-01-21 17:16 ` Arnd Bergmann
@ 2013-01-22 21:20 ` Kees Cook
-1 siblings, 0 replies; 155+ messages in thread
From: Kees Cook @ 2013-01-22 21:20 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-arm-kernel, LKML, arm, Heiko Carstens, James Morris, Will Drewry
On Mon, Jan 21, 2013 at 9:16 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> 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>
I'm fine with this. Thanks!
Acked-by: Kees Cook <keescook@chromium.org>
-Kees
> ---
> 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
>
--
Kees Cook
Chrome OS Security
^ permalink raw reply [flat|nested] 155+ messages in thread
* [PATCH 14/15] samples/seccomp: be less stupid about cross compiling
@ 2013-01-22 21:20 ` Kees Cook
0 siblings, 0 replies; 155+ messages in thread
From: Kees Cook @ 2013-01-22 21:20 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, Jan 21, 2013 at 9:16 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> 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>
I'm fine with this. Thanks!
Acked-by: Kees Cook <keescook@chromium.org>
-Kees
> ---
> 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
>
--
Kees Cook
Chrome OS Security
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [PATCH 14/15] samples/seccomp: be less stupid about cross compiling
2013-01-22 21:20 ` Kees Cook
@ 2013-01-28 14:26 ` Will Drewry
-1 siblings, 0 replies; 155+ messages in thread
From: Will Drewry @ 2013-01-28 14:26 UTC (permalink / raw)
To: Kees Cook
Cc: Arnd Bergmann, linux-arm-kernel, LKML, arm, Heiko Carstens,
James Morris, Andrew Morton
On Tue, Jan 22, 2013 at 3:20 PM, Kees Cook <keescook@chromium.org> wrote:
> On Mon, Jan 21, 2013 at 9:16 AM, Arnd Bergmann <arnd@arndb.de> wrote:
>> 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>
>
> I'm fine with this. Thanks!
>
> Acked-by: Kees Cook <keescook@chromium.org>
Thanks! This makes a lot of sense and maybe buys a bit more time to
figure out the best way to build these (all?) samples for the target.
Acked-by: Will Drewry <wad@chromium.org>
>
>> ---
>> 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
>>
>
>
>
> --
> Kees Cook
> Chrome OS Security
^ permalink raw reply [flat|nested] 155+ messages in thread
* [PATCH 14/15] samples/seccomp: be less stupid about cross compiling
@ 2013-01-28 14:26 ` Will Drewry
0 siblings, 0 replies; 155+ messages in thread
From: Will Drewry @ 2013-01-28 14:26 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Jan 22, 2013 at 3:20 PM, Kees Cook <keescook@chromium.org> wrote:
> On Mon, Jan 21, 2013 at 9:16 AM, Arnd Bergmann <arnd@arndb.de> wrote:
>> 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>
>
> I'm fine with this. Thanks!
>
> Acked-by: Kees Cook <keescook@chromium.org>
Thanks! This makes a lot of sense and maybe buys a bit more time to
figure out the best way to build these (all?) samples for the target.
Acked-by: Will Drewry <wad@chromium.org>
>
>> ---
>> 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
>>
>
>
>
> --
> Kees Cook
> Chrome OS Security
^ permalink raw reply [flat|nested] 155+ messages in thread
* [PATCH 15/15] staging/omapdrm: don't build on multiplatform
2013-01-21 17:15 ` Arnd Bergmann
@ 2013-01-21 17:16 ` Arnd Bergmann
-1 siblings, 0 replies; 155+ messages in thread
From: Arnd Bergmann @ 2013-01-21 17:16 UTC (permalink / raw)
To: linux-arm-kernel
Cc: linux-kernel, arm, Arnd Bergmann, Rob Clark, Greg Kroah-Hartman
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 [flat|nested] 155+ messages in thread
* [PATCH 15/15] staging/omapdrm: don't build on multiplatform
@ 2013-01-21 17:16 ` Arnd Bergmann
0 siblings, 0 replies; 155+ messages in thread
From: Arnd Bergmann @ 2013-01-21 17:16 UTC (permalink / raw)
To: linux-arm-kernel
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 [flat|nested] 155+ messages in thread
* Re: [PATCH 15/15] staging/omapdrm: don't build on multiplatform
2013-01-21 17:16 ` Arnd Bergmann
@ 2013-01-21 17:26 ` Rob Clark
-1 siblings, 0 replies; 155+ messages in thread
From: Rob Clark @ 2013-01-21 17:26 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linux-arm-kernel, linux-kernel, arm, Greg Kroah-Hartman
On 01/21/2013 11:16 AM, Arnd Bergmann wrote:
> 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.
Are you sure OMAP2_DSS requires ARCH_OMAP2PLUS? I don't see this, and
it at least used to not depend on ARCH_OMAP2PLUS. If it does now, I
think the correct fix would be to remove the dependency in OMAP2_DSS. I
don't think removing ARCH_MULTIPLATFORM support in omapdrm is the
correct solution.
> 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
This was an unrelated build break which should be fixed in latest master
after 'staging: drm/omap: use omapdss low level API'
BR,
-R
>
> 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
^ permalink raw reply [flat|nested] 155+ messages in thread
* [PATCH 15/15] staging/omapdrm: don't build on multiplatform
@ 2013-01-21 17:26 ` Rob Clark
0 siblings, 0 replies; 155+ messages in thread
From: Rob Clark @ 2013-01-21 17:26 UTC (permalink / raw)
To: linux-arm-kernel
On 01/21/2013 11:16 AM, Arnd Bergmann wrote:
> 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.
Are you sure OMAP2_DSS requires ARCH_OMAP2PLUS? I don't see this, and
it at least used to not depend on ARCH_OMAP2PLUS. If it does now, I
think the correct fix would be to remove the dependency in OMAP2_DSS. I
don't think removing ARCH_MULTIPLATFORM support in omapdrm is the
correct solution.
> 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
This was an unrelated build break which should be fixed in latest master
after 'staging: drm/omap: use omapdss low level API'
BR,
-R
>
> 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
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [PATCH 15/15] staging/omapdrm: don't build on multiplatform
2013-01-21 17:26 ` Rob Clark
@ 2013-01-21 17:29 ` Rob Clark
-1 siblings, 0 replies; 155+ messages in thread
From: Rob Clark @ 2013-01-21 17:29 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linux-arm-kernel, linux-kernel, arm, Greg Kroah-Hartman
On 01/21/2013 11:26 AM, Rob Clark wrote:
> On 01/21/2013 11:16 AM, Arnd Bergmann wrote:
>> 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.
>
> Are you sure OMAP2_DSS requires ARCH_OMAP2PLUS? I don't see this, and
> it at least used to not depend on ARCH_OMAP2PLUS. If it does now, I
> think the correct fix would be to remove the dependency in OMAP2_DSS.
> I don't think removing ARCH_MULTIPLATFORM support in omapdrm is the
> correct solution.
hmm, yes, it does appear that OMAP2_DSS depends on ARCH_OMAP2PLUS.. let
me have a quick look at this, fixing omapdss would be a better solution..
BR,
-R
>
>
>> 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
>
>
> This was an unrelated build break which should be fixed in latest
> master after 'staging: drm/omap: use omapdss low level API'
>
> BR,
> -R
>
>>
>> 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
>
^ permalink raw reply [flat|nested] 155+ messages in thread
* [PATCH 15/15] staging/omapdrm: don't build on multiplatform
@ 2013-01-21 17:29 ` Rob Clark
0 siblings, 0 replies; 155+ messages in thread
From: Rob Clark @ 2013-01-21 17:29 UTC (permalink / raw)
To: linux-arm-kernel
On 01/21/2013 11:26 AM, Rob Clark wrote:
> On 01/21/2013 11:16 AM, Arnd Bergmann wrote:
>> 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.
>
> Are you sure OMAP2_DSS requires ARCH_OMAP2PLUS? I don't see this, and
> it at least used to not depend on ARCH_OMAP2PLUS. If it does now, I
> think the correct fix would be to remove the dependency in OMAP2_DSS.
> I don't think removing ARCH_MULTIPLATFORM support in omapdrm is the
> correct solution.
hmm, yes, it does appear that OMAP2_DSS depends on ARCH_OMAP2PLUS.. let
me have a quick look at this, fixing omapdss would be a better solution..
BR,
-R
>
>
>> 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
>
>
> This was an unrelated build break which should be fixed in latest
> master after 'staging: drm/omap: use omapdss low level API'
>
> BR,
> -R
>
>>
>> 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
>
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [PATCH 15/15] staging/omapdrm: don't build on multiplatform
2013-01-21 17:26 ` Rob Clark
@ 2013-01-21 17:41 ` Arnd Bergmann
-1 siblings, 0 replies; 155+ messages in thread
From: Arnd Bergmann @ 2013-01-21 17:41 UTC (permalink / raw)
To: Rob Clark; +Cc: linux-arm-kernel, linux-kernel, arm, Greg Kroah-Hartman
On Monday 21 January 2013, Rob Clark wrote:
> Are you sure OMAP2_DSS requires ARCH_OMAP2PLUS? I don't see this, and
> it at least used to not depend on ARCH_OMAP2PLUS. If it does now, I
> think the correct fix would be to remove the dependency in OMAP2_DSS. I
> don't think removing ARCH_MULTIPLATFORM support in omapdrm is the
> correct solution.
At least it says so in drivers/video/omap2/Kconfig, which contains
if ARCH_OMAP2PLUS
source drivers/video/omap2/dss/Kconfig
endif
We can probably change this, but until we do, we should not select
OMAP2_DSS from something that doesn't also depend on 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
>
>
> This was an unrelated build break which should be fixed in latest master
> after 'staging: drm/omap: use omapdss low level API'
Ok, it seems the message is stale then, I created the patch some time ago, but
only today wrote rest of the explanation for the changeset text.
With all the other patches from my series applied, allyesconfig still gives me
drivers/video/omap2/dss/dss.c:572:20: error: 'CONFIG_OMAP2_DSS_MIN_FCK_PER_PCK' undeclared
because that symbol is only defined when OMAP2_DSS is enabled rather than
selected. Changing drivers/video/omap2/Kconfig to not depend on OMAP seems
to work as well, but that seems a little intrusive for v3.8, because it would
let a lot of people build that code that have no use for it.
Arnd
^ permalink raw reply [flat|nested] 155+ messages in thread
* [PATCH 15/15] staging/omapdrm: don't build on multiplatform
@ 2013-01-21 17:41 ` Arnd Bergmann
0 siblings, 0 replies; 155+ messages in thread
From: Arnd Bergmann @ 2013-01-21 17:41 UTC (permalink / raw)
To: linux-arm-kernel
On Monday 21 January 2013, Rob Clark wrote:
> Are you sure OMAP2_DSS requires ARCH_OMAP2PLUS? I don't see this, and
> it at least used to not depend on ARCH_OMAP2PLUS. If it does now, I
> think the correct fix would be to remove the dependency in OMAP2_DSS. I
> don't think removing ARCH_MULTIPLATFORM support in omapdrm is the
> correct solution.
At least it says so in drivers/video/omap2/Kconfig, which contains
if ARCH_OMAP2PLUS
source drivers/video/omap2/dss/Kconfig
endif
We can probably change this, but until we do, we should not select
OMAP2_DSS from something that doesn't also depend on 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
>
>
> This was an unrelated build break which should be fixed in latest master
> after 'staging: drm/omap: use omapdss low level API'
Ok, it seems the message is stale then, I created the patch some time ago, but
only today wrote rest of the explanation for the changeset text.
With all the other patches from my series applied, allyesconfig still gives me
drivers/video/omap2/dss/dss.c:572:20: error: 'CONFIG_OMAP2_DSS_MIN_FCK_PER_PCK' undeclared
because that symbol is only defined when OMAP2_DSS is enabled rather than
selected. Changing drivers/video/omap2/Kconfig to not depend on OMAP seems
to work as well, but that seems a little intrusive for v3.8, because it would
let a lot of people build that code that have no use for it.
Arnd
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [PATCH 15/15] staging/omapdrm: don't build on multiplatform
2013-01-21 17:41 ` Arnd Bergmann
@ 2013-01-21 18:39 ` Rob Clark
-1 siblings, 0 replies; 155+ messages in thread
From: Rob Clark @ 2013-01-21 18:39 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linux-arm-kernel, linux-kernel, arm, Greg Kroah-Hartman
On 01/21/2013 11:41 AM, Arnd Bergmann wrote:
> On Monday 21 January 2013, Rob Clark wrote:
>> Are you sure OMAP2_DSS requires ARCH_OMAP2PLUS? I don't see this, and
>> it at least used to not depend on ARCH_OMAP2PLUS. If it does now, I
>> think the correct fix would be to remove the dependency in OMAP2_DSS. I
>> don't think removing ARCH_MULTIPLATFORM support in omapdrm is the
>> correct solution.
> At least it says so in drivers/video/omap2/Kconfig, which contains
>
> if ARCH_OMAP2PLUS
> source drivers/video/omap2/dss/Kconfig
> endif
ahh, ok, I see.. the if ARCH_OMAP2PLUS bit looks like it came in
recently (770b6cb)
what about changing this to 'if ARCH_OMAP2PLUS || ARCH_MULTIPLATFORM'?
BR,
-R
> We can probably change this, but until we do, we should not select
> OMAP2_DSS from something that doesn't also depend on 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
>>
>> This was an unrelated build break which should be fixed in latest master
>> after 'staging: drm/omap: use omapdss low level API'
> Ok, it seems the message is stale then, I created the patch some time ago, but
> only today wrote rest of the explanation for the changeset text.
>
> With all the other patches from my series applied, allyesconfig still gives me
>
> drivers/video/omap2/dss/dss.c:572:20: error: 'CONFIG_OMAP2_DSS_MIN_FCK_PER_PCK' undeclared
>
> because that symbol is only defined when OMAP2_DSS is enabled rather than
> selected. Changing drivers/video/omap2/Kconfig to not depend on OMAP seems
> to work as well, but that seems a little intrusive for v3.8, because it would
> let a lot of people build that code that have no use for it.
>
> Arnd
^ permalink raw reply [flat|nested] 155+ messages in thread
* [PATCH 15/15] staging/omapdrm: don't build on multiplatform
@ 2013-01-21 18:39 ` Rob Clark
0 siblings, 0 replies; 155+ messages in thread
From: Rob Clark @ 2013-01-21 18:39 UTC (permalink / raw)
To: linux-arm-kernel
On 01/21/2013 11:41 AM, Arnd Bergmann wrote:
> On Monday 21 January 2013, Rob Clark wrote:
>> Are you sure OMAP2_DSS requires ARCH_OMAP2PLUS? I don't see this, and
>> it at least used to not depend on ARCH_OMAP2PLUS. If it does now, I
>> think the correct fix would be to remove the dependency in OMAP2_DSS. I
>> don't think removing ARCH_MULTIPLATFORM support in omapdrm is the
>> correct solution.
> At least it says so in drivers/video/omap2/Kconfig, which contains
>
> if ARCH_OMAP2PLUS
> source drivers/video/omap2/dss/Kconfig
> endif
ahh, ok, I see.. the if ARCH_OMAP2PLUS bit looks like it came in
recently (770b6cb)
what about changing this to 'if ARCH_OMAP2PLUS || ARCH_MULTIPLATFORM'?
BR,
-R
> We can probably change this, but until we do, we should not select
> OMAP2_DSS from something that doesn't also depend on 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
>>
>> This was an unrelated build break which should be fixed in latest master
>> after 'staging: drm/omap: use omapdss low level API'
> Ok, it seems the message is stale then, I created the patch some time ago, but
> only today wrote rest of the explanation for the changeset text.
>
> With all the other patches from my series applied, allyesconfig still gives me
>
> drivers/video/omap2/dss/dss.c:572:20: error: 'CONFIG_OMAP2_DSS_MIN_FCK_PER_PCK' undeclared
>
> because that symbol is only defined when OMAP2_DSS is enabled rather than
> selected. Changing drivers/video/omap2/Kconfig to not depend on OMAP seems
> to work as well, but that seems a little intrusive for v3.8, because it would
> let a lot of people build that code that have no use for it.
>
> Arnd
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [PATCH 15/15] staging/omapdrm: don't build on multiplatform
2013-01-21 18:39 ` Rob Clark
@ 2013-01-21 20:09 ` Arnd Bergmann
-1 siblings, 0 replies; 155+ messages in thread
From: Arnd Bergmann @ 2013-01-21 20:09 UTC (permalink / raw)
To: Rob Clark; +Cc: linux-arm-kernel, linux-kernel, arm, Greg Kroah-Hartman
On Monday 21 January 2013, Rob Clark wrote:
> ahh, ok, I see.. the if ARCH_OMAP2PLUS bit looks like it came in
> recently (770b6cb)
>
> what about changing this to 'if ARCH_OMAP2PLUS || ARCH_MULTIPLATFORM'?
Fine with me in general, but the patch I posted would be the more
conservative choice for v3.8.
Arnd
^ permalink raw reply [flat|nested] 155+ messages in thread
* [PATCH 15/15] staging/omapdrm: don't build on multiplatform
@ 2013-01-21 20:09 ` Arnd Bergmann
0 siblings, 0 replies; 155+ messages in thread
From: Arnd Bergmann @ 2013-01-21 20:09 UTC (permalink / raw)
To: linux-arm-kernel
On Monday 21 January 2013, Rob Clark wrote:
> ahh, ok, I see.. the if ARCH_OMAP2PLUS bit looks like it came in
> recently (770b6cb)
>
> what about changing this to 'if ARCH_OMAP2PLUS || ARCH_MULTIPLATFORM'?
Fine with me in general, but the patch I posted would be the more
conservative choice for v3.8.
Arnd
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [PATCH 15/15] staging/omapdrm: don't build on multiplatform
2013-01-21 18:39 ` Rob Clark
@ 2013-01-22 16:53 ` Greg Kroah-Hartman
-1 siblings, 0 replies; 155+ messages in thread
From: Greg Kroah-Hartman @ 2013-01-22 16:53 UTC (permalink / raw)
To: Rob Clark; +Cc: Arnd Bergmann, linux-arm-kernel, linux-kernel, arm
On Mon, Jan 21, 2013 at 12:39:31PM -0600, Rob Clark wrote:
> On 01/21/2013 11:41 AM, Arnd Bergmann wrote:
> >On Monday 21 January 2013, Rob Clark wrote:
> >>Are you sure OMAP2_DSS requires ARCH_OMAP2PLUS? I don't see this, and
> >>it at least used to not depend on ARCH_OMAP2PLUS. If it does now, I
> >>think the correct fix would be to remove the dependency in OMAP2_DSS. I
> >>don't think removing ARCH_MULTIPLATFORM support in omapdrm is the
> >>correct solution.
> >At least it says so in drivers/video/omap2/Kconfig, which contains
> >
> >if ARCH_OMAP2PLUS
> >source drivers/video/omap2/dss/Kconfig
> >endif
>
> ahh, ok, I see.. the if ARCH_OMAP2PLUS bit looks like it came in
> recently (770b6cb)
>
> what about changing this to 'if ARCH_OMAP2PLUS || ARCH_MULTIPLATFORM'?
That's what Arnd's patch did.
totally confused,
greg k-h
^ permalink raw reply [flat|nested] 155+ messages in thread
* [PATCH 15/15] staging/omapdrm: don't build on multiplatform
@ 2013-01-22 16:53 ` Greg Kroah-Hartman
0 siblings, 0 replies; 155+ messages in thread
From: Greg Kroah-Hartman @ 2013-01-22 16:53 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, Jan 21, 2013 at 12:39:31PM -0600, Rob Clark wrote:
> On 01/21/2013 11:41 AM, Arnd Bergmann wrote:
> >On Monday 21 January 2013, Rob Clark wrote:
> >>Are you sure OMAP2_DSS requires ARCH_OMAP2PLUS? I don't see this, and
> >>it at least used to not depend on ARCH_OMAP2PLUS. If it does now, I
> >>think the correct fix would be to remove the dependency in OMAP2_DSS. I
> >>don't think removing ARCH_MULTIPLATFORM support in omapdrm is the
> >>correct solution.
> >At least it says so in drivers/video/omap2/Kconfig, which contains
> >
> >if ARCH_OMAP2PLUS
> >source drivers/video/omap2/dss/Kconfig
> >endif
>
> ahh, ok, I see.. the if ARCH_OMAP2PLUS bit looks like it came in
> recently (770b6cb)
>
> what about changing this to 'if ARCH_OMAP2PLUS || ARCH_MULTIPLATFORM'?
That's what Arnd's patch did.
totally confused,
greg k-h
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [PATCH 15/15] staging/omapdrm: don't build on multiplatform
2013-01-22 16:53 ` Greg Kroah-Hartman
@ 2013-01-22 16:57 ` Rob Clark
-1 siblings, 0 replies; 155+ messages in thread
From: Rob Clark @ 2013-01-22 16:57 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Arnd Bergmann, linux-arm-kernel, linux-kernel, arm, Tomi Valkeinen
On 01/22/2013 10:53 AM, Greg Kroah-Hartman wrote:
> On Mon, Jan 21, 2013 at 12:39:31PM -0600, Rob Clark wrote:
>> On 01/21/2013 11:41 AM, Arnd Bergmann wrote:
>>> On Monday 21 January 2013, Rob Clark wrote:
>>>> Are you sure OMAP2_DSS requires ARCH_OMAP2PLUS? I don't see this, and
>>>> it at least used to not depend on ARCH_OMAP2PLUS. If it does now, I
>>>> think the correct fix would be to remove the dependency in OMAP2_DSS. I
>>>> don't think removing ARCH_MULTIPLATFORM support in omapdrm is the
>>>> correct solution.
>>> At least it says so in drivers/video/omap2/Kconfig, which contains
>>>
>>> if ARCH_OMAP2PLUS
>>> source drivers/video/omap2/dss/Kconfig
>>> endif
>> ahh, ok, I see.. the if ARCH_OMAP2PLUS bit looks like it came in
>> recently (770b6cb)
>>
>> what about changing this to 'if ARCH_OMAP2PLUS || ARCH_MULTIPLATFORM'?
> That's what Arnd's patch did.
sorry, I was talking about in drivers/video/omap2/Kconfig
Ie. I'd prefer to re-enable omapdss on multi-plat rather than disabling
omapdrm. With changes in drm core, it is a bit of a pain to compile
test all the arm drivers by doing N different builds, so we've been
trying to get to the point of all arm drm drivers supporting multi-plat
BR,
-R
> totally confused,
>
> greg k-h
^ permalink raw reply [flat|nested] 155+ messages in thread
* [PATCH 15/15] staging/omapdrm: don't build on multiplatform
@ 2013-01-22 16:57 ` Rob Clark
0 siblings, 0 replies; 155+ messages in thread
From: Rob Clark @ 2013-01-22 16:57 UTC (permalink / raw)
To: linux-arm-kernel
On 01/22/2013 10:53 AM, Greg Kroah-Hartman wrote:
> On Mon, Jan 21, 2013 at 12:39:31PM -0600, Rob Clark wrote:
>> On 01/21/2013 11:41 AM, Arnd Bergmann wrote:
>>> On Monday 21 January 2013, Rob Clark wrote:
>>>> Are you sure OMAP2_DSS requires ARCH_OMAP2PLUS? I don't see this, and
>>>> it at least used to not depend on ARCH_OMAP2PLUS. If it does now, I
>>>> think the correct fix would be to remove the dependency in OMAP2_DSS. I
>>>> don't think removing ARCH_MULTIPLATFORM support in omapdrm is the
>>>> correct solution.
>>> At least it says so in drivers/video/omap2/Kconfig, which contains
>>>
>>> if ARCH_OMAP2PLUS
>>> source drivers/video/omap2/dss/Kconfig
>>> endif
>> ahh, ok, I see.. the if ARCH_OMAP2PLUS bit looks like it came in
>> recently (770b6cb)
>>
>> what about changing this to 'if ARCH_OMAP2PLUS || ARCH_MULTIPLATFORM'?
> That's what Arnd's patch did.
sorry, I was talking about in drivers/video/omap2/Kconfig
Ie. I'd prefer to re-enable omapdss on multi-plat rather than disabling
omapdrm. With changes in drm core, it is a bit of a pain to compile
test all the arm drivers by doing N different builds, so we've been
trying to get to the point of all arm drm drivers supporting multi-plat
BR,
-R
> totally confused,
>
> greg k-h
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [PATCH 15/15] staging/omapdrm: don't build on multiplatform
2013-01-22 16:57 ` Rob Clark
@ 2013-01-22 17:30 ` Greg Kroah-Hartman
-1 siblings, 0 replies; 155+ messages in thread
From: Greg Kroah-Hartman @ 2013-01-22 17:30 UTC (permalink / raw)
To: Rob Clark
Cc: Arnd Bergmann, linux-arm-kernel, linux-kernel, arm, Tomi Valkeinen
On Tue, Jan 22, 2013 at 10:57:44AM -0600, Rob Clark wrote:
> On 01/22/2013 10:53 AM, Greg Kroah-Hartman wrote:
> >On Mon, Jan 21, 2013 at 12:39:31PM -0600, Rob Clark wrote:
> >>On 01/21/2013 11:41 AM, Arnd Bergmann wrote:
> >>>On Monday 21 January 2013, Rob Clark wrote:
> >>>>Are you sure OMAP2_DSS requires ARCH_OMAP2PLUS? I don't see this, and
> >>>>it at least used to not depend on ARCH_OMAP2PLUS. If it does now, I
> >>>>think the correct fix would be to remove the dependency in OMAP2_DSS. I
> >>>>don't think removing ARCH_MULTIPLATFORM support in omapdrm is the
> >>>>correct solution.
> >>>At least it says so in drivers/video/omap2/Kconfig, which contains
> >>>
> >>>if ARCH_OMAP2PLUS
> >>>source drivers/video/omap2/dss/Kconfig
> >>>endif
> >>ahh, ok, I see.. the if ARCH_OMAP2PLUS bit looks like it came in
> >>recently (770b6cb)
> >>
> >>what about changing this to 'if ARCH_OMAP2PLUS || ARCH_MULTIPLATFORM'?
> >That's what Arnd's patch did.
>
> sorry, I was talking about in drivers/video/omap2/Kconfig
Ah, ok.
> Ie. I'd prefer to re-enable omapdss on multi-plat rather than
> disabling omapdrm. With changes in drm core, it is a bit of a pain
> to compile test all the arm drivers by doing N different builds, so
> we've been trying to get to the point of all arm drm drivers
> supporting multi-plat
Ok, I'll let you and Arnd fight it out and drop this patch from my
to-apply queue for now...
greg k-h
^ permalink raw reply [flat|nested] 155+ messages in thread
* [PATCH 15/15] staging/omapdrm: don't build on multiplatform
@ 2013-01-22 17:30 ` Greg Kroah-Hartman
0 siblings, 0 replies; 155+ messages in thread
From: Greg Kroah-Hartman @ 2013-01-22 17:30 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Jan 22, 2013 at 10:57:44AM -0600, Rob Clark wrote:
> On 01/22/2013 10:53 AM, Greg Kroah-Hartman wrote:
> >On Mon, Jan 21, 2013 at 12:39:31PM -0600, Rob Clark wrote:
> >>On 01/21/2013 11:41 AM, Arnd Bergmann wrote:
> >>>On Monday 21 January 2013, Rob Clark wrote:
> >>>>Are you sure OMAP2_DSS requires ARCH_OMAP2PLUS? I don't see this, and
> >>>>it at least used to not depend on ARCH_OMAP2PLUS. If it does now, I
> >>>>think the correct fix would be to remove the dependency in OMAP2_DSS. I
> >>>>don't think removing ARCH_MULTIPLATFORM support in omapdrm is the
> >>>>correct solution.
> >>>At least it says so in drivers/video/omap2/Kconfig, which contains
> >>>
> >>>if ARCH_OMAP2PLUS
> >>>source drivers/video/omap2/dss/Kconfig
> >>>endif
> >>ahh, ok, I see.. the if ARCH_OMAP2PLUS bit looks like it came in
> >>recently (770b6cb)
> >>
> >>what about changing this to 'if ARCH_OMAP2PLUS || ARCH_MULTIPLATFORM'?
> >That's what Arnd's patch did.
>
> sorry, I was talking about in drivers/video/omap2/Kconfig
Ah, ok.
> Ie. I'd prefer to re-enable omapdss on multi-plat rather than
> disabling omapdrm. With changes in drm core, it is a bit of a pain
> to compile test all the arm drivers by doing N different builds, so
> we've been trying to get to the point of all arm drm drivers
> supporting multi-plat
Ok, I'll let you and Arnd fight it out and drop this patch from my
to-apply queue for now...
greg k-h
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [PATCH 15/15] staging/omapdrm: don't build on multiplatform
2013-01-22 17:30 ` Greg Kroah-Hartman
@ 2013-01-22 17:47 ` Arnd Bergmann
-1 siblings, 0 replies; 155+ messages in thread
From: Arnd Bergmann @ 2013-01-22 17:47 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Rob Clark, linux-arm-kernel, linux-kernel, arm, Tomi Valkeinen
On Tuesday 22 January 2013, Greg Kroah-Hartman wrote:
> > Ie. I'd prefer to re-enable omapdss on multi-plat rather than
> > disabling omapdrm. With changes in drm core, it is a bit of a pain
> > to compile test all the arm drivers by doing N different builds, so
> > we've been trying to get to the point of all arm drm drivers
> > supporting multi-plat
>
> Ok, I'll let you and Arnd fight it out and drop this patch from my
> to-apply queue for now...
If Rob thinks there is no danger in allowing omap2_dss to be built
on all platforms, and Tomi has no objections, I'm fine with that, too.
In general, that is the right solution, I was just trying to be
conservative for the 3.8 cycle.
Arnd
^ permalink raw reply [flat|nested] 155+ messages in thread
* [PATCH 15/15] staging/omapdrm: don't build on multiplatform
@ 2013-01-22 17:47 ` Arnd Bergmann
0 siblings, 0 replies; 155+ messages in thread
From: Arnd Bergmann @ 2013-01-22 17:47 UTC (permalink / raw)
To: linux-arm-kernel
On Tuesday 22 January 2013, Greg Kroah-Hartman wrote:
> > Ie. I'd prefer to re-enable omapdss on multi-plat rather than
> > disabling omapdrm. With changes in drm core, it is a bit of a pain
> > to compile test all the arm drivers by doing N different builds, so
> > we've been trying to get to the point of all arm drm drivers
> > supporting multi-plat
>
> Ok, I'll let you and Arnd fight it out and drop this patch from my
> to-apply queue for now...
If Rob thinks there is no danger in allowing omap2_dss to be built
on all platforms, and Tomi has no objections, I'm fine with that, too.
In general, that is the right solution, I was just trying to be
conservative for the 3.8 cycle.
Arnd
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [PATCH 15/15] staging/omapdrm: don't build on multiplatform
2013-01-22 17:47 ` Arnd Bergmann
@ 2013-01-22 18:16 ` Rob Clark
-1 siblings, 0 replies; 155+ messages in thread
From: Rob Clark @ 2013-01-22 18:16 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Greg Kroah-Hartman, linux-arm-kernel, linux-kernel, arm, Tomi Valkeinen
On 01/22/2013 11:47 AM, Arnd Bergmann wrote:
> On Tuesday 22 January 2013, Greg Kroah-Hartman wrote:
>>> Ie. I'd prefer to re-enable omapdss on multi-plat rather than
>>> disabling omapdrm. With changes in drm core, it is a bit of a pain
>>> to compile test all the arm drivers by doing N different builds, so
>>> we've been trying to get to the point of all arm drm drivers
>>> supporting multi-plat
>> Ok, I'll let you and Arnd fight it out and drop this patch from my
>> to-apply queue for now...
> If Rob thinks there is no danger in allowing omap2_dss to be built
> on all platforms, and Tomi has no objections, I'm fine with that, too.
> In general, that is the right solution, I was just trying to be
> conservative for the 3.8 cycle.
I think it should be safe.. or at least it built fine for multi-plat in
the recent past and shouldn't really do anything if there is no omapdss
platform device.
Do you want me to make a patch or are you already doing this?
BR,
-R
> Arnd
^ permalink raw reply [flat|nested] 155+ messages in thread
* [PATCH 15/15] staging/omapdrm: don't build on multiplatform
@ 2013-01-22 18:16 ` Rob Clark
0 siblings, 0 replies; 155+ messages in thread
From: Rob Clark @ 2013-01-22 18:16 UTC (permalink / raw)
To: linux-arm-kernel
On 01/22/2013 11:47 AM, Arnd Bergmann wrote:
> On Tuesday 22 January 2013, Greg Kroah-Hartman wrote:
>>> Ie. I'd prefer to re-enable omapdss on multi-plat rather than
>>> disabling omapdrm. With changes in drm core, it is a bit of a pain
>>> to compile test all the arm drivers by doing N different builds, so
>>> we've been trying to get to the point of all arm drm drivers
>>> supporting multi-plat
>> Ok, I'll let you and Arnd fight it out and drop this patch from my
>> to-apply queue for now...
> If Rob thinks there is no danger in allowing omap2_dss to be built
> on all platforms, and Tomi has no objections, I'm fine with that, too.
> In general, that is the right solution, I was just trying to be
> conservative for the 3.8 cycle.
I think it should be safe.. or at least it built fine for multi-plat in
the recent past and shouldn't really do anything if there is no omapdss
platform device.
Do you want me to make a patch or are you already doing this?
BR,
-R
> Arnd
^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [PATCH 15/15] staging/omapdrm: don't build on multiplatform
2013-01-22 18:16 ` Rob Clark
@ 2013-01-22 21:07 ` Arnd Bergmann
-1 siblings, 0 replies; 155+ messages in thread
From: Arnd Bergmann @ 2013-01-22 21:07 UTC (permalink / raw)
To: Rob Clark
Cc: Greg Kroah-Hartman, linux-arm-kernel, linux-kernel, arm, Tomi Valkeinen
On Tuesday 22 January 2013, Rob Clark wrote:
> I think it should be safe.. or at least it built fine for multi-plat in
> the recent past and shouldn't really do anything if there is no omapdss
> platform device.
>
> Do you want me to make a patch or are you already doing this?
Please make one. Feel free to reuse my changeset description if needed.
Arnd
^ permalink raw reply [flat|nested] 155+ messages in thread
* [PATCH 15/15] staging/omapdrm: don't build on multiplatform
@ 2013-01-22 21:07 ` Arnd Bergmann
0 siblings, 0 replies; 155+ messages in thread
From: Arnd Bergmann @ 2013-01-22 21:07 UTC (permalink / raw)
To: linux-arm-kernel
On Tuesday 22 January 2013, Rob Clark wrote:
> I think it should be safe.. or at least it built fine for multi-plat in
> the recent past and shouldn't really do anything if there is no omapdss
> platform device.
>
> Do you want me to make a patch or are you already doing this?
Please make one. Feel free to reuse my changeset description if needed.
Arnd
^ permalink raw reply [flat|nested] 155+ messages in thread