* [PATCH 0/9] arm-soc/for-next allyesconfig build regressions
@ 2013-02-14 22:47 ` Arnd Bergmann
0 siblings, 0 replies; 70+ messages in thread
From: Arnd Bergmann @ 2013-02-14 22:47 UTC (permalink / raw)
To: linux-arm-kernel
These are the patches I still need to cleanly build allyesconfig
and allmodconfig on arm-soc/for-next. Please review and provide
Acks where appropriate so we can add the fixes directly to the
branches that introduce the problems, or apply them directly
to a maintainer tree where appropriate.
The bulk of these patches happen to be omap specific, which
does not mean that we had a lot of regressions in omap, but
that we just started including omap in the multiplatform
builds, which has uncovered a number of older problems that
we did not see before.
Arnd
Arnd Bergmann (9):
ARM: arch_timer: include linux/errno.h
ARM: imx: MACH_MX31ADS_WM1133_EV1 needs REGULATOR_WM8350
ARM: omap2: include linux/errno.h in hwmod_reset
ARM: omap: add include guard for soc.h
drm: export drm_vm_open_locked
net: cwdavinci_cpdma: export symbols for cpsw
remoteproc: omap: depend on OMAP_MBOX_FWK
[HACK] ARM: imx: work around v7_cpu_resume link error
[media] davinci: do not include mach/hardware.h
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Marc Zyngier <marc.zyngier@arm.com>
Cc: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: Mauro Carvalho Chehab <mchehab@redhat.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Rob Clark <rob@ti.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Sascha Hauer <s.hauer@pengutronix.de>
Cc: Shawn Guo <shawn.guo@linaro.org>
Cc: Tony Lindgren <tony@atomide.com>
Cc: netdev at vger.kernel.org
arch/arm/kernel/arch_timer.c | 1 +
arch/arm/mach-imx/Kconfig | 2 +-
arch/arm/mach-imx/headsmp.S | 4 +++-
arch/arm/mach-omap2/omap_hwmod_reset.c | 1 +
arch/arm/mach-omap2/soc.h | 3 +++
drivers/gpu/drm/drm_vm.c | 1 +
drivers/media/platform/davinci/vpss.c | 1 -
drivers/net/ethernet/ti/davinci_cpdma.c | 3 +++
drivers/remoteproc/Kconfig | 2 +-
9 files changed, 14 insertions(+), 4 deletions(-)
--
1.8.1.2
^ permalink raw reply [flat|nested] 70+ messages in thread
* [PATCH 1/9] ARM: arch_timer: include linux/errno.h
2013-02-14 22:47 ` Arnd Bergmann
@ 2013-02-14 22:47 ` Arnd Bergmann
-1 siblings, 0 replies; 70+ messages in thread
From: Arnd Bergmann @ 2013-02-14 22:47 UTC (permalink / raw)
To: linux-arm-kernel
Cc: linux-kernel, arm, Arnd Bergmann, Mark Rutland, Catalin Marinas,
Marc Zyngier
Patch 8a4da6e "arm: arch_timer: move core to drivers/clocksource"
moved a lot of code out of arch_timer.c, but ended up deleting
too much, which broke some configurations.
Obviously, include linux/errno.h is required to return error
values.
Without this patch, building allmodconfig results in:
arch/arm/kernel/arch_timer.c: In function 'arch_timer_sched_clock_init':
arch/arm/kernel/arch_timer.c:55:11: error: 'ENXIO' undeclared (first use in this function)
arch/arm/kernel/arch_timer.c:55:11: note: each undeclared identifier is reported only once for each function it appears in
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Marc Zyngier <marc.zyngier@arm.com>
---
arch/arm/kernel/arch_timer.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/kernel/arch_timer.c b/arch/arm/kernel/arch_timer.c
index 36ebcf4..d957a51 100644
--- a/arch/arm/kernel/arch_timer.c
+++ b/arch/arm/kernel/arch_timer.c
@@ -10,6 +10,7 @@
*/
#include <linux/init.h>
#include <linux/types.h>
+#include <linux/errno.h>
#include <asm/delay.h>
#include <asm/sched_clock.h>
--
1.8.1.2
^ permalink raw reply related [flat|nested] 70+ messages in thread
* [PATCH 1/9] ARM: arch_timer: include linux/errno.h
@ 2013-02-14 22:47 ` Arnd Bergmann
0 siblings, 0 replies; 70+ messages in thread
From: Arnd Bergmann @ 2013-02-14 22:47 UTC (permalink / raw)
To: linux-arm-kernel
Patch 8a4da6e "arm: arch_timer: move core to drivers/clocksource"
moved a lot of code out of arch_timer.c, but ended up deleting
too much, which broke some configurations.
Obviously, include linux/errno.h is required to return error
values.
Without this patch, building allmodconfig results in:
arch/arm/kernel/arch_timer.c: In function 'arch_timer_sched_clock_init':
arch/arm/kernel/arch_timer.c:55:11: error: 'ENXIO' undeclared (first use in this function)
arch/arm/kernel/arch_timer.c:55:11: note: each undeclared identifier is reported only once for each function it appears in
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Marc Zyngier <marc.zyngier@arm.com>
---
arch/arm/kernel/arch_timer.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/kernel/arch_timer.c b/arch/arm/kernel/arch_timer.c
index 36ebcf4..d957a51 100644
--- a/arch/arm/kernel/arch_timer.c
+++ b/arch/arm/kernel/arch_timer.c
@@ -10,6 +10,7 @@
*/
#include <linux/init.h>
#include <linux/types.h>
+#include <linux/errno.h>
#include <asm/delay.h>
#include <asm/sched_clock.h>
--
1.8.1.2
^ permalink raw reply related [flat|nested] 70+ messages in thread
* Re: [PATCH 1/9] ARM: arch_timer: include linux/errno.h
2013-02-14 22:47 ` Arnd Bergmann
@ 2013-02-15 10:26 ` Mark Rutland
-1 siblings, 0 replies; 70+ messages in thread
From: Mark Rutland @ 2013-02-15 10:26 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-arm-kernel, linux-kernel, arm, Catalin Marinas,
Marc Zyngier, Stephen Warren
Hi,
As with Stephen Warren's fix [1], this looks right to me. Stephen's has the
added benefit of keeping the includes ordered.
For either version:
Acked-By: Mark Rutland <mark.rutland@arm.com>
Thanks,
Mark.
[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2013-February/149579.html
On Thu, Feb 14, 2013 at 10:47:43PM +0000, Arnd Bergmann wrote:
> Patch 8a4da6e "arm: arch_timer: move core to drivers/clocksource"
> moved a lot of code out of arch_timer.c, but ended up deleting
> too much, which broke some configurations.
>
> Obviously, include linux/errno.h is required to return error
> values.
>
> Without this patch, building allmodconfig results in:
>
> arch/arm/kernel/arch_timer.c: In function 'arch_timer_sched_clock_init':
> arch/arm/kernel/arch_timer.c:55:11: error: 'ENXIO' undeclared (first use in this function)
> arch/arm/kernel/arch_timer.c:55:11: note: each undeclared identifier is reported only once for each function it appears in
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Marc Zyngier <marc.zyngier@arm.com>
> ---
> arch/arm/kernel/arch_timer.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/kernel/arch_timer.c b/arch/arm/kernel/arch_timer.c
> index 36ebcf4..d957a51 100644
> --- a/arch/arm/kernel/arch_timer.c
> +++ b/arch/arm/kernel/arch_timer.c
> @@ -10,6 +10,7 @@
> */
> #include <linux/init.h>
> #include <linux/types.h>
> +#include <linux/errno.h>
>
> #include <asm/delay.h>
> #include <asm/sched_clock.h>
> --
> 1.8.1.2
>
>
^ permalink raw reply [flat|nested] 70+ messages in thread
* [PATCH 1/9] ARM: arch_timer: include linux/errno.h
@ 2013-02-15 10:26 ` Mark Rutland
0 siblings, 0 replies; 70+ messages in thread
From: Mark Rutland @ 2013-02-15 10:26 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
As with Stephen Warren's fix [1], this looks right to me. Stephen's has the
added benefit of keeping the includes ordered.
For either version:
Acked-By: Mark Rutland <mark.rutland@arm.com>
Thanks,
Mark.
[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2013-February/149579.html
On Thu, Feb 14, 2013 at 10:47:43PM +0000, Arnd Bergmann wrote:
> Patch 8a4da6e "arm: arch_timer: move core to drivers/clocksource"
> moved a lot of code out of arch_timer.c, but ended up deleting
> too much, which broke some configurations.
>
> Obviously, include linux/errno.h is required to return error
> values.
>
> Without this patch, building allmodconfig results in:
>
> arch/arm/kernel/arch_timer.c: In function 'arch_timer_sched_clock_init':
> arch/arm/kernel/arch_timer.c:55:11: error: 'ENXIO' undeclared (first use in this function)
> arch/arm/kernel/arch_timer.c:55:11: note: each undeclared identifier is reported only once for each function it appears in
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Marc Zyngier <marc.zyngier@arm.com>
> ---
> arch/arm/kernel/arch_timer.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/kernel/arch_timer.c b/arch/arm/kernel/arch_timer.c
> index 36ebcf4..d957a51 100644
> --- a/arch/arm/kernel/arch_timer.c
> +++ b/arch/arm/kernel/arch_timer.c
> @@ -10,6 +10,7 @@
> */
> #include <linux/init.h>
> #include <linux/types.h>
> +#include <linux/errno.h>
>
> #include <asm/delay.h>
> #include <asm/sched_clock.h>
> --
> 1.8.1.2
>
>
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH 1/9] ARM: arch_timer: include linux/errno.h
2013-02-15 10:26 ` Mark Rutland
@ 2013-02-15 18:33 ` Arnd Bergmann
-1 siblings, 0 replies; 70+ messages in thread
From: Arnd Bergmann @ 2013-02-15 18:33 UTC (permalink / raw)
To: Mark Rutland
Cc: linux-arm-kernel, linux-kernel, arm, Catalin Marinas,
Marc Zyngier, Stephen Warren
On Friday 15 February 2013, Mark Rutland wrote:
> As with Stephen Warren's fix [1], this looks right to me. Stephen's has the
> added benefit of keeping the includes ordered.
>
> For either version:
>
> Acked-By: Mark Rutland <mark.rutland@arm.com>
Applied to the next/virt branch now.
Arnd
^ permalink raw reply [flat|nested] 70+ messages in thread
* [PATCH 1/9] ARM: arch_timer: include linux/errno.h
@ 2013-02-15 18:33 ` Arnd Bergmann
0 siblings, 0 replies; 70+ messages in thread
From: Arnd Bergmann @ 2013-02-15 18:33 UTC (permalink / raw)
To: linux-arm-kernel
On Friday 15 February 2013, Mark Rutland wrote:
> As with Stephen Warren's fix [1], this looks right to me. Stephen's has the
> added benefit of keeping the includes ordered.
>
> For either version:
>
> Acked-By: Mark Rutland <mark.rutland@arm.com>
Applied to the next/virt branch now.
Arnd
^ permalink raw reply [flat|nested] 70+ messages in thread
* [PATCH 2/9] ARM: imx: MACH_MX31ADS_WM1133_EV1 needs REGULATOR_WM8350
2013-02-14 22:47 ` Arnd Bergmann
@ 2013-02-14 22:47 ` Arnd Bergmann
-1 siblings, 0 replies; 70+ messages in thread
From: Arnd Bergmann @ 2013-02-14 22:47 UTC (permalink / raw)
To: linux-arm-kernel
Cc: linux-kernel, arm, Arnd Bergmann, Shawn Guo, Sascha Hauer,
Axel Lin, Mark Brown
MACH_MX31ADS_WM1133_EV1 already depends on REGULATOR_WM8350,
but that still allows REGULATOR_WM8350 to be a loadable
module. Depending on REGULATOR_WM8350 to be built-in
ensures we cannot create a broken configuration.
Without this patch, building allmodconfig results in:
arch/arm/mach-imx/built-in.o: In function `mx31_wm8350_init':
arch/arm/mach-imx/mach-mx31ads.c:461: undefined reference to `wm8350_register_regulator'
arch/arm/mach-imx/mach-mx31ads.c:471: undefined reference to `wm8350_dcdc_set_slot'
arch/arm/mach-imx/mach-mx31ads.c:473: undefined reference to `wm8350_isink_set_flash'
arch/arm/mach-imx/mach-mx31ads.c:480: undefined reference to `wm8350_dcdc25_set_mode'
arch/arm/mach-imx/mach-mx31ads.c:485: undefined reference to `wm8350_register_led'
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Shawn Guo <shawn.guo@linaro.org>
Cc: Sascha Hauer <s.hauer@pengutronix.de>
Cc: Axel Lin <axel.lin@gmail.com>
Cc: Mark Brown <broonie@opensource.wolfsonmicro.com>
---
arch/arm/mach-imx/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
index 7b11d33..4c9c6f9 100644
--- a/arch/arm/mach-imx/Kconfig
+++ b/arch/arm/mach-imx/Kconfig
@@ -480,7 +480,7 @@ config MACH_MX31ADS_WM1133_EV1
bool "Support Wolfson Microelectronics 1133-EV1 module"
depends on MACH_MX31ADS
depends on MFD_WM8350_I2C
- depends on REGULATOR_WM8350
+ depends on REGULATOR_WM8350 = y
select MFD_WM8350_CONFIG_MODE_0
select MFD_WM8352_CONFIG_MODE_0
help
--
1.8.1.2
^ permalink raw reply related [flat|nested] 70+ messages in thread
* [PATCH 2/9] ARM: imx: MACH_MX31ADS_WM1133_EV1 needs REGULATOR_WM8350
@ 2013-02-14 22:47 ` Arnd Bergmann
0 siblings, 0 replies; 70+ messages in thread
From: Arnd Bergmann @ 2013-02-14 22:47 UTC (permalink / raw)
To: linux-arm-kernel
MACH_MX31ADS_WM1133_EV1 already depends on REGULATOR_WM8350,
but that still allows REGULATOR_WM8350 to be a loadable
module. Depending on REGULATOR_WM8350 to be built-in
ensures we cannot create a broken configuration.
Without this patch, building allmodconfig results in:
arch/arm/mach-imx/built-in.o: In function `mx31_wm8350_init':
arch/arm/mach-imx/mach-mx31ads.c:461: undefined reference to `wm8350_register_regulator'
arch/arm/mach-imx/mach-mx31ads.c:471: undefined reference to `wm8350_dcdc_set_slot'
arch/arm/mach-imx/mach-mx31ads.c:473: undefined reference to `wm8350_isink_set_flash'
arch/arm/mach-imx/mach-mx31ads.c:480: undefined reference to `wm8350_dcdc25_set_mode'
arch/arm/mach-imx/mach-mx31ads.c:485: undefined reference to `wm8350_register_led'
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Shawn Guo <shawn.guo@linaro.org>
Cc: Sascha Hauer <s.hauer@pengutronix.de>
Cc: Axel Lin <axel.lin@gmail.com>
Cc: Mark Brown <broonie@opensource.wolfsonmicro.com>
---
arch/arm/mach-imx/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
index 7b11d33..4c9c6f9 100644
--- a/arch/arm/mach-imx/Kconfig
+++ b/arch/arm/mach-imx/Kconfig
@@ -480,7 +480,7 @@ config MACH_MX31ADS_WM1133_EV1
bool "Support Wolfson Microelectronics 1133-EV1 module"
depends on MACH_MX31ADS
depends on MFD_WM8350_I2C
- depends on REGULATOR_WM8350
+ depends on REGULATOR_WM8350 = y
select MFD_WM8350_CONFIG_MODE_0
select MFD_WM8352_CONFIG_MODE_0
help
--
1.8.1.2
^ permalink raw reply related [flat|nested] 70+ messages in thread
* Re: [PATCH 2/9] ARM: imx: MACH_MX31ADS_WM1133_EV1 needs REGULATOR_WM8350
2013-02-14 22:47 ` Arnd Bergmann
@ 2013-02-15 17:21 ` Sascha Hauer
-1 siblings, 0 replies; 70+ messages in thread
From: Sascha Hauer @ 2013-02-15 17:21 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-arm-kernel, linux-kernel, arm, Shawn Guo, Axel Lin, Mark Brown
On Thu, Feb 14, 2013 at 11:47:44PM +0100, Arnd Bergmann wrote:
> MACH_MX31ADS_WM1133_EV1 already depends on REGULATOR_WM8350,
> but that still allows REGULATOR_WM8350 to be a loadable
> module. Depending on REGULATOR_WM8350 to be built-in
> ensures we cannot create a broken configuration.
>
> Without this patch, building allmodconfig results in:
>
> arch/arm/mach-imx/built-in.o: In function `mx31_wm8350_init':
> arch/arm/mach-imx/mach-mx31ads.c:461: undefined reference to `wm8350_register_regulator'
> arch/arm/mach-imx/mach-mx31ads.c:471: undefined reference to `wm8350_dcdc_set_slot'
> arch/arm/mach-imx/mach-mx31ads.c:473: undefined reference to `wm8350_isink_set_flash'
> arch/arm/mach-imx/mach-mx31ads.c:480: undefined reference to `wm8350_dcdc25_set_mode'
> arch/arm/mach-imx/mach-mx31ads.c:485: undefined reference to `wm8350_register_led'
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Shawn Guo <shawn.guo@linaro.org>
> Cc: Sascha Hauer <s.hauer@pengutronix.de>
> Cc: Axel Lin <axel.lin@gmail.com>
> Cc: Mark Brown <broonie@opensource.wolfsonmicro.com>
Hail to devicetree probing where such things don't happen.
Acked-by: Sascha Hauer <s.hauer@pengutronix.de>
> ---
> arch/arm/mach-imx/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
> index 7b11d33..4c9c6f9 100644
> --- a/arch/arm/mach-imx/Kconfig
> +++ b/arch/arm/mach-imx/Kconfig
> @@ -480,7 +480,7 @@ config MACH_MX31ADS_WM1133_EV1
> bool "Support Wolfson Microelectronics 1133-EV1 module"
> depends on MACH_MX31ADS
> depends on MFD_WM8350_I2C
> - depends on REGULATOR_WM8350
> + depends on REGULATOR_WM8350 = y
> select MFD_WM8350_CONFIG_MODE_0
> select MFD_WM8352_CONFIG_MODE_0
> help
> --
> 1.8.1.2
>
>
--
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] 70+ messages in thread
* [PATCH 2/9] ARM: imx: MACH_MX31ADS_WM1133_EV1 needs REGULATOR_WM8350
@ 2013-02-15 17:21 ` Sascha Hauer
0 siblings, 0 replies; 70+ messages in thread
From: Sascha Hauer @ 2013-02-15 17:21 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Feb 14, 2013 at 11:47:44PM +0100, Arnd Bergmann wrote:
> MACH_MX31ADS_WM1133_EV1 already depends on REGULATOR_WM8350,
> but that still allows REGULATOR_WM8350 to be a loadable
> module. Depending on REGULATOR_WM8350 to be built-in
> ensures we cannot create a broken configuration.
>
> Without this patch, building allmodconfig results in:
>
> arch/arm/mach-imx/built-in.o: In function `mx31_wm8350_init':
> arch/arm/mach-imx/mach-mx31ads.c:461: undefined reference to `wm8350_register_regulator'
> arch/arm/mach-imx/mach-mx31ads.c:471: undefined reference to `wm8350_dcdc_set_slot'
> arch/arm/mach-imx/mach-mx31ads.c:473: undefined reference to `wm8350_isink_set_flash'
> arch/arm/mach-imx/mach-mx31ads.c:480: undefined reference to `wm8350_dcdc25_set_mode'
> arch/arm/mach-imx/mach-mx31ads.c:485: undefined reference to `wm8350_register_led'
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Shawn Guo <shawn.guo@linaro.org>
> Cc: Sascha Hauer <s.hauer@pengutronix.de>
> Cc: Axel Lin <axel.lin@gmail.com>
> Cc: Mark Brown <broonie@opensource.wolfsonmicro.com>
Hail to devicetree probing where such things don't happen.
Acked-by: Sascha Hauer <s.hauer@pengutronix.de>
> ---
> arch/arm/mach-imx/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
> index 7b11d33..4c9c6f9 100644
> --- a/arch/arm/mach-imx/Kconfig
> +++ b/arch/arm/mach-imx/Kconfig
> @@ -480,7 +480,7 @@ config MACH_MX31ADS_WM1133_EV1
> bool "Support Wolfson Microelectronics 1133-EV1 module"
> depends on MACH_MX31ADS
> depends on MFD_WM8350_I2C
> - depends on REGULATOR_WM8350
> + depends on REGULATOR_WM8350 = y
> select MFD_WM8350_CONFIG_MODE_0
> select MFD_WM8352_CONFIG_MODE_0
> help
> --
> 1.8.1.2
>
>
--
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] 70+ messages in thread
* [PATCH 3/9] ARM: omap2: include linux/errno.h in hwmod_reset
2013-02-14 22:47 ` Arnd Bergmann
@ 2013-02-14 22:47 ` Arnd Bergmann
-1 siblings, 0 replies; 70+ messages in thread
From: Arnd Bergmann @ 2013-02-14 22:47 UTC (permalink / raw)
To: linux-arm-kernel
Cc: linux-kernel, arm, Arnd Bergmann, Paul Walmsley,
Sebastien Guiriec, Tony Lindgren
The newly created omap_hwmod_reset.c is missing an
include of linux/errno.h in commit c02060d8 "ARM:
OMAP4+: AESS: enable internal auto-gating during
initial setup". It still works in omap2_defconfig,
but not in all other combinations.
Without this patch, building allmodconfig results in:
arch/arm/mach-omap2/omap_hwmod_reset.c: In function 'omap_hwmod_aess_preprogram':
arch/arm/mach-omap2/omap_hwmod_reset.c:47:11: error: 'EINVAL' undeclared (first use in this function)
arch/arm/mach-omap2/omap_hwmod_reset.c:47:11: note: each undeclared identifier is reported only once for each function it appears in
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Sebastien Guiriec <s-guiriec@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
---
arch/arm/mach-omap2/omap_hwmod_reset.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-omap2/omap_hwmod_reset.c b/arch/arm/mach-omap2/omap_hwmod_reset.c
index bba43fa..65e186c 100644
--- a/arch/arm/mach-omap2/omap_hwmod_reset.c
+++ b/arch/arm/mach-omap2/omap_hwmod_reset.c
@@ -24,6 +24,7 @@
* 02110-1301 USA
*/
#include <linux/kernel.h>
+#include <linux/errno.h>
#include <sound/aess.h>
--
1.8.1.2
^ permalink raw reply related [flat|nested] 70+ messages in thread
* [PATCH 3/9] ARM: omap2: include linux/errno.h in hwmod_reset
@ 2013-02-14 22:47 ` Arnd Bergmann
0 siblings, 0 replies; 70+ messages in thread
From: Arnd Bergmann @ 2013-02-14 22:47 UTC (permalink / raw)
To: linux-arm-kernel
The newly created omap_hwmod_reset.c is missing an
include of linux/errno.h in commit c02060d8 "ARM:
OMAP4+: AESS: enable internal auto-gating during
initial setup". It still works in omap2_defconfig,
but not in all other combinations.
Without this patch, building allmodconfig results in:
arch/arm/mach-omap2/omap_hwmod_reset.c: In function 'omap_hwmod_aess_preprogram':
arch/arm/mach-omap2/omap_hwmod_reset.c:47:11: error: 'EINVAL' undeclared (first use in this function)
arch/arm/mach-omap2/omap_hwmod_reset.c:47:11: note: each undeclared identifier is reported only once for each function it appears in
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Sebastien Guiriec <s-guiriec@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
---
arch/arm/mach-omap2/omap_hwmod_reset.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-omap2/omap_hwmod_reset.c b/arch/arm/mach-omap2/omap_hwmod_reset.c
index bba43fa..65e186c 100644
--- a/arch/arm/mach-omap2/omap_hwmod_reset.c
+++ b/arch/arm/mach-omap2/omap_hwmod_reset.c
@@ -24,6 +24,7 @@
* 02110-1301 USA
*/
#include <linux/kernel.h>
+#include <linux/errno.h>
#include <sound/aess.h>
--
1.8.1.2
^ permalink raw reply related [flat|nested] 70+ messages in thread
* Re: [PATCH 3/9] ARM: omap2: include linux/errno.h in hwmod_reset
2013-02-14 22:47 ` Arnd Bergmann
@ 2013-02-14 22:51 ` Tony Lindgren
-1 siblings, 0 replies; 70+ messages in thread
From: Tony Lindgren @ 2013-02-14 22:51 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-arm-kernel, linux-kernel, arm, Paul Walmsley, Sebastien Guiriec
* Arnd Bergmann <arnd@arndb.de> [130214 14:51]:
> The newly created omap_hwmod_reset.c is missing an
> include of linux/errno.h in commit c02060d8 "ARM:
> OMAP4+: AESS: enable internal auto-gating during
> initial setup". It still works in omap2_defconfig,
> but not in all other combinations.
>
> Without this patch, building allmodconfig results in:
>
> arch/arm/mach-omap2/omap_hwmod_reset.c: In function 'omap_hwmod_aess_preprogram':
> arch/arm/mach-omap2/omap_hwmod_reset.c:47:11: error: 'EINVAL' undeclared (first use in this function)
> arch/arm/mach-omap2/omap_hwmod_reset.c:47:11: note: each undeclared identifier is reported only once for each function it appears in
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Paul Walmsley <paul@pwsan.com>
> Cc: Sebastien Guiriec <s-guiriec@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
> ---
> arch/arm/mach-omap2/omap_hwmod_reset.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/mach-omap2/omap_hwmod_reset.c b/arch/arm/mach-omap2/omap_hwmod_reset.c
> index bba43fa..65e186c 100644
> --- a/arch/arm/mach-omap2/omap_hwmod_reset.c
> +++ b/arch/arm/mach-omap2/omap_hwmod_reset.c
> @@ -24,6 +24,7 @@
> * 02110-1301 USA
> */
> #include <linux/kernel.h>
> +#include <linux/errno.h>
>
> #include <sound/aess.h>
>
> --
> 1.8.1.2
>
^ permalink raw reply [flat|nested] 70+ messages in thread
* [PATCH 3/9] ARM: omap2: include linux/errno.h in hwmod_reset
@ 2013-02-14 22:51 ` Tony Lindgren
0 siblings, 0 replies; 70+ messages in thread
From: Tony Lindgren @ 2013-02-14 22:51 UTC (permalink / raw)
To: linux-arm-kernel
* Arnd Bergmann <arnd@arndb.de> [130214 14:51]:
> The newly created omap_hwmod_reset.c is missing an
> include of linux/errno.h in commit c02060d8 "ARM:
> OMAP4+: AESS: enable internal auto-gating during
> initial setup". It still works in omap2_defconfig,
> but not in all other combinations.
>
> Without this patch, building allmodconfig results in:
>
> arch/arm/mach-omap2/omap_hwmod_reset.c: In function 'omap_hwmod_aess_preprogram':
> arch/arm/mach-omap2/omap_hwmod_reset.c:47:11: error: 'EINVAL' undeclared (first use in this function)
> arch/arm/mach-omap2/omap_hwmod_reset.c:47:11: note: each undeclared identifier is reported only once for each function it appears in
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Paul Walmsley <paul@pwsan.com>
> Cc: Sebastien Guiriec <s-guiriec@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
> ---
> arch/arm/mach-omap2/omap_hwmod_reset.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/mach-omap2/omap_hwmod_reset.c b/arch/arm/mach-omap2/omap_hwmod_reset.c
> index bba43fa..65e186c 100644
> --- a/arch/arm/mach-omap2/omap_hwmod_reset.c
> +++ b/arch/arm/mach-omap2/omap_hwmod_reset.c
> @@ -24,6 +24,7 @@
> * 02110-1301 USA
> */
> #include <linux/kernel.h>
> +#include <linux/errno.h>
>
> #include <sound/aess.h>
>
> --
> 1.8.1.2
>
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH 3/9] ARM: omap2: include linux/errno.h in hwmod_reset
2013-02-14 22:51 ` Tony Lindgren
@ 2013-02-15 12:38 ` Arnd Bergmann
-1 siblings, 0 replies; 70+ messages in thread
From: Arnd Bergmann @ 2013-02-15 12:38 UTC (permalink / raw)
To: Tony Lindgren
Cc: linux-arm-kernel, linux-kernel, arm, Paul Walmsley, Sebastien Guiriec
On Thursday 14 February 2013, Tony Lindgren wrote:
> * Arnd Bergmann <arnd@arndb.de> [130214 14:51]:
> > The newly created omap_hwmod_reset.c is missing an
> > include of linux/errno.h in commit c02060d8 "ARM:
> > OMAP4+: AESS: enable internal auto-gating during
> > initial setup". It still works in omap2_defconfig,
> > but not in all other combinations.
> >
> > Without this patch, building allmodconfig results in:
> >
> > arch/arm/mach-omap2/omap_hwmod_reset.c: In function 'omap_hwmod_aess_preprogram':
> > arch/arm/mach-omap2/omap_hwmod_reset.c:47:11: error: 'EINVAL' undeclared (first use in this function)
> > arch/arm/mach-omap2/omap_hwmod_reset.c:47:11: note: each undeclared identifier is reported only once for each function it appears in
> >
> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > Cc: Paul Walmsley <paul@pwsan.com>
> > Cc: Sebastien Guiriec <s-guiriec@ti.com>
>
> Acked-by: Tony Lindgren <tony@atomide.com>
Ok, applied on top of late/omap
Arnd
^ permalink raw reply [flat|nested] 70+ messages in thread
* [PATCH 3/9] ARM: omap2: include linux/errno.h in hwmod_reset
@ 2013-02-15 12:38 ` Arnd Bergmann
0 siblings, 0 replies; 70+ messages in thread
From: Arnd Bergmann @ 2013-02-15 12:38 UTC (permalink / raw)
To: linux-arm-kernel
On Thursday 14 February 2013, Tony Lindgren wrote:
> * Arnd Bergmann <arnd@arndb.de> [130214 14:51]:
> > The newly created omap_hwmod_reset.c is missing an
> > include of linux/errno.h in commit c02060d8 "ARM:
> > OMAP4+: AESS: enable internal auto-gating during
> > initial setup". It still works in omap2_defconfig,
> > but not in all other combinations.
> >
> > Without this patch, building allmodconfig results in:
> >
> > arch/arm/mach-omap2/omap_hwmod_reset.c: In function 'omap_hwmod_aess_preprogram':
> > arch/arm/mach-omap2/omap_hwmod_reset.c:47:11: error: 'EINVAL' undeclared (first use in this function)
> > arch/arm/mach-omap2/omap_hwmod_reset.c:47:11: note: each undeclared identifier is reported only once for each function it appears in
> >
> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > Cc: Paul Walmsley <paul@pwsan.com>
> > Cc: Sebastien Guiriec <s-guiriec@ti.com>
>
> Acked-by: Tony Lindgren <tony@atomide.com>
Ok, applied on top of late/omap
Arnd
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH 3/9] ARM: omap2: include linux/errno.h in hwmod_reset
2013-02-14 22:47 ` Arnd Bergmann
@ 2013-02-14 22:58 ` Paul Walmsley
-1 siblings, 0 replies; 70+ messages in thread
From: Paul Walmsley @ 2013-02-14 22:58 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-arm-kernel, linux-kernel, arm, Sebastien Guiriec, Tony Lindgren
On Thu, 14 Feb 2013, Arnd Bergmann wrote:
> The newly created omap_hwmod_reset.c is missing an
> include of linux/errno.h in commit c02060d8 "ARM:
> OMAP4+: AESS: enable internal auto-gating during
> initial setup". It still works in omap2_defconfig,
> but not in all other combinations.
>
> Without this patch, building allmodconfig results in:
>
> arch/arm/mach-omap2/omap_hwmod_reset.c: In function 'omap_hwmod_aess_preprogram':
> arch/arm/mach-omap2/omap_hwmod_reset.c:47:11: error: 'EINVAL' undeclared (first use in this function)
> arch/arm/mach-omap2/omap_hwmod_reset.c:47:11: note: each undeclared identifier is reported only once for each function it appears in
Acked-by: Paul Walmsley <paul@pwsan.com>
- Paul
^ permalink raw reply [flat|nested] 70+ messages in thread
* [PATCH 3/9] ARM: omap2: include linux/errno.h in hwmod_reset
@ 2013-02-14 22:58 ` Paul Walmsley
0 siblings, 0 replies; 70+ messages in thread
From: Paul Walmsley @ 2013-02-14 22:58 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, 14 Feb 2013, Arnd Bergmann wrote:
> The newly created omap_hwmod_reset.c is missing an
> include of linux/errno.h in commit c02060d8 "ARM:
> OMAP4+: AESS: enable internal auto-gating during
> initial setup". It still works in omap2_defconfig,
> but not in all other combinations.
>
> Without this patch, building allmodconfig results in:
>
> arch/arm/mach-omap2/omap_hwmod_reset.c: In function 'omap_hwmod_aess_preprogram':
> arch/arm/mach-omap2/omap_hwmod_reset.c:47:11: error: 'EINVAL' undeclared (first use in this function)
> arch/arm/mach-omap2/omap_hwmod_reset.c:47:11: note: each undeclared identifier is reported only once for each function it appears in
Acked-by: Paul Walmsley <paul@pwsan.com>
- Paul
^ permalink raw reply [flat|nested] 70+ messages in thread
* [PATCH 4/9] ARM: omap: add include guard for soc.h
2013-02-14 22:47 ` Arnd Bergmann
@ 2013-02-14 22:47 ` Arnd Bergmann
-1 siblings, 0 replies; 70+ messages in thread
From: Arnd Bergmann @ 2013-02-14 22:47 UTC (permalink / raw)
To: linux-arm-kernel; +Cc: linux-kernel, arm, Arnd Bergmann, Tony Lindgren
Commit e4c060db "ARM: OMAP: Split plat/cpu.h into local soc.h for
mach-omap1 and mach-omap2" moved the bulk of "plat/cpu.h" into "cpu.h"
but did not add an include guard for the new file that was present
in the old one. There are cases where the file is indeed included
multiple times, probably by accident, but adding the include
guard ensures that this has no further consequences.
Without this patch, building allmodconfig results in lots of warnings like:
In file included from arch/arm/mach-omap2/drm.c:31:0:
arch/arm/mach-omap2/soc.h:206:0: warning: "cpu_is_omap24xx" redefined [enabled by default]
In file included from arch/arm/mach-omap2/drm.c:28:0:
arch/arm/mach-omap2/soc.h:227:0: note: this is the location of the previous definition
In file included from arch/arm/mach-omap2/drm.c:31:0:
arch/arm/mach-omap2/soc.h:207:0: warning: "cpu_is_omap242x" redefined [enabled by default]
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Tony Lindgren <tony@atomide.com>
---
arch/arm/mach-omap2/soc.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm/mach-omap2/soc.h b/arch/arm/mach-omap2/soc.h
index c62116b..97dd373 100644
--- a/arch/arm/mach-omap2/soc.h
+++ b/arch/arm/mach-omap2/soc.h
@@ -24,6 +24,8 @@
* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
*
*/
+#ifndef OMAP2_SOC_H
+#define OMAP2_SOC_H
#include "omap24xx.h"
#include "omap34xx.h"
@@ -497,3 +499,4 @@ level(__##fn);
#endif /* __ASSEMBLY__ */
+#endif
--
1.8.1.2
^ permalink raw reply related [flat|nested] 70+ messages in thread
* [PATCH 4/9] ARM: omap: add include guard for soc.h
@ 2013-02-14 22:47 ` Arnd Bergmann
0 siblings, 0 replies; 70+ messages in thread
From: Arnd Bergmann @ 2013-02-14 22:47 UTC (permalink / raw)
To: linux-arm-kernel
Commit e4c060db "ARM: OMAP: Split plat/cpu.h into local soc.h for
mach-omap1 and mach-omap2" moved the bulk of "plat/cpu.h" into "cpu.h"
but did not add an include guard for the new file that was present
in the old one. There are cases where the file is indeed included
multiple times, probably by accident, but adding the include
guard ensures that this has no further consequences.
Without this patch, building allmodconfig results in lots of warnings like:
In file included from arch/arm/mach-omap2/drm.c:31:0:
arch/arm/mach-omap2/soc.h:206:0: warning: "cpu_is_omap24xx" redefined [enabled by default]
In file included from arch/arm/mach-omap2/drm.c:28:0:
arch/arm/mach-omap2/soc.h:227:0: note: this is the location of the previous definition
In file included from arch/arm/mach-omap2/drm.c:31:0:
arch/arm/mach-omap2/soc.h:207:0: warning: "cpu_is_omap242x" redefined [enabled by default]
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Tony Lindgren <tony@atomide.com>
---
arch/arm/mach-omap2/soc.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm/mach-omap2/soc.h b/arch/arm/mach-omap2/soc.h
index c62116b..97dd373 100644
--- a/arch/arm/mach-omap2/soc.h
+++ b/arch/arm/mach-omap2/soc.h
@@ -24,6 +24,8 @@
* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
*
*/
+#ifndef OMAP2_SOC_H
+#define OMAP2_SOC_H
#include "omap24xx.h"
#include "omap34xx.h"
@@ -497,3 +499,4 @@ level(__##fn);
#endif /* __ASSEMBLY__ */
+#endif
--
1.8.1.2
^ permalink raw reply related [flat|nested] 70+ messages in thread
* Re: [PATCH 4/9] ARM: omap: add include guard for soc.h
2013-02-14 22:47 ` Arnd Bergmann
@ 2013-02-14 22:55 ` Tony Lindgren
-1 siblings, 0 replies; 70+ messages in thread
From: Tony Lindgren @ 2013-02-14 22:55 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linux-arm-kernel, linux-kernel, arm
* Arnd Bergmann <arnd@arndb.de> [130214 14:51]:
> Commit e4c060db "ARM: OMAP: Split plat/cpu.h into local soc.h for
> mach-omap1 and mach-omap2" moved the bulk of "plat/cpu.h" into "cpu.h"
> but did not add an include guard for the new file that was present
> in the old one. There are cases where the file is indeed included
> multiple times, probably by accident, but adding the include
> guard ensures that this has no further consequences.
>
> Without this patch, building allmodconfig results in lots of warnings like:
>
> In file included from arch/arm/mach-omap2/drm.c:31:0:
> arch/arm/mach-omap2/soc.h:206:0: warning: "cpu_is_omap24xx" redefined [enabled by default]
> In file included from arch/arm/mach-omap2/drm.c:28:0:
> arch/arm/mach-omap2/soc.h:227:0: note: this is the location of the previous definition
> In file included from arch/arm/mach-omap2/drm.c:31:0:
> arch/arm/mach-omap2/soc.h:207:0: warning: "cpu_is_omap242x" redefined [enabled by default]
I left it out intentionally as these are private to mach-omap2,
and I'd like to simplify the indirect includes there further.
So I'd rather just remove the duplicate soc.h from drm.c.
If people really think this should be applied, I have no
objections to this patch naturally.
Regards,
Tony
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Tony Lindgren <tony@atomide.com>
> ---
> arch/arm/mach-omap2/soc.h | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/arch/arm/mach-omap2/soc.h b/arch/arm/mach-omap2/soc.h
> index c62116b..97dd373 100644
> --- a/arch/arm/mach-omap2/soc.h
> +++ b/arch/arm/mach-omap2/soc.h
> @@ -24,6 +24,8 @@
> * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
> *
> */
> +#ifndef OMAP2_SOC_H
> +#define OMAP2_SOC_H
>
> #include "omap24xx.h"
> #include "omap34xx.h"
> @@ -497,3 +499,4 @@ level(__##fn);
>
> #endif /* __ASSEMBLY__ */
>
> +#endif
> --
> 1.8.1.2
>
^ permalink raw reply [flat|nested] 70+ messages in thread
* [PATCH 4/9] ARM: omap: add include guard for soc.h
@ 2013-02-14 22:55 ` Tony Lindgren
0 siblings, 0 replies; 70+ messages in thread
From: Tony Lindgren @ 2013-02-14 22:55 UTC (permalink / raw)
To: linux-arm-kernel
* Arnd Bergmann <arnd@arndb.de> [130214 14:51]:
> Commit e4c060db "ARM: OMAP: Split plat/cpu.h into local soc.h for
> mach-omap1 and mach-omap2" moved the bulk of "plat/cpu.h" into "cpu.h"
> but did not add an include guard for the new file that was present
> in the old one. There are cases where the file is indeed included
> multiple times, probably by accident, but adding the include
> guard ensures that this has no further consequences.
>
> Without this patch, building allmodconfig results in lots of warnings like:
>
> In file included from arch/arm/mach-omap2/drm.c:31:0:
> arch/arm/mach-omap2/soc.h:206:0: warning: "cpu_is_omap24xx" redefined [enabled by default]
> In file included from arch/arm/mach-omap2/drm.c:28:0:
> arch/arm/mach-omap2/soc.h:227:0: note: this is the location of the previous definition
> In file included from arch/arm/mach-omap2/drm.c:31:0:
> arch/arm/mach-omap2/soc.h:207:0: warning: "cpu_is_omap242x" redefined [enabled by default]
I left it out intentionally as these are private to mach-omap2,
and I'd like to simplify the indirect includes there further.
So I'd rather just remove the duplicate soc.h from drm.c.
If people really think this should be applied, I have no
objections to this patch naturally.
Regards,
Tony
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Tony Lindgren <tony@atomide.com>
> ---
> arch/arm/mach-omap2/soc.h | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/arch/arm/mach-omap2/soc.h b/arch/arm/mach-omap2/soc.h
> index c62116b..97dd373 100644
> --- a/arch/arm/mach-omap2/soc.h
> +++ b/arch/arm/mach-omap2/soc.h
> @@ -24,6 +24,8 @@
> * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
> *
> */
> +#ifndef OMAP2_SOC_H
> +#define OMAP2_SOC_H
>
> #include "omap24xx.h"
> #include "omap34xx.h"
> @@ -497,3 +499,4 @@ level(__##fn);
>
> #endif /* __ASSEMBLY__ */
>
> +#endif
> --
> 1.8.1.2
>
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH 4/9] ARM: omap: add include guard for soc.h
2013-02-14 22:55 ` Tony Lindgren
@ 2013-02-14 23:11 ` Arnd Bergmann
-1 siblings, 0 replies; 70+ messages in thread
From: Arnd Bergmann @ 2013-02-14 23:11 UTC (permalink / raw)
To: Tony Lindgren; +Cc: linux-arm-kernel, linux-kernel, arm
On Thursday 14 February 2013, Tony Lindgren wrote:
> I left it out intentionally as these are private to mach-omap2,
> and I'd like to simplify the indirect includes there further.
> So I'd rather just remove the duplicate soc.h from drm.c.
>
> If people really think this should be applied, I have no
> objections to this patch naturally.
Either way is fine with me.
Arnd
^ permalink raw reply [flat|nested] 70+ messages in thread
* [PATCH 4/9] ARM: omap: add include guard for soc.h
@ 2013-02-14 23:11 ` Arnd Bergmann
0 siblings, 0 replies; 70+ messages in thread
From: Arnd Bergmann @ 2013-02-14 23:11 UTC (permalink / raw)
To: linux-arm-kernel
On Thursday 14 February 2013, Tony Lindgren wrote:
> I left it out intentionally as these are private to mach-omap2,
> and I'd like to simplify the indirect includes there further.
> So I'd rather just remove the duplicate soc.h from drm.c.
>
> If people really think this should be applied, I have no
> objections to this patch naturally.
Either way is fine with me.
Arnd
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH 4/9] ARM: omap: add include guard for soc.h
2013-02-14 22:55 ` Tony Lindgren
@ 2013-02-15 12:40 ` Arnd Bergmann
-1 siblings, 0 replies; 70+ messages in thread
From: Arnd Bergmann @ 2013-02-15 12:40 UTC (permalink / raw)
To: Tony Lindgren; +Cc: linux-arm-kernel, linux-kernel, arm
On Thursday 14 February 2013, Tony Lindgren wrote:
> I left it out intentionally as these are private to mach-omap2,
> and I'd like to simplify the indirect includes there further.
> So I'd rather just remove the duplicate soc.h from drm.c.
>
> If people really think this should be applied, I have no
> objections to this patch naturally.
The duplicate #include was a result of an automated mismerge between
v3.8-rc5 and the omap/multiplatform branch. I have merge v3.8-rc5
into next/multiplatform to resolve this correctly, and pulled in
a new omap/multiplatform-fixes branch with patches 6, 7, and 9
from this series.
Arnd
^ permalink raw reply [flat|nested] 70+ messages in thread
* [PATCH 4/9] ARM: omap: add include guard for soc.h
@ 2013-02-15 12:40 ` Arnd Bergmann
0 siblings, 0 replies; 70+ messages in thread
From: Arnd Bergmann @ 2013-02-15 12:40 UTC (permalink / raw)
To: linux-arm-kernel
On Thursday 14 February 2013, Tony Lindgren wrote:
> I left it out intentionally as these are private to mach-omap2,
> and I'd like to simplify the indirect includes there further.
> So I'd rather just remove the duplicate soc.h from drm.c.
>
> If people really think this should be applied, I have no
> objections to this patch naturally.
The duplicate #include was a result of an automated mismerge between
v3.8-rc5 and the omap/multiplatform branch. I have merge v3.8-rc5
into next/multiplatform to resolve this correctly, and pulled in
a new omap/multiplatform-fixes branch with patches 6, 7, and 9
from this series.
Arnd
^ permalink raw reply [flat|nested] 70+ messages in thread
* [PATCH 5/9] drm: export drm_vm_open_locked
2013-02-14 22:47 ` Arnd Bergmann
@ 2013-02-14 22:47 ` Arnd Bergmann
-1 siblings, 0 replies; 70+ messages in thread
From: Arnd Bergmann @ 2013-02-14 22:47 UTC (permalink / raw)
To: linux-arm-kernel
Cc: linux-kernel, arm, Arnd Bergmann, Dave Airlie, Shirish S,
Inki Dae, Rob Clark
Since the exynos DRM driver can now be built as a module on
all multiplatform configurations, an existing bug has
become visible: The exynos driver uses the drm_vm_open_locked
function that is not exported. The obvious solution is to
export that symbol.
Without this patch, building ARM allmodconfig results in:
ERROR: "drm_vm_open_locked" [drivers/gpu/drm/exynos/exynosdrm.ko] undefined!
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Shirish S <s.shirish@samsung.com>
Cc: Inki Dae <inki.dae@samsung.com>
Cc: Rob Clark <rob@ti.com>
---
drivers/gpu/drm/drm_vm.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/drm_vm.c b/drivers/gpu/drm/drm_vm.c
index db7bd29..1d4f7c9 100644
--- a/drivers/gpu/drm/drm_vm.c
+++ b/drivers/gpu/drm/drm_vm.c
@@ -422,6 +422,7 @@ void drm_vm_open_locked(struct drm_device *dev,
list_add(&vma_entry->head, &dev->vmalist);
}
}
+EXPORT_SYMBOL_GPL(drm_vm_open_locked);
static void drm_vm_open(struct vm_area_struct *vma)
{
--
1.8.1.2
^ permalink raw reply related [flat|nested] 70+ messages in thread
* [PATCH 5/9] drm: export drm_vm_open_locked
@ 2013-02-14 22:47 ` Arnd Bergmann
0 siblings, 0 replies; 70+ messages in thread
From: Arnd Bergmann @ 2013-02-14 22:47 UTC (permalink / raw)
To: linux-arm-kernel
Since the exynos DRM driver can now be built as a module on
all multiplatform configurations, an existing bug has
become visible: The exynos driver uses the drm_vm_open_locked
function that is not exported. The obvious solution is to
export that symbol.
Without this patch, building ARM allmodconfig results in:
ERROR: "drm_vm_open_locked" [drivers/gpu/drm/exynos/exynosdrm.ko] undefined!
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Shirish S <s.shirish@samsung.com>
Cc: Inki Dae <inki.dae@samsung.com>
Cc: Rob Clark <rob@ti.com>
---
drivers/gpu/drm/drm_vm.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/drm_vm.c b/drivers/gpu/drm/drm_vm.c
index db7bd29..1d4f7c9 100644
--- a/drivers/gpu/drm/drm_vm.c
+++ b/drivers/gpu/drm/drm_vm.c
@@ -422,6 +422,7 @@ void drm_vm_open_locked(struct drm_device *dev,
list_add(&vma_entry->head, &dev->vmalist);
}
}
+EXPORT_SYMBOL_GPL(drm_vm_open_locked);
static void drm_vm_open(struct vm_area_struct *vma)
{
--
1.8.1.2
^ permalink raw reply related [flat|nested] 70+ messages in thread
* [PATCH 6/9] net: cwdavinci_cpdma: export symbols for cpsw
2013-02-14 22:47 ` Arnd Bergmann
@ 2013-02-14 22:47 ` Arnd Bergmann
-1 siblings, 0 replies; 70+ messages in thread
From: Arnd Bergmann @ 2013-02-14 22:47 UTC (permalink / raw)
To: linux-arm-kernel
Cc: linux-kernel, arm, Arnd Bergmann, Mugunthan V N,
Vaibhav Hiremath, Richard Cochran, netdev
With the support for ARM AM33xx in multiplatform kernels
in 3.9, an older bug appears in ARM allmodconfig:
When the cpsw driver is built as a module with cpdma
support enabled, it uses symbols that the cpdma driver
does not export.
Without this patch, building allmodconfig results in:
ERROR: "cpdma_ctlr_int_ctrl" [drivers/net/ethernet/ti/ti_cpsw.ko] undefined!
ERROR: "cpdma_control_set" [drivers/net/ethernet/ti/ti_cpsw.ko] undefined!
ERROR: "cpdma_ctlr_eoi" [drivers/net/ethernet/ti/ti_cpsw.ko] undefined!
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Mugunthan V N <mugunthanvnm@ti.com>
Cc: Vaibhav Hiremath <hvaibhav@ti.com>
Cc: Richard Cochran <richardcochran@gmail.com>
Cc: netdev@vger.kernel.org
---
drivers/net/ethernet/ti/davinci_cpdma.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/ethernet/ti/davinci_cpdma.c b/drivers/net/ethernet/ti/davinci_cpdma.c
index 7d3bffd..8eeb7c9 100644
--- a/drivers/net/ethernet/ti/davinci_cpdma.c
+++ b/drivers/net/ethernet/ti/davinci_cpdma.c
@@ -492,11 +492,13 @@ int cpdma_ctlr_int_ctrl(struct cpdma_ctlr *ctlr, bool enable)
spin_unlock_irqrestore(&ctlr->lock, flags);
return 0;
}
+EXPORT_SYMBOL_GPL(cpdma_ctlr_int_ctrl);
void cpdma_ctlr_eoi(struct cpdma_ctlr *ctlr)
{
dma_reg_write(ctlr, CPDMA_MACEOIVECTOR, 0);
}
+EXPORT_SYMBOL_GPL(cpdma_ctlr_eoi);
struct cpdma_chan *cpdma_chan_create(struct cpdma_ctlr *ctlr, int chan_num,
cpdma_handler_fn handler)
@@ -1028,3 +1030,4 @@ unlock_ret:
spin_unlock_irqrestore(&ctlr->lock, flags);
return ret;
}
+EXPORT_SYMBOL_GPL(cpdma_control_set);
--
1.8.1.2
^ permalink raw reply related [flat|nested] 70+ messages in thread
* [PATCH 6/9] net: cwdavinci_cpdma: export symbols for cpsw
@ 2013-02-14 22:47 ` Arnd Bergmann
0 siblings, 0 replies; 70+ messages in thread
From: Arnd Bergmann @ 2013-02-14 22:47 UTC (permalink / raw)
To: linux-arm-kernel
With the support for ARM AM33xx in multiplatform kernels
in 3.9, an older bug appears in ARM allmodconfig:
When the cpsw driver is built as a module with cpdma
support enabled, it uses symbols that the cpdma driver
does not export.
Without this patch, building allmodconfig results in:
ERROR: "cpdma_ctlr_int_ctrl" [drivers/net/ethernet/ti/ti_cpsw.ko] undefined!
ERROR: "cpdma_control_set" [drivers/net/ethernet/ti/ti_cpsw.ko] undefined!
ERROR: "cpdma_ctlr_eoi" [drivers/net/ethernet/ti/ti_cpsw.ko] undefined!
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Mugunthan V N <mugunthanvnm@ti.com>
Cc: Vaibhav Hiremath <hvaibhav@ti.com>
Cc: Richard Cochran <richardcochran@gmail.com>
Cc: netdev at vger.kernel.org
---
drivers/net/ethernet/ti/davinci_cpdma.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/ethernet/ti/davinci_cpdma.c b/drivers/net/ethernet/ti/davinci_cpdma.c
index 7d3bffd..8eeb7c9 100644
--- a/drivers/net/ethernet/ti/davinci_cpdma.c
+++ b/drivers/net/ethernet/ti/davinci_cpdma.c
@@ -492,11 +492,13 @@ int cpdma_ctlr_int_ctrl(struct cpdma_ctlr *ctlr, bool enable)
spin_unlock_irqrestore(&ctlr->lock, flags);
return 0;
}
+EXPORT_SYMBOL_GPL(cpdma_ctlr_int_ctrl);
void cpdma_ctlr_eoi(struct cpdma_ctlr *ctlr)
{
dma_reg_write(ctlr, CPDMA_MACEOIVECTOR, 0);
}
+EXPORT_SYMBOL_GPL(cpdma_ctlr_eoi);
struct cpdma_chan *cpdma_chan_create(struct cpdma_ctlr *ctlr, int chan_num,
cpdma_handler_fn handler)
@@ -1028,3 +1030,4 @@ unlock_ret:
spin_unlock_irqrestore(&ctlr->lock, flags);
return ret;
}
+EXPORT_SYMBOL_GPL(cpdma_control_set);
--
1.8.1.2
^ permalink raw reply related [flat|nested] 70+ messages in thread
* Re: [PATCH 6/9] net: cwdavinci_cpdma: export symbols for cpsw
2013-02-14 22:47 ` Arnd Bergmann
@ 2013-02-14 22:52 ` David Miller
-1 siblings, 0 replies; 70+ messages in thread
From: David Miller @ 2013-02-14 22:52 UTC (permalink / raw)
To: arnd
Cc: linux-arm-kernel, linux-kernel, arm, mugunthanvnm, hvaibhav,
richardcochran, netdev
From: Arnd Bergmann <arnd@arndb.de>
Date: Thu, 14 Feb 2013 23:47:48 +0100
> With the support for ARM AM33xx in multiplatform kernels
> in 3.9, an older bug appears in ARM allmodconfig:
> When the cpsw driver is built as a module with cpdma
> support enabled, it uses symbols that the cpdma driver
> does not export.
>
> Without this patch, building allmodconfig results in:
>
> ERROR: "cpdma_ctlr_int_ctrl" [drivers/net/ethernet/ti/ti_cpsw.ko] undefined!
> ERROR: "cpdma_control_set" [drivers/net/ethernet/ti/ti_cpsw.ko] undefined!
> ERROR: "cpdma_ctlr_eoi" [drivers/net/ethernet/ti/ti_cpsw.ko] undefined!
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: David S. Miller <davem@davemloft.net>
^ permalink raw reply [flat|nested] 70+ messages in thread
* [PATCH 6/9] net: cwdavinci_cpdma: export symbols for cpsw
@ 2013-02-14 22:52 ` David Miller
0 siblings, 0 replies; 70+ messages in thread
From: David Miller @ 2013-02-14 22:52 UTC (permalink / raw)
To: linux-arm-kernel
From: Arnd Bergmann <arnd@arndb.de>
Date: Thu, 14 Feb 2013 23:47:48 +0100
> With the support for ARM AM33xx in multiplatform kernels
> in 3.9, an older bug appears in ARM allmodconfig:
> When the cpsw driver is built as a module with cpdma
> support enabled, it uses symbols that the cpdma driver
> does not export.
>
> Without this patch, building allmodconfig results in:
>
> ERROR: "cpdma_ctlr_int_ctrl" [drivers/net/ethernet/ti/ti_cpsw.ko] undefined!
> ERROR: "cpdma_control_set" [drivers/net/ethernet/ti/ti_cpsw.ko] undefined!
> ERROR: "cpdma_ctlr_eoi" [drivers/net/ethernet/ti/ti_cpsw.ko] undefined!
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: David S. Miller <davem@davemloft.net>
^ permalink raw reply [flat|nested] 70+ messages in thread
* [PATCH 7/9] remoteproc: omap: depend on OMAP_MBOX_FWK
2013-02-14 22:47 ` Arnd Bergmann
@ 2013-02-14 22:47 ` Arnd Bergmann
-1 siblings, 0 replies; 70+ messages in thread
From: Arnd Bergmann @ 2013-02-14 22:47 UTC (permalink / raw)
To: linux-arm-kernel
Cc: linux-kernel, arm, Arnd Bergmann, Tony Lindgren, Ohad Ben-Cohen
Patch a62a6e98 "ARM: OMAP2+: Disable code that currently does not work
with multiplaform" makes the OMAP_MBOX_FWK option depend on !MULTIPLATFORM,
which means we cannot simply select that symbol from OMAP_REMOTEPROC.
Turning the 'select' into 'depends on' ensures that all dependencies
are correct until OMAP_MBOX_FWK loses its dependency.
Without this patch, building allmodconfig results in:
drivers/remoteproc/omap_remoteproc.c:31:26: fatal error: plat/mailbox.h: No such file or directory
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Ohad Ben-Cohen <ohad@wizery.com>
---
drivers/remoteproc/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
index 0b24108..cc1f7bf 100644
--- a/drivers/remoteproc/Kconfig
+++ b/drivers/remoteproc/Kconfig
@@ -12,8 +12,8 @@ config OMAP_REMOTEPROC
depends on HAS_DMA
depends on ARCH_OMAP4
depends on OMAP_IOMMU
+ depends on OMAP_MBOX_FWK
select REMOTEPROC
- select OMAP_MBOX_FWK
select RPMSG
help
Say y here to support OMAP's remote processors (dual M3
--
1.8.1.2
^ permalink raw reply related [flat|nested] 70+ messages in thread
* [PATCH 7/9] remoteproc: omap: depend on OMAP_MBOX_FWK
@ 2013-02-14 22:47 ` Arnd Bergmann
0 siblings, 0 replies; 70+ messages in thread
From: Arnd Bergmann @ 2013-02-14 22:47 UTC (permalink / raw)
To: linux-arm-kernel
Patch a62a6e98 "ARM: OMAP2+: Disable code that currently does not work
with multiplaform" makes the OMAP_MBOX_FWK option depend on !MULTIPLATFORM,
which means we cannot simply select that symbol from OMAP_REMOTEPROC.
Turning the 'select' into 'depends on' ensures that all dependencies
are correct until OMAP_MBOX_FWK loses its dependency.
Without this patch, building allmodconfig results in:
drivers/remoteproc/omap_remoteproc.c:31:26: fatal error: plat/mailbox.h: No such file or directory
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Ohad Ben-Cohen <ohad@wizery.com>
---
drivers/remoteproc/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
index 0b24108..cc1f7bf 100644
--- a/drivers/remoteproc/Kconfig
+++ b/drivers/remoteproc/Kconfig
@@ -12,8 +12,8 @@ config OMAP_REMOTEPROC
depends on HAS_DMA
depends on ARCH_OMAP4
depends on OMAP_IOMMU
+ depends on OMAP_MBOX_FWK
select REMOTEPROC
- select OMAP_MBOX_FWK
select RPMSG
help
Say y here to support OMAP's remote processors (dual M3
--
1.8.1.2
^ permalink raw reply related [flat|nested] 70+ messages in thread
* Re: [PATCH 7/9] remoteproc: omap: depend on OMAP_MBOX_FWK
2013-02-14 22:47 ` Arnd Bergmann
@ 2013-02-14 22:55 ` Tony Lindgren
-1 siblings, 0 replies; 70+ messages in thread
From: Tony Lindgren @ 2013-02-14 22:55 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linux-arm-kernel, linux-kernel, arm, Ohad Ben-Cohen
* Arnd Bergmann <arnd@arndb.de> [130214 14:51]:
> Patch a62a6e98 "ARM: OMAP2+: Disable code that currently does not work
> with multiplaform" makes the OMAP_MBOX_FWK option depend on !MULTIPLATFORM,
> which means we cannot simply select that symbol from OMAP_REMOTEPROC.
>
> Turning the 'select' into 'depends on' ensures that all dependencies
> are correct until OMAP_MBOX_FWK loses its dependency.
>
> Without this patch, building allmodconfig results in:
>
> drivers/remoteproc/omap_remoteproc.c:31:26: fatal error: plat/mailbox.h: No such file or directory
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Tony Lindgren <tony@atomide.com>
> Cc: Ohad Ben-Cohen <ohad@wizery.com>
> ---
> drivers/remoteproc/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
> index 0b24108..cc1f7bf 100644
> --- a/drivers/remoteproc/Kconfig
> +++ b/drivers/remoteproc/Kconfig
> @@ -12,8 +12,8 @@ config OMAP_REMOTEPROC
> depends on HAS_DMA
> depends on ARCH_OMAP4
> depends on OMAP_IOMMU
> + depends on OMAP_MBOX_FWK
> select REMOTEPROC
> - select OMAP_MBOX_FWK
> select RPMSG
> help
> Say y here to support OMAP's remote processors (dual M3
> --
> 1.8.1.2
>
^ permalink raw reply [flat|nested] 70+ messages in thread
* [PATCH 7/9] remoteproc: omap: depend on OMAP_MBOX_FWK
@ 2013-02-14 22:55 ` Tony Lindgren
0 siblings, 0 replies; 70+ messages in thread
From: Tony Lindgren @ 2013-02-14 22:55 UTC (permalink / raw)
To: linux-arm-kernel
* Arnd Bergmann <arnd@arndb.de> [130214 14:51]:
> Patch a62a6e98 "ARM: OMAP2+: Disable code that currently does not work
> with multiplaform" makes the OMAP_MBOX_FWK option depend on !MULTIPLATFORM,
> which means we cannot simply select that symbol from OMAP_REMOTEPROC.
>
> Turning the 'select' into 'depends on' ensures that all dependencies
> are correct until OMAP_MBOX_FWK loses its dependency.
>
> Without this patch, building allmodconfig results in:
>
> drivers/remoteproc/omap_remoteproc.c:31:26: fatal error: plat/mailbox.h: No such file or directory
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Tony Lindgren <tony@atomide.com>
> Cc: Ohad Ben-Cohen <ohad@wizery.com>
> ---
> drivers/remoteproc/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
> index 0b24108..cc1f7bf 100644
> --- a/drivers/remoteproc/Kconfig
> +++ b/drivers/remoteproc/Kconfig
> @@ -12,8 +12,8 @@ config OMAP_REMOTEPROC
> depends on HAS_DMA
> depends on ARCH_OMAP4
> depends on OMAP_IOMMU
> + depends on OMAP_MBOX_FWK
> select REMOTEPROC
> - select OMAP_MBOX_FWK
> select RPMSG
> help
> Say y here to support OMAP's remote processors (dual M3
> --
> 1.8.1.2
>
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH 7/9] remoteproc: omap: depend on OMAP_MBOX_FWK
2013-02-14 22:55 ` Tony Lindgren
@ 2013-02-15 6:56 ` Ohad Ben-Cohen
-1 siblings, 0 replies; 70+ messages in thread
From: Ohad Ben-Cohen @ 2013-02-15 6:56 UTC (permalink / raw)
To: Tony Lindgren; +Cc: Arnd Bergmann, linux-arm, linux-kernel, arm
On Fri, Feb 15, 2013 at 12:55 AM, Tony Lindgren <tony@atomide.com> wrote:
> * Arnd Bergmann <arnd@arndb.de> [130214 14:51]:
>> Patch a62a6e98 "ARM: OMAP2+: Disable code that currently does not work
>> with multiplaform" makes the OMAP_MBOX_FWK option depend on !MULTIPLATFORM,
>> which means we cannot simply select that symbol from OMAP_REMOTEPROC.
>>
>> Turning the 'select' into 'depends on' ensures that all dependencies
>> are correct until OMAP_MBOX_FWK loses its dependency.
>>
>> Without this patch, building allmodconfig results in:
>>
>> drivers/remoteproc/omap_remoteproc.c:31:26: fatal error: plat/mailbox.h: No such file or directory
>>
>> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>
> Acked-by: Tony Lindgren <tony@atomide.com>
Acked-by: Ohad Ben-Cohen <ohad@wizery.com>
Feel free to take this via your tree - thanks.
^ permalink raw reply [flat|nested] 70+ messages in thread
* [PATCH 7/9] remoteproc: omap: depend on OMAP_MBOX_FWK
@ 2013-02-15 6:56 ` Ohad Ben-Cohen
0 siblings, 0 replies; 70+ messages in thread
From: Ohad Ben-Cohen @ 2013-02-15 6:56 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, Feb 15, 2013 at 12:55 AM, Tony Lindgren <tony@atomide.com> wrote:
> * Arnd Bergmann <arnd@arndb.de> [130214 14:51]:
>> Patch a62a6e98 "ARM: OMAP2+: Disable code that currently does not work
>> with multiplaform" makes the OMAP_MBOX_FWK option depend on !MULTIPLATFORM,
>> which means we cannot simply select that symbol from OMAP_REMOTEPROC.
>>
>> Turning the 'select' into 'depends on' ensures that all dependencies
>> are correct until OMAP_MBOX_FWK loses its dependency.
>>
>> Without this patch, building allmodconfig results in:
>>
>> drivers/remoteproc/omap_remoteproc.c:31:26: fatal error: plat/mailbox.h: No such file or directory
>>
>> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>
> Acked-by: Tony Lindgren <tony@atomide.com>
Acked-by: Ohad Ben-Cohen <ohad@wizery.com>
Feel free to take this via your tree - thanks.
^ permalink raw reply [flat|nested] 70+ messages in thread
* [PATCH 8/9] [HACK] ARM: imx: work around v7_cpu_resume link error
2013-02-14 22:47 ` Arnd Bergmann
@ 2013-02-14 22:47 ` Arnd Bergmann
-1 siblings, 0 replies; 70+ messages in thread
From: Arnd Bergmann @ 2013-02-14 22:47 UTC (permalink / raw)
To: linux-arm-kernel
Cc: linux-kernel, arm, Arnd Bergmann, Shawn Guo, Sascha Hauer,
Dinh Nguyen, Pavel Machek, Stephen Warren, Simon Horman
Patch c08e20d24 "arm: Add v7_invalidate_l1 to cache-v7.S"
moves the v7_invalidate_l1 symbol out of imx/headsmp.S,
which seems to cause a link error because it is now
too far away from v7_cpu_resume when building an
allyesconfig kernel.
If we move the v7_cpu_resume function from the .data
section to .text, that creates another link error
for the reference to phys_l2x0_saved_regs, but we
can move all of the above to .text.
I believe that this is not a correct bug fix but just
a bad workaround, so I'm open to ideas from people
who understand the bigger picture.
Without this patch, building allyesconfig results in:
arch/arm/mach-imx/built-in.o: In function `v7_cpu_resume':
arch/arm/mach-imx/headsmp.S:55:(.data+0x87f8): relocation truncated to fit: R_ARM_CALL against symbol `v7_invalidate_l1' defined in .text section in arch/arm/mm/built-in.o
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Shawn Guo <shawn.guo@linaro.org>
Cc: Sascha Hauer <s.hauer@pengutronix.de>
Cc: Dinh Nguyen <dinguyen@altera.com>
Cc: Pavel Machek <pavel@denx.de>
Cc: Stephen Warren <swarren@nvidia.com>
Cc: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm/mach-imx/headsmp.S | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-imx/headsmp.S b/arch/arm/mach-imx/headsmp.S
index 921fc15..0de76cc 100644
--- a/arch/arm/mach-imx/headsmp.S
+++ b/arch/arm/mach-imx/headsmp.S
@@ -30,7 +30,7 @@ ENDPROC(v7_secondary_startup)
* allow phys_l2x0_saved_regs to be accessed with a relative load
* as we are running on physical address here.
*/
- .data
+ .text
.align
#ifdef CONFIG_CACHE_L2X0
@@ -51,6 +51,8 @@ phys_l2x0_saved_regs:
.endm
#endif
+ .text
+
ENTRY(v7_cpu_resume)
bl v7_invalidate_l1
pl310_resume
--
1.8.1.2
^ permalink raw reply related [flat|nested] 70+ messages in thread
* [PATCH 8/9] [HACK] ARM: imx: work around v7_cpu_resume link error
@ 2013-02-14 22:47 ` Arnd Bergmann
0 siblings, 0 replies; 70+ messages in thread
From: Arnd Bergmann @ 2013-02-14 22:47 UTC (permalink / raw)
To: linux-arm-kernel
Patch c08e20d24 "arm: Add v7_invalidate_l1 to cache-v7.S"
moves the v7_invalidate_l1 symbol out of imx/headsmp.S,
which seems to cause a link error because it is now
too far away from v7_cpu_resume when building an
allyesconfig kernel.
If we move the v7_cpu_resume function from the .data
section to .text, that creates another link error
for the reference to phys_l2x0_saved_regs, but we
can move all of the above to .text.
I believe that this is not a correct bug fix but just
a bad workaround, so I'm open to ideas from people
who understand the bigger picture.
Without this patch, building allyesconfig results in:
arch/arm/mach-imx/built-in.o: In function `v7_cpu_resume':
arch/arm/mach-imx/headsmp.S:55:(.data+0x87f8): relocation truncated to fit: R_ARM_CALL against symbol `v7_invalidate_l1' defined in .text section in arch/arm/mm/built-in.o
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Shawn Guo <shawn.guo@linaro.org>
Cc: Sascha Hauer <s.hauer@pengutronix.de>
Cc: Dinh Nguyen <dinguyen@altera.com>
Cc: Pavel Machek <pavel@denx.de>
Cc: Stephen Warren <swarren@nvidia.com>
Cc: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm/mach-imx/headsmp.S | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-imx/headsmp.S b/arch/arm/mach-imx/headsmp.S
index 921fc15..0de76cc 100644
--- a/arch/arm/mach-imx/headsmp.S
+++ b/arch/arm/mach-imx/headsmp.S
@@ -30,7 +30,7 @@ ENDPROC(v7_secondary_startup)
* allow phys_l2x0_saved_regs to be accessed with a relative load
* as we are running on physical address here.
*/
- .data
+ .text
.align
#ifdef CONFIG_CACHE_L2X0
@@ -51,6 +51,8 @@ phys_l2x0_saved_regs:
.endm
#endif
+ .text
+
ENTRY(v7_cpu_resume)
bl v7_invalidate_l1
pl310_resume
--
1.8.1.2
^ permalink raw reply related [flat|nested] 70+ messages in thread
* Re: [PATCH 8/9] [HACK] ARM: imx: work around v7_cpu_resume link error
2013-02-14 22:47 ` Arnd Bergmann
@ 2013-02-14 23:45 ` Stephen Warren
-1 siblings, 0 replies; 70+ messages in thread
From: Stephen Warren @ 2013-02-14 23:45 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-arm-kernel, linux-kernel, arm, Shawn Guo, Sascha Hauer,
Dinh Nguyen, Pavel Machek, Stephen Warren, Simon Horman
On 02/14/2013 03:47 PM, Arnd Bergmann wrote:
> Patch c08e20d24 "arm: Add v7_invalidate_l1 to cache-v7.S"
> moves the v7_invalidate_l1 symbol out of imx/headsmp.S,
> which seems to cause a link error because it is now
> too far away from v7_cpu_resume when building an
> allyesconfig kernel.
Is the problem from the following in arch/arm/mach-imx/headsmp.S:
ENTRY(v7_cpu_resume)
bl v7_invalidate_l1
Isn't the range of bl +/- 32MiB (or +/- 16MibB in Thumb 2). Is the
kernel really that big? Sorry, I'm having trouble understanding what
causes the problem.
^ permalink raw reply [flat|nested] 70+ messages in thread
* [PATCH 8/9] [HACK] ARM: imx: work around v7_cpu_resume link error
@ 2013-02-14 23:45 ` Stephen Warren
0 siblings, 0 replies; 70+ messages in thread
From: Stephen Warren @ 2013-02-14 23:45 UTC (permalink / raw)
To: linux-arm-kernel
On 02/14/2013 03:47 PM, Arnd Bergmann wrote:
> Patch c08e20d24 "arm: Add v7_invalidate_l1 to cache-v7.S"
> moves the v7_invalidate_l1 symbol out of imx/headsmp.S,
> which seems to cause a link error because it is now
> too far away from v7_cpu_resume when building an
> allyesconfig kernel.
Is the problem from the following in arch/arm/mach-imx/headsmp.S:
ENTRY(v7_cpu_resume)
bl v7_invalidate_l1
Isn't the range of bl +/- 32MiB (or +/- 16MibB in Thumb 2). Is the
kernel really that big? Sorry, I'm having trouble understanding what
causes the problem.
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH 8/9] [HACK] ARM: imx: work around v7_cpu_resume link error
2013-02-14 23:45 ` Stephen Warren
@ 2013-02-15 11:05 ` Arnd Bergmann
-1 siblings, 0 replies; 70+ messages in thread
From: Arnd Bergmann @ 2013-02-15 11:05 UTC (permalink / raw)
To: Stephen Warren
Cc: linux-arm-kernel, linux-kernel, arm, Shawn Guo, Sascha Hauer,
Dinh Nguyen, Pavel Machek, Stephen Warren, Simon Horman
On Thursday 14 February 2013, Stephen Warren wrote:
> On 02/14/2013 03:47 PM, Arnd Bergmann wrote:
> > Patch c08e20d24 "arm: Add v7_invalidate_l1 to cache-v7.S"
> > moves the v7_invalidate_l1 symbol out of imx/headsmp.S,
> > which seems to cause a link error because it is now
> > too far away from v7_cpu_resume when building an
> > allyesconfig kernel.
>
> Is the problem from the following in arch/arm/mach-imx/headsmp.S:
>
> ENTRY(v7_cpu_resume)
> bl v7_invalidate_l1
>
> Isn't the range of bl +/- 32MiB (or +/- 16MibB in Thumb 2). Is the
> kernel really that big? Sorry, I'm having trouble understanding what
> causes the problem.
Well, it is an "allyesconfig" kernel, so things can get pretty big:
$ size obj-tmp/vmlinux -A
obj-tmp/vmlinux :
section size addr
.head.text 504 3221258240
.text 32707336 3221258752
.text.head 8 3253966088
.rodata 14028722 3253968896
__bug_table 127764 3267997624
.builtin_fw 684 3268125388
__ksymtab 53424 3268126072
__ksymtab_gpl 43560 3268179496
__kcrctab 26712 3268223056
__kcrctab_gpl 21780 3268249768
__ksymtab_strings 233706 3268271548
__param 33104 3268505256
__modver 4104 3268538360
__ex_table 4112 3268542464
.ARM.unwind_idx 967784 3268546576
.ARM.unwind_tab 1452168 3269514360
.notes 36 3270966528
.init.text 677840 3270967296
.exit.text 125672 3271645136
.init.arch.info 5396 3271770808
.init.tagtable 72 3271776204
.init.smpalt 928 3271776276
.init.pv_table 1704 3271777204
.init.data 678108 3271778912
.exit.data 119 3272457020
.data..percpu 1460032 3272458240
.data 3370068 3273924608
.tcm_start 940 3277294676
.bss 8007724 3277295616
.comment 43 0
.ARM.attributes 50 0
.debug_line 15780363 0
.debug_info 57192143 0
.debug_abbrev 5747374 0
.debug_aranges 299608 0
.debug_ranges 5414592 0
.debug_frame 4801748 0
.debug_str 7003282 0
.debug_loc 36237476 0
Total 196510790
THUMB2 support is obviously enabled (allyesconfig), and from the start of the
.head.text section to the end of .bss, it is 64,045,100 bytes, using yesterday's
linux-next kernel with my fixes. It will get bigger as we add more stuff
to multiplatform. The .text section alone is just short of 32MB.
Arnd
^ permalink raw reply [flat|nested] 70+ messages in thread
* [PATCH 8/9] [HACK] ARM: imx: work around v7_cpu_resume link error
@ 2013-02-15 11:05 ` Arnd Bergmann
0 siblings, 0 replies; 70+ messages in thread
From: Arnd Bergmann @ 2013-02-15 11:05 UTC (permalink / raw)
To: linux-arm-kernel
On Thursday 14 February 2013, Stephen Warren wrote:
> On 02/14/2013 03:47 PM, Arnd Bergmann wrote:
> > Patch c08e20d24 "arm: Add v7_invalidate_l1 to cache-v7.S"
> > moves the v7_invalidate_l1 symbol out of imx/headsmp.S,
> > which seems to cause a link error because it is now
> > too far away from v7_cpu_resume when building an
> > allyesconfig kernel.
>
> Is the problem from the following in arch/arm/mach-imx/headsmp.S:
>
> ENTRY(v7_cpu_resume)
> bl v7_invalidate_l1
>
> Isn't the range of bl +/- 32MiB (or +/- 16MibB in Thumb 2). Is the
> kernel really that big? Sorry, I'm having trouble understanding what
> causes the problem.
Well, it is an "allyesconfig" kernel, so things can get pretty big:
$ size obj-tmp/vmlinux -A
obj-tmp/vmlinux :
section size addr
.head.text 504 3221258240
.text 32707336 3221258752
.text.head 8 3253966088
.rodata 14028722 3253968896
__bug_table 127764 3267997624
.builtin_fw 684 3268125388
__ksymtab 53424 3268126072
__ksymtab_gpl 43560 3268179496
__kcrctab 26712 3268223056
__kcrctab_gpl 21780 3268249768
__ksymtab_strings 233706 3268271548
__param 33104 3268505256
__modver 4104 3268538360
__ex_table 4112 3268542464
.ARM.unwind_idx 967784 3268546576
.ARM.unwind_tab 1452168 3269514360
.notes 36 3270966528
.init.text 677840 3270967296
.exit.text 125672 3271645136
.init.arch.info 5396 3271770808
.init.tagtable 72 3271776204
.init.smpalt 928 3271776276
.init.pv_table 1704 3271777204
.init.data 678108 3271778912
.exit.data 119 3272457020
.data..percpu 1460032 3272458240
.data 3370068 3273924608
.tcm_start 940 3277294676
.bss 8007724 3277295616
.comment 43 0
.ARM.attributes 50 0
.debug_line 15780363 0
.debug_info 57192143 0
.debug_abbrev 5747374 0
.debug_aranges 299608 0
.debug_ranges 5414592 0
.debug_frame 4801748 0
.debug_str 7003282 0
.debug_loc 36237476 0
Total 196510790
THUMB2 support is obviously enabled (allyesconfig), and from the start of the
.head.text section to the end of .bss, it is 64,045,100 bytes, using yesterday's
linux-next kernel with my fixes. It will get bigger as we add more stuff
to multiplatform. The .text section alone is just short of 32MB.
Arnd
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH 8/9] [HACK] ARM: imx: work around v7_cpu_resume link error
2013-02-15 11:05 ` Arnd Bergmann
@ 2013-02-15 11:13 ` Russell King - ARM Linux
-1 siblings, 0 replies; 70+ messages in thread
From: Russell King - ARM Linux @ 2013-02-15 11:13 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Stephen Warren, linux-arm-kernel, linux-kernel, arm, Shawn Guo,
Sascha Hauer, Dinh Nguyen, Pavel Machek, Stephen Warren,
Simon Horman
On Fri, Feb 15, 2013 at 11:05:14AM +0000, Arnd Bergmann wrote:
> $ size obj-tmp/vmlinux -A
> obj-tmp/vmlinux :
> section size addr
> .head.text 504 3221258240
> .text 32707336 3221258752
> .text.head 8 3253966088
Interesting... I wonder if that should be .head.text, or maybe just .text.
Looking at iMX, it's just the secondary startup, which is calling into
.head.text, so it would be much safer given the size of the .text segment
for it to be in .head.text.
> The .text section alone is just short of 32MB.
I suspect when it does go over that, we'll see a lot more link time
failures due to the 'bl' instructions failing to encode their PC relative
jumps. The only solution then will be to switch everything to use the
less efficient long jumps (load address from literal pool, bx) which'll
also need much of the asm changed. That also brings up the question
whether we want to penalize the kernel performance just to make
allyesconfig work... I guess we can make it a compile time option, which
of course allyesconfig will automatically enable. I suspect we'll see
a lot of people mistakenly enabling it too though.
^ permalink raw reply [flat|nested] 70+ messages in thread
* [PATCH 8/9] [HACK] ARM: imx: work around v7_cpu_resume link error
@ 2013-02-15 11:13 ` Russell King - ARM Linux
0 siblings, 0 replies; 70+ messages in thread
From: Russell King - ARM Linux @ 2013-02-15 11:13 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, Feb 15, 2013 at 11:05:14AM +0000, Arnd Bergmann wrote:
> $ size obj-tmp/vmlinux -A
> obj-tmp/vmlinux :
> section size addr
> .head.text 504 3221258240
> .text 32707336 3221258752
> .text.head 8 3253966088
Interesting... I wonder if that should be .head.text, or maybe just .text.
Looking at iMX, it's just the secondary startup, which is calling into
.head.text, so it would be much safer given the size of the .text segment
for it to be in .head.text.
> The .text section alone is just short of 32MB.
I suspect when it does go over that, we'll see a lot more link time
failures due to the 'bl' instructions failing to encode their PC relative
jumps. The only solution then will be to switch everything to use the
less efficient long jumps (load address from literal pool, bx) which'll
also need much of the asm changed. That also brings up the question
whether we want to penalize the kernel performance just to make
allyesconfig work... I guess we can make it a compile time option, which
of course allyesconfig will automatically enable. I suspect we'll see
a lot of people mistakenly enabling it too though.
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH 8/9] [HACK] ARM: imx: work around v7_cpu_resume link error
2013-02-15 11:13 ` Russell King - ARM Linux
@ 2013-02-15 15:49 ` Arnd Bergmann
-1 siblings, 0 replies; 70+ messages in thread
From: Arnd Bergmann @ 2013-02-15 15:49 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Stephen Warren, linux-arm-kernel, linux-kernel, arm, Shawn Guo,
Sascha Hauer, Dinh Nguyen, Pavel Machek, Stephen Warren,
Simon Horman
On Friday 15 February 2013, Russell King - ARM Linux wrote:
> > The .text section alone is just short of 32MB.
>
> I suspect when it does go over that, we'll see a lot more link time
> failures due to the 'bl' instructions failing to encode their PC relative
> jumps. The only solution then will be to switch everything to use the
> less efficient long jumps (load address from literal pool, bx) which'll
> also need much of the asm changed. That also brings up the question
> whether we want to penalize the kernel performance just to make
> allyesconfig work... I guess we can make it a compile time option, which
> of course allyesconfig will automatically enable. I suspect we'll see
> a lot of people mistakenly enabling it too though.
I'm not too worried about people accidentally enabling such a build option,
at least if it's appropriately labeled as something that nobody should
need.
Changing the inline assembly however sounds like a big pain to do, which
would cause performance and size overhead as well as regressions in
rarely executed code when we get it wrong. I've tried rebulding
the allyesconfig kernel with -O3 -funroll-all-loops to make it even
bigger on purpose, and got these errors:
arch/arm/kernel/built-in.o:(.fixup+0x8): relocation truncated to fit: R_ARM_JUMP24 against `.text'
arch/arm/kernel/built-in.o:(.fixup+0x10): relocation truncated to fit: R_ARM_JUMP24 against `.text'
arch/arm/kernel/built-in.o:(.fixup+0x18): relocation truncated to fit: R_ARM_JUMP24 against `.text'
arch/arm/kernel/built-in.o:(.fixup+0x20): relocation truncated to fit: R_ARM_JUMP24 against `.text'
arch/arm/kernel/built-in.o:(.fixup+0x28): relocation truncated to fit: R_ARM_JUMP24 against `.text'
arch/arm/kernel/built-in.o:(.fixup+0x30): relocation truncated to fit: R_ARM_JUMP24 against `.text'
arch/arm/kernel/built-in.o:(.fixup+0x38): relocation truncated to fit: R_ARM_JUMP24 against `.text'
arch/arm/kernel/built-in.o:(.fixup+0x40): relocation truncated to fit: R_ARM_JUMP24 against `.text'
arch/arm/kernel/built-in.o:(.fixup+0x48): relocation truncated to fit: R_ARM_JUMP24 against `.text'
arch/arm/kernel/built-in.o:(.fixup+0x50): relocation truncated to fit: R_ARM_JUMP24 against `.text'
arch/arm/kernel/built-in.o:(.fixup+0x58): additional relocation overflows omitted from the output
so the .fixup section is completely out of reach of the start of the .text section.
The size output for the partial link of vmlinux.o is
section size addr
.head.text 492 3221258240
.text 43889568 3221258752
.text.head 8 0
.rodata 11020608 4096
__bug_table 138636 11024704
.pci_fixup 0 11163340
.builtin_fw 684 11163340
.rio_ops 0 11164024
__ksymtab 53424 11164024
__ksymtab_gpl 43560 11217448
__ksymtab_unused 0 11261008
__ksymtab_unused_gpl 0 11261008
__ksymtab_gpl_future 0 11261008
__kcrctab 26712 11261008
__kcrctab_gpl 21780 11287720
__kcrctab_unused 0 11309500
__kcrctab_unused_gpl 0 11309500
__kcrctab_gpl_future 0 11309500
__ksymtab_strings 251888 11309500
__param 33104 11561388
__modver 1284 11594492
__ex_table 6288 11595776
.ARM.unwind_idx 907888 11602064
.ARM.unwind_tab 1362276 12509952
.notes 36 13872228
.init.text 685436 13873152
.exit.text 124324 14558588
.init.arch.info 5396 14682912
.init.tagtable 72 14688308
.init.smpalt 952 14688380
.init.pv_table 2232 14689332
.init.data 649164 14691568
.exit.data 120 15340732
.data..percpu 1460032 15343616
.data 3370676 16809984
.tcm_start 332 20180660
.text_itcm 0 4294836224
.dtcm_start 0 20180992
.data_dtcm 0 4294868992
.tcm_end 0 20180992
.bss 8007852 20180992
.comment 314424 0
.ARM.attributes 50 0
.debug_line 19185565 0
.debug_info 61757649 0
.debug_abbrev 5835457 0
.debug_aranges 299416 0
.debug_ranges 10482064 0
.debug_frame 4601768 0
.debug_str 37433732 0
.debug_loc 45578206 0
Total 257553155
I had the idea that turning off THUMB2 support in allyesconfig would help,
but then I found that it's already disabled unlike what I claimed earlier,
because ARMv6 support is enabled alongside ARMv7, so we are still screwed.
Also, with the size of the kernel binary growing, it may just be a
matter of time until this is not just a problem for artificial cases
like allyesconfig, but also for something that users will actually
want to run.
IIRC, 10 years ago, half a megabyte seemed like a reasonable size
for a kernel binary, while today 5 megabyte are not out of the
ordinary on ARM. If the trend continues the same way, we might
have users complaining about 32 megabyte kernels in 5-7 years from
now, unless everybody is using 64-bit by then ;-)
Arnd
^ permalink raw reply [flat|nested] 70+ messages in thread
* [PATCH 8/9] [HACK] ARM: imx: work around v7_cpu_resume link error
@ 2013-02-15 15:49 ` Arnd Bergmann
0 siblings, 0 replies; 70+ messages in thread
From: Arnd Bergmann @ 2013-02-15 15:49 UTC (permalink / raw)
To: linux-arm-kernel
On Friday 15 February 2013, Russell King - ARM Linux wrote:
> > The .text section alone is just short of 32MB.
>
> I suspect when it does go over that, we'll see a lot more link time
> failures due to the 'bl' instructions failing to encode their PC relative
> jumps. The only solution then will be to switch everything to use the
> less efficient long jumps (load address from literal pool, bx) which'll
> also need much of the asm changed. That also brings up the question
> whether we want to penalize the kernel performance just to make
> allyesconfig work... I guess we can make it a compile time option, which
> of course allyesconfig will automatically enable. I suspect we'll see
> a lot of people mistakenly enabling it too though.
I'm not too worried about people accidentally enabling such a build option,
at least if it's appropriately labeled as something that nobody should
need.
Changing the inline assembly however sounds like a big pain to do, which
would cause performance and size overhead as well as regressions in
rarely executed code when we get it wrong. I've tried rebulding
the allyesconfig kernel with -O3 -funroll-all-loops to make it even
bigger on purpose, and got these errors:
arch/arm/kernel/built-in.o:(.fixup+0x8): relocation truncated to fit: R_ARM_JUMP24 against `.text'
arch/arm/kernel/built-in.o:(.fixup+0x10): relocation truncated to fit: R_ARM_JUMP24 against `.text'
arch/arm/kernel/built-in.o:(.fixup+0x18): relocation truncated to fit: R_ARM_JUMP24 against `.text'
arch/arm/kernel/built-in.o:(.fixup+0x20): relocation truncated to fit: R_ARM_JUMP24 against `.text'
arch/arm/kernel/built-in.o:(.fixup+0x28): relocation truncated to fit: R_ARM_JUMP24 against `.text'
arch/arm/kernel/built-in.o:(.fixup+0x30): relocation truncated to fit: R_ARM_JUMP24 against `.text'
arch/arm/kernel/built-in.o:(.fixup+0x38): relocation truncated to fit: R_ARM_JUMP24 against `.text'
arch/arm/kernel/built-in.o:(.fixup+0x40): relocation truncated to fit: R_ARM_JUMP24 against `.text'
arch/arm/kernel/built-in.o:(.fixup+0x48): relocation truncated to fit: R_ARM_JUMP24 against `.text'
arch/arm/kernel/built-in.o:(.fixup+0x50): relocation truncated to fit: R_ARM_JUMP24 against `.text'
arch/arm/kernel/built-in.o:(.fixup+0x58): additional relocation overflows omitted from the output
so the .fixup section is completely out of reach of the start of the .text section.
The size output for the partial link of vmlinux.o is
section size addr
.head.text 492 3221258240
.text 43889568 3221258752
.text.head 8 0
.rodata 11020608 4096
__bug_table 138636 11024704
.pci_fixup 0 11163340
.builtin_fw 684 11163340
.rio_ops 0 11164024
__ksymtab 53424 11164024
__ksymtab_gpl 43560 11217448
__ksymtab_unused 0 11261008
__ksymtab_unused_gpl 0 11261008
__ksymtab_gpl_future 0 11261008
__kcrctab 26712 11261008
__kcrctab_gpl 21780 11287720
__kcrctab_unused 0 11309500
__kcrctab_unused_gpl 0 11309500
__kcrctab_gpl_future 0 11309500
__ksymtab_strings 251888 11309500
__param 33104 11561388
__modver 1284 11594492
__ex_table 6288 11595776
.ARM.unwind_idx 907888 11602064
.ARM.unwind_tab 1362276 12509952
.notes 36 13872228
.init.text 685436 13873152
.exit.text 124324 14558588
.init.arch.info 5396 14682912
.init.tagtable 72 14688308
.init.smpalt 952 14688380
.init.pv_table 2232 14689332
.init.data 649164 14691568
.exit.data 120 15340732
.data..percpu 1460032 15343616
.data 3370676 16809984
.tcm_start 332 20180660
.text_itcm 0 4294836224
.dtcm_start 0 20180992
.data_dtcm 0 4294868992
.tcm_end 0 20180992
.bss 8007852 20180992
.comment 314424 0
.ARM.attributes 50 0
.debug_line 19185565 0
.debug_info 61757649 0
.debug_abbrev 5835457 0
.debug_aranges 299416 0
.debug_ranges 10482064 0
.debug_frame 4601768 0
.debug_str 37433732 0
.debug_loc 45578206 0
Total 257553155
I had the idea that turning off THUMB2 support in allyesconfig would help,
but then I found that it's already disabled unlike what I claimed earlier,
because ARMv6 support is enabled alongside ARMv7, so we are still screwed.
Also, with the size of the kernel binary growing, it may just be a
matter of time until this is not just a problem for artificial cases
like allyesconfig, but also for something that users will actually
want to run.
IIRC, 10 years ago, half a megabyte seemed like a reasonable size
for a kernel binary, while today 5 megabyte are not out of the
ordinary on ARM. If the trend continues the same way, we might
have users complaining about 32 megabyte kernels in 5-7 years from
now, unless everybody is using 64-bit by then ;-)
Arnd
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH 8/9] [HACK] ARM: imx: work around v7_cpu_resume link error
2013-02-14 22:47 ` Arnd Bergmann
@ 2013-02-15 11:07 ` Russell King - ARM Linux
-1 siblings, 0 replies; 70+ messages in thread
From: Russell King - ARM Linux @ 2013-02-15 11:07 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-arm-kernel, Stephen Warren, Pavel Machek, Sascha Hauer,
linux-kernel, arm, Simon Horman, Shawn Guo, Dinh Nguyen
On Thu, Feb 14, 2013 at 11:47:50PM +0100, Arnd Bergmann wrote:
> Patch c08e20d24 "arm: Add v7_invalidate_l1 to cache-v7.S"
> moves the v7_invalidate_l1 symbol out of imx/headsmp.S,
> which seems to cause a link error because it is now
> too far away from v7_cpu_resume when building an
> allyesconfig kernel.
>
> If we move the v7_cpu_resume function from the .data
> section to .text, that creates another link error
> for the reference to phys_l2x0_saved_regs, but we
> can move all of the above to .text.
>
> I believe that this is not a correct bug fix but just
> a bad workaround, so I'm open to ideas from people
> who understand the bigger picture.
Unfortunately, this ends up with writable data in the .text section, which
is supposed to be read-only. We should try to preserve that status, even
though we don't enforce it.
I guess the problem is that we end up with the .data segment soo far away
from the .text segment that these branches no longer work (and remember
that this code executes with the MMU off.)
The only solution I can think is that we need to do quite a bit of magic
here to jump to an absolute address, but taking account of the V:P offset.
That's not going to be particularly nice, and it's going to then also have
to jump back the other way - to the cpu_resume code which is also in the
.data section.
^ permalink raw reply [flat|nested] 70+ messages in thread
* [PATCH 8/9] [HACK] ARM: imx: work around v7_cpu_resume link error
@ 2013-02-15 11:07 ` Russell King - ARM Linux
0 siblings, 0 replies; 70+ messages in thread
From: Russell King - ARM Linux @ 2013-02-15 11:07 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Feb 14, 2013 at 11:47:50PM +0100, Arnd Bergmann wrote:
> Patch c08e20d24 "arm: Add v7_invalidate_l1 to cache-v7.S"
> moves the v7_invalidate_l1 symbol out of imx/headsmp.S,
> which seems to cause a link error because it is now
> too far away from v7_cpu_resume when building an
> allyesconfig kernel.
>
> If we move the v7_cpu_resume function from the .data
> section to .text, that creates another link error
> for the reference to phys_l2x0_saved_regs, but we
> can move all of the above to .text.
>
> I believe that this is not a correct bug fix but just
> a bad workaround, so I'm open to ideas from people
> who understand the bigger picture.
Unfortunately, this ends up with writable data in the .text section, which
is supposed to be read-only. We should try to preserve that status, even
though we don't enforce it.
I guess the problem is that we end up with the .data segment soo far away
from the .text segment that these branches no longer work (and remember
that this code executes with the MMU off.)
The only solution I can think is that we need to do quite a bit of magic
here to jump to an absolute address, but taking account of the V:P offset.
That's not going to be particularly nice, and it's going to then also have
to jump back the other way - to the cpu_resume code which is also in the
.data section.
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH 8/9] [HACK] ARM: imx: work around v7_cpu_resume link error
2013-02-15 11:07 ` Russell King - ARM Linux
@ 2013-02-16 5:14 ` Nicolas Pitre
-1 siblings, 0 replies; 70+ messages in thread
From: Nicolas Pitre @ 2013-02-16 5:14 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Arnd Bergmann, linux-arm-kernel, Stephen Warren, Pavel Machek,
Sascha Hauer, linux-kernel, arm, Simon Horman, Shawn Guo,
Dinh Nguyen
On Fri, 15 Feb 2013, Russell King - ARM Linux wrote:
> On Thu, Feb 14, 2013 at 11:47:50PM +0100, Arnd Bergmann wrote:
> > Patch c08e20d24 "arm: Add v7_invalidate_l1 to cache-v7.S"
> > moves the v7_invalidate_l1 symbol out of imx/headsmp.S,
> > which seems to cause a link error because it is now
> > too far away from v7_cpu_resume when building an
> > allyesconfig kernel.
> >
> > If we move the v7_cpu_resume function from the .data
> > section to .text, that creates another link error
> > for the reference to phys_l2x0_saved_regs, but we
> > can move all of the above to .text.
> >
> > I believe that this is not a correct bug fix but just
> > a bad workaround, so I'm open to ideas from people
> > who understand the bigger picture.
>
> Unfortunately, this ends up with writable data in the .text section, which
> is supposed to be read-only. We should try to preserve that status, even
> though we don't enforce it.
>
> I guess the problem is that we end up with the .data segment soo far away
> from the .text segment that these branches no longer work (and remember
> that this code executes with the MMU off.)
>
> The only solution I can think is that we need to do quite a bit of magic
> here to jump to an absolute address, but taking account of the V:P offset.
> That's not going to be particularly nice, and it's going to then also have
> to jump back the other way - to the cpu_resume code which is also in the
> .data section.
Something like this should work:
diff --git a/arch/arm/mach-imx/headsmp.S b/arch/arm/mach-imx/headsmp.S
index 7e49deb128..9de26f3edb 100644
--- a/arch/arm/mach-imx/headsmp.S
+++ b/arch/arm/mach-imx/headsmp.S
@@ -99,8 +99,11 @@ phys_l2x0_saved_regs:
#endif
ENTRY(v7_cpu_resume)
- bl v7_invalidate_l1
+ ldr ip, 2f
+ mov lr, pc
+1: add pc, pc, ip
pl310_resume
b cpu_resume
+2: .word v7_invalidate_l1 - 1b - 8
ENDPROC(v7_cpu_resume)
#endif
However it is probably best to move all the code to the .text section
where it belongs and fixup the data access instead. I must plead guilty
for introducing this idea of putting code in the .data section with the
SA1100resume code over 10 years ago that everyone copied since.
So here's how I think it should look instead, and how I should have done
the SA1100 code back then:
diff --git a/arch/arm/mach-imx/headsmp.S b/arch/arm/mach-imx/headsmp.S
index 7e49deb128..38a544a037 100644
--- a/arch/arm/mach-imx/headsmp.S
+++ b/arch/arm/mach-imx/headsmp.S
@@ -73,16 +73,16 @@ ENDPROC(v7_secondary_startup)
#ifdef CONFIG_PM
/*
- * The following code is located into the .data section. This is to
- * allow phys_l2x0_saved_regs to be accessed with a relative load
- * as we are running on physical address here.
+ * The following code must assume it is running from physical address
+ * where absolute virtual addresses to the data section have to be
+ * turned into relative ones.
*/
- .data
- .align
#ifdef CONFIG_CACHE_L2X0
.macro pl310_resume
- ldr r2, phys_l2x0_saved_regs
+ adr r0, phys_l2x0_saved_ptr_offset
+ ldr r2, [r0]
+ add r2, r2, r0
ldr r0, [r2, #L2X0_R_PHY_BASE] @ get physical base of l2x0
ldr r1, [r2, #L2X0_R_AUX_CTRL] @ get aux_ctrl value
str r1, [r0, #L2X0_AUX_CTRL] @ restore aux_ctrl
@@ -90,9 +90,13 @@ ENDPROC(v7_secondary_startup)
str r1, [r0, #L2X0_CTRL] @ re-enable L2
.endm
+ .bss
.globl phys_l2x0_saved_regs
phys_l2x0_saved_regs:
- .long 0
+ .space 4
+ .previous
+phys_l2x0_saved_ptr_offset:
+ .word phys_l2x0_saved_regs - .
#else
.macro pl310_resume
.endm
And yet we could dispense with phys_l2x0_saved_regs
altogether and use l2x0_saved_regs directly here instead.
That doesn't solve the issue of the kernel becoming too large for branch
displacement fixup though.
Nicolas
^ permalink raw reply related [flat|nested] 70+ messages in thread
* [PATCH 8/9] [HACK] ARM: imx: work around v7_cpu_resume link error
@ 2013-02-16 5:14 ` Nicolas Pitre
0 siblings, 0 replies; 70+ messages in thread
From: Nicolas Pitre @ 2013-02-16 5:14 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, 15 Feb 2013, Russell King - ARM Linux wrote:
> On Thu, Feb 14, 2013 at 11:47:50PM +0100, Arnd Bergmann wrote:
> > Patch c08e20d24 "arm: Add v7_invalidate_l1 to cache-v7.S"
> > moves the v7_invalidate_l1 symbol out of imx/headsmp.S,
> > which seems to cause a link error because it is now
> > too far away from v7_cpu_resume when building an
> > allyesconfig kernel.
> >
> > If we move the v7_cpu_resume function from the .data
> > section to .text, that creates another link error
> > for the reference to phys_l2x0_saved_regs, but we
> > can move all of the above to .text.
> >
> > I believe that this is not a correct bug fix but just
> > a bad workaround, so I'm open to ideas from people
> > who understand the bigger picture.
>
> Unfortunately, this ends up with writable data in the .text section, which
> is supposed to be read-only. We should try to preserve that status, even
> though we don't enforce it.
>
> I guess the problem is that we end up with the .data segment soo far away
> from the .text segment that these branches no longer work (and remember
> that this code executes with the MMU off.)
>
> The only solution I can think is that we need to do quite a bit of magic
> here to jump to an absolute address, but taking account of the V:P offset.
> That's not going to be particularly nice, and it's going to then also have
> to jump back the other way - to the cpu_resume code which is also in the
> .data section.
Something like this should work:
diff --git a/arch/arm/mach-imx/headsmp.S b/arch/arm/mach-imx/headsmp.S
index 7e49deb128..9de26f3edb 100644
--- a/arch/arm/mach-imx/headsmp.S
+++ b/arch/arm/mach-imx/headsmp.S
@@ -99,8 +99,11 @@ phys_l2x0_saved_regs:
#endif
ENTRY(v7_cpu_resume)
- bl v7_invalidate_l1
+ ldr ip, 2f
+ mov lr, pc
+1: add pc, pc, ip
pl310_resume
b cpu_resume
+2: .word v7_invalidate_l1 - 1b - 8
ENDPROC(v7_cpu_resume)
#endif
However it is probably best to move all the code to the .text section
where it belongs and fixup the data access instead. I must plead guilty
for introducing this idea of putting code in the .data section with the
SA1100resume code over 10 years ago that everyone copied since.
So here's how I think it should look instead, and how I should have done
the SA1100 code back then:
diff --git a/arch/arm/mach-imx/headsmp.S b/arch/arm/mach-imx/headsmp.S
index 7e49deb128..38a544a037 100644
--- a/arch/arm/mach-imx/headsmp.S
+++ b/arch/arm/mach-imx/headsmp.S
@@ -73,16 +73,16 @@ ENDPROC(v7_secondary_startup)
#ifdef CONFIG_PM
/*
- * The following code is located into the .data section. This is to
- * allow phys_l2x0_saved_regs to be accessed with a relative load
- * as we are running on physical address here.
+ * The following code must assume it is running from physical address
+ * where absolute virtual addresses to the data section have to be
+ * turned into relative ones.
*/
- .data
- .align
#ifdef CONFIG_CACHE_L2X0
.macro pl310_resume
- ldr r2, phys_l2x0_saved_regs
+ adr r0, phys_l2x0_saved_ptr_offset
+ ldr r2, [r0]
+ add r2, r2, r0
ldr r0, [r2, #L2X0_R_PHY_BASE] @ get physical base of l2x0
ldr r1, [r2, #L2X0_R_AUX_CTRL] @ get aux_ctrl value
str r1, [r0, #L2X0_AUX_CTRL] @ restore aux_ctrl
@@ -90,9 +90,13 @@ ENDPROC(v7_secondary_startup)
str r1, [r0, #L2X0_CTRL] @ re-enable L2
.endm
+ .bss
.globl phys_l2x0_saved_regs
phys_l2x0_saved_regs:
- .long 0
+ .space 4
+ .previous
+phys_l2x0_saved_ptr_offset:
+ .word phys_l2x0_saved_regs - .
#else
.macro pl310_resume
.endm
And yet we could dispense with phys_l2x0_saved_regs
altogether and use l2x0_saved_regs directly here instead.
That doesn't solve the issue of the kernel becoming too large for branch
displacement fixup though.
Nicolas
^ permalink raw reply related [flat|nested] 70+ messages in thread
* Re: [PATCH 8/9] [HACK] ARM: imx: work around v7_cpu_resume link error
2013-02-16 5:14 ` Nicolas Pitre
@ 2013-02-18 5:55 ` Shawn Guo
-1 siblings, 0 replies; 70+ messages in thread
From: Shawn Guo @ 2013-02-18 5:55 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Russell King - ARM Linux, Arnd Bergmann, linux-arm-kernel,
Stephen Warren, Pavel Machek, Sascha Hauer, linux-kernel, arm,
Simon Horman, Dinh Nguyen
On Sat, Feb 16, 2013 at 12:14:49AM -0500, Nicolas Pitre wrote:
> On Fri, 15 Feb 2013, Russell King - ARM Linux wrote:
>
> > On Thu, Feb 14, 2013 at 11:47:50PM +0100, Arnd Bergmann wrote:
> > > Patch c08e20d24 "arm: Add v7_invalidate_l1 to cache-v7.S"
> > > moves the v7_invalidate_l1 symbol out of imx/headsmp.S,
> > > which seems to cause a link error because it is now
> > > too far away from v7_cpu_resume when building an
> > > allyesconfig kernel.
> > >
> > > If we move the v7_cpu_resume function from the .data
> > > section to .text, that creates another link error
> > > for the reference to phys_l2x0_saved_regs, but we
> > > can move all of the above to .text.
> > >
> > > I believe that this is not a correct bug fix but just
> > > a bad workaround, so I'm open to ideas from people
> > > who understand the bigger picture.
> >
> > Unfortunately, this ends up with writable data in the .text section, which
> > is supposed to be read-only. We should try to preserve that status, even
> > though we don't enforce it.
> >
> > I guess the problem is that we end up with the .data segment soo far away
> > from the .text segment that these branches no longer work (and remember
> > that this code executes with the MMU off.)
> >
> > The only solution I can think is that we need to do quite a bit of magic
> > here to jump to an absolute address, but taking account of the V:P offset.
> > That's not going to be particularly nice, and it's going to then also have
> > to jump back the other way - to the cpu_resume code which is also in the
> > .data section.
>
> Something like this should work:
>
> diff --git a/arch/arm/mach-imx/headsmp.S b/arch/arm/mach-imx/headsmp.S
> index 7e49deb128..9de26f3edb 100644
> --- a/arch/arm/mach-imx/headsmp.S
> +++ b/arch/arm/mach-imx/headsmp.S
> @@ -99,8 +99,11 @@ phys_l2x0_saved_regs:
> #endif
>
> ENTRY(v7_cpu_resume)
> - bl v7_invalidate_l1
> + ldr ip, 2f
> + mov lr, pc
> +1: add pc, pc, ip
> pl310_resume
> b cpu_resume
> +2: .word v7_invalidate_l1 - 1b - 8
> ENDPROC(v7_cpu_resume)
> #endif
>
Yes, it works.
>
> However it is probably best to move all the code to the .text section
> where it belongs and fixup the data access instead. I must plead guilty
> for introducing this idea of putting code in the .data section with the
> SA1100resume code over 10 years ago that everyone copied since.
>
> So here's how I think it should look instead, and how I should have done
> the SA1100 code back then:
>
> diff --git a/arch/arm/mach-imx/headsmp.S b/arch/arm/mach-imx/headsmp.S
> index 7e49deb128..38a544a037 100644
> --- a/arch/arm/mach-imx/headsmp.S
> +++ b/arch/arm/mach-imx/headsmp.S
> @@ -73,16 +73,16 @@ ENDPROC(v7_secondary_startup)
>
> #ifdef CONFIG_PM
> /*
> - * The following code is located into the .data section. This is to
> - * allow phys_l2x0_saved_regs to be accessed with a relative load
> - * as we are running on physical address here.
> + * The following code must assume it is running from physical address
> + * where absolute virtual addresses to the data section have to be
> + * turned into relative ones.
> */
> - .data
> - .align
>
> #ifdef CONFIG_CACHE_L2X0
> .macro pl310_resume
> - ldr r2, phys_l2x0_saved_regs
> + adr r0, phys_l2x0_saved_ptr_offset
> + ldr r2, [r0]
> + add r2, r2, r0
> ldr r0, [r2, #L2X0_R_PHY_BASE] @ get physical base of l2x0
> ldr r1, [r2, #L2X0_R_AUX_CTRL] @ get aux_ctrl value
> str r1, [r0, #L2X0_AUX_CTRL] @ restore aux_ctrl
> @@ -90,9 +90,13 @@ ENDPROC(v7_secondary_startup)
> str r1, [r0, #L2X0_CTRL] @ re-enable L2
> .endm
>
> + .bss
> .globl phys_l2x0_saved_regs
> phys_l2x0_saved_regs:
> - .long 0
> + .space 4
> + .previous
> +phys_l2x0_saved_ptr_offset:
> + .word phys_l2x0_saved_regs - .
> #else
> .macro pl310_resume
> .endm
>
But this does not work. It seems the execution jumps to the start of
kernel on system resuming.
Shawn
root@freescale ~$ ./rtcwakeup.sh
rtcwakeup.out: wakeup from "mem" using rtc0 at Fri Jan 2 00:09:43 1970
PM: Syncing filesystems ... done.
PM: Preparing system for mem sleep
mmc0: card a8a5 removed
mmc1: card b368 removed
Freezing user space processes ... (elapsed 0.01 seconds) done.
Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done.
PM: Entering mem sleep
fec_stop : Graceful transmit stop did not complete !
PM: suspend of devices complete after 8.361 msecs
PM: suspend devices took 0.010 seconds
PM: late suspend of devices complete after 0.267 msecs
PM: noirq suspend of devices complete after 0.754 msecs
Disabling non-boot CPUs ...
CPU1: shutdown
CPU2: shutdown
CPU3: shutdown
Booting Linux on physical CPU 0x0
Linux version 3.8.0-rc7-next-20130215+ (r65073@S2101-09) (gcc version
4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) ) #341 SMP Mon Feb 18 13:36:48 CST
2013
CPU: ARMv7 Processor [412fc09a] revision 10 (ARMv7), cr=10c53c7d
CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
Machine: Freescale i.MX6 Quad (Device Tree), model: Freescale i.MX6 Quad
SABRE Lite Board
Memory policy: ECC disabled, Data cache writealloc
^ permalink raw reply [flat|nested] 70+ messages in thread
* [PATCH 8/9] [HACK] ARM: imx: work around v7_cpu_resume link error
@ 2013-02-18 5:55 ` Shawn Guo
0 siblings, 0 replies; 70+ messages in thread
From: Shawn Guo @ 2013-02-18 5:55 UTC (permalink / raw)
To: linux-arm-kernel
On Sat, Feb 16, 2013 at 12:14:49AM -0500, Nicolas Pitre wrote:
> On Fri, 15 Feb 2013, Russell King - ARM Linux wrote:
>
> > On Thu, Feb 14, 2013 at 11:47:50PM +0100, Arnd Bergmann wrote:
> > > Patch c08e20d24 "arm: Add v7_invalidate_l1 to cache-v7.S"
> > > moves the v7_invalidate_l1 symbol out of imx/headsmp.S,
> > > which seems to cause a link error because it is now
> > > too far away from v7_cpu_resume when building an
> > > allyesconfig kernel.
> > >
> > > If we move the v7_cpu_resume function from the .data
> > > section to .text, that creates another link error
> > > for the reference to phys_l2x0_saved_regs, but we
> > > can move all of the above to .text.
> > >
> > > I believe that this is not a correct bug fix but just
> > > a bad workaround, so I'm open to ideas from people
> > > who understand the bigger picture.
> >
> > Unfortunately, this ends up with writable data in the .text section, which
> > is supposed to be read-only. We should try to preserve that status, even
> > though we don't enforce it.
> >
> > I guess the problem is that we end up with the .data segment soo far away
> > from the .text segment that these branches no longer work (and remember
> > that this code executes with the MMU off.)
> >
> > The only solution I can think is that we need to do quite a bit of magic
> > here to jump to an absolute address, but taking account of the V:P offset.
> > That's not going to be particularly nice, and it's going to then also have
> > to jump back the other way - to the cpu_resume code which is also in the
> > .data section.
>
> Something like this should work:
>
> diff --git a/arch/arm/mach-imx/headsmp.S b/arch/arm/mach-imx/headsmp.S
> index 7e49deb128..9de26f3edb 100644
> --- a/arch/arm/mach-imx/headsmp.S
> +++ b/arch/arm/mach-imx/headsmp.S
> @@ -99,8 +99,11 @@ phys_l2x0_saved_regs:
> #endif
>
> ENTRY(v7_cpu_resume)
> - bl v7_invalidate_l1
> + ldr ip, 2f
> + mov lr, pc
> +1: add pc, pc, ip
> pl310_resume
> b cpu_resume
> +2: .word v7_invalidate_l1 - 1b - 8
> ENDPROC(v7_cpu_resume)
> #endif
>
Yes, it works.
>
> However it is probably best to move all the code to the .text section
> where it belongs and fixup the data access instead. I must plead guilty
> for introducing this idea of putting code in the .data section with the
> SA1100resume code over 10 years ago that everyone copied since.
>
> So here's how I think it should look instead, and how I should have done
> the SA1100 code back then:
>
> diff --git a/arch/arm/mach-imx/headsmp.S b/arch/arm/mach-imx/headsmp.S
> index 7e49deb128..38a544a037 100644
> --- a/arch/arm/mach-imx/headsmp.S
> +++ b/arch/arm/mach-imx/headsmp.S
> @@ -73,16 +73,16 @@ ENDPROC(v7_secondary_startup)
>
> #ifdef CONFIG_PM
> /*
> - * The following code is located into the .data section. This is to
> - * allow phys_l2x0_saved_regs to be accessed with a relative load
> - * as we are running on physical address here.
> + * The following code must assume it is running from physical address
> + * where absolute virtual addresses to the data section have to be
> + * turned into relative ones.
> */
> - .data
> - .align
>
> #ifdef CONFIG_CACHE_L2X0
> .macro pl310_resume
> - ldr r2, phys_l2x0_saved_regs
> + adr r0, phys_l2x0_saved_ptr_offset
> + ldr r2, [r0]
> + add r2, r2, r0
> ldr r0, [r2, #L2X0_R_PHY_BASE] @ get physical base of l2x0
> ldr r1, [r2, #L2X0_R_AUX_CTRL] @ get aux_ctrl value
> str r1, [r0, #L2X0_AUX_CTRL] @ restore aux_ctrl
> @@ -90,9 +90,13 @@ ENDPROC(v7_secondary_startup)
> str r1, [r0, #L2X0_CTRL] @ re-enable L2
> .endm
>
> + .bss
> .globl phys_l2x0_saved_regs
> phys_l2x0_saved_regs:
> - .long 0
> + .space 4
> + .previous
> +phys_l2x0_saved_ptr_offset:
> + .word phys_l2x0_saved_regs - .
> #else
> .macro pl310_resume
> .endm
>
But this does not work. It seems the execution jumps to the start of
kernel on system resuming.
Shawn
root at freescale ~$ ./rtcwakeup.sh
rtcwakeup.out: wakeup from "mem" using rtc0 at Fri Jan 2 00:09:43 1970
PM: Syncing filesystems ... done.
PM: Preparing system for mem sleep
mmc0: card a8a5 removed
mmc1: card b368 removed
Freezing user space processes ... (elapsed 0.01 seconds) done.
Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done.
PM: Entering mem sleep
fec_stop : Graceful transmit stop did not complete !
PM: suspend of devices complete after 8.361 msecs
PM: suspend devices took 0.010 seconds
PM: late suspend of devices complete after 0.267 msecs
PM: noirq suspend of devices complete after 0.754 msecs
Disabling non-boot CPUs ...
CPU1: shutdown
CPU2: shutdown
CPU3: shutdown
Booting Linux on physical CPU 0x0
Linux version 3.8.0-rc7-next-20130215+ (r65073 at S2101-09) (gcc version
4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) ) #341 SMP Mon Feb 18 13:36:48 CST
2013
CPU: ARMv7 Processor [412fc09a] revision 10 (ARMv7), cr=10c53c7d
CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
Machine: Freescale i.MX6 Quad (Device Tree), model: Freescale i.MX6 Quad
SABRE Lite Board
Memory policy: ECC disabled, Data cache writealloc
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH 8/9] [HACK] ARM: imx: work around v7_cpu_resume link error
2013-02-18 5:55 ` Shawn Guo
@ 2013-02-18 17:06 ` Nicolas Pitre
-1 siblings, 0 replies; 70+ messages in thread
From: Nicolas Pitre @ 2013-02-18 17:06 UTC (permalink / raw)
To: Shawn Guo
Cc: Russell King - ARM Linux, Arnd Bergmann, linux-arm-kernel,
Stephen Warren, Pavel Machek, Sascha Hauer, linux-kernel, arm,
Simon Horman, Dinh Nguyen
On Mon, 18 Feb 2013, Shawn Guo wrote:
> On Sat, Feb 16, 2013 at 12:14:49AM -0500, Nicolas Pitre wrote:
> > Something like this should work:
> >
> > diff --git a/arch/arm/mach-imx/headsmp.S b/arch/arm/mach-imx/headsmp.S
> > index 7e49deb128..9de26f3edb 100644
> > --- a/arch/arm/mach-imx/headsmp.S
> > +++ b/arch/arm/mach-imx/headsmp.S
> > @@ -99,8 +99,11 @@ phys_l2x0_saved_regs:
> > #endif
> >
> > ENTRY(v7_cpu_resume)
> > - bl v7_invalidate_l1
> > + ldr ip, 2f
> > + mov lr, pc
> > +1: add pc, pc, ip
> > pl310_resume
> > b cpu_resume
> > +2: .word v7_invalidate_l1 - 1b - 8
> > ENDPROC(v7_cpu_resume)
> > #endif
> >
> Yes, it works.
>
> >
> > However it is probably best to move all the code to the .text section
> > where it belongs and fixup the data access instead. I must plead guilty
> > for introducing this idea of putting code in the .data section with the
> > SA1100resume code over 10 years ago that everyone copied since.
> >
> > So here's how I think it should look instead, and how I should have done
> > the SA1100 code back then:
> >
> > diff --git a/arch/arm/mach-imx/headsmp.S b/arch/arm/mach-imx/headsmp.S
> > index 7e49deb128..38a544a037 100644
> > --- a/arch/arm/mach-imx/headsmp.S
> > +++ b/arch/arm/mach-imx/headsmp.S
> > @@ -73,16 +73,16 @@ ENDPROC(v7_secondary_startup)
> >
> > #ifdef CONFIG_PM
> > /*
> > - * The following code is located into the .data section. This is to
> > - * allow phys_l2x0_saved_regs to be accessed with a relative load
> > - * as we are running on physical address here.
> > + * The following code must assume it is running from physical address
> > + * where absolute virtual addresses to the data section have to be
> > + * turned into relative ones.
> > */
> > - .data
> > - .align
> >
> > #ifdef CONFIG_CACHE_L2X0
> > .macro pl310_resume
> > - ldr r2, phys_l2x0_saved_regs
> > + adr r0, phys_l2x0_saved_ptr_offset
> > + ldr r2, [r0]
> > + add r2, r2, r0
> > ldr r0, [r2, #L2X0_R_PHY_BASE] @ get physical base of l2x0
> > ldr r1, [r2, #L2X0_R_AUX_CTRL] @ get aux_ctrl value
> > str r1, [r0, #L2X0_AUX_CTRL] @ restore aux_ctrl
> > @@ -90,9 +90,13 @@ ENDPROC(v7_secondary_startup)
> > str r1, [r0, #L2X0_CTRL] @ re-enable L2
> > .endm
> >
> > + .bss
> > .globl phys_l2x0_saved_regs
> > phys_l2x0_saved_regs:
> > - .long 0
> > + .space 4
> > + .previous
> > +phys_l2x0_saved_ptr_offset:
> > + .word phys_l2x0_saved_regs - .
> > #else
> > .macro pl310_resume
> > .endm
> >
> But this does not work. It seems the execution jumps to the start of
> kernel on system resuming.
Try the following instead. It makes the code simpler and easier to
debug.
diff --git a/arch/arm/mach-imx/headsmp.S b/arch/arm/mach-imx/headsmp.S
index 7e49deb128..27bc06e910 100644
--- a/arch/arm/mach-imx/headsmp.S
+++ b/arch/arm/mach-imx/headsmp.S
@@ -73,16 +73,16 @@ ENDPROC(v7_secondary_startup)
#ifdef CONFIG_PM
/*
- * The following code is located into the .data section. This is to
- * allow phys_l2x0_saved_regs to be accessed with a relative load
- * as we are running on physical address here.
+ * The following code must assume it is running from physical address
+ * where absolute virtual addresses to the data section have to be
+ * turned into relative ones.
*/
- .data
- .align
#ifdef CONFIG_CACHE_L2X0
.macro pl310_resume
- ldr r2, phys_l2x0_saved_regs
+ adr r0, l2x0_saved_regs_offset
+ ldr r2, [r0]
+ add r2, r2, r0
ldr r0, [r2, #L2X0_R_PHY_BASE] @ get physical base of l2x0
ldr r1, [r2, #L2X0_R_AUX_CTRL] @ get aux_ctrl value
str r1, [r0, #L2X0_AUX_CTRL] @ restore aux_ctrl
@@ -90,9 +90,9 @@ ENDPROC(v7_secondary_startup)
str r1, [r0, #L2X0_CTRL] @ re-enable L2
.endm
- .globl phys_l2x0_saved_regs
-phys_l2x0_saved_regs:
- .long 0
+l2x0_saved_regs_offset:
+ .word l2x0_saved_regs - .
+
#else
.macro pl310_resume
.endm
diff --git a/arch/arm/mach-imx/pm-imx6q.c b/arch/arm/mach-imx/pm-imx6q.c
index f7b0c2b1b9..f3791f980d 100644
--- a/arch/arm/mach-imx/pm-imx6q.c
+++ b/arch/arm/mach-imx/pm-imx6q.c
@@ -21,8 +21,6 @@
#include <mach/common.h>
#include <mach/hardware.h>
-extern unsigned long phys_l2x0_saved_regs;
-
static int imx6q_suspend_finish(unsigned long val)
{
cpu_do_idle();
@@ -55,18 +53,5 @@ static const struct platform_suspend_ops imx6q_pm_ops = {
void __init imx6q_pm_init(void)
{
- /*
- * The l2x0 core code provides an infrastucture to save and restore
- * l2x0 registers across suspend/resume cycle. But because imx6q
- * retains L2 content during suspend and needs to resume L2 before
- * MMU is enabled, it can only utilize register saving support and
- * have to take care of restoring on its own. So we save physical
- * address of the data structure used by l2x0 core to save registers,
- * and later restore the necessary ones in imx6q resume entry.
- */
-#ifdef CONFIG_CACHE_L2X0
- phys_l2x0_saved_regs = __pa(&l2x0_saved_regs);
-#endif
-
suspend_set_ops(&imx6q_pm_ops);
}
Nicolas
^ permalink raw reply related [flat|nested] 70+ messages in thread
* [PATCH 8/9] [HACK] ARM: imx: work around v7_cpu_resume link error
@ 2013-02-18 17:06 ` Nicolas Pitre
0 siblings, 0 replies; 70+ messages in thread
From: Nicolas Pitre @ 2013-02-18 17:06 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, 18 Feb 2013, Shawn Guo wrote:
> On Sat, Feb 16, 2013 at 12:14:49AM -0500, Nicolas Pitre wrote:
> > Something like this should work:
> >
> > diff --git a/arch/arm/mach-imx/headsmp.S b/arch/arm/mach-imx/headsmp.S
> > index 7e49deb128..9de26f3edb 100644
> > --- a/arch/arm/mach-imx/headsmp.S
> > +++ b/arch/arm/mach-imx/headsmp.S
> > @@ -99,8 +99,11 @@ phys_l2x0_saved_regs:
> > #endif
> >
> > ENTRY(v7_cpu_resume)
> > - bl v7_invalidate_l1
> > + ldr ip, 2f
> > + mov lr, pc
> > +1: add pc, pc, ip
> > pl310_resume
> > b cpu_resume
> > +2: .word v7_invalidate_l1 - 1b - 8
> > ENDPROC(v7_cpu_resume)
> > #endif
> >
> Yes, it works.
>
> >
> > However it is probably best to move all the code to the .text section
> > where it belongs and fixup the data access instead. I must plead guilty
> > for introducing this idea of putting code in the .data section with the
> > SA1100resume code over 10 years ago that everyone copied since.
> >
> > So here's how I think it should look instead, and how I should have done
> > the SA1100 code back then:
> >
> > diff --git a/arch/arm/mach-imx/headsmp.S b/arch/arm/mach-imx/headsmp.S
> > index 7e49deb128..38a544a037 100644
> > --- a/arch/arm/mach-imx/headsmp.S
> > +++ b/arch/arm/mach-imx/headsmp.S
> > @@ -73,16 +73,16 @@ ENDPROC(v7_secondary_startup)
> >
> > #ifdef CONFIG_PM
> > /*
> > - * The following code is located into the .data section. This is to
> > - * allow phys_l2x0_saved_regs to be accessed with a relative load
> > - * as we are running on physical address here.
> > + * The following code must assume it is running from physical address
> > + * where absolute virtual addresses to the data section have to be
> > + * turned into relative ones.
> > */
> > - .data
> > - .align
> >
> > #ifdef CONFIG_CACHE_L2X0
> > .macro pl310_resume
> > - ldr r2, phys_l2x0_saved_regs
> > + adr r0, phys_l2x0_saved_ptr_offset
> > + ldr r2, [r0]
> > + add r2, r2, r0
> > ldr r0, [r2, #L2X0_R_PHY_BASE] @ get physical base of l2x0
> > ldr r1, [r2, #L2X0_R_AUX_CTRL] @ get aux_ctrl value
> > str r1, [r0, #L2X0_AUX_CTRL] @ restore aux_ctrl
> > @@ -90,9 +90,13 @@ ENDPROC(v7_secondary_startup)
> > str r1, [r0, #L2X0_CTRL] @ re-enable L2
> > .endm
> >
> > + .bss
> > .globl phys_l2x0_saved_regs
> > phys_l2x0_saved_regs:
> > - .long 0
> > + .space 4
> > + .previous
> > +phys_l2x0_saved_ptr_offset:
> > + .word phys_l2x0_saved_regs - .
> > #else
> > .macro pl310_resume
> > .endm
> >
> But this does not work. It seems the execution jumps to the start of
> kernel on system resuming.
Try the following instead. It makes the code simpler and easier to
debug.
diff --git a/arch/arm/mach-imx/headsmp.S b/arch/arm/mach-imx/headsmp.S
index 7e49deb128..27bc06e910 100644
--- a/arch/arm/mach-imx/headsmp.S
+++ b/arch/arm/mach-imx/headsmp.S
@@ -73,16 +73,16 @@ ENDPROC(v7_secondary_startup)
#ifdef CONFIG_PM
/*
- * The following code is located into the .data section. This is to
- * allow phys_l2x0_saved_regs to be accessed with a relative load
- * as we are running on physical address here.
+ * The following code must assume it is running from physical address
+ * where absolute virtual addresses to the data section have to be
+ * turned into relative ones.
*/
- .data
- .align
#ifdef CONFIG_CACHE_L2X0
.macro pl310_resume
- ldr r2, phys_l2x0_saved_regs
+ adr r0, l2x0_saved_regs_offset
+ ldr r2, [r0]
+ add r2, r2, r0
ldr r0, [r2, #L2X0_R_PHY_BASE] @ get physical base of l2x0
ldr r1, [r2, #L2X0_R_AUX_CTRL] @ get aux_ctrl value
str r1, [r0, #L2X0_AUX_CTRL] @ restore aux_ctrl
@@ -90,9 +90,9 @@ ENDPROC(v7_secondary_startup)
str r1, [r0, #L2X0_CTRL] @ re-enable L2
.endm
- .globl phys_l2x0_saved_regs
-phys_l2x0_saved_regs:
- .long 0
+l2x0_saved_regs_offset:
+ .word l2x0_saved_regs - .
+
#else
.macro pl310_resume
.endm
diff --git a/arch/arm/mach-imx/pm-imx6q.c b/arch/arm/mach-imx/pm-imx6q.c
index f7b0c2b1b9..f3791f980d 100644
--- a/arch/arm/mach-imx/pm-imx6q.c
+++ b/arch/arm/mach-imx/pm-imx6q.c
@@ -21,8 +21,6 @@
#include <mach/common.h>
#include <mach/hardware.h>
-extern unsigned long phys_l2x0_saved_regs;
-
static int imx6q_suspend_finish(unsigned long val)
{
cpu_do_idle();
@@ -55,18 +53,5 @@ static const struct platform_suspend_ops imx6q_pm_ops = {
void __init imx6q_pm_init(void)
{
- /*
- * The l2x0 core code provides an infrastucture to save and restore
- * l2x0 registers across suspend/resume cycle. But because imx6q
- * retains L2 content during suspend and needs to resume L2 before
- * MMU is enabled, it can only utilize register saving support and
- * have to take care of restoring on its own. So we save physical
- * address of the data structure used by l2x0 core to save registers,
- * and later restore the necessary ones in imx6q resume entry.
- */
-#ifdef CONFIG_CACHE_L2X0
- phys_l2x0_saved_regs = __pa(&l2x0_saved_regs);
-#endif
-
suspend_set_ops(&imx6q_pm_ops);
}
Nicolas
^ permalink raw reply related [flat|nested] 70+ messages in thread
* Re: [PATCH 8/9] [HACK] ARM: imx: work around v7_cpu_resume link error
2013-02-18 17:06 ` Nicolas Pitre
@ 2013-02-19 1:42 ` Shawn Guo
-1 siblings, 0 replies; 70+ messages in thread
From: Shawn Guo @ 2013-02-19 1:42 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Russell King - ARM Linux, Arnd Bergmann, linux-arm-kernel,
Stephen Warren, Pavel Machek, Sascha Hauer, linux-kernel, arm,
Simon Horman, Dinh Nguyen
On Mon, Feb 18, 2013 at 12:06:32PM -0500, Nicolas Pitre wrote:
> Try the following instead. It makes the code simpler and easier to
> debug.
>
It works now. Thanks, Nico. Care to send a patch for it? I'd like
to apply it.
Shawn
> diff --git a/arch/arm/mach-imx/headsmp.S b/arch/arm/mach-imx/headsmp.S
> index 7e49deb128..27bc06e910 100644
> --- a/arch/arm/mach-imx/headsmp.S
> +++ b/arch/arm/mach-imx/headsmp.S
> @@ -73,16 +73,16 @@ ENDPROC(v7_secondary_startup)
>
> #ifdef CONFIG_PM
> /*
> - * The following code is located into the .data section. This is to
> - * allow phys_l2x0_saved_regs to be accessed with a relative load
> - * as we are running on physical address here.
> + * The following code must assume it is running from physical address
> + * where absolute virtual addresses to the data section have to be
> + * turned into relative ones.
> */
> - .data
> - .align
>
> #ifdef CONFIG_CACHE_L2X0
> .macro pl310_resume
> - ldr r2, phys_l2x0_saved_regs
> + adr r0, l2x0_saved_regs_offset
> + ldr r2, [r0]
> + add r2, r2, r0
> ldr r0, [r2, #L2X0_R_PHY_BASE] @ get physical base of l2x0
> ldr r1, [r2, #L2X0_R_AUX_CTRL] @ get aux_ctrl value
> str r1, [r0, #L2X0_AUX_CTRL] @ restore aux_ctrl
> @@ -90,9 +90,9 @@ ENDPROC(v7_secondary_startup)
> str r1, [r0, #L2X0_CTRL] @ re-enable L2
> .endm
>
> - .globl phys_l2x0_saved_regs
> -phys_l2x0_saved_regs:
> - .long 0
> +l2x0_saved_regs_offset:
> + .word l2x0_saved_regs - .
> +
> #else
> .macro pl310_resume
> .endm
> diff --git a/arch/arm/mach-imx/pm-imx6q.c b/arch/arm/mach-imx/pm-imx6q.c
> index f7b0c2b1b9..f3791f980d 100644
> --- a/arch/arm/mach-imx/pm-imx6q.c
> +++ b/arch/arm/mach-imx/pm-imx6q.c
> @@ -21,8 +21,6 @@
> #include <mach/common.h>
> #include <mach/hardware.h>
>
> -extern unsigned long phys_l2x0_saved_regs;
> -
> static int imx6q_suspend_finish(unsigned long val)
> {
> cpu_do_idle();
> @@ -55,18 +53,5 @@ static const struct platform_suspend_ops imx6q_pm_ops = {
>
> void __init imx6q_pm_init(void)
> {
> - /*
> - * The l2x0 core code provides an infrastucture to save and restore
> - * l2x0 registers across suspend/resume cycle. But because imx6q
> - * retains L2 content during suspend and needs to resume L2 before
> - * MMU is enabled, it can only utilize register saving support and
> - * have to take care of restoring on its own. So we save physical
> - * address of the data structure used by l2x0 core to save registers,
> - * and later restore the necessary ones in imx6q resume entry.
> - */
> -#ifdef CONFIG_CACHE_L2X0
> - phys_l2x0_saved_regs = __pa(&l2x0_saved_regs);
> -#endif
> -
> suspend_set_ops(&imx6q_pm_ops);
> }
>
> Nicolas
^ permalink raw reply [flat|nested] 70+ messages in thread
* [PATCH 8/9] [HACK] ARM: imx: work around v7_cpu_resume link error
@ 2013-02-19 1:42 ` Shawn Guo
0 siblings, 0 replies; 70+ messages in thread
From: Shawn Guo @ 2013-02-19 1:42 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, Feb 18, 2013 at 12:06:32PM -0500, Nicolas Pitre wrote:
> Try the following instead. It makes the code simpler and easier to
> debug.
>
It works now. Thanks, Nico. Care to send a patch for it? I'd like
to apply it.
Shawn
> diff --git a/arch/arm/mach-imx/headsmp.S b/arch/arm/mach-imx/headsmp.S
> index 7e49deb128..27bc06e910 100644
> --- a/arch/arm/mach-imx/headsmp.S
> +++ b/arch/arm/mach-imx/headsmp.S
> @@ -73,16 +73,16 @@ ENDPROC(v7_secondary_startup)
>
> #ifdef CONFIG_PM
> /*
> - * The following code is located into the .data section. This is to
> - * allow phys_l2x0_saved_regs to be accessed with a relative load
> - * as we are running on physical address here.
> + * The following code must assume it is running from physical address
> + * where absolute virtual addresses to the data section have to be
> + * turned into relative ones.
> */
> - .data
> - .align
>
> #ifdef CONFIG_CACHE_L2X0
> .macro pl310_resume
> - ldr r2, phys_l2x0_saved_regs
> + adr r0, l2x0_saved_regs_offset
> + ldr r2, [r0]
> + add r2, r2, r0
> ldr r0, [r2, #L2X0_R_PHY_BASE] @ get physical base of l2x0
> ldr r1, [r2, #L2X0_R_AUX_CTRL] @ get aux_ctrl value
> str r1, [r0, #L2X0_AUX_CTRL] @ restore aux_ctrl
> @@ -90,9 +90,9 @@ ENDPROC(v7_secondary_startup)
> str r1, [r0, #L2X0_CTRL] @ re-enable L2
> .endm
>
> - .globl phys_l2x0_saved_regs
> -phys_l2x0_saved_regs:
> - .long 0
> +l2x0_saved_regs_offset:
> + .word l2x0_saved_regs - .
> +
> #else
> .macro pl310_resume
> .endm
> diff --git a/arch/arm/mach-imx/pm-imx6q.c b/arch/arm/mach-imx/pm-imx6q.c
> index f7b0c2b1b9..f3791f980d 100644
> --- a/arch/arm/mach-imx/pm-imx6q.c
> +++ b/arch/arm/mach-imx/pm-imx6q.c
> @@ -21,8 +21,6 @@
> #include <mach/common.h>
> #include <mach/hardware.h>
>
> -extern unsigned long phys_l2x0_saved_regs;
> -
> static int imx6q_suspend_finish(unsigned long val)
> {
> cpu_do_idle();
> @@ -55,18 +53,5 @@ static const struct platform_suspend_ops imx6q_pm_ops = {
>
> void __init imx6q_pm_init(void)
> {
> - /*
> - * The l2x0 core code provides an infrastucture to save and restore
> - * l2x0 registers across suspend/resume cycle. But because imx6q
> - * retains L2 content during suspend and needs to resume L2 before
> - * MMU is enabled, it can only utilize register saving support and
> - * have to take care of restoring on its own. So we save physical
> - * address of the data structure used by l2x0 core to save registers,
> - * and later restore the necessary ones in imx6q resume entry.
> - */
> -#ifdef CONFIG_CACHE_L2X0
> - phys_l2x0_saved_regs = __pa(&l2x0_saved_regs);
> -#endif
> -
> suspend_set_ops(&imx6q_pm_ops);
> }
>
> Nicolas
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH 8/9] [HACK] ARM: imx: work around v7_cpu_resume link error
2013-02-19 1:42 ` Shawn Guo
@ 2013-02-19 4:11 ` Nicolas Pitre
-1 siblings, 0 replies; 70+ messages in thread
From: Nicolas Pitre @ 2013-02-19 4:11 UTC (permalink / raw)
To: Shawn Guo
Cc: Russell King - ARM Linux, Arnd Bergmann, linux-arm-kernel,
Stephen Warren, Pavel Machek, Sascha Hauer, linux-kernel, arm,
Simon Horman, Dinh Nguyen
On Tue, 19 Feb 2013, Shawn Guo wrote:
> On Mon, Feb 18, 2013 at 12:06:32PM -0500, Nicolas Pitre wrote:
> > Try the following instead. It makes the code simpler and easier to
> > debug.
> >
> It works now. Thanks, Nico. Care to send a patch for it? I'd like
> to apply it.
----- >8
FRom: Nicolas Pitre <nicolas.pitre@linaro.org>
Date: Mon, 18 Feb 2013 12:06:32 -0500 (EST)
Subject: ARM: mach-imx: move early resume code out of the .data section
Building the kernel with allyesconfig fails because the i.mx early
resume code located in the .data section is unable to fixup the bl
relocation as the branch target gets too far away.
The idea of having code in the .data section allows for easy access to
nearby data using relative addressing while the MMU is off. However it
is probably best to move the code back to the .text section where it
belongs and fixup the data access instead. This solves the bl reloc
issue (at least until this becomes a general problem) and simplifies
the code as well.
Signed-off-by: Nicolas Pitre <nico@linaro.org>
---
I'll probably convert other "code in .data" instances as well in the
near future.
diff --git a/arch/arm/mach-imx/headsmp.S b/arch/arm/mach-imx/headsmp.S
index 7e49deb128..27bc06e910 100644
--- a/arch/arm/mach-imx/headsmp.S
+++ b/arch/arm/mach-imx/headsmp.S
@@ -73,16 +73,16 @@ ENDPROC(v7_secondary_startup)
#ifdef CONFIG_PM
/*
- * The following code is located into the .data section. This is to
- * allow phys_l2x0_saved_regs to be accessed with a relative load
- * as we are running on physical address here.
+ * The following code must assume it is running from physical address
+ * where absolute virtual addresses to the data section have to be
+ * turned into relative ones.
*/
- .data
- .align
#ifdef CONFIG_CACHE_L2X0
.macro pl310_resume
- ldr r2, phys_l2x0_saved_regs
+ adr r0, l2x0_saved_regs_offset
+ ldr r2, [r0]
+ add r2, r2, r0
ldr r0, [r2, #L2X0_R_PHY_BASE] @ get physical base of l2x0
ldr r1, [r2, #L2X0_R_AUX_CTRL] @ get aux_ctrl value
str r1, [r0, #L2X0_AUX_CTRL] @ restore aux_ctrl
@@ -90,9 +90,9 @@ ENDPROC(v7_secondary_startup)
str r1, [r0, #L2X0_CTRL] @ re-enable L2
.endm
- .globl phys_l2x0_saved_regs
-phys_l2x0_saved_regs:
- .long 0
+l2x0_saved_regs_offset:
+ .word l2x0_saved_regs - .
+
#else
.macro pl310_resume
.endm
diff --git a/arch/arm/mach-imx/pm-imx6q.c b/arch/arm/mach-imx/pm-imx6q.c
index f7b0c2b1b9..f3791f980d 100644
--- a/arch/arm/mach-imx/pm-imx6q.c
+++ b/arch/arm/mach-imx/pm-imx6q.c
@@ -21,8 +21,6 @@
#include <mach/common.h>
#include <mach/hardware.h>
-extern unsigned long phys_l2x0_saved_regs;
-
static int imx6q_suspend_finish(unsigned long val)
{
cpu_do_idle();
@@ -55,18 +53,5 @@ static const struct platform_suspend_ops imx6q_pm_ops = {
void __init imx6q_pm_init(void)
{
- /*
- * The l2x0 core code provides an infrastucture to save and restore
- * l2x0 registers across suspend/resume cycle. But because imx6q
- * retains L2 content during suspend and needs to resume L2 before
- * MMU is enabled, it can only utilize register saving support and
- * have to take care of restoring on its own. So we save physical
- * address of the data structure used by l2x0 core to save registers,
- * and later restore the necessary ones in imx6q resume entry.
- */
-#ifdef CONFIG_CACHE_L2X0
- phys_l2x0_saved_regs = __pa(&l2x0_saved_regs);
-#endif
-
suspend_set_ops(&imx6q_pm_ops);
}
^ permalink raw reply related [flat|nested] 70+ messages in thread
* [PATCH 8/9] [HACK] ARM: imx: work around v7_cpu_resume link error
@ 2013-02-19 4:11 ` Nicolas Pitre
0 siblings, 0 replies; 70+ messages in thread
From: Nicolas Pitre @ 2013-02-19 4:11 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, 19 Feb 2013, Shawn Guo wrote:
> On Mon, Feb 18, 2013 at 12:06:32PM -0500, Nicolas Pitre wrote:
> > Try the following instead. It makes the code simpler and easier to
> > debug.
> >
> It works now. Thanks, Nico. Care to send a patch for it? I'd like
> to apply it.
----- >8
FRom: Nicolas Pitre <nicolas.pitre@linaro.org>
Date: Mon, 18 Feb 2013 12:06:32 -0500 (EST)
Subject: ARM: mach-imx: move early resume code out of the .data section
Building the kernel with allyesconfig fails because the i.mx early
resume code located in the .data section is unable to fixup the bl
relocation as the branch target gets too far away.
The idea of having code in the .data section allows for easy access to
nearby data using relative addressing while the MMU is off. However it
is probably best to move the code back to the .text section where it
belongs and fixup the data access instead. This solves the bl reloc
issue (at least until this becomes a general problem) and simplifies
the code as well.
Signed-off-by: Nicolas Pitre <nico@linaro.org>
---
I'll probably convert other "code in .data" instances as well in the
near future.
diff --git a/arch/arm/mach-imx/headsmp.S b/arch/arm/mach-imx/headsmp.S
index 7e49deb128..27bc06e910 100644
--- a/arch/arm/mach-imx/headsmp.S
+++ b/arch/arm/mach-imx/headsmp.S
@@ -73,16 +73,16 @@ ENDPROC(v7_secondary_startup)
#ifdef CONFIG_PM
/*
- * The following code is located into the .data section. This is to
- * allow phys_l2x0_saved_regs to be accessed with a relative load
- * as we are running on physical address here.
+ * The following code must assume it is running from physical address
+ * where absolute virtual addresses to the data section have to be
+ * turned into relative ones.
*/
- .data
- .align
#ifdef CONFIG_CACHE_L2X0
.macro pl310_resume
- ldr r2, phys_l2x0_saved_regs
+ adr r0, l2x0_saved_regs_offset
+ ldr r2, [r0]
+ add r2, r2, r0
ldr r0, [r2, #L2X0_R_PHY_BASE] @ get physical base of l2x0
ldr r1, [r2, #L2X0_R_AUX_CTRL] @ get aux_ctrl value
str r1, [r0, #L2X0_AUX_CTRL] @ restore aux_ctrl
@@ -90,9 +90,9 @@ ENDPROC(v7_secondary_startup)
str r1, [r0, #L2X0_CTRL] @ re-enable L2
.endm
- .globl phys_l2x0_saved_regs
-phys_l2x0_saved_regs:
- .long 0
+l2x0_saved_regs_offset:
+ .word l2x0_saved_regs - .
+
#else
.macro pl310_resume
.endm
diff --git a/arch/arm/mach-imx/pm-imx6q.c b/arch/arm/mach-imx/pm-imx6q.c
index f7b0c2b1b9..f3791f980d 100644
--- a/arch/arm/mach-imx/pm-imx6q.c
+++ b/arch/arm/mach-imx/pm-imx6q.c
@@ -21,8 +21,6 @@
#include <mach/common.h>
#include <mach/hardware.h>
-extern unsigned long phys_l2x0_saved_regs;
-
static int imx6q_suspend_finish(unsigned long val)
{
cpu_do_idle();
@@ -55,18 +53,5 @@ static const struct platform_suspend_ops imx6q_pm_ops = {
void __init imx6q_pm_init(void)
{
- /*
- * The l2x0 core code provides an infrastucture to save and restore
- * l2x0 registers across suspend/resume cycle. But because imx6q
- * retains L2 content during suspend and needs to resume L2 before
- * MMU is enabled, it can only utilize register saving support and
- * have to take care of restoring on its own. So we save physical
- * address of the data structure used by l2x0 core to save registers,
- * and later restore the necessary ones in imx6q resume entry.
- */
-#ifdef CONFIG_CACHE_L2X0
- phys_l2x0_saved_regs = __pa(&l2x0_saved_regs);
-#endif
-
suspend_set_ops(&imx6q_pm_ops);
}
^ permalink raw reply related [flat|nested] 70+ messages in thread
* Re: [PATCH 8/9] [HACK] ARM: imx: work around v7_cpu_resume link error
2013-02-19 4:11 ` Nicolas Pitre
@ 2013-02-19 5:10 ` Shawn Guo
-1 siblings, 0 replies; 70+ messages in thread
From: Shawn Guo @ 2013-02-19 5:10 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Russell King - ARM Linux, Arnd Bergmann, linux-arm-kernel,
Stephen Warren, Pavel Machek, Sascha Hauer, linux-kernel, arm,
Simon Horman, Dinh Nguyen
On Mon, Feb 18, 2013 at 11:11:30PM -0500, Nicolas Pitre wrote:
> On Tue, 19 Feb 2013, Shawn Guo wrote:
>
> > On Mon, Feb 18, 2013 at 12:06:32PM -0500, Nicolas Pitre wrote:
> > > Try the following instead. It makes the code simpler and easier to
> > > debug.
> > >
> > It works now. Thanks, Nico. Care to send a patch for it? I'd like
> > to apply it.
>
> ----- >8
>
> FRom: Nicolas Pitre <nicolas.pitre@linaro.org>
> Date: Mon, 18 Feb 2013 12:06:32 -0500 (EST)
> Subject: ARM: mach-imx: move early resume code out of the .data section
>
> Building the kernel with allyesconfig fails because the i.mx early
> resume code located in the .data section is unable to fixup the bl
> relocation as the branch target gets too far away.
>
> The idea of having code in the .data section allows for easy access to
> nearby data using relative addressing while the MMU is off. However it
> is probably best to move the code back to the .text section where it
> belongs and fixup the data access instead. This solves the bl reloc
> issue (at least until this becomes a general problem) and simplifies
> the code as well.
>
> Signed-off-by: Nicolas Pitre <nico@linaro.org>
Applied as a fix for 3.9-rc, thanks.
Shawn
^ permalink raw reply [flat|nested] 70+ messages in thread
* [PATCH 8/9] [HACK] ARM: imx: work around v7_cpu_resume link error
@ 2013-02-19 5:10 ` Shawn Guo
0 siblings, 0 replies; 70+ messages in thread
From: Shawn Guo @ 2013-02-19 5:10 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, Feb 18, 2013 at 11:11:30PM -0500, Nicolas Pitre wrote:
> On Tue, 19 Feb 2013, Shawn Guo wrote:
>
> > On Mon, Feb 18, 2013 at 12:06:32PM -0500, Nicolas Pitre wrote:
> > > Try the following instead. It makes the code simpler and easier to
> > > debug.
> > >
> > It works now. Thanks, Nico. Care to send a patch for it? I'd like
> > to apply it.
>
> ----- >8
>
> FRom: Nicolas Pitre <nicolas.pitre@linaro.org>
> Date: Mon, 18 Feb 2013 12:06:32 -0500 (EST)
> Subject: ARM: mach-imx: move early resume code out of the .data section
>
> Building the kernel with allyesconfig fails because the i.mx early
> resume code located in the .data section is unable to fixup the bl
> relocation as the branch target gets too far away.
>
> The idea of having code in the .data section allows for easy access to
> nearby data using relative addressing while the MMU is off. However it
> is probably best to move the code back to the .text section where it
> belongs and fixup the data access instead. This solves the bl reloc
> issue (at least until this becomes a general problem) and simplifies
> the code as well.
>
> Signed-off-by: Nicolas Pitre <nico@linaro.org>
Applied as a fix for 3.9-rc, thanks.
Shawn
^ permalink raw reply [flat|nested] 70+ messages in thread
* [PATCH 9/9] [media] davinci: do not include mach/hardware.h
2013-02-14 22:47 ` Arnd Bergmann
@ 2013-02-14 22:47 ` Arnd Bergmann
-1 siblings, 0 replies; 70+ messages in thread
From: Arnd Bergmann @ 2013-02-14 22:47 UTC (permalink / raw)
To: linux-arm-kernel
Cc: linux-kernel, arm, Arnd Bergmann, Mauro Carvalho Chehab, Lad,
Prabhakar, Tony Lindgren
It is now possible to build the davinci vpss code
on multiplatform kernels, which causes a problem
since the driver tries to incude the davinci
platform specific mach/hardware.h file. Fortunately
that file is not required at all in the driver,
so we can simply remove the #include statement.
Without this patch, building allyesconfig results in:
drivers/media/platform/davinci/vpss.c:28:27: fatal error: mach/hardware.h: No such file or directory
compilation terminated.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Mauro Carvalho Chehab <mchehab@redhat.com>
Cc: "Lad, Prabhakar" <prabhakar.lad@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
---
drivers/media/platform/davinci/vpss.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/media/platform/davinci/vpss.c b/drivers/media/platform/davinci/vpss.c
index 494d322..a19c552 100644
--- a/drivers/media/platform/davinci/vpss.c
+++ b/drivers/media/platform/davinci/vpss.c
@@ -25,7 +25,6 @@
#include <linux/spinlock.h>
#include <linux/compiler.h>
#include <linux/io.h>
-#include <mach/hardware.h>
#include <media/davinci/vpss.h>
MODULE_LICENSE("GPL");
--
1.8.1.2
^ permalink raw reply related [flat|nested] 70+ messages in thread
* [PATCH 9/9] [media] davinci: do not include mach/hardware.h
@ 2013-02-14 22:47 ` Arnd Bergmann
0 siblings, 0 replies; 70+ messages in thread
From: Arnd Bergmann @ 2013-02-14 22:47 UTC (permalink / raw)
To: linux-arm-kernel
It is now possible to build the davinci vpss code
on multiplatform kernels, which causes a problem
since the driver tries to incude the davinci
platform specific mach/hardware.h file. Fortunately
that file is not required at all in the driver,
so we can simply remove the #include statement.
Without this patch, building allyesconfig results in:
drivers/media/platform/davinci/vpss.c:28:27: fatal error: mach/hardware.h: No such file or directory
compilation terminated.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Mauro Carvalho Chehab <mchehab@redhat.com>
Cc: "Lad, Prabhakar" <prabhakar.lad@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
---
drivers/media/platform/davinci/vpss.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/media/platform/davinci/vpss.c b/drivers/media/platform/davinci/vpss.c
index 494d322..a19c552 100644
--- a/drivers/media/platform/davinci/vpss.c
+++ b/drivers/media/platform/davinci/vpss.c
@@ -25,7 +25,6 @@
#include <linux/spinlock.h>
#include <linux/compiler.h>
#include <linux/io.h>
-#include <mach/hardware.h>
#include <media/davinci/vpss.h>
MODULE_LICENSE("GPL");
--
1.8.1.2
^ permalink raw reply related [flat|nested] 70+ messages in thread
* Re: [PATCH 9/9] [media] davinci: do not include mach/hardware.h
2013-02-14 22:47 ` Arnd Bergmann
@ 2013-02-14 22:57 ` Tony Lindgren
-1 siblings, 0 replies; 70+ messages in thread
From: Tony Lindgren @ 2013-02-14 22:57 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-arm-kernel, linux-kernel, arm, Mauro Carvalho Chehab, Lad,
Prabhakar
* Arnd Bergmann <arnd@arndb.de> [130214 14:51]:
> It is now possible to build the davinci vpss code
> on multiplatform kernels, which causes a problem
> since the driver tries to incude the davinci
> platform specific mach/hardware.h file. Fortunately
> that file is not required at all in the driver,
> so we can simply remove the #include statement.
>
> Without this patch, building allyesconfig results in:
>
> drivers/media/platform/davinci/vpss.c:28:27: fatal error: mach/hardware.h: No such file or directory
> compilation terminated.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Mauro Carvalho Chehab <mchehab@redhat.com>
> Cc: "Lad, Prabhakar" <prabhakar.lad@ti.com>
All mach and plat includes from drivers should be fixed
and removed as that adds nasty dependencies between core SoC
code and the drivers.
Acked-by: Tony Lindgren <tony@atomide.com>
> ---
> drivers/media/platform/davinci/vpss.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/media/platform/davinci/vpss.c b/drivers/media/platform/davinci/vpss.c
> index 494d322..a19c552 100644
> --- a/drivers/media/platform/davinci/vpss.c
> +++ b/drivers/media/platform/davinci/vpss.c
> @@ -25,7 +25,6 @@
> #include <linux/spinlock.h>
> #include <linux/compiler.h>
> #include <linux/io.h>
> -#include <mach/hardware.h>
> #include <media/davinci/vpss.h>
>
> MODULE_LICENSE("GPL");
> --
> 1.8.1.2
>
^ permalink raw reply [flat|nested] 70+ messages in thread
* [PATCH 9/9] [media] davinci: do not include mach/hardware.h
@ 2013-02-14 22:57 ` Tony Lindgren
0 siblings, 0 replies; 70+ messages in thread
From: Tony Lindgren @ 2013-02-14 22:57 UTC (permalink / raw)
To: linux-arm-kernel
* Arnd Bergmann <arnd@arndb.de> [130214 14:51]:
> It is now possible to build the davinci vpss code
> on multiplatform kernels, which causes a problem
> since the driver tries to incude the davinci
> platform specific mach/hardware.h file. Fortunately
> that file is not required at all in the driver,
> so we can simply remove the #include statement.
>
> Without this patch, building allyesconfig results in:
>
> drivers/media/platform/davinci/vpss.c:28:27: fatal error: mach/hardware.h: No such file or directory
> compilation terminated.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Mauro Carvalho Chehab <mchehab@redhat.com>
> Cc: "Lad, Prabhakar" <prabhakar.lad@ti.com>
All mach and plat includes from drivers should be fixed
and removed as that adds nasty dependencies between core SoC
code and the drivers.
Acked-by: Tony Lindgren <tony@atomide.com>
> ---
> drivers/media/platform/davinci/vpss.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/media/platform/davinci/vpss.c b/drivers/media/platform/davinci/vpss.c
> index 494d322..a19c552 100644
> --- a/drivers/media/platform/davinci/vpss.c
> +++ b/drivers/media/platform/davinci/vpss.c
> @@ -25,7 +25,6 @@
> #include <linux/spinlock.h>
> #include <linux/compiler.h>
> #include <linux/io.h>
> -#include <mach/hardware.h>
> #include <media/davinci/vpss.h>
>
> MODULE_LICENSE("GPL");
> --
> 1.8.1.2
>
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH 9/9] [media] davinci: do not include mach/hardware.h
2013-02-14 22:47 ` Arnd Bergmann
@ 2013-02-15 5:06 ` Prabhakar Lad
-1 siblings, 0 replies; 70+ messages in thread
From: Prabhakar Lad @ 2013-02-15 5:06 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-arm-kernel, Mauro Carvalho Chehab, Tony Lindgren,
linux-kernel, Lad, Prabhakar, arm, dlos, linux-media
Hi Arnd,
Thanks for the patch.
On Fri, Feb 15, 2013 at 4:17 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> It is now possible to build the davinci vpss code
> on multiplatform kernels, which causes a problem
> since the driver tries to incude the davinci
> platform specific mach/hardware.h file. Fortunately
> that file is not required at all in the driver,
> so we can simply remove the #include statement.
>
> Without this patch, building allyesconfig results in:
>
> drivers/media/platform/davinci/vpss.c:28:27: fatal error: mach/hardware.h: No such file or directory
> compilation terminated.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Mauro Carvalho Chehab <mchehab@redhat.com>
> Cc: "Lad, Prabhakar" <prabhakar.lad@ti.com>
> Cc: Tony Lindgren <tony@atomide.com>
Acked-by: Lad, Prabhakar <prabhakar.lad@ti.com>
Regards,
--Prabhakar
> ---
> drivers/media/platform/davinci/vpss.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/media/platform/davinci/vpss.c b/drivers/media/platform/davinci/vpss.c
> index 494d322..a19c552 100644
> --- a/drivers/media/platform/davinci/vpss.c
> +++ b/drivers/media/platform/davinci/vpss.c
> @@ -25,7 +25,6 @@
> #include <linux/spinlock.h>
> #include <linux/compiler.h>
> #include <linux/io.h>
> -#include <mach/hardware.h>
> #include <media/davinci/vpss.h>
>
> MODULE_LICENSE("GPL");
> --
> 1.8.1.2
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 70+ messages in thread
* [PATCH 9/9] [media] davinci: do not include mach/hardware.h
@ 2013-02-15 5:06 ` Prabhakar Lad
0 siblings, 0 replies; 70+ messages in thread
From: Prabhakar Lad @ 2013-02-15 5:06 UTC (permalink / raw)
To: linux-arm-kernel
Hi Arnd,
Thanks for the patch.
On Fri, Feb 15, 2013 at 4:17 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> It is now possible to build the davinci vpss code
> on multiplatform kernels, which causes a problem
> since the driver tries to incude the davinci
> platform specific mach/hardware.h file. Fortunately
> that file is not required at all in the driver,
> so we can simply remove the #include statement.
>
> Without this patch, building allyesconfig results in:
>
> drivers/media/platform/davinci/vpss.c:28:27: fatal error: mach/hardware.h: No such file or directory
> compilation terminated.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Mauro Carvalho Chehab <mchehab@redhat.com>
> Cc: "Lad, Prabhakar" <prabhakar.lad@ti.com>
> Cc: Tony Lindgren <tony@atomide.com>
Acked-by: Lad, Prabhakar <prabhakar.lad@ti.com>
Regards,
--Prabhakar
> ---
> drivers/media/platform/davinci/vpss.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/media/platform/davinci/vpss.c b/drivers/media/platform/davinci/vpss.c
> index 494d322..a19c552 100644
> --- a/drivers/media/platform/davinci/vpss.c
> +++ b/drivers/media/platform/davinci/vpss.c
> @@ -25,7 +25,6 @@
> #include <linux/spinlock.h>
> #include <linux/compiler.h>
> #include <linux/io.h>
> -#include <mach/hardware.h>
> #include <media/davinci/vpss.h>
>
> MODULE_LICENSE("GPL");
> --
> 1.8.1.2
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 70+ messages in thread