* [PATCH 0/6] ARM: randconfig bugs
@ 2012-08-22 15:13 ` Arnd Bergmann
0 siblings, 0 replies; 42+ messages in thread
From: Arnd Bergmann @ 2012-08-22 15:13 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Russell King, linux-kernel, Arnd Bergmann, Artem Bityutskiy,
Eric Miao, Kevin Hilman, Lee Jones, Linus Walleij,
Santosh Shilimkar, Sascha Hauer, Shawn Guo, Tony Lindgren,
Yong Shen
Hi everyone,
Here are some more patches for bugs I found using
'make randconfig' in v3.6-rc+multiplatform. I can
to merge them through the arm-soc tree, but please
have a look and provide Acks.
Arnd
---
Cc: Artem Bityutskiy <dedekind1@gmail.com>
Cc: Eric Miao <eric.miao@linaro.org>
Cc: Kevin Hilman <khilman@ti.com>
Cc: Lee Jones <lee.jones@linaro.org>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Sascha Hauer <s.hauer@pengutronix.de>
Cc: Shawn Guo <shawn.guo@linaro.org>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Yong Shen <yong.shen@linaro.org>
Arnd Bergmann (6):
ARM: ux500: don't select LEDS_GPIO for snowball
ARM: omap: allow building omap44xx without SMP
ARM: imx: build pm-imx5 code only when PM is enabled
ARM: imx: fix ksz9021rn_phy_fixup
ARM: imx: select CPU_FREQ_TABLE when needed
ARM: imx: select ARM_CPU_SUSPEND when necessary
arch/arm/Kconfig | 1 +
arch/arm/mach-imx/Kconfig | 1 +
arch/arm/mach-imx/Makefile | 3 ++-
arch/arm/mach-imx/mach-imx6q.c | 4 ++--
arch/arm/mach-omap2/Kconfig | 2 +-
arch/arm/mach-omap2/cpuidle44xx.c | 3 ++-
arch/arm/mach-ux500/Kconfig | 1 -
include/linux/cpuidle.h | 4 ++++
8 files changed, 13 insertions(+), 6 deletions(-)
--
1.7.10
^ permalink raw reply [flat|nested] 42+ messages in thread
* [PATCH 1/6] ARM: ux500: don't select LEDS_GPIO for snowball
2012-08-22 15:13 ` Arnd Bergmann
@ 2012-08-22 15:13 ` Arnd Bergmann
-1 siblings, 0 replies; 42+ messages in thread
From: Arnd Bergmann @ 2012-08-22 15:13 UTC (permalink / raw)
To: linux-arm-kernel
The gpio leds driver can only be built if the generic LED code is
also enabled. Snowball selects LEDS_GPIO for an unknown reason
but it does not select LEDS_CLASS and also does not really require
the LED support at all, so we can just drop this dependency.
Without this patch, building without LEDS_CLASS esults in:
drivers/built-in.o: In function `create_gpio_led.part.2':
governor_userspace.c:(.devinit.text+0x5a58): undefined reference to `led_classdev_register'
drivers/built-in.o: In function `gpio_led_remove':
governor_userspace.c:(.devexit.text+0x6b8): undefined reference to `led_classdev_unregister'
This reverts 8733f53c6 "ARM: ux500: Kconfig: Compile in leds-gpio
support for Snowball", which was not completely thought through.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Lee Jones <lee.jones@linaro.org>
---
arch/arm/mach-ux500/Kconfig | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/mach-ux500/Kconfig b/arch/arm/mach-ux500/Kconfig
index c013bbf..53d3d46 100644
--- a/arch/arm/mach-ux500/Kconfig
+++ b/arch/arm/mach-ux500/Kconfig
@@ -41,7 +41,6 @@ config MACH_HREFV60
config MACH_SNOWBALL
bool "U8500 Snowball platform"
select MACH_MOP500
- select LEDS_GPIO
help
Include support for the snowball development platform.
--
1.7.10
^ permalink raw reply related [flat|nested] 42+ messages in thread
* [PATCH 1/6] ARM: ux500: don't select LEDS_GPIO for snowball
@ 2012-08-22 15:13 ` Arnd Bergmann
0 siblings, 0 replies; 42+ messages in thread
From: Arnd Bergmann @ 2012-08-22 15:13 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Russell King, linux-kernel, Arnd Bergmann, Linus Walleij,
Lee Jones
The gpio leds driver can only be built if the generic LED code is
also enabled. Snowball selects LEDS_GPIO for an unknown reason
but it does not select LEDS_CLASS and also does not really require
the LED support at all, so we can just drop this dependency.
Without this patch, building without LEDS_CLASS esults in:
drivers/built-in.o: In function `create_gpio_led.part.2':
governor_userspace.c:(.devinit.text+0x5a58): undefined reference to `led_classdev_register'
drivers/built-in.o: In function `gpio_led_remove':
governor_userspace.c:(.devexit.text+0x6b8): undefined reference to `led_classdev_unregister'
This reverts 8733f53c6 "ARM: ux500: Kconfig: Compile in leds-gpio
support for Snowball", which was not completely thought through.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Lee Jones <lee.jones@linaro.org>
---
arch/arm/mach-ux500/Kconfig | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/mach-ux500/Kconfig b/arch/arm/mach-ux500/Kconfig
index c013bbf..53d3d46 100644
--- a/arch/arm/mach-ux500/Kconfig
+++ b/arch/arm/mach-ux500/Kconfig
@@ -41,7 +41,6 @@ config MACH_HREFV60
config MACH_SNOWBALL
bool "U8500 Snowball platform"
select MACH_MOP500
- select LEDS_GPIO
help
Include support for the snowball development platform.
--
1.7.10
^ permalink raw reply related [flat|nested] 42+ messages in thread
* [PATCH 1/6] ARM: ux500: don't select LEDS_GPIO for snowball
2012-08-22 15:13 ` Arnd Bergmann
@ 2012-08-23 14:26 ` Arnd Bergmann
-1 siblings, 0 replies; 42+ messages in thread
From: Arnd Bergmann @ 2012-08-23 14:26 UTC (permalink / raw)
To: linux-arm-kernel
On Wednesday 22 August 2012, Arnd Bergmann wrote:
> The gpio leds driver can only be built if the generic LED code is
> also enabled. Snowball selects LEDS_GPIO for an unknown reason
> but it does not select LEDS_CLASS and also does not really require
> the LED support at all, so we can just drop this dependency.
>
> Without this patch, building without LEDS_CLASS esults in:
>
> drivers/built-in.o: In function `create_gpio_led.part.2':
> governor_userspace.c:(.devinit.text+0x5a58): undefined reference to `led_classdev_register'
> drivers/built-in.o: In function `gpio_led_remove':
> governor_userspace.c:(.devexit.text+0x6b8): undefined reference to `led_classdev_unregister'
>
> This reverts 8733f53c6 "ARM: ux500: Kconfig: Compile in leds-gpio
> support for Snowball", which was not completely thought through.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Linus Walleij <linus.walleij@linaro.org>
> Cc: Lee Jones <lee.jones@linaro.org>
I discussed this with Lee on IRC, he really wants to keep the LED enabled for snowball
for his own convenience. How is this version instead?
Arnd
>From 53c4e002b7ebd70ad9dcfa7a97c0ae58e874e643 Mon Sep 17 00:00:00 2001
From: Arnd Bergmann <arnd@arndb.de>
Date: Wed, 15 Aug 2012 20:34:48 +0000
Subject: [PATCH] ARM: ux500: don't select LEDS_GPIO for snowball
The gpio leds driver can only be built if the generic LED code is
also enabled. Snowball selects LEDS_GPIO for an unknown reason
but it does not select LEDS_CLASS and also does not really require
the LED support at all, so we can just drop this dependency.
Without this patch, building without LEDS_CLASS esults in:
drivers/built-in.o: In function `create_gpio_led.part.2':
governor_userspace.c:(.devinit.text+0x5a58): undefined reference to `led_classdev_register'
drivers/built-in.o: In function `gpio_led_remove':
governor_userspace.c:(.devexit.text+0x6b8): undefined reference to `led_classdev_unregister'
This reverts 8733f53c6 "ARM: ux500: Kconfig: Compile in leds-gpio
support for Snowball", which was not completely thought through.
In order to leave the GPIO LED code still present in normal
builds, this also enables the symbol in u8500_defconfig, in addition
to the other LED drivers that are already selected there.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Lee Jones <lee.jones@linaro.org>
diff --git a/arch/arm/configs/u8500_defconfig b/arch/arm/configs/u8500_defconfig
index 2d4f661..da68454 100644
--- a/arch/arm/configs/u8500_defconfig
+++ b/arch/arm/configs/u8500_defconfig
@@ -86,6 +86,7 @@ CONFIG_NEW_LEDS=y
CONFIG_LEDS_CLASS=y
CONFIG_LEDS_LM3530=y
CONFIG_LEDS_LP5521=y
+CONFIG_LEDS_GPIO=y
CONFIG_RTC_CLASS=y
CONFIG_RTC_DRV_AB8500=y
CONFIG_RTC_DRV_PL031=y
diff --git a/arch/arm/mach-ux500/Kconfig b/arch/arm/mach-ux500/Kconfig
index c013bbf..53d3d46 100644
--- a/arch/arm/mach-ux500/Kconfig
+++ b/arch/arm/mach-ux500/Kconfig
@@ -41,7 +41,6 @@ config MACH_HREFV60
config MACH_SNOWBALL
bool "U8500 Snowball platform"
select MACH_MOP500
- select LEDS_GPIO
help
Include support for the snowball development platform.
^ permalink raw reply related [flat|nested] 42+ messages in thread
* Re: [PATCH 1/6] ARM: ux500: don't select LEDS_GPIO for snowball
@ 2012-08-23 14:26 ` Arnd Bergmann
0 siblings, 0 replies; 42+ messages in thread
From: Arnd Bergmann @ 2012-08-23 14:26 UTC (permalink / raw)
To: linux-arm-kernel; +Cc: Russell King, linux-kernel, Linus Walleij, Lee Jones
On Wednesday 22 August 2012, Arnd Bergmann wrote:
> The gpio leds driver can only be built if the generic LED code is
> also enabled. Snowball selects LEDS_GPIO for an unknown reason
> but it does not select LEDS_CLASS and also does not really require
> the LED support at all, so we can just drop this dependency.
>
> Without this patch, building without LEDS_CLASS esults in:
>
> drivers/built-in.o: In function `create_gpio_led.part.2':
> governor_userspace.c:(.devinit.text+0x5a58): undefined reference to `led_classdev_register'
> drivers/built-in.o: In function `gpio_led_remove':
> governor_userspace.c:(.devexit.text+0x6b8): undefined reference to `led_classdev_unregister'
>
> This reverts 8733f53c6 "ARM: ux500: Kconfig: Compile in leds-gpio
> support for Snowball", which was not completely thought through.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Linus Walleij <linus.walleij@linaro.org>
> Cc: Lee Jones <lee.jones@linaro.org>
I discussed this with Lee on IRC, he really wants to keep the LED enabled for snowball
for his own convenience. How is this version instead?
Arnd
>From 53c4e002b7ebd70ad9dcfa7a97c0ae58e874e643 Mon Sep 17 00:00:00 2001
From: Arnd Bergmann <arnd@arndb.de>
Date: Wed, 15 Aug 2012 20:34:48 +0000
Subject: [PATCH] ARM: ux500: don't select LEDS_GPIO for snowball
The gpio leds driver can only be built if the generic LED code is
also enabled. Snowball selects LEDS_GPIO for an unknown reason
but it does not select LEDS_CLASS and also does not really require
the LED support at all, so we can just drop this dependency.
Without this patch, building without LEDS_CLASS esults in:
drivers/built-in.o: In function `create_gpio_led.part.2':
governor_userspace.c:(.devinit.text+0x5a58): undefined reference to `led_classdev_register'
drivers/built-in.o: In function `gpio_led_remove':
governor_userspace.c:(.devexit.text+0x6b8): undefined reference to `led_classdev_unregister'
This reverts 8733f53c6 "ARM: ux500: Kconfig: Compile in leds-gpio
support for Snowball", which was not completely thought through.
In order to leave the GPIO LED code still present in normal
builds, this also enables the symbol in u8500_defconfig, in addition
to the other LED drivers that are already selected there.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Lee Jones <lee.jones@linaro.org>
diff --git a/arch/arm/configs/u8500_defconfig b/arch/arm/configs/u8500_defconfig
index 2d4f661..da68454 100644
--- a/arch/arm/configs/u8500_defconfig
+++ b/arch/arm/configs/u8500_defconfig
@@ -86,6 +86,7 @@ CONFIG_NEW_LEDS=y
CONFIG_LEDS_CLASS=y
CONFIG_LEDS_LM3530=y
CONFIG_LEDS_LP5521=y
+CONFIG_LEDS_GPIO=y
CONFIG_RTC_CLASS=y
CONFIG_RTC_DRV_AB8500=y
CONFIG_RTC_DRV_PL031=y
diff --git a/arch/arm/mach-ux500/Kconfig b/arch/arm/mach-ux500/Kconfig
index c013bbf..53d3d46 100644
--- a/arch/arm/mach-ux500/Kconfig
+++ b/arch/arm/mach-ux500/Kconfig
@@ -41,7 +41,6 @@ config MACH_HREFV60
config MACH_SNOWBALL
bool "U8500 Snowball platform"
select MACH_MOP500
- select LEDS_GPIO
help
Include support for the snowball development platform.
^ permalink raw reply related [flat|nested] 42+ messages in thread
* [PATCH 1/6] ARM: ux500: don't select LEDS_GPIO for snowball
2012-08-23 14:26 ` Arnd Bergmann
@ 2012-08-27 23:40 ` Linus Walleij
-1 siblings, 0 replies; 42+ messages in thread
From: Linus Walleij @ 2012-08-27 23:40 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Aug 23, 2012 at 7:26 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> I discussed this with Lee on IRC, he really wants to keep the LED enabled for snowball
> for his own convenience. How is this version instead?
Sure, I guess you already merged it though?
Acked-by.
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH 1/6] ARM: ux500: don't select LEDS_GPIO for snowball
@ 2012-08-27 23:40 ` Linus Walleij
0 siblings, 0 replies; 42+ messages in thread
From: Linus Walleij @ 2012-08-27 23:40 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linux-arm-kernel, Russell King, linux-kernel, Lee Jones
On Thu, Aug 23, 2012 at 7:26 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> I discussed this with Lee on IRC, he really wants to keep the LED enabled for snowball
> for his own convenience. How is this version instead?
Sure, I guess you already merged it though?
Acked-by.
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 42+ messages in thread
* [PATCH 2/6] ARM: omap: allow building omap44xx without SMP
2012-08-22 15:13 ` Arnd Bergmann
@ 2012-08-22 15:13 ` Arnd Bergmann
-1 siblings, 0 replies; 42+ messages in thread
From: Arnd Bergmann @ 2012-08-22 15:13 UTC (permalink / raw)
To: linux-arm-kernel
The new omap4 cpuidle implementation currently requires
ARCH_NEEDS_CPU_IDLE_COUPLED, which only works on SMP.
This patch makes it possible to build a non-SMP kernel
for that platform. This is not normally desired for
end-users but can be useful for testing.
Without this patch, building rand-0y2jSKT results in:
drivers/cpuidle/coupled.c: In function 'cpuidle_coupled_poke':
drivers/cpuidle/coupled.c:317:3: error: implicit declaration of function '__smp_call_function_single' [-Werror=implicit-function-declaration]
It's not clear if this patch is the best solution for
the problem at hand. I have made sure that we can now
build the kernel in all configurations, but that does
not mean it will actually work on an OMAP44xx.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Kevin Hilman <khilman@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
---
arch/arm/mach-omap2/Kconfig | 2 +-
arch/arm/mach-omap2/cpuidle44xx.c | 3 ++-
include/linux/cpuidle.h | 4 ++++
3 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index dd2db02..66a8be3 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -62,7 +62,7 @@ config ARCH_OMAP4
select PM_OPP if PM
select USB_ARCH_HAS_EHCI if USB_SUPPORT
select ARM_CPU_SUSPEND if PM
- select ARCH_NEEDS_CPU_IDLE_COUPLED
+ select ARCH_NEEDS_CPU_IDLE_COUPLED if SMP
config SOC_OMAP5
bool "TI OMAP5"
diff --git a/arch/arm/mach-omap2/cpuidle44xx.c b/arch/arm/mach-omap2/cpuidle44xx.c
index ee05e19..288bee6 100644
--- a/arch/arm/mach-omap2/cpuidle44xx.c
+++ b/arch/arm/mach-omap2/cpuidle44xx.c
@@ -238,8 +238,9 @@ int __init omap4_idle_init(void)
for_each_cpu(cpu_id, cpu_online_mask) {
dev = &per_cpu(omap4_idle_dev, cpu_id);
dev->cpu = cpu_id;
+#ifdef CONFIG_ARCH_NEEDS_CPU_IDLE_COUPLED
dev->coupled_cpus = *cpu_online_mask;
-
+#endif
cpuidle_register_driver(&omap4_idle_driver);
if (cpuidle_register_device(dev)) {
diff --git a/include/linux/cpuidle.h b/include/linux/cpuidle.h
index 040b13b..279b1ea 100644
--- a/include/linux/cpuidle.h
+++ b/include/linux/cpuidle.h
@@ -194,6 +194,10 @@ static inline int cpuidle_play_dead(void) {return -ENODEV; }
#ifdef CONFIG_ARCH_NEEDS_CPU_IDLE_COUPLED
void cpuidle_coupled_parallel_barrier(struct cpuidle_device *dev, atomic_t *a);
+#else
+static inline void cpuidle_coupled_parallel_barrier(struct cpuidle_device *dev, atomic_t *a)
+{
+}
#endif
/******************************
--
1.7.10
^ permalink raw reply related [flat|nested] 42+ messages in thread* [PATCH 2/6] ARM: omap: allow building omap44xx without SMP
@ 2012-08-22 15:13 ` Arnd Bergmann
0 siblings, 0 replies; 42+ messages in thread
From: Arnd Bergmann @ 2012-08-22 15:13 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Russell King, linux-kernel, Arnd Bergmann, Santosh Shilimkar,
Kevin Hilman, Tony Lindgren
The new omap4 cpuidle implementation currently requires
ARCH_NEEDS_CPU_IDLE_COUPLED, which only works on SMP.
This patch makes it possible to build a non-SMP kernel
for that platform. This is not normally desired for
end-users but can be useful for testing.
Without this patch, building rand-0y2jSKT results in:
drivers/cpuidle/coupled.c: In function 'cpuidle_coupled_poke':
drivers/cpuidle/coupled.c:317:3: error: implicit declaration of function '__smp_call_function_single' [-Werror=implicit-function-declaration]
It's not clear if this patch is the best solution for
the problem at hand. I have made sure that we can now
build the kernel in all configurations, but that does
not mean it will actually work on an OMAP44xx.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Kevin Hilman <khilman@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
---
arch/arm/mach-omap2/Kconfig | 2 +-
arch/arm/mach-omap2/cpuidle44xx.c | 3 ++-
include/linux/cpuidle.h | 4 ++++
3 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index dd2db02..66a8be3 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -62,7 +62,7 @@ config ARCH_OMAP4
select PM_OPP if PM
select USB_ARCH_HAS_EHCI if USB_SUPPORT
select ARM_CPU_SUSPEND if PM
- select ARCH_NEEDS_CPU_IDLE_COUPLED
+ select ARCH_NEEDS_CPU_IDLE_COUPLED if SMP
config SOC_OMAP5
bool "TI OMAP5"
diff --git a/arch/arm/mach-omap2/cpuidle44xx.c b/arch/arm/mach-omap2/cpuidle44xx.c
index ee05e19..288bee6 100644
--- a/arch/arm/mach-omap2/cpuidle44xx.c
+++ b/arch/arm/mach-omap2/cpuidle44xx.c
@@ -238,8 +238,9 @@ int __init omap4_idle_init(void)
for_each_cpu(cpu_id, cpu_online_mask) {
dev = &per_cpu(omap4_idle_dev, cpu_id);
dev->cpu = cpu_id;
+#ifdef CONFIG_ARCH_NEEDS_CPU_IDLE_COUPLED
dev->coupled_cpus = *cpu_online_mask;
-
+#endif
cpuidle_register_driver(&omap4_idle_driver);
if (cpuidle_register_device(dev)) {
diff --git a/include/linux/cpuidle.h b/include/linux/cpuidle.h
index 040b13b..279b1ea 100644
--- a/include/linux/cpuidle.h
+++ b/include/linux/cpuidle.h
@@ -194,6 +194,10 @@ static inline int cpuidle_play_dead(void) {return -ENODEV; }
#ifdef CONFIG_ARCH_NEEDS_CPU_IDLE_COUPLED
void cpuidle_coupled_parallel_barrier(struct cpuidle_device *dev, atomic_t *a);
+#else
+static inline void cpuidle_coupled_parallel_barrier(struct cpuidle_device *dev, atomic_t *a)
+{
+}
#endif
/******************************
--
1.7.10
^ permalink raw reply related [flat|nested] 42+ messages in thread* [PATCH 2/6] ARM: omap: allow building omap44xx without SMP
2012-08-22 15:13 ` Arnd Bergmann
@ 2012-08-22 15:36 ` Shilimkar, Santosh
-1 siblings, 0 replies; 42+ messages in thread
From: Shilimkar, Santosh @ 2012-08-22 15:36 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, Aug 22, 2012 at 8:43 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> The new omap4 cpuidle implementation currently requires
> ARCH_NEEDS_CPU_IDLE_COUPLED, which only works on SMP.
>
> This patch makes it possible to build a non-SMP kernel
> for that platform. This is not normally desired for
> end-users but can be useful for testing.
>
> Without this patch, building rand-0y2jSKT results in:
>
> drivers/cpuidle/coupled.c: In function 'cpuidle_coupled_poke':
> drivers/cpuidle/coupled.c:317:3: error: implicit declaration of function '__smp_call_function_single' [-Werror=implicit-function-declaration]
>
> It's not clear if this patch is the best solution for
> the problem at hand. I have made sure that we can now
> build the kernel in all configurations, but that does
> not mean it will actually work on an OMAP44xx.
>
Am not sure either about the subject patch.
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
> Cc: Kevin Hilman <khilman@ti.com>
> Cc: Tony Lindgren <tony@atomide.com>
> ---
> arch/arm/mach-omap2/Kconfig | 2 +-
> arch/arm/mach-omap2/cpuidle44xx.c | 3 ++-
> include/linux/cpuidle.h | 4 ++++
> 3 files changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
> index dd2db02..66a8be3 100644
> --- a/arch/arm/mach-omap2/Kconfig
> +++ b/arch/arm/mach-omap2/Kconfig
> @@ -62,7 +62,7 @@ config ARCH_OMAP4
> select PM_OPP if PM
> select USB_ARCH_HAS_EHCI if USB_SUPPORT
> select ARM_CPU_SUSPEND if PM
> - select ARCH_NEEDS_CPU_IDLE_COUPLED
> + select ARCH_NEEDS_CPU_IDLE_COUPLED if SMP
>
> config SOC_OMAP5
> bool "TI OMAP5"
> diff --git a/arch/arm/mach-omap2/cpuidle44xx.c b/arch/arm/mach-omap2/cpuidle44xx.c
> index ee05e19..288bee6 100644
> --- a/arch/arm/mach-omap2/cpuidle44xx.c
> +++ b/arch/arm/mach-omap2/cpuidle44xx.c
> @@ -238,8 +238,9 @@ int __init omap4_idle_init(void)
> for_each_cpu(cpu_id, cpu_online_mask) {
> dev = &per_cpu(omap4_idle_dev, cpu_id);
> dev->cpu = cpu_id;
> +#ifdef CONFIG_ARCH_NEEDS_CPU_IDLE_COUPLED
> dev->coupled_cpus = *cpu_online_mask;
> -
> +#endif
Was just thinking whether we should just take care of it at
core cpuidle level itself. Will below be enough to kill the build
error what you mentioned in the change log ?
diff --git a/drivers/cpuidle/coupled.c b/drivers/cpuidle/coupled.c
index 2c9bf26..df34534 100644
--- a/drivers/cpuidle/coupled.c
+++ b/drivers/cpuidle/coupled.c
@@ -314,7 +314,9 @@ static void cpuidle_coupled_poke(int cpu)
struct call_single_data *csd = &per_cpu(cpuidle_coupled_poke_cb, cpu);
if (!cpumask_test_and_set_cpu(cpu, &cpuidle_coupled_poked_mask))
+#ifdef CONFIG_SMP
__smp_call_function_single(cpu, csd, 0);
+#endif
}
/**
Regards
Santosh
^ permalink raw reply related [flat|nested] 42+ messages in thread* Re: [PATCH 2/6] ARM: omap: allow building omap44xx without SMP
@ 2012-08-22 15:36 ` Shilimkar, Santosh
0 siblings, 0 replies; 42+ messages in thread
From: Shilimkar, Santosh @ 2012-08-22 15:36 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-arm-kernel, Russell King, linux-kernel, Kevin Hilman,
Tony Lindgren
On Wed, Aug 22, 2012 at 8:43 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> The new omap4 cpuidle implementation currently requires
> ARCH_NEEDS_CPU_IDLE_COUPLED, which only works on SMP.
>
> This patch makes it possible to build a non-SMP kernel
> for that platform. This is not normally desired for
> end-users but can be useful for testing.
>
> Without this patch, building rand-0y2jSKT results in:
>
> drivers/cpuidle/coupled.c: In function 'cpuidle_coupled_poke':
> drivers/cpuidle/coupled.c:317:3: error: implicit declaration of function '__smp_call_function_single' [-Werror=implicit-function-declaration]
>
> It's not clear if this patch is the best solution for
> the problem at hand. I have made sure that we can now
> build the kernel in all configurations, but that does
> not mean it will actually work on an OMAP44xx.
>
Am not sure either about the subject patch.
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
> Cc: Kevin Hilman <khilman@ti.com>
> Cc: Tony Lindgren <tony@atomide.com>
> ---
> arch/arm/mach-omap2/Kconfig | 2 +-
> arch/arm/mach-omap2/cpuidle44xx.c | 3 ++-
> include/linux/cpuidle.h | 4 ++++
> 3 files changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
> index dd2db02..66a8be3 100644
> --- a/arch/arm/mach-omap2/Kconfig
> +++ b/arch/arm/mach-omap2/Kconfig
> @@ -62,7 +62,7 @@ config ARCH_OMAP4
> select PM_OPP if PM
> select USB_ARCH_HAS_EHCI if USB_SUPPORT
> select ARM_CPU_SUSPEND if PM
> - select ARCH_NEEDS_CPU_IDLE_COUPLED
> + select ARCH_NEEDS_CPU_IDLE_COUPLED if SMP
>
> config SOC_OMAP5
> bool "TI OMAP5"
> diff --git a/arch/arm/mach-omap2/cpuidle44xx.c b/arch/arm/mach-omap2/cpuidle44xx.c
> index ee05e19..288bee6 100644
> --- a/arch/arm/mach-omap2/cpuidle44xx.c
> +++ b/arch/arm/mach-omap2/cpuidle44xx.c
> @@ -238,8 +238,9 @@ int __init omap4_idle_init(void)
> for_each_cpu(cpu_id, cpu_online_mask) {
> dev = &per_cpu(omap4_idle_dev, cpu_id);
> dev->cpu = cpu_id;
> +#ifdef CONFIG_ARCH_NEEDS_CPU_IDLE_COUPLED
> dev->coupled_cpus = *cpu_online_mask;
> -
> +#endif
Was just thinking whether we should just take care of it at
core cpuidle level itself. Will below be enough to kill the build
error what you mentioned in the change log ?
diff --git a/drivers/cpuidle/coupled.c b/drivers/cpuidle/coupled.c
index 2c9bf26..df34534 100644
--- a/drivers/cpuidle/coupled.c
+++ b/drivers/cpuidle/coupled.c
@@ -314,7 +314,9 @@ static void cpuidle_coupled_poke(int cpu)
struct call_single_data *csd = &per_cpu(cpuidle_coupled_poke_cb, cpu);
if (!cpumask_test_and_set_cpu(cpu, &cpuidle_coupled_poked_mask))
+#ifdef CONFIG_SMP
__smp_call_function_single(cpu, csd, 0);
+#endif
}
/**
Regards
Santosh
^ permalink raw reply related [flat|nested] 42+ messages in thread* [PATCH 2/6] ARM: omap: allow building omap44xx without SMP
2012-08-22 15:36 ` Shilimkar, Santosh
@ 2012-08-22 17:22 ` Arnd Bergmann
-1 siblings, 0 replies; 42+ messages in thread
From: Arnd Bergmann @ 2012-08-22 17:22 UTC (permalink / raw)
To: linux-arm-kernel
On Wednesday 22 August 2012, Shilimkar, Santosh wrote:
> Was just thinking whether we should just take care of it at
> core cpuidle level itself. Will below be enough to kill the build
> error what you mentioned in the change log ?
>
> diff --git a/drivers/cpuidle/coupled.c b/drivers/cpuidle/coupled.c
> index 2c9bf26..df34534 100644
> --- a/drivers/cpuidle/coupled.c
> +++ b/drivers/cpuidle/coupled.c
> @@ -314,7 +314,9 @@ static void cpuidle_coupled_poke(int cpu)
> struct call_single_data *csd = &per_cpu(cpuidle_coupled_poke_cb, cpu);
>
> if (!cpumask_test_and_set_cpu(cpu, &cpuidle_coupled_poked_mask))
> +#ifdef CONFIG_SMP
> __smp_call_function_single(cpu, csd, 0);
> +#endif
> }
>
That would work, but isn't the entire concept of the cpuidle-coupled driver
dependent on SMP? If this driver makes no sense on UP, I think we should
not attempt to build it.
Arnd
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH 2/6] ARM: omap: allow building omap44xx without SMP
@ 2012-08-22 17:22 ` Arnd Bergmann
0 siblings, 0 replies; 42+ messages in thread
From: Arnd Bergmann @ 2012-08-22 17:22 UTC (permalink / raw)
To: Shilimkar, Santosh
Cc: linux-arm-kernel, Russell King, linux-kernel, Kevin Hilman,
Tony Lindgren
On Wednesday 22 August 2012, Shilimkar, Santosh wrote:
> Was just thinking whether we should just take care of it at
> core cpuidle level itself. Will below be enough to kill the build
> error what you mentioned in the change log ?
>
> diff --git a/drivers/cpuidle/coupled.c b/drivers/cpuidle/coupled.c
> index 2c9bf26..df34534 100644
> --- a/drivers/cpuidle/coupled.c
> +++ b/drivers/cpuidle/coupled.c
> @@ -314,7 +314,9 @@ static void cpuidle_coupled_poke(int cpu)
> struct call_single_data *csd = &per_cpu(cpuidle_coupled_poke_cb, cpu);
>
> if (!cpumask_test_and_set_cpu(cpu, &cpuidle_coupled_poked_mask))
> +#ifdef CONFIG_SMP
> __smp_call_function_single(cpu, csd, 0);
> +#endif
> }
>
That would work, but isn't the entire concept of the cpuidle-coupled driver
dependent on SMP? If this driver makes no sense on UP, I think we should
not attempt to build it.
Arnd
^ permalink raw reply [flat|nested] 42+ messages in thread
* [PATCH 2/6] ARM: omap: allow building omap44xx without SMP
2012-08-22 17:22 ` Arnd Bergmann
@ 2012-08-23 7:05 ` Shilimkar, Santosh
-1 siblings, 0 replies; 42+ messages in thread
From: Shilimkar, Santosh @ 2012-08-23 7:05 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, Aug 22, 2012 at 10:52 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>
> On Wednesday 22 August 2012, Shilimkar, Santosh wrote:
>
> > Was just thinking whether we should just take care of it at
> > core cpuidle level itself. Will below be enough to kill the build
> > error what you mentioned in the change log ?
> >
> > diff --git a/drivers/cpuidle/coupled.c b/drivers/cpuidle/coupled.c
> > index 2c9bf26..df34534 100644
> > --- a/drivers/cpuidle/coupled.c
> > +++ b/drivers/cpuidle/coupled.c
> > @@ -314,7 +314,9 @@ static void cpuidle_coupled_poke(int cpu)
> > struct call_single_data *csd = &per_cpu(cpuidle_coupled_poke_cb,
> > cpu);
> >
> > if (!cpumask_test_and_set_cpu(cpu, &cpuidle_coupled_poked_mask))
> > +#ifdef CONFIG_SMP
> > __smp_call_function_single(cpu, csd, 0);
> > +#endif
> > }
> >
>
> That would work, but isn't the entire concept of the cpuidle-coupled
> driver
> dependent on SMP? If this driver makes no sense on UP, I think we should
> not attempt to build it.
>
I see your point but alternate patch is pushing down the fix to the low
level driver and that means you end up patching more drivers when they
use COUPLE idle infrastructure. That was the only reason I was thinking
of suppressing the error at the source.
Since it is just for the random builds and actually doesn't impact the real
functionality as such, I am fine with your proposed patch too.
Regards
santosh
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH 2/6] ARM: omap: allow building omap44xx without SMP
@ 2012-08-23 7:05 ` Shilimkar, Santosh
0 siblings, 0 replies; 42+ messages in thread
From: Shilimkar, Santosh @ 2012-08-23 7:05 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-arm-kernel, Russell King, linux-kernel, Kevin Hilman,
Tony Lindgren
On Wed, Aug 22, 2012 at 10:52 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>
> On Wednesday 22 August 2012, Shilimkar, Santosh wrote:
>
> > Was just thinking whether we should just take care of it at
> > core cpuidle level itself. Will below be enough to kill the build
> > error what you mentioned in the change log ?
> >
> > diff --git a/drivers/cpuidle/coupled.c b/drivers/cpuidle/coupled.c
> > index 2c9bf26..df34534 100644
> > --- a/drivers/cpuidle/coupled.c
> > +++ b/drivers/cpuidle/coupled.c
> > @@ -314,7 +314,9 @@ static void cpuidle_coupled_poke(int cpu)
> > struct call_single_data *csd = &per_cpu(cpuidle_coupled_poke_cb,
> > cpu);
> >
> > if (!cpumask_test_and_set_cpu(cpu, &cpuidle_coupled_poked_mask))
> > +#ifdef CONFIG_SMP
> > __smp_call_function_single(cpu, csd, 0);
> > +#endif
> > }
> >
>
> That would work, but isn't the entire concept of the cpuidle-coupled
> driver
> dependent on SMP? If this driver makes no sense on UP, I think we should
> not attempt to build it.
>
I see your point but alternate patch is pushing down the fix to the low
level driver and that means you end up patching more drivers when they
use COUPLE idle infrastructure. That was the only reason I was thinking
of suppressing the error at the source.
Since it is just for the random builds and actually doesn't impact the real
functionality as such, I am fine with your proposed patch too.
Regards
santosh
^ permalink raw reply [flat|nested] 42+ messages in thread
* [PATCH 2/6] ARM: omap: allow building omap44xx without SMP
2012-08-23 7:05 ` Shilimkar, Santosh
@ 2012-08-23 12:12 ` Arnd Bergmann
-1 siblings, 0 replies; 42+ messages in thread
From: Arnd Bergmann @ 2012-08-23 12:12 UTC (permalink / raw)
To: linux-arm-kernel
On Thursday 23 August 2012, Shilimkar, Santosh wrote:
> I see your point but alternate patch is pushing down the fix to the low
> level driver and that means you end up patching more drivers when they
> use COUPLE idle infrastructure. That was the only reason I was thinking
> of suppressing the error at the source.
>
> Since it is just for the random builds and actually doesn't impact the real
> functionality as such, I am fine with your proposed patch too.
Ok. It would be nice of course to test if this actually works on uniprocessor
configurations.
Arnd
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH 2/6] ARM: omap: allow building omap44xx without SMP
@ 2012-08-23 12:12 ` Arnd Bergmann
0 siblings, 0 replies; 42+ messages in thread
From: Arnd Bergmann @ 2012-08-23 12:12 UTC (permalink / raw)
To: Shilimkar, Santosh
Cc: linux-arm-kernel, Russell King, linux-kernel, Kevin Hilman,
Tony Lindgren
On Thursday 23 August 2012, Shilimkar, Santosh wrote:
> I see your point but alternate patch is pushing down the fix to the low
> level driver and that means you end up patching more drivers when they
> use COUPLE idle infrastructure. That was the only reason I was thinking
> of suppressing the error at the source.
>
> Since it is just for the random builds and actually doesn't impact the real
> functionality as such, I am fine with your proposed patch too.
Ok. It would be nice of course to test if this actually works on uniprocessor
configurations.
Arnd
^ permalink raw reply [flat|nested] 42+ messages in thread
* [PATCH 2/6] ARM: omap: allow building omap44xx without SMP
2012-08-23 12:12 ` Arnd Bergmann
@ 2012-08-23 13:00 ` Shilimkar, Santosh
-1 siblings, 0 replies; 42+ messages in thread
From: Shilimkar, Santosh @ 2012-08-23 13:00 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Aug 23, 2012 at 5:42 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>
> On Thursday 23 August 2012, Shilimkar, Santosh wrote:
> > I see your point but alternate patch is pushing down the fix to the low
> > level driver and that means you end up patching more drivers when they
> > use COUPLE idle infrastructure. That was the only reason I was thinking
> > of suppressing the error at the source.
> >
> > Since it is just for the random builds and actually doesn't impact the
> > real
> > functionality as such, I am fine with your proposed patch too.
>
> Ok. It would be nice of course to test if this actually works on
> uniprocessor
> configurations.
>
Have tested the patch and it does boot with UP build on OMAP.
Acked-tested-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH 2/6] ARM: omap: allow building omap44xx without SMP
@ 2012-08-23 13:00 ` Shilimkar, Santosh
0 siblings, 0 replies; 42+ messages in thread
From: Shilimkar, Santosh @ 2012-08-23 13:00 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-arm-kernel, Russell King, linux-kernel, Kevin Hilman,
Tony Lindgren
On Thu, Aug 23, 2012 at 5:42 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>
> On Thursday 23 August 2012, Shilimkar, Santosh wrote:
> > I see your point but alternate patch is pushing down the fix to the low
> > level driver and that means you end up patching more drivers when they
> > use COUPLE idle infrastructure. That was the only reason I was thinking
> > of suppressing the error at the source.
> >
> > Since it is just for the random builds and actually doesn't impact the
> > real
> > functionality as such, I am fine with your proposed patch too.
>
> Ok. It would be nice of course to test if this actually works on
> uniprocessor
> configurations.
>
Have tested the patch and it does boot with UP build on OMAP.
Acked-tested-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
^ permalink raw reply [flat|nested] 42+ messages in thread
* [PATCH 2/6] ARM: omap: allow building omap44xx without SMP
2012-08-23 13:00 ` Shilimkar, Santosh
@ 2012-08-23 13:32 ` Arnd Bergmann
-1 siblings, 0 replies; 42+ messages in thread
From: Arnd Bergmann @ 2012-08-23 13:32 UTC (permalink / raw)
To: linux-arm-kernel
On Thursday 23 August 2012, Shilimkar, Santosh wrote:
>
> On Thu, Aug 23, 2012 at 5:42 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> >
> > On Thursday 23 August 2012, Shilimkar, Santosh wrote:
> > > I see your point but alternate patch is pushing down the fix to the low
> > > level driver and that means you end up patching more drivers when they
> > > use COUPLE idle infrastructure. That was the only reason I was thinking
> > > of suppressing the error at the source.
> > >
> > > Since it is just for the random builds and actually doesn't impact the
> > > real
> > > functionality as such, I am fine with your proposed patch too.
> >
> > Ok. It would be nice of course to test if this actually works on
> > uniprocessor
> > configurations.
> >
> Have tested the patch and it does boot with UP build on OMAP.
>
> Acked-tested-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Ok, thanks a lot!
Arnd
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH 2/6] ARM: omap: allow building omap44xx without SMP
@ 2012-08-23 13:32 ` Arnd Bergmann
0 siblings, 0 replies; 42+ messages in thread
From: Arnd Bergmann @ 2012-08-23 13:32 UTC (permalink / raw)
To: Shilimkar, Santosh
Cc: linux-arm-kernel, Russell King, linux-kernel, Kevin Hilman,
Tony Lindgren
On Thursday 23 August 2012, Shilimkar, Santosh wrote:
>
> On Thu, Aug 23, 2012 at 5:42 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> >
> > On Thursday 23 August 2012, Shilimkar, Santosh wrote:
> > > I see your point but alternate patch is pushing down the fix to the low
> > > level driver and that means you end up patching more drivers when they
> > > use COUPLE idle infrastructure. That was the only reason I was thinking
> > > of suppressing the error at the source.
> > >
> > > Since it is just for the random builds and actually doesn't impact the
> > > real
> > > functionality as such, I am fine with your proposed patch too.
> >
> > Ok. It would be nice of course to test if this actually works on
> > uniprocessor
> > configurations.
> >
> Have tested the patch and it does boot with UP build on OMAP.
>
> Acked-tested-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Ok, thanks a lot!
Arnd
^ permalink raw reply [flat|nested] 42+ messages in thread
* [PATCH 3/6] ARM: imx: build pm-imx5 code only when PM is enabled
2012-08-22 15:13 ` Arnd Bergmann
@ 2012-08-22 15:13 ` Arnd Bergmann
-1 siblings, 0 replies; 42+ messages in thread
From: Arnd Bergmann @ 2012-08-22 15:13 UTC (permalink / raw)
To: linux-arm-kernel
This moves the imx5 pm code out of the list of unconditionally
compiled files for imx5, mirroring what we already do for imx6
and how it was done before the code was move from mach-mx5 to
mach-imx in v3.3.
Without this patch, building with CONFIG_PM disabled results in:
arch/arm/mach-imx/pm-imx5.c:202:116: error: redefinition of 'imx51_pm_init'
arch/arm/mach-imx/include/mach-imx/common.h:154:91: note: previous definition of 'imx51_pm_init' was here
arch/arm/mach-imx/pm-imx5.c:209:116: error: redefinition of 'imx53_pm_init'
arch/arm/mach-imx/include/mach-imx/common.h:155:91: note: previous definition of 'imx53_pm_init' was here
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Shawn Guo <shawn.guo@linaro.org>
Cc: Sascha Hauer <s.hauer@pengutronix.de>
Cc: stable at vger.kernel.org
---
arch/arm/mach-imx/Makefile | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-imx/Makefile b/arch/arm/mach-imx/Makefile
index 07f7c22..e08adb7 100644
--- a/arch/arm/mach-imx/Makefile
+++ b/arch/arm/mach-imx/Makefile
@@ -9,7 +9,8 @@ obj-$(CONFIG_SOC_IMX27) += clk-imx27.o mm-imx27.o ehci-imx27.o
obj-$(CONFIG_SOC_IMX31) += mm-imx3.o cpu-imx31.o clk-imx31.o iomux-imx31.o ehci-imx31.o pm-imx3.o
obj-$(CONFIG_SOC_IMX35) += mm-imx3.o cpu-imx35.o clk-imx35.o ehci-imx35.o pm-imx3.o
-obj-$(CONFIG_SOC_IMX5) += cpu-imx5.o mm-imx5.o clk-imx51-imx53.o ehci-imx5.o pm-imx5.o cpu_op-mx51.o
+imx5-pm-$(CONFIG_PM) += pm-imx5.o
+obj-$(CONFIG_SOC_IMX5) += cpu-imx5.o mm-imx5.o clk-imx51-imx53.o ehci-imx5.o $(imx5-pm-y) cpu_op-mx51.o
obj-$(CONFIG_COMMON_CLK) += clk-pllv1.o clk-pllv2.o clk-pllv3.o clk-gate2.o \
clk-pfd.o clk-busy.o
--
1.7.10
^ permalink raw reply related [flat|nested] 42+ messages in thread
* [PATCH 3/6] ARM: imx: build pm-imx5 code only when PM is enabled
@ 2012-08-22 15:13 ` Arnd Bergmann
0 siblings, 0 replies; 42+ messages in thread
From: Arnd Bergmann @ 2012-08-22 15:13 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Russell King, linux-kernel, Arnd Bergmann, Shawn Guo,
Sascha Hauer, stable
This moves the imx5 pm code out of the list of unconditionally
compiled files for imx5, mirroring what we already do for imx6
and how it was done before the code was move from mach-mx5 to
mach-imx in v3.3.
Without this patch, building with CONFIG_PM disabled results in:
arch/arm/mach-imx/pm-imx5.c:202:116: error: redefinition of 'imx51_pm_init'
arch/arm/mach-imx/include/mach-imx/common.h:154:91: note: previous definition of 'imx51_pm_init' was here
arch/arm/mach-imx/pm-imx5.c:209:116: error: redefinition of 'imx53_pm_init'
arch/arm/mach-imx/include/mach-imx/common.h:155:91: note: previous definition of 'imx53_pm_init' was here
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Shawn Guo <shawn.guo@linaro.org>
Cc: Sascha Hauer <s.hauer@pengutronix.de>
Cc: stable@vger.kernel.org
---
arch/arm/mach-imx/Makefile | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-imx/Makefile b/arch/arm/mach-imx/Makefile
index 07f7c22..e08adb7 100644
--- a/arch/arm/mach-imx/Makefile
+++ b/arch/arm/mach-imx/Makefile
@@ -9,7 +9,8 @@ obj-$(CONFIG_SOC_IMX27) += clk-imx27.o mm-imx27.o ehci-imx27.o
obj-$(CONFIG_SOC_IMX31) += mm-imx3.o cpu-imx31.o clk-imx31.o iomux-imx31.o ehci-imx31.o pm-imx3.o
obj-$(CONFIG_SOC_IMX35) += mm-imx3.o cpu-imx35.o clk-imx35.o ehci-imx35.o pm-imx3.o
-obj-$(CONFIG_SOC_IMX5) += cpu-imx5.o mm-imx5.o clk-imx51-imx53.o ehci-imx5.o pm-imx5.o cpu_op-mx51.o
+imx5-pm-$(CONFIG_PM) += pm-imx5.o
+obj-$(CONFIG_SOC_IMX5) += cpu-imx5.o mm-imx5.o clk-imx51-imx53.o ehci-imx5.o $(imx5-pm-y) cpu_op-mx51.o
obj-$(CONFIG_COMMON_CLK) += clk-pllv1.o clk-pllv2.o clk-pllv3.o clk-gate2.o \
clk-pfd.o clk-busy.o
--
1.7.10
^ permalink raw reply related [flat|nested] 42+ messages in thread
* [PATCH 3/6] ARM: imx: build pm-imx5 code only when PM is enabled
2012-08-22 15:13 ` Arnd Bergmann
@ 2012-08-23 2:07 ` Shawn Guo
-1 siblings, 0 replies; 42+ messages in thread
From: Shawn Guo @ 2012-08-23 2:07 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, Aug 22, 2012 at 05:13:07PM +0200, Arnd Bergmann wrote:
> This moves the imx5 pm code out of the list of unconditionally
> compiled files for imx5, mirroring what we already do for imx6
> and how it was done before the code was move from mach-mx5 to
> mach-imx in v3.3.
>
> Without this patch, building with CONFIG_PM disabled results in:
>
> arch/arm/mach-imx/pm-imx5.c:202:116: error: redefinition of 'imx51_pm_init'
> arch/arm/mach-imx/include/mach-imx/common.h:154:91: note: previous definition of 'imx51_pm_init' was here
> arch/arm/mach-imx/pm-imx5.c:209:116: error: redefinition of 'imx53_pm_init'
> arch/arm/mach-imx/include/mach-imx/common.h:155:91: note: previous definition of 'imx53_pm_init' was here
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Shawn Guo <shawn.guo@linaro.org>
> Cc: Sascha Hauer <s.hauer@pengutronix.de>
> Cc: stable at vger.kernel.org
Acked-by: Shawn Guo <shawn.guo@linaro.org>
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH 3/6] ARM: imx: build pm-imx5 code only when PM is enabled
@ 2012-08-23 2:07 ` Shawn Guo
0 siblings, 0 replies; 42+ messages in thread
From: Shawn Guo @ 2012-08-23 2:07 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-arm-kernel, Russell King, linux-kernel, Sascha Hauer,
stable
On Wed, Aug 22, 2012 at 05:13:07PM +0200, Arnd Bergmann wrote:
> This moves the imx5 pm code out of the list of unconditionally
> compiled files for imx5, mirroring what we already do for imx6
> and how it was done before the code was move from mach-mx5 to
> mach-imx in v3.3.
>
> Without this patch, building with CONFIG_PM disabled results in:
>
> arch/arm/mach-imx/pm-imx5.c:202:116: error: redefinition of 'imx51_pm_init'
> arch/arm/mach-imx/include/mach-imx/common.h:154:91: note: previous definition of 'imx51_pm_init' was here
> arch/arm/mach-imx/pm-imx5.c:209:116: error: redefinition of 'imx53_pm_init'
> arch/arm/mach-imx/include/mach-imx/common.h:155:91: note: previous definition of 'imx53_pm_init' was here
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Shawn Guo <shawn.guo@linaro.org>
> Cc: Sascha Hauer <s.hauer@pengutronix.de>
> Cc: stable@vger.kernel.org
Acked-by: Shawn Guo <shawn.guo@linaro.org>
^ permalink raw reply [flat|nested] 42+ messages in thread
* [PATCH 4/6] ARM: imx: fix ksz9021rn_phy_fixup
2012-08-22 15:13 ` Arnd Bergmann
@ 2012-08-22 15:13 ` Arnd Bergmann
-1 siblings, 0 replies; 42+ messages in thread
From: Arnd Bergmann @ 2012-08-22 15:13 UTC (permalink / raw)
To: linux-arm-kernel
The ksz9021rn_phy_fixup and mx6q_sabrelite functions try to
set up an ethernet phy if they can. They do check whether
phylib is enabled, but unfortunately the functions can only
be called from platform code if phylib is builtin, not
if it is a module
Without this patch, building with a modular phylib results in:
arch/arm/mach-imx/mach-imx6q.c: In function 'imx6q_sabrelite_init':
arch/arm/mach-imx/mach-imx6q.c:120:5: error: 'ksz9021rn_phy_fixup' undeclared (first use in this function)
arch/arm/mach-imx/mach-imx6q.c:120:5: note: each undeclared identifier is reported only once for each function it appears in
The bug was originally reported by Artem Bityutskiy but only
partially fixed in ef441806 "ARM: imx6q: register phy fixup only when
CONFIG_PHYLIB is enabled".
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Artem Bityutskiy <dedekind1@gmail.com>
Cc: Shawn Guo <shawn.guo@linaro.org>
Cc: Sascha Hauer <s.hauer@pengutronix.de>
---
arch/arm/mach-imx/mach-imx6q.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-imx/mach-imx6q.c b/arch/arm/mach-imx/mach-imx6q.c
index 5ec0608..045b3f6 100644
--- a/arch/arm/mach-imx/mach-imx6q.c
+++ b/arch/arm/mach-imx/mach-imx6q.c
@@ -71,7 +71,7 @@ soft:
/* For imx6q sabrelite board: set KSZ9021RN RGMII pad skew */
static int ksz9021rn_phy_fixup(struct phy_device *phydev)
{
- if (IS_ENABLED(CONFIG_PHYLIB)) {
+ if (IS_BUILTIN(CONFIG_PHYLIB)) {
/* min rx data delay */
phy_write(phydev, 0x0b, 0x8105);
phy_write(phydev, 0x0c, 0x0000);
@@ -112,7 +112,7 @@ put_clk:
static void __init imx6q_sabrelite_init(void)
{
- if (IS_ENABLED(CONFIG_PHYLIB))
+ if (IS_BUILTIN(CONFIG_PHYLIB))
phy_register_fixup_for_uid(PHY_ID_KSZ9021, MICREL_PHY_ID_MASK,
ksz9021rn_phy_fixup);
imx6q_sabrelite_cko1_setup();
--
1.7.10
^ permalink raw reply related [flat|nested] 42+ messages in thread* [PATCH 4/6] ARM: imx: fix ksz9021rn_phy_fixup
@ 2012-08-22 15:13 ` Arnd Bergmann
0 siblings, 0 replies; 42+ messages in thread
From: Arnd Bergmann @ 2012-08-22 15:13 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Russell King, linux-kernel, Arnd Bergmann, Artem Bityutskiy,
Shawn Guo, Sascha Hauer
The ksz9021rn_phy_fixup and mx6q_sabrelite functions try to
set up an ethernet phy if they can. They do check whether
phylib is enabled, but unfortunately the functions can only
be called from platform code if phylib is builtin, not
if it is a module
Without this patch, building with a modular phylib results in:
arch/arm/mach-imx/mach-imx6q.c: In function 'imx6q_sabrelite_init':
arch/arm/mach-imx/mach-imx6q.c:120:5: error: 'ksz9021rn_phy_fixup' undeclared (first use in this function)
arch/arm/mach-imx/mach-imx6q.c:120:5: note: each undeclared identifier is reported only once for each function it appears in
The bug was originally reported by Artem Bityutskiy but only
partially fixed in ef441806 "ARM: imx6q: register phy fixup only when
CONFIG_PHYLIB is enabled".
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Artem Bityutskiy <dedekind1@gmail.com>
Cc: Shawn Guo <shawn.guo@linaro.org>
Cc: Sascha Hauer <s.hauer@pengutronix.de>
---
arch/arm/mach-imx/mach-imx6q.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-imx/mach-imx6q.c b/arch/arm/mach-imx/mach-imx6q.c
index 5ec0608..045b3f6 100644
--- a/arch/arm/mach-imx/mach-imx6q.c
+++ b/arch/arm/mach-imx/mach-imx6q.c
@@ -71,7 +71,7 @@ soft:
/* For imx6q sabrelite board: set KSZ9021RN RGMII pad skew */
static int ksz9021rn_phy_fixup(struct phy_device *phydev)
{
- if (IS_ENABLED(CONFIG_PHYLIB)) {
+ if (IS_BUILTIN(CONFIG_PHYLIB)) {
/* min rx data delay */
phy_write(phydev, 0x0b, 0x8105);
phy_write(phydev, 0x0c, 0x0000);
@@ -112,7 +112,7 @@ put_clk:
static void __init imx6q_sabrelite_init(void)
{
- if (IS_ENABLED(CONFIG_PHYLIB))
+ if (IS_BUILTIN(CONFIG_PHYLIB))
phy_register_fixup_for_uid(PHY_ID_KSZ9021, MICREL_PHY_ID_MASK,
ksz9021rn_phy_fixup);
imx6q_sabrelite_cko1_setup();
--
1.7.10
^ permalink raw reply related [flat|nested] 42+ messages in thread* [PATCH 4/6] ARM: imx: fix ksz9021rn_phy_fixup
2012-08-22 15:13 ` Arnd Bergmann
@ 2012-08-23 2:10 ` Shawn Guo
-1 siblings, 0 replies; 42+ messages in thread
From: Shawn Guo @ 2012-08-23 2:10 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, Aug 22, 2012 at 05:13:08PM +0200, Arnd Bergmann wrote:
> The ksz9021rn_phy_fixup and mx6q_sabrelite functions try to
> set up an ethernet phy if they can. They do check whether
> phylib is enabled, but unfortunately the functions can only
> be called from platform code if phylib is builtin, not
> if it is a module
>
> Without this patch, building with a modular phylib results in:
>
> arch/arm/mach-imx/mach-imx6q.c: In function 'imx6q_sabrelite_init':
> arch/arm/mach-imx/mach-imx6q.c:120:5: error: 'ksz9021rn_phy_fixup' undeclared (first use in this function)
> arch/arm/mach-imx/mach-imx6q.c:120:5: note: each undeclared identifier is reported only once for each function it appears in
>
> The bug was originally reported by Artem Bityutskiy but only
> partially fixed in ef441806 "ARM: imx6q: register phy fixup only when
> CONFIG_PHYLIB is enabled".
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Artem Bityutskiy <dedekind1@gmail.com>
> Cc: Shawn Guo <shawn.guo@linaro.org>
> Cc: Sascha Hauer <s.hauer@pengutronix.de>
Acked-by: Shawn Guo <shawn.guo@linaro.org>
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH 4/6] ARM: imx: fix ksz9021rn_phy_fixup
@ 2012-08-23 2:10 ` Shawn Guo
0 siblings, 0 replies; 42+ messages in thread
From: Shawn Guo @ 2012-08-23 2:10 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-arm-kernel, Russell King, linux-kernel, Artem Bityutskiy,
Sascha Hauer
On Wed, Aug 22, 2012 at 05:13:08PM +0200, Arnd Bergmann wrote:
> The ksz9021rn_phy_fixup and mx6q_sabrelite functions try to
> set up an ethernet phy if they can. They do check whether
> phylib is enabled, but unfortunately the functions can only
> be called from platform code if phylib is builtin, not
> if it is a module
>
> Without this patch, building with a modular phylib results in:
>
> arch/arm/mach-imx/mach-imx6q.c: In function 'imx6q_sabrelite_init':
> arch/arm/mach-imx/mach-imx6q.c:120:5: error: 'ksz9021rn_phy_fixup' undeclared (first use in this function)
> arch/arm/mach-imx/mach-imx6q.c:120:5: note: each undeclared identifier is reported only once for each function it appears in
>
> The bug was originally reported by Artem Bityutskiy but only
> partially fixed in ef441806 "ARM: imx6q: register phy fixup only when
> CONFIG_PHYLIB is enabled".
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Artem Bityutskiy <dedekind1@gmail.com>
> Cc: Shawn Guo <shawn.guo@linaro.org>
> Cc: Sascha Hauer <s.hauer@pengutronix.de>
Acked-by: Shawn Guo <shawn.guo@linaro.org>
^ permalink raw reply [flat|nested] 42+ messages in thread
* [PATCH 5/6] ARM: imx: select CPU_FREQ_TABLE when needed
2012-08-22 15:13 ` Arnd Bergmann
@ 2012-08-22 15:13 ` Arnd Bergmann
-1 siblings, 0 replies; 42+ messages in thread
From: Arnd Bergmann @ 2012-08-22 15:13 UTC (permalink / raw)
To: linux-arm-kernel
The i.MX cpufreq implementation uses the CPU_FREQ_TABLE helpers,
so it needs to select that code to be built. This problem has
apparently existed since the i.MX cpufreq code was first merged
in v3.6.37.
Building IMX without CPU_FREQ_TABLE results in:
arch/arm/plat-mxc/built-in.o: In function `mxc_cpufreq_exit':
arch/arm/plat-mxc/cpufreq.c:173: undefined reference to `cpufreq_frequency_table_put_attr'
arch/arm/plat-mxc/built-in.o: In function `mxc_set_target':
arch/arm/plat-mxc/cpufreq.c:84: undefined reference to `cpufreq_frequency_table_target'
arch/arm/plat-mxc/built-in.o: In function `mxc_verify_speed':
arch/arm/plat-mxc/cpufreq.c:65: undefined reference to `cpufreq_frequency_table_verify'
arch/arm/plat-mxc/built-in.o: In function `mxc_cpufreq_init':
arch/arm/plat-mxc/cpufreq.c:154: undefined reference to `cpufreq_frequency_table_cpuinfo'
arch/arm/plat-mxc/cpufreq.c:162: undefined reference to `cpufreq_frequency_table_get_attr'
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Sascha Hauer <s.hauer@pengutronix.de>
Cc: Yong Shen <yong.shen@linaro.org>
Cc: Shawn Guo <shawn.guo@freescale.com>
Cc: stable at vger.kernel.org
---
arch/arm/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index e91c7cd..84b5a0c 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -2150,6 +2150,7 @@ source "drivers/cpufreq/Kconfig"
config CPU_FREQ_IMX
tristate "CPUfreq driver for i.MX CPUs"
depends on ARCH_MXC && CPU_FREQ
+ select CPU_FREQ_TABLE
help
This enables the CPUfreq driver for i.MX CPUs.
--
1.7.10
^ permalink raw reply related [flat|nested] 42+ messages in thread
* [PATCH 5/6] ARM: imx: select CPU_FREQ_TABLE when needed
@ 2012-08-22 15:13 ` Arnd Bergmann
0 siblings, 0 replies; 42+ messages in thread
From: Arnd Bergmann @ 2012-08-22 15:13 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Russell King, linux-kernel, Arnd Bergmann, Sascha Hauer,
Yong Shen, Shawn Guo, stable
The i.MX cpufreq implementation uses the CPU_FREQ_TABLE helpers,
so it needs to select that code to be built. This problem has
apparently existed since the i.MX cpufreq code was first merged
in v3.6.37.
Building IMX without CPU_FREQ_TABLE results in:
arch/arm/plat-mxc/built-in.o: In function `mxc_cpufreq_exit':
arch/arm/plat-mxc/cpufreq.c:173: undefined reference to `cpufreq_frequency_table_put_attr'
arch/arm/plat-mxc/built-in.o: In function `mxc_set_target':
arch/arm/plat-mxc/cpufreq.c:84: undefined reference to `cpufreq_frequency_table_target'
arch/arm/plat-mxc/built-in.o: In function `mxc_verify_speed':
arch/arm/plat-mxc/cpufreq.c:65: undefined reference to `cpufreq_frequency_table_verify'
arch/arm/plat-mxc/built-in.o: In function `mxc_cpufreq_init':
arch/arm/plat-mxc/cpufreq.c:154: undefined reference to `cpufreq_frequency_table_cpuinfo'
arch/arm/plat-mxc/cpufreq.c:162: undefined reference to `cpufreq_frequency_table_get_attr'
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Sascha Hauer <s.hauer@pengutronix.de>
Cc: Yong Shen <yong.shen@linaro.org>
Cc: Shawn Guo <shawn.guo@freescale.com>
Cc: stable@vger.kernel.org
---
arch/arm/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index e91c7cd..84b5a0c 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -2150,6 +2150,7 @@ source "drivers/cpufreq/Kconfig"
config CPU_FREQ_IMX
tristate "CPUfreq driver for i.MX CPUs"
depends on ARCH_MXC && CPU_FREQ
+ select CPU_FREQ_TABLE
help
This enables the CPUfreq driver for i.MX CPUs.
--
1.7.10
^ permalink raw reply related [flat|nested] 42+ messages in thread
* [PATCH 5/6] ARM: imx: select CPU_FREQ_TABLE when needed
2012-08-22 15:13 ` Arnd Bergmann
@ 2012-08-23 2:13 ` Shawn Guo
-1 siblings, 0 replies; 42+ messages in thread
From: Shawn Guo @ 2012-08-23 2:13 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, Aug 22, 2012 at 05:13:09PM +0200, Arnd Bergmann wrote:
> The i.MX cpufreq implementation uses the CPU_FREQ_TABLE helpers,
> so it needs to select that code to be built. This problem has
> apparently existed since the i.MX cpufreq code was first merged
> in v3.6.37.
>
s/v3.6.37/v2.6.37?
Otherwise,
Acked-by: Shawn Guo <shawn.guo@linaro.org>
> Building IMX without CPU_FREQ_TABLE results in:
>
> arch/arm/plat-mxc/built-in.o: In function `mxc_cpufreq_exit':
> arch/arm/plat-mxc/cpufreq.c:173: undefined reference to `cpufreq_frequency_table_put_attr'
> arch/arm/plat-mxc/built-in.o: In function `mxc_set_target':
> arch/arm/plat-mxc/cpufreq.c:84: undefined reference to `cpufreq_frequency_table_target'
> arch/arm/plat-mxc/built-in.o: In function `mxc_verify_speed':
> arch/arm/plat-mxc/cpufreq.c:65: undefined reference to `cpufreq_frequency_table_verify'
> arch/arm/plat-mxc/built-in.o: In function `mxc_cpufreq_init':
> arch/arm/plat-mxc/cpufreq.c:154: undefined reference to `cpufreq_frequency_table_cpuinfo'
> arch/arm/plat-mxc/cpufreq.c:162: undefined reference to `cpufreq_frequency_table_get_attr'
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Sascha Hauer <s.hauer@pengutronix.de>
> Cc: Yong Shen <yong.shen@linaro.org>
> Cc: Shawn Guo <shawn.guo@freescale.com>
> Cc: stable at vger.kernel.org
> ---
> arch/arm/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index e91c7cd..84b5a0c 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -2150,6 +2150,7 @@ source "drivers/cpufreq/Kconfig"
> config CPU_FREQ_IMX
> tristate "CPUfreq driver for i.MX CPUs"
> depends on ARCH_MXC && CPU_FREQ
> + select CPU_FREQ_TABLE
> help
> This enables the CPUfreq driver for i.MX CPUs.
>
> --
> 1.7.10
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH 5/6] ARM: imx: select CPU_FREQ_TABLE when needed
@ 2012-08-23 2:13 ` Shawn Guo
0 siblings, 0 replies; 42+ messages in thread
From: Shawn Guo @ 2012-08-23 2:13 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-arm-kernel, Russell King, linux-kernel, Sascha Hauer,
Yong Shen, Shawn Guo, stable
On Wed, Aug 22, 2012 at 05:13:09PM +0200, Arnd Bergmann wrote:
> The i.MX cpufreq implementation uses the CPU_FREQ_TABLE helpers,
> so it needs to select that code to be built. This problem has
> apparently existed since the i.MX cpufreq code was first merged
> in v3.6.37.
>
s/v3.6.37/v2.6.37?
Otherwise,
Acked-by: Shawn Guo <shawn.guo@linaro.org>
> Building IMX without CPU_FREQ_TABLE results in:
>
> arch/arm/plat-mxc/built-in.o: In function `mxc_cpufreq_exit':
> arch/arm/plat-mxc/cpufreq.c:173: undefined reference to `cpufreq_frequency_table_put_attr'
> arch/arm/plat-mxc/built-in.o: In function `mxc_set_target':
> arch/arm/plat-mxc/cpufreq.c:84: undefined reference to `cpufreq_frequency_table_target'
> arch/arm/plat-mxc/built-in.o: In function `mxc_verify_speed':
> arch/arm/plat-mxc/cpufreq.c:65: undefined reference to `cpufreq_frequency_table_verify'
> arch/arm/plat-mxc/built-in.o: In function `mxc_cpufreq_init':
> arch/arm/plat-mxc/cpufreq.c:154: undefined reference to `cpufreq_frequency_table_cpuinfo'
> arch/arm/plat-mxc/cpufreq.c:162: undefined reference to `cpufreq_frequency_table_get_attr'
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Sascha Hauer <s.hauer@pengutronix.de>
> Cc: Yong Shen <yong.shen@linaro.org>
> Cc: Shawn Guo <shawn.guo@freescale.com>
> Cc: stable@vger.kernel.org
> ---
> arch/arm/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index e91c7cd..84b5a0c 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -2150,6 +2150,7 @@ source "drivers/cpufreq/Kconfig"
> config CPU_FREQ_IMX
> tristate "CPUfreq driver for i.MX CPUs"
> depends on ARCH_MXC && CPU_FREQ
> + select CPU_FREQ_TABLE
> help
> This enables the CPUfreq driver for i.MX CPUs.
>
> --
> 1.7.10
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 42+ messages in thread
* [PATCH 6/6] ARM: imx: select ARM_CPU_SUSPEND when necessary
2012-08-22 15:13 ` Arnd Bergmann
@ 2012-08-22 15:13 ` Arnd Bergmann
-1 siblings, 0 replies; 42+ messages in thread
From: Arnd Bergmann @ 2012-08-22 15:13 UTC (permalink / raw)
To: linux-arm-kernel
On i.MX6, we select ARM_CPU_SUSPEND when building with power management
support, but for some reason this was omitted on i.MX5. Normally we
build kernels for both together so the error only showed up in
randconfig tests.
Without this patch, building imx5 standalone results in:
arch/arm/mach-imx/built-in.o: In function `v7_cpu_resume':
arch/arm/mach-imx/head-v7.S:104: undefined reference to `cpu_resume'
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Eric Miao <eric.miao@linaro.org>
Cc: Shawn Guo <shawn.guo@linaro.org>
Cc: stable at vger.kernel.org
---
arch/arm/mach-imx/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
index afd542a..8e96573 100644
--- a/arch/arm/mach-imx/Kconfig
+++ b/arch/arm/mach-imx/Kconfig
@@ -89,6 +89,7 @@ config SOC_IMX5
select ARCH_MXC_IOMUX_V3
select ARCH_HAS_CPUFREQ
select ARCH_MX5
+ select ARM_CPU_SUSPEND if PM
bool
config SOC_IMX50
--
1.7.10
^ permalink raw reply related [flat|nested] 42+ messages in thread
* [PATCH 6/6] ARM: imx: select ARM_CPU_SUSPEND when necessary
@ 2012-08-22 15:13 ` Arnd Bergmann
0 siblings, 0 replies; 42+ messages in thread
From: Arnd Bergmann @ 2012-08-22 15:13 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Russell King, linux-kernel, Arnd Bergmann, Eric Miao, Shawn Guo,
stable
On i.MX6, we select ARM_CPU_SUSPEND when building with power management
support, but for some reason this was omitted on i.MX5. Normally we
build kernels for both together so the error only showed up in
randconfig tests.
Without this patch, building imx5 standalone results in:
arch/arm/mach-imx/built-in.o: In function `v7_cpu_resume':
arch/arm/mach-imx/head-v7.S:104: undefined reference to `cpu_resume'
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Eric Miao <eric.miao@linaro.org>
Cc: Shawn Guo <shawn.guo@linaro.org>
Cc: stable@vger.kernel.org
---
arch/arm/mach-imx/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
index afd542a..8e96573 100644
--- a/arch/arm/mach-imx/Kconfig
+++ b/arch/arm/mach-imx/Kconfig
@@ -89,6 +89,7 @@ config SOC_IMX5
select ARCH_MXC_IOMUX_V3
select ARCH_HAS_CPUFREQ
select ARCH_MX5
+ select ARM_CPU_SUSPEND if PM
bool
config SOC_IMX50
--
1.7.10
^ permalink raw reply related [flat|nested] 42+ messages in thread
* [PATCH 6/6] ARM: imx: select ARM_CPU_SUSPEND when necessary
2012-08-22 15:13 ` Arnd Bergmann
@ 2012-08-23 2:41 ` Shawn Guo
-1 siblings, 0 replies; 42+ messages in thread
From: Shawn Guo @ 2012-08-23 2:41 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, Aug 22, 2012 at 05:13:10PM +0200, Arnd Bergmann wrote:
> On i.MX6, we select ARM_CPU_SUSPEND when building with power management
> support, but for some reason this was omitted on i.MX5. Normally we
> build kernels for both together so the error only showed up in
> randconfig tests.
>
> Without this patch, building imx5 standalone results in:
>
> arch/arm/mach-imx/built-in.o: In function `v7_cpu_resume':
> arch/arm/mach-imx/head-v7.S:104: undefined reference to `cpu_resume'
>
So far, none of the functions in head-v7.S is used on imx5. Also
since imx5 SoCs implement State Retention Power Gating in hardware,
ARM_CPU_SUSPEND support will never be used on imx5.
Maybe we should make head-v7.S only compile for imx6?
Regards,
Shawn
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Eric Miao <eric.miao@linaro.org>
> Cc: Shawn Guo <shawn.guo@linaro.org>
> Cc: stable at vger.kernel.org
> ---
> arch/arm/mach-imx/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
> index afd542a..8e96573 100644
> --- a/arch/arm/mach-imx/Kconfig
> +++ b/arch/arm/mach-imx/Kconfig
> @@ -89,6 +89,7 @@ config SOC_IMX5
> select ARCH_MXC_IOMUX_V3
> select ARCH_HAS_CPUFREQ
> select ARCH_MX5
> + select ARM_CPU_SUSPEND if PM
> bool
>
> config SOC_IMX50
> --
> 1.7.10
>
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH 6/6] ARM: imx: select ARM_CPU_SUSPEND when necessary
@ 2012-08-23 2:41 ` Shawn Guo
0 siblings, 0 replies; 42+ messages in thread
From: Shawn Guo @ 2012-08-23 2:41 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-arm-kernel, Russell King, linux-kernel, Eric Miao, stable
On Wed, Aug 22, 2012 at 05:13:10PM +0200, Arnd Bergmann wrote:
> On i.MX6, we select ARM_CPU_SUSPEND when building with power management
> support, but for some reason this was omitted on i.MX5. Normally we
> build kernels for both together so the error only showed up in
> randconfig tests.
>
> Without this patch, building imx5 standalone results in:
>
> arch/arm/mach-imx/built-in.o: In function `v7_cpu_resume':
> arch/arm/mach-imx/head-v7.S:104: undefined reference to `cpu_resume'
>
So far, none of the functions in head-v7.S is used on imx5. Also
since imx5 SoCs implement State Retention Power Gating in hardware,
ARM_CPU_SUSPEND support will never be used on imx5.
Maybe we should make head-v7.S only compile for imx6?
Regards,
Shawn
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Eric Miao <eric.miao@linaro.org>
> Cc: Shawn Guo <shawn.guo@linaro.org>
> Cc: stable@vger.kernel.org
> ---
> arch/arm/mach-imx/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
> index afd542a..8e96573 100644
> --- a/arch/arm/mach-imx/Kconfig
> +++ b/arch/arm/mach-imx/Kconfig
> @@ -89,6 +89,7 @@ config SOC_IMX5
> select ARCH_MXC_IOMUX_V3
> select ARCH_HAS_CPUFREQ
> select ARCH_MX5
> + select ARM_CPU_SUSPEND if PM
> bool
>
> config SOC_IMX50
> --
> 1.7.10
>
^ permalink raw reply [flat|nested] 42+ messages in thread
* [PATCH 6/6] ARM: imx: select ARM_CPU_SUSPEND when necessary
2012-08-23 2:41 ` Shawn Guo
@ 2012-08-23 14:20 ` Arnd Bergmann
-1 siblings, 0 replies; 42+ messages in thread
From: Arnd Bergmann @ 2012-08-23 14:20 UTC (permalink / raw)
To: linux-arm-kernel
On Thursday 23 August 2012, Shawn Guo wrote:
> On Wed, Aug 22, 2012 at 05:13:10PM +0200, Arnd Bergmann wrote:
> > On i.MX6, we select ARM_CPU_SUSPEND when building with power management
> > support, but for some reason this was omitted on i.MX5. Normally we
> > build kernels for both together so the error only showed up in
> > randconfig tests.
> >
> > Without this patch, building imx5 standalone results in:
> >
> > arch/arm/mach-imx/built-in.o: In function `v7_cpu_resume':
> > arch/arm/mach-imx/head-v7.S:104: undefined reference to `cpu_resume'
> >
> So far, none of the functions in head-v7.S is used on imx5. Also
> since imx5 SoCs implement State Retention Power Gating in hardware,
> ARM_CPU_SUSPEND support will never be used on imx5.
>
> Maybe we should make head-v7.S only compile for imx6?
In tegra and shmobile, the respective file is called headsmp.S, so
I would suggest we rename it to the same here and only build it when
CONFIG_SMP is set, which comes down to imx6 at the moment.
How is this version?
Arnd
>From 4036e8f292887e7b1abc8eacec7d619abd608178 Mon Sep 17 00:00:00 2001
From: Arnd Bergmann <arnd@arndb.de>
Date: Fri, 17 Aug 2012 00:16:08 +0000
Subject: [PATCH] ARM: imx: build i.MX6 functions only when needed
The head-v7.S contains a call to the generic cpu_suspend function,
which is only available when selected by the i.MX6 code. As
pointed out by Shawn Guo, i.MX does not actually use any
functions defined in head-v7.S. It is also needed only for
the i.MX6 power management code and for the SMP code, so
we can restrict building this file to situations in which
at least one of those two is present.
Finally, other platforms with a similar file call it headsmp.S,
so we can rename it to the same for consistency.
Without this patch, building imx5 standalone results in:
arch/arm/mach-imx/built-in.o: In function `v7_cpu_resume':
arch/arm/mach-imx/head-v7.S:104: undefined reference to `cpu_resume'
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Eric Miao <eric.miao@linaro.org>
Cc: Shawn Guo <shawn.guo@linaro.org>
Cc: stable at vger.kernel.org
diff --git a/arch/arm/mach-imx/Makefile b/arch/arm/mach-imx/Makefile
index e08adb7..d004d37 100644
--- a/arch/arm/mach-imx/Makefile
+++ b/arch/arm/mach-imx/Makefile
@@ -71,14 +71,13 @@ obj-$(CONFIG_DEBUG_LL) += lluart.o
obj-$(CONFIG_HAVE_IMX_GPC) += gpc.o
obj-$(CONFIG_HAVE_IMX_MMDC) += mmdc.o
obj-$(CONFIG_HAVE_IMX_SRC) += src.o
-obj-$(CONFIG_CPU_V7) += head-v7.o
-AFLAGS_head-v7.o :=-Wa,-march=armv7-a
-obj-$(CONFIG_SMP) += platsmp.o
+AFLAGS_headsmp.o :=-Wa,-march=armv7-a
+obj-$(CONFIG_SMP) += headsmp.o platsmp.o
obj-$(CONFIG_HOTPLUG_CPU) += hotplug.o
obj-$(CONFIG_SOC_IMX6Q) += clk-imx6q.o mach-imx6q.o
ifeq ($(CONFIG_PM),y)
-obj-$(CONFIG_SOC_IMX6Q) += pm-imx6q.o
+obj-$(CONFIG_SOC_IMX6Q) += pm-imx6q.o headsmp.o
endif
# i.MX5 based machines
diff --git a/arch/arm/mach-imx/head-v7.S b/arch/arm/mach-imx/headsmp.S
similarity index 100%
rename from arch/arm/mach-imx/head-v7.S
rename to arch/arm/mach-imx/headsmp.S
^ permalink raw reply related [flat|nested] 42+ messages in thread
* Re: [PATCH 6/6] ARM: imx: select ARM_CPU_SUSPEND when necessary
@ 2012-08-23 14:20 ` Arnd Bergmann
0 siblings, 0 replies; 42+ messages in thread
From: Arnd Bergmann @ 2012-08-23 14:20 UTC (permalink / raw)
To: Shawn Guo; +Cc: linux-arm-kernel, Russell King, linux-kernel, Eric Miao, stable
On Thursday 23 August 2012, Shawn Guo wrote:
> On Wed, Aug 22, 2012 at 05:13:10PM +0200, Arnd Bergmann wrote:
> > On i.MX6, we select ARM_CPU_SUSPEND when building with power management
> > support, but for some reason this was omitted on i.MX5. Normally we
> > build kernels for both together so the error only showed up in
> > randconfig tests.
> >
> > Without this patch, building imx5 standalone results in:
> >
> > arch/arm/mach-imx/built-in.o: In function `v7_cpu_resume':
> > arch/arm/mach-imx/head-v7.S:104: undefined reference to `cpu_resume'
> >
> So far, none of the functions in head-v7.S is used on imx5. Also
> since imx5 SoCs implement State Retention Power Gating in hardware,
> ARM_CPU_SUSPEND support will never be used on imx5.
>
> Maybe we should make head-v7.S only compile for imx6?
In tegra and shmobile, the respective file is called headsmp.S, so
I would suggest we rename it to the same here and only build it when
CONFIG_SMP is set, which comes down to imx6 at the moment.
How is this version?
Arnd
>From 4036e8f292887e7b1abc8eacec7d619abd608178 Mon Sep 17 00:00:00 2001
From: Arnd Bergmann <arnd@arndb.de>
Date: Fri, 17 Aug 2012 00:16:08 +0000
Subject: [PATCH] ARM: imx: build i.MX6 functions only when needed
The head-v7.S contains a call to the generic cpu_suspend function,
which is only available when selected by the i.MX6 code. As
pointed out by Shawn Guo, i.MX does not actually use any
functions defined in head-v7.S. It is also needed only for
the i.MX6 power management code and for the SMP code, so
we can restrict building this file to situations in which
at least one of those two is present.
Finally, other platforms with a similar file call it headsmp.S,
so we can rename it to the same for consistency.
Without this patch, building imx5 standalone results in:
arch/arm/mach-imx/built-in.o: In function `v7_cpu_resume':
arch/arm/mach-imx/head-v7.S:104: undefined reference to `cpu_resume'
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Eric Miao <eric.miao@linaro.org>
Cc: Shawn Guo <shawn.guo@linaro.org>
Cc: stable@vger.kernel.org
diff --git a/arch/arm/mach-imx/Makefile b/arch/arm/mach-imx/Makefile
index e08adb7..d004d37 100644
--- a/arch/arm/mach-imx/Makefile
+++ b/arch/arm/mach-imx/Makefile
@@ -71,14 +71,13 @@ obj-$(CONFIG_DEBUG_LL) += lluart.o
obj-$(CONFIG_HAVE_IMX_GPC) += gpc.o
obj-$(CONFIG_HAVE_IMX_MMDC) += mmdc.o
obj-$(CONFIG_HAVE_IMX_SRC) += src.o
-obj-$(CONFIG_CPU_V7) += head-v7.o
-AFLAGS_head-v7.o :=-Wa,-march=armv7-a
-obj-$(CONFIG_SMP) += platsmp.o
+AFLAGS_headsmp.o :=-Wa,-march=armv7-a
+obj-$(CONFIG_SMP) += headsmp.o platsmp.o
obj-$(CONFIG_HOTPLUG_CPU) += hotplug.o
obj-$(CONFIG_SOC_IMX6Q) += clk-imx6q.o mach-imx6q.o
ifeq ($(CONFIG_PM),y)
-obj-$(CONFIG_SOC_IMX6Q) += pm-imx6q.o
+obj-$(CONFIG_SOC_IMX6Q) += pm-imx6q.o headsmp.o
endif
# i.MX5 based machines
diff --git a/arch/arm/mach-imx/head-v7.S b/arch/arm/mach-imx/headsmp.S
similarity index 100%
rename from arch/arm/mach-imx/head-v7.S
rename to arch/arm/mach-imx/headsmp.S
^ permalink raw reply related [flat|nested] 42+ messages in thread
* [PATCH 6/6] ARM: imx: select ARM_CPU_SUSPEND when necessary
2012-08-23 14:20 ` Arnd Bergmann
@ 2012-08-23 14:55 ` Shawn Guo
-1 siblings, 0 replies; 42+ messages in thread
From: Shawn Guo @ 2012-08-23 14:55 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Aug 23, 2012 at 02:20:50PM +0000, Arnd Bergmann wrote:
> From 4036e8f292887e7b1abc8eacec7d619abd608178 Mon Sep 17 00:00:00 2001
> From: Arnd Bergmann <arnd@arndb.de>
> Date: Fri, 17 Aug 2012 00:16:08 +0000
> Subject: [PATCH] ARM: imx: build i.MX6 functions only when needed
>
> The head-v7.S contains a call to the generic cpu_suspend function,
> which is only available when selected by the i.MX6 code. As
> pointed out by Shawn Guo, i.MX does not actually use any
s/i.MX/i.MX5
Acked-by: Shawn Guo <shawn.guo@linaro.org>
> functions defined in head-v7.S. It is also needed only for
> the i.MX6 power management code and for the SMP code, so
> we can restrict building this file to situations in which
> at least one of those two is present.
>
> Finally, other platforms with a similar file call it headsmp.S,
> so we can rename it to the same for consistency.
>
> Without this patch, building imx5 standalone results in:
>
> arch/arm/mach-imx/built-in.o: In function `v7_cpu_resume':
> arch/arm/mach-imx/head-v7.S:104: undefined reference to `cpu_resume'
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Eric Miao <eric.miao@linaro.org>
> Cc: Shawn Guo <shawn.guo@linaro.org>
> Cc: stable at vger.kernel.org
>
> diff --git a/arch/arm/mach-imx/Makefile b/arch/arm/mach-imx/Makefile
> index e08adb7..d004d37 100644
> --- a/arch/arm/mach-imx/Makefile
> +++ b/arch/arm/mach-imx/Makefile
> @@ -71,14 +71,13 @@ obj-$(CONFIG_DEBUG_LL) += lluart.o
> obj-$(CONFIG_HAVE_IMX_GPC) += gpc.o
> obj-$(CONFIG_HAVE_IMX_MMDC) += mmdc.o
> obj-$(CONFIG_HAVE_IMX_SRC) += src.o
> -obj-$(CONFIG_CPU_V7) += head-v7.o
> -AFLAGS_head-v7.o :=-Wa,-march=armv7-a
> -obj-$(CONFIG_SMP) += platsmp.o
> +AFLAGS_headsmp.o :=-Wa,-march=armv7-a
> +obj-$(CONFIG_SMP) += headsmp.o platsmp.o
> obj-$(CONFIG_HOTPLUG_CPU) += hotplug.o
> obj-$(CONFIG_SOC_IMX6Q) += clk-imx6q.o mach-imx6q.o
>
> ifeq ($(CONFIG_PM),y)
> -obj-$(CONFIG_SOC_IMX6Q) += pm-imx6q.o
> +obj-$(CONFIG_SOC_IMX6Q) += pm-imx6q.o headsmp.o
> endif
>
> # i.MX5 based machines
> diff --git a/arch/arm/mach-imx/head-v7.S b/arch/arm/mach-imx/headsmp.S
> similarity index 100%
> rename from arch/arm/mach-imx/head-v7.S
> rename to arch/arm/mach-imx/headsmp.S
--
Regards,
Shawn
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH 6/6] ARM: imx: select ARM_CPU_SUSPEND when necessary
@ 2012-08-23 14:55 ` Shawn Guo
0 siblings, 0 replies; 42+ messages in thread
From: Shawn Guo @ 2012-08-23 14:55 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-arm-kernel, Russell King, linux-kernel, Eric Miao, stable
On Thu, Aug 23, 2012 at 02:20:50PM +0000, Arnd Bergmann wrote:
> From 4036e8f292887e7b1abc8eacec7d619abd608178 Mon Sep 17 00:00:00 2001
> From: Arnd Bergmann <arnd@arndb.de>
> Date: Fri, 17 Aug 2012 00:16:08 +0000
> Subject: [PATCH] ARM: imx: build i.MX6 functions only when needed
>
> The head-v7.S contains a call to the generic cpu_suspend function,
> which is only available when selected by the i.MX6 code. As
> pointed out by Shawn Guo, i.MX does not actually use any
s/i.MX/i.MX5
Acked-by: Shawn Guo <shawn.guo@linaro.org>
> functions defined in head-v7.S. It is also needed only for
> the i.MX6 power management code and for the SMP code, so
> we can restrict building this file to situations in which
> at least one of those two is present.
>
> Finally, other platforms with a similar file call it headsmp.S,
> so we can rename it to the same for consistency.
>
> Without this patch, building imx5 standalone results in:
>
> arch/arm/mach-imx/built-in.o: In function `v7_cpu_resume':
> arch/arm/mach-imx/head-v7.S:104: undefined reference to `cpu_resume'
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Eric Miao <eric.miao@linaro.org>
> Cc: Shawn Guo <shawn.guo@linaro.org>
> Cc: stable@vger.kernel.org
>
> diff --git a/arch/arm/mach-imx/Makefile b/arch/arm/mach-imx/Makefile
> index e08adb7..d004d37 100644
> --- a/arch/arm/mach-imx/Makefile
> +++ b/arch/arm/mach-imx/Makefile
> @@ -71,14 +71,13 @@ obj-$(CONFIG_DEBUG_LL) += lluart.o
> obj-$(CONFIG_HAVE_IMX_GPC) += gpc.o
> obj-$(CONFIG_HAVE_IMX_MMDC) += mmdc.o
> obj-$(CONFIG_HAVE_IMX_SRC) += src.o
> -obj-$(CONFIG_CPU_V7) += head-v7.o
> -AFLAGS_head-v7.o :=-Wa,-march=armv7-a
> -obj-$(CONFIG_SMP) += platsmp.o
> +AFLAGS_headsmp.o :=-Wa,-march=armv7-a
> +obj-$(CONFIG_SMP) += headsmp.o platsmp.o
> obj-$(CONFIG_HOTPLUG_CPU) += hotplug.o
> obj-$(CONFIG_SOC_IMX6Q) += clk-imx6q.o mach-imx6q.o
>
> ifeq ($(CONFIG_PM),y)
> -obj-$(CONFIG_SOC_IMX6Q) += pm-imx6q.o
> +obj-$(CONFIG_SOC_IMX6Q) += pm-imx6q.o headsmp.o
> endif
>
> # i.MX5 based machines
> diff --git a/arch/arm/mach-imx/head-v7.S b/arch/arm/mach-imx/headsmp.S
> similarity index 100%
> rename from arch/arm/mach-imx/head-v7.S
> rename to arch/arm/mach-imx/headsmp.S
--
Regards,
Shawn
^ permalink raw reply [flat|nested] 42+ messages in thread