Hello maintainers,
I've kept these to myself for too long, and would like to get them into
v3.20. I hope all of these are noncontroversial, but please have
a look and provide an Ack/Nak where appropriate so we can stick
them into the first fixes pull request after the initial merge
for -rc1.
Arnd
Arnd Bergmann (11):
ARM: vexpress: use ARM_CPU_SUSPEND if needed
ARM: sunxi: always select RESET_CONTROLLER
ARM: BCM: put back ARCH_MULTI_V7 dependency for mobile
ARM: davinci: davinci_cfg_reg cannot be init
ARM: davinci: multi-soc kernels require AUTO_ZRELADDR
ARM: at91: fix pm declarations
ARM: prima2: do not select SMP_ON_UP
ARM: ixp4xx: fix {in,out}s{bwl} data types
ARM: rockchip: make rockchip_suspend_init conditional
ARM: sti: always enable RESET_CONTROLLER
ARM: mvebu: build armada375-smp code conditionally
arch/arm/mach-at91/generic.h | 8 ++++----
arch/arm/mach-bcm/Kconfig | 4 ++--
arch/arm/mach-davinci/Kconfig | 2 ++
arch/arm/mach-davinci/mux.c | 4 ++--
arch/arm/mach-ixp4xx/include/mach/io.h | 19 +++++++++++++------
arch/arm/mach-mvebu/system-controller.c | 2 +-
arch/arm/mach-prima2/Kconfig | 1 -
arch/arm/mach-rockchip/pm.h | 6 ++++++
arch/arm/mach-sti/Kconfig | 1 +
arch/arm/mach-sunxi/Kconfig | 8 ++------
arch/arm/mach-vexpress/Kconfig | 1 +
11 files changed, 34 insertions(+), 22 deletions(-)
--
2.1.0.rc2
Cc: Andrew Lunn <[email protected]>
Cc: Barry Song <[email protected]>
Cc: Christian Daudt <[email protected]>
Cc: Florian Fainelli <[email protected]>
Cc: Gregory Clement <[email protected]>
Cc: Heiko Stuebner <[email protected]>
Cc: Imre Kaloz <[email protected]>
Cc: Jason Cooper <[email protected]>
Cc: Kevin Hilman <[email protected]>
Cc: Krzysztof Halasa <[email protected]>
Cc: Liviu Dudau <[email protected]>
Cc: Lorenzo Pieralisi <[email protected]>
Cc: Maxime Coquelin <[email protected]>
Cc: Maxime Ripard <[email protected]>
Cc: Nicolas Ferre <[email protected]>
Cc: Sekhar Nori <[email protected]>
Cc: Srinivas Kandagatla <[email protected]>
Cc: Sudeep Holla <[email protected]>
The vexpress tc2 power management code calls mcpm_loopback, which
is only available if ARM_CPU_SUSPEND is enabled, otherwise we
get a link error:
arch/arm/mach-vexpress/built-in.o: In function `tc2_pm_init':
arch/arm/mach-vexpress/tc2_pm.c:389: undefined reference to `mcpm_loopback'
This explicitly selects ARM_CPU_SUSPEND like other platforms that
need it.
Signed-off-by: Arnd Bergmann <[email protected]>
Fixes: 3592d7e002438 ("ARM: 8082/1: TC2: test the MCPM loopback during boot")
Cc: Nicolas Pitre <[email protected]>
Cc: Kevin Hilman <[email protected]>
Cc: Liviu Dudau <[email protected]>
Cc: Sudeep Holla <[email protected]>
Cc: Lorenzo Pieralisi <[email protected]>
---
arch/arm/mach-vexpress/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-vexpress/Kconfig b/arch/arm/mach-vexpress/Kconfig
index d6b16d9a7838..3c2509b4b694 100644
--- a/arch/arm/mach-vexpress/Kconfig
+++ b/arch/arm/mach-vexpress/Kconfig
@@ -73,6 +73,7 @@ config ARCH_VEXPRESS_TC2_PM
depends on MCPM
select ARM_CCI
select ARCH_VEXPRESS_SPC
+ select ARM_CPU_SUSPEND
help
Support for CPU and cluster power management on Versatile Express
with a TC2 (A15x2 A7x3) big.LITTLE core tile.
--
2.1.0.rc2
A lot of drivers for mach-sunxi depend on RESET_CONTROLLER. While
this is selected for the drivers that have it, we keep running
into build errors in drivers that are used on both the SoCs with
and without a reset controller.
This patch moves the select statements into the common sunxi
Kconfig option, which solves multiple such problems.
Signed-off-by: Arnd Bergmann <[email protected]>
Cc: Maxime Ripard <[email protected]>
---
arch/arm/mach-sunxi/Kconfig | 8 ++------
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig
index a77604fbaf25..8f9f5abf5674 100644
--- a/arch/arm/mach-sunxi/Kconfig
+++ b/arch/arm/mach-sunxi/Kconfig
@@ -1,9 +1,11 @@
menuconfig ARCH_SUNXI
bool "Allwinner SoCs" if ARCH_MULTI_V7
select ARCH_REQUIRE_GPIOLIB
+ select ARCH_HAS_RESET_CONTROLLER
select CLKSRC_MMIO
select GENERIC_IRQ_CHIP
select PINCTRL
+ select RESET_CONTROLLER
select SUN4I_TIMER
if ARCH_SUNXI
@@ -20,10 +22,8 @@ config MACH_SUN5I
config MACH_SUN6I
bool "Allwinner A31 (sun6i) SoCs support"
default ARCH_SUNXI
- select ARCH_HAS_RESET_CONTROLLER
select ARM_GIC
select MFD_SUN6I_PRCM
- select RESET_CONTROLLER
select SUN5I_HSTIMER
config MACH_SUN7I
@@ -37,16 +37,12 @@ config MACH_SUN7I
config MACH_SUN8I
bool "Allwinner A23 (sun8i) SoCs support"
default ARCH_SUNXI
- select ARCH_HAS_RESET_CONTROLLER
select ARM_GIC
select MFD_SUN6I_PRCM
- select RESET_CONTROLLER
config MACH_SUN9I
bool "Allwinner (sun9i) SoCs support"
default ARCH_SUNXI
- select ARCH_HAS_RESET_CONTROLLER
select ARM_GIC
- select RESET_CONTROLLER
endif
--
2.1.0.rc2
A recent cleanup rearranged the Kconfig file for mach-bcm and
accidentally dropped the dependency on ARCH_MULTI_V7, which
makes it possible to now build the two mobile SoC platforms
on an ARMv6-only kernel, resulting in a log of Kconfig
warnings like
warning: ARCH_BCM_MOBILE selects ARM_ERRATA_775420 which has unmet direct dependencies (CPU_V7)
and which of course cannot work on any machine.
This puts back the dependencies as before.
Signed-off-by: Arnd Bergmann <[email protected]>
Fixes: 64e74aa788f99 ("ARM: mach-bcm: ARCH_BCM_MOBILE: remove one level of menu from Kconfig")
Cc: Florian Fainelli <[email protected]>
Cc: Christian Daudt <[email protected]>
Cc: Scott Branden <[email protected]>
---
arch/arm/mach-bcm/Kconfig | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-bcm/Kconfig b/arch/arm/mach-bcm/Kconfig
index aaeec78c3ec4..8b11f44bb36e 100644
--- a/arch/arm/mach-bcm/Kconfig
+++ b/arch/arm/mach-bcm/Kconfig
@@ -68,7 +68,7 @@ config ARCH_BCM_MOBILE
This enables support for systems based on Broadcom mobile SoCs.
config ARCH_BCM_281XX
- bool "Broadcom BCM281XX SoC family"
+ bool "Broadcom BCM281XX SoC family" if ARCH_MULTI_V7
select ARCH_BCM_MOBILE
select HAVE_SMP
help
@@ -77,7 +77,7 @@ config ARCH_BCM_281XX
variants.
config ARCH_BCM_21664
- bool "Broadcom BCM21664 SoC family"
+ bool "Broadcom BCM21664 SoC family" if ARCH_MULTI_V7
select ARCH_BCM_MOBILE
select HAVE_SMP
help
--
2.1.0.rc2
davinci_cfg_reg gets called from a lot of locations that
might get called after the init section has been discarded,
so the function itself must not be marked __init either.
The kernel build currently warns about this with lots of
messages like:
WARNING: vmlinux.o(.text.unlikely+0x24c): Section mismatch in reference from the function dm365evm_mmc_configure() to the function .init.text:davinci_cfg_reg()
The function dm365evm_mmc_configure() references
the function __init davinci_cfg_reg().
This is often because dm365evm_mmc_configure lacks a __init
annotation or the annotation of davinci_cfg_reg is wrong.
This removes the extraneous __init_or_module annotation.
Signed-off-by: Arnd Bergmann <[email protected]>
Cc: Sekhar Nori <[email protected]>
Cc: Kevin Hilman <[email protected]>
---
arch/arm/mach-davinci/mux.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-davinci/mux.c b/arch/arm/mach-davinci/mux.c
index a8eb909a2b6c..6a2ff0a654a5 100644
--- a/arch/arm/mach-davinci/mux.c
+++ b/arch/arm/mach-davinci/mux.c
@@ -30,7 +30,7 @@ static void __iomem *pinmux_base;
/*
* Sets the DAVINCI MUX register based on the table
*/
-int __init_or_module davinci_cfg_reg(const unsigned long index)
+int davinci_cfg_reg(const unsigned long index)
{
static DEFINE_SPINLOCK(mux_spin_lock);
struct davinci_soc_info *soc_info = &davinci_soc_info;
@@ -101,7 +101,7 @@ int __init_or_module davinci_cfg_reg(const unsigned long index)
}
EXPORT_SYMBOL(davinci_cfg_reg);
-int __init_or_module davinci_cfg_reg_list(const short pins[])
+int davinci_cfg_reg_list(const short pins[])
{
int i, error = -EINVAL;
--
2.1.0.rc2
The davinci DA8xx and DMx families have incompatible zreladdr
settings, and attempting to build a kernel with both enabled
results in an error unless AUTO_ZRELADDR is set:
multiple zreladdrs: 0xc0008000 0x80008000
This needs CONFIG_AUTO_ZRELADDR to be set
This patch changes Kconfig to make the two families mutually
exclusive when this is unset.
Signed-off-by: Arnd Bergmann <[email protected]>
Cc: Sekhar Nori <[email protected]>
Cc: Kevin Hilman <[email protected]>
---
arch/arm/mach-davinci/Kconfig | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/mach-davinci/Kconfig b/arch/arm/mach-davinci/Kconfig
index 584e8d4e2892..cd30f6f5f2ff 100644
--- a/arch/arm/mach-davinci/Kconfig
+++ b/arch/arm/mach-davinci/Kconfig
@@ -32,12 +32,14 @@ config ARCH_DAVINCI_DM646x
config ARCH_DAVINCI_DA830
bool "DA830/OMAP-L137/AM17x based system"
+ depends on !ARCH_DAVINCI_DMx || AUTO_ZRELADDR
select ARCH_DAVINCI_DA8XX
select CPU_DCACHE_WRITETHROUGH # needed on silicon revs 1.0, 1.1
select CP_INTC
config ARCH_DAVINCI_DA850
bool "DA850/OMAP-L138/AM18x based system"
+ depends on !ARCH_DAVINCI_DMx || AUTO_ZRELADDR
select ARCH_DAVINCI_DA8XX
select CP_INTC
--
2.1.0.rc2
In a recent rearrangement of the at91 pm initialization code, a broken
set of declarations was added for the !CONFIG_PM-case, leading to
this link error:
arch/arm/mach-at91/board-dt-sama5.o: In function `at91_rm9200_pm_init':
arch/arm/mach-at91/generic.h:40: multiple definition of `at91_rm9200_pm_init'
arch/arm/mach-at91/setup.o:arch/arm/mach-at91/generic.h:40: first defined here
arch/arm/mach-at91/board-dt-sama5.o: In function `at91_sam9260_pm_init':
arch/arm/mach-at91/generic.h:41: multiple definition of `at91_sam9260_pm_init'
arch/arm/mach-at91/setup.o:arch/arm/mach-at91/generic.h:41: first defined here
arch/arm/mach-at91/board-dt-sama5.o: In function `at91_sam9g45_pm_init':
arch/arm/mach-at91/generic.h:42: multiple definition of `at91_sam9g45_pm_init'
arch/arm/mach-at91/setup.o:arch/arm/mach-at91/generic.h:42: first defined here
This adds the missing 'static inline' to the declarations to avoid
creating a copy of the functions in each file that includes the
header.
Signed-off-by: Arnd Bergmann <[email protected]>
Fixes: 4db0ba22da9 ("ARM: at91: pm: prepare for multiplatform")
Cc: Nicolas Ferre <[email protected]>
Cc: Jean-Christophe Plagniol-Villard <[email protected]>
Cc: Alexandre Belloni <[email protected]>
---
arch/arm/mach-at91/generic.h | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-at91/generic.h b/arch/arm/mach-at91/generic.h
index a6e726a6e0b5..583369ffc284 100644
--- a/arch/arm/mach-at91/generic.h
+++ b/arch/arm/mach-at91/generic.h
@@ -35,10 +35,10 @@ extern void __init at91sam9260_pm_init(void);
extern void __init at91sam9g45_pm_init(void);
extern void __init at91sam9x5_pm_init(void);
#else
-void __init at91rm9200_pm_init(void) { }
-void __init at91sam9260_pm_init(void) { }
-void __init at91sam9g45_pm_init(void) { }
-void __init at91sam9x5_pm_init(void) { }
+static inline void __init at91rm9200_pm_init(void) { }
+static inline void __init at91sam9260_pm_init(void) { }
+static inline void __init at91sam9g45_pm_init(void) { }
+static inline void __init at91sam9x5_pm_init(void) { }
#endif
#endif /* _AT91_GENERIC_H */
--
2.1.0.rc2
The new Atlas7 platform implicitly selects 'CONFIG_SMP_ON_UP',
which leads to problems if we enable building the platform without
MMU, as that combination is not allowed and causes a link error:
arch/arm/kernel/built-in.o: In function `c_show':
:(.text+0x1872): undefined reference to `smp_on_up'
:(.text+0x1876): undefined reference to `smp_on_up'
arch/arm/kernel/built-in.o: In function `arch_irq_work_raise':
:(.text+0x3d48): undefined reference to `smp_on_up'
:(.text+0x3d4c): undefined reference to `smp_on_up'
arch/arm/kernel/built-in.o: In function `smp_setup_processor_id':
:(.init.text+0x180): undefined reference to `smp_on_up'
This removes the 'select' statement.
Signed-off-by: Arnd Bergmann <[email protected]>
Fixes: 4cba058526a7 ("ARM: sirf: add Atlas7 machine support")
Cc: Zhiwu Song <[email protected]>
Cc: Barry Song <[email protected]>
---
arch/arm/mach-prima2/Kconfig | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/mach-prima2/Kconfig b/arch/arm/mach-prima2/Kconfig
index a219dc310d5d..e03d8b5c9ad0 100644
--- a/arch/arm/mach-prima2/Kconfig
+++ b/arch/arm/mach-prima2/Kconfig
@@ -27,7 +27,6 @@ config ARCH_ATLAS7
select CPU_V7
select HAVE_ARM_SCU if SMP
select HAVE_SMP
- select SMP_ON_UP if SMP
help
Support for CSR SiRFSoC ARM Cortex A7 Platform
--
2.1.0.rc2
Most platforms use void pointer arguments in these functions, but
ixp4xx does not, which triggers lots of warnings in device drivers like:
net/ethernet/8390/ne2k-pci.c: In function 'ne2k_pci_get_8390_hdr':
net/ethernet/8390/ne2k-pci.c:503:3: warning: passing argument 2 of 'insw' from incompatible pointer type
insw(NE_BASE + NE_DATAPORT, hdr, sizeof(struct e8390_pkt_hdr)>>1);
^
In file included from include/asm/io.h:214:0,
from /git/arm-soc/include/linux/io.h:22,
from /git/arm-soc/include/linux/pci.h:31,
from net/ethernet/8390/ne2k-pci.c:48:
mach-ixp4xx/include/mach/io.h:316:91: note: expected 'u16 *' but argument is of type 'struct e8390_pkt_hdr *'
static inline void insw(u32 io_addr, u16 *vaddr, u32 count)
Fixing the drivers seems hopeless, so this changes the ixp4xx code
to do the same as the others to avoid the warnings.
Signed-off-by: Arnd Bergmann <[email protected]>
Cc: Imre Kaloz <[email protected]>
Cc: Krzysztof Halasa <[email protected]>
---
arch/arm/mach-ixp4xx/include/mach/io.h | 19 +++++++++++++------
1 file changed, 13 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-ixp4xx/include/mach/io.h b/arch/arm/mach-ixp4xx/include/mach/io.h
index 6a722860e34d..b02439019963 100644
--- a/arch/arm/mach-ixp4xx/include/mach/io.h
+++ b/arch/arm/mach-ixp4xx/include/mach/io.h
@@ -245,8 +245,10 @@ static inline void outb(u8 value, u32 addr)
}
#define outsb outsb
-static inline void outsb(u32 io_addr, const u8 *vaddr, u32 count)
+static inline void outsb(u32 io_addr, const void *p, u32 count)
{
+ const u8 *vaddr = p;
+
while (count--)
outb(*vaddr++, io_addr);
}
@@ -262,8 +264,9 @@ static inline void outw(u16 value, u32 addr)
}
#define outsw outsw
-static inline void outsw(u32 io_addr, const u16 *vaddr, u32 count)
+static inline void outsw(u32 io_addr, const void *p, u32 count)
{
+ const u16 *vaddr = p;
while (count--)
outw(cpu_to_le16(*vaddr++), io_addr);
}
@@ -275,8 +278,9 @@ static inline void outl(u32 value, u32 addr)
}
#define outsl outsl
-static inline void outsl(u32 io_addr, const u32 *vaddr, u32 count)
+static inline void outsl(u32 io_addr, const void *p, u32 count)
{
+ const u32 *vaddr = p;
while (count--)
outl(cpu_to_le32(*vaddr++), io_addr);
}
@@ -294,8 +298,9 @@ static inline u8 inb(u32 addr)
}
#define insb insb
-static inline void insb(u32 io_addr, u8 *vaddr, u32 count)
+static inline void insb(u32 io_addr, void *p, u32 count)
{
+ u8 *vaddr = p;
while (count--)
*vaddr++ = inb(io_addr);
}
@@ -313,8 +318,9 @@ static inline u16 inw(u32 addr)
}
#define insw insw
-static inline void insw(u32 io_addr, u16 *vaddr, u32 count)
+static inline void insw(u32 io_addr, void *p, u32 count)
{
+ u16 *vaddr = p;
while (count--)
*vaddr++ = le16_to_cpu(inw(io_addr));
}
@@ -330,8 +336,9 @@ static inline u32 inl(u32 addr)
}
#define insl insl
-static inline void insl(u32 io_addr, u32 *vaddr, u32 count)
+static inline void insl(u32 io_addr, void *p, u32 count)
{
+ u32 *vaddr = p;
while (count--)
*vaddr++ = le32_to_cpu(inl(io_addr));
}
--
2.1.0.rc2
If CONFIG_PM_SLEEP is disabled, we get a build error for rockchips:
arch/arm/mach-rockchip/built-in.o: In function `rockchip_dt_init':
:(.init.text+0x1c): undefined reference to `rockchip_suspend_init'
This adds an inline alternative for that case.
Signed-off-by: Arnd Bergmann <[email protected]>
Cc: Heiko Stuebner <[email protected]>
Cc: [email protected]
---
arch/arm/mach-rockchip/pm.h | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/mach-rockchip/pm.h b/arch/arm/mach-rockchip/pm.h
index 7d752ff39f91..7c889c04604b 100644
--- a/arch/arm/mach-rockchip/pm.h
+++ b/arch/arm/mach-rockchip/pm.h
@@ -24,7 +24,13 @@ extern unsigned long rkpm_bootdata_ddr_data;
extern unsigned long rk3288_bootram_sz;
void rockchip_slp_cpu_resume(void);
+#ifdef CONFIG_PM_SLEEP
void __init rockchip_suspend_init(void);
+#else
+static inline void rockchip_suspend_init(void)
+{
+}
+#endif
/****** following is rk3288 defined **********/
#define RK3288_PMU_WAKEUP_CFG0 0x00
--
2.1.0.rc2
A lot of the sti device drivers require reset controller support,
but do not all have individual 'depends on RESET_CONTROLLER'
statements. Using 'select' here once avoids a lot of build errors
resulting from this.
Signed-off-by: Arnd Bergmann <[email protected]>
Cc: Maxime Coquelin <[email protected]>
Cc: Srinivas Kandagatla <[email protected]>
Cc: Patrice Chotard <[email protected]>
---
arch/arm/mach-sti/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-sti/Kconfig b/arch/arm/mach-sti/Kconfig
index 8825bc9e2553..3b1ac463a494 100644
--- a/arch/arm/mach-sti/Kconfig
+++ b/arch/arm/mach-sti/Kconfig
@@ -13,6 +13,7 @@ menuconfig ARCH_STI
select ARM_ERRATA_775420
select PL310_ERRATA_753970 if CACHE_L2X0
select PL310_ERRATA_769419 if CACHE_L2X0
+ select RESET_CONTROLLER
help
Include support for STiH41x SOCs like STiH415/416 using the device tree
for discovery
--
2.1.0.rc2
mvebu_armada375_smp_wa_init is only used on armada 375 but is defined
for all mvebu machines. As it calls a function that is only provided
sometimes, this can result in a link error:
arch/arm/mach-mvebu/built-in.o: In function `mvebu_armada375_smp_wa_init':
:(.text+0x228): undefined reference to `mvebu_setup_boot_addr_wa'
To solve this, we can just change the existing #ifdef around the
function to also check for Armada375 SMP platforms.
Signed-off-by: Arnd Bergmann <[email protected]>
Fixes: 305969fb6292 ("ARM: mvebu: use the common function for Armada 375 SMP workaround")
Cc: Andrew Lunn <[email protected]>
Cc: Jason Cooper <[email protected]>
Cc: Gregory Clement <[email protected]>
---
arch/arm/mach-mvebu/system-controller.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-mvebu/system-controller.c b/arch/arm/mach-mvebu/system-controller.c
index a068cb5c2ce8..c6c132acd7a6 100644
--- a/arch/arm/mach-mvebu/system-controller.c
+++ b/arch/arm/mach-mvebu/system-controller.c
@@ -126,7 +126,7 @@ int mvebu_system_controller_get_soc_id(u32 *dev, u32 *rev)
return -ENODEV;
}
-#ifdef CONFIG_SMP
+#if defined(CONFIG_SMP) && defined(CONFIG_MACH_MVEBU_V7)
void mvebu_armada375_smp_wa_init(void)
{
u32 dev, rev;
--
2.1.0.rc2
2015-02-12 11:42 GMT-08:00 Arnd Bergmann <[email protected]>:
> A recent cleanup rearranged the Kconfig file for mach-bcm and
> accidentally dropped the dependency on ARCH_MULTI_V7, which
> makes it possible to now build the two mobile SoC platforms
> on an ARMv6-only kernel, resulting in a log of Kconfig
> warnings like
>
> warning: ARCH_BCM_MOBILE selects ARM_ERRATA_775420 which has unmet direct dependencies (CPU_V7)
>
> and which of course cannot work on any machine.
>
> This puts back the dependencies as before.
Since both of these Kconfig options also select ARCH_BCM_MOBILE, you
could put the select there instead?
>
> Signed-off-by: Arnd Bergmann <[email protected]>
> Fixes: 64e74aa788f99 ("ARM: mach-bcm: ARCH_BCM_MOBILE: remove one level of menu from Kconfig")
> Cc: Florian Fainelli <[email protected]>
> Cc: Christian Daudt <[email protected]>
> Cc: Scott Branden <[email protected]>
> ---
> arch/arm/mach-bcm/Kconfig | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/mach-bcm/Kconfig b/arch/arm/mach-bcm/Kconfig
> index aaeec78c3ec4..8b11f44bb36e 100644
> --- a/arch/arm/mach-bcm/Kconfig
> +++ b/arch/arm/mach-bcm/Kconfig
> @@ -68,7 +68,7 @@ config ARCH_BCM_MOBILE
> This enables support for systems based on Broadcom mobile SoCs.
>
> config ARCH_BCM_281XX
> - bool "Broadcom BCM281XX SoC family"
> + bool "Broadcom BCM281XX SoC family" if ARCH_MULTI_V7
> select ARCH_BCM_MOBILE
> select HAVE_SMP
> help
> @@ -77,7 +77,7 @@ config ARCH_BCM_281XX
> variants.
>
> config ARCH_BCM_21664
> - bool "Broadcom BCM21664 SoC family"
> + bool "Broadcom BCM21664 SoC family" if ARCH_MULTI_V7
> select ARCH_BCM_MOBILE
> select HAVE_SMP
> help
> --
> 2.1.0.rc2
>
--
Florian
> Florian Fainelli <[email protected]> hat am 12. Februar 2015 um 21:02
> geschrieben:
> 2015-02-12 11:42 GMT-08:00 Arnd Bergmann <[email protected]>:
> > A recent cleanup rearranged the Kconfig file for mach-bcm and
> > accidentally dropped the dependency on ARCH_MULTI_V7, which
> > makes it possible to now build the two mobile SoC platforms
> > on an ARMv6-only kernel, resulting in a log of Kconfig
> > warnings like
> >
> > warning: ARCH_BCM_MOBILE selects ARM_ERRATA_775420 which has unmet direct
> > dependencies (CPU_V7)
> >
> > and which of course cannot work on any machine.
> >
> > This puts back the dependencies as before.
>
> Since both of these Kconfig options also select ARCH_BCM_MOBILE, you
> could put the select there instead?
No, that would only work with 'select', but we need 'depends on' here.
Arnd
2015-02-12 11:42 GMT-08:00 Arnd Bergmann <[email protected]>:
> A recent cleanup rearranged the Kconfig file for mach-bcm and
> accidentally dropped the dependency on ARCH_MULTI_V7, which
> makes it possible to now build the two mobile SoC platforms
> on an ARMv6-only kernel, resulting in a log of Kconfig
> warnings like
>
> warning: ARCH_BCM_MOBILE selects ARM_ERRATA_775420 which has unmet direct dependencies (CPU_V7)
>
> and which of course cannot work on any machine.
>
> This puts back the dependencies as before.
>
> Signed-off-by: Arnd Bergmann <[email protected]>
> Fixes: 64e74aa788f99 ("ARM: mach-bcm: ARCH_BCM_MOBILE: remove one level of menu from Kconfig")
> Cc: Florian Fainelli <[email protected]>
> Cc: Christian Daudt <[email protected]>
> Cc: Scott Branden <[email protected]>
Acked-by: Florian Fainelli <[email protected]>
> ---
> arch/arm/mach-bcm/Kconfig | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/mach-bcm/Kconfig b/arch/arm/mach-bcm/Kconfig
> index aaeec78c3ec4..8b11f44bb36e 100644
> --- a/arch/arm/mach-bcm/Kconfig
> +++ b/arch/arm/mach-bcm/Kconfig
> @@ -68,7 +68,7 @@ config ARCH_BCM_MOBILE
> This enables support for systems based on Broadcom mobile SoCs.
>
> config ARCH_BCM_281XX
> - bool "Broadcom BCM281XX SoC family"
> + bool "Broadcom BCM281XX SoC family" if ARCH_MULTI_V7
> select ARCH_BCM_MOBILE
> select HAVE_SMP
> help
> @@ -77,7 +77,7 @@ config ARCH_BCM_281XX
> variants.
>
> config ARCH_BCM_21664
> - bool "Broadcom BCM21664 SoC family"
> + bool "Broadcom BCM21664 SoC family" if ARCH_MULTI_V7
> select ARCH_BCM_MOBILE
> select HAVE_SMP
> help
> --
> 2.1.0.rc2
>
--
Florian
On 15-02-12 01:57 PM, Florian Fainelli wrote:
> 2015-02-12 11:42 GMT-08:00 Arnd Bergmann <[email protected]>:
>> A recent cleanup rearranged the Kconfig file for mach-bcm and
>> accidentally dropped the dependency on ARCH_MULTI_V7, which
>> makes it possible to now build the two mobile SoC platforms
>> on an ARMv6-only kernel, resulting in a log of Kconfig
>> warnings like
>>
>> warning: ARCH_BCM_MOBILE selects ARM_ERRATA_775420 which has unmet direct dependencies (CPU_V7)
>>
>> and which of course cannot work on any machine.
>>
>> This puts back the dependencies as before.
>>
>> Signed-off-by: Arnd Bergmann <[email protected]>
>> Fixes: 64e74aa788f99 ("ARM: mach-bcm: ARCH_BCM_MOBILE: remove one level of menu from Kconfig")
>> Cc: Florian Fainelli <[email protected]>
>> Cc: Christian Daudt <[email protected]>
>> Cc: Scott Branden <[email protected]>
>
> Acked-by: Florian Fainelli <[email protected]>
Acked-by: Scott Branden <[email protected]>
>
>> ---
>> arch/arm/mach-bcm/Kconfig | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/arm/mach-bcm/Kconfig b/arch/arm/mach-bcm/Kconfig
>> index aaeec78c3ec4..8b11f44bb36e 100644
>> --- a/arch/arm/mach-bcm/Kconfig
>> +++ b/arch/arm/mach-bcm/Kconfig
>> @@ -68,7 +68,7 @@ config ARCH_BCM_MOBILE
>> This enables support for systems based on Broadcom mobile SoCs.
>>
>> config ARCH_BCM_281XX
>> - bool "Broadcom BCM281XX SoC family"
>> + bool "Broadcom BCM281XX SoC family" if ARCH_MULTI_V7
>> select ARCH_BCM_MOBILE
>> select HAVE_SMP
>> help
>> @@ -77,7 +77,7 @@ config ARCH_BCM_281XX
>> variants.
>>
>> config ARCH_BCM_21664
>> - bool "Broadcom BCM21664 SoC family"
>> + bool "Broadcom BCM21664 SoC family" if ARCH_MULTI_V7
>> select ARCH_BCM_MOBILE
>> select HAVE_SMP
>> help
>> --
>> 2.1.0.rc2
>>
>
>
>
On Thu, 12 Feb 2015, Arnd Bergmann wrote:
> The vexpress tc2 power management code calls mcpm_loopback, which
> is only available if ARM_CPU_SUSPEND is enabled, otherwise we
> get a link error:
>
> arch/arm/mach-vexpress/built-in.o: In function `tc2_pm_init':
> arch/arm/mach-vexpress/tc2_pm.c:389: undefined reference to `mcpm_loopback'
>
> This explicitly selects ARM_CPU_SUSPEND like other platforms that
> need it.
>
> Signed-off-by: Arnd Bergmann <[email protected]>
> Fixes: 3592d7e002438 ("ARM: 8082/1: TC2: test the MCPM loopback during boot")
> Cc: Nicolas Pitre <[email protected]>
> Cc: Kevin Hilman <[email protected]>
> Cc: Liviu Dudau <[email protected]>
> Cc: Sudeep Holla <[email protected]>
> Cc: Lorenzo Pieralisi <[email protected]>
Acked-by: Nicolas Pitre <[email protected]>
> ---
> arch/arm/mach-vexpress/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/mach-vexpress/Kconfig b/arch/arm/mach-vexpress/Kconfig
> index d6b16d9a7838..3c2509b4b694 100644
> --- a/arch/arm/mach-vexpress/Kconfig
> +++ b/arch/arm/mach-vexpress/Kconfig
> @@ -73,6 +73,7 @@ config ARCH_VEXPRESS_TC2_PM
> depends on MCPM
> select ARM_CCI
> select ARCH_VEXPRESS_SPC
> + select ARM_CPU_SUSPEND
> help
> Support for CPU and cluster power management on Versatile Express
> with a TC2 (A15x2 A7x3) big.LITTLE core tile.
> --
> 2.1.0.rc2
>
>
2015-02-13 3:42 GMT+08:00 Arnd Bergmann <[email protected]>:
> The new Atlas7 platform implicitly selects 'CONFIG_SMP_ON_UP',
> which leads to problems if we enable building the platform without
> MMU, as that combination is not allowed and causes a link error:
>
> arch/arm/kernel/built-in.o: In function `c_show':
> :(.text+0x1872): undefined reference to `smp_on_up'
> :(.text+0x1876): undefined reference to `smp_on_up'
> arch/arm/kernel/built-in.o: In function `arch_irq_work_raise':
> :(.text+0x3d48): undefined reference to `smp_on_up'
> :(.text+0x3d4c): undefined reference to `smp_on_up'
> arch/arm/kernel/built-in.o: In function `smp_setup_processor_id':
> :(.init.text+0x180): undefined reference to `smp_on_up'
>
> This removes the 'select' statement.
>
> Signed-off-by: Arnd Bergmann <[email protected]>
> Fixes: 4cba058526a7 ("ARM: sirf: add Atlas7 machine support")
> Cc: Zhiwu Song <[email protected]>
> Cc: Barry Song <[email protected]>
> ---
> arch/arm/mach-prima2/Kconfig | 1 -
> 1 file changed, 1 deletion(-)
Acked-by: Barry Song <[email protected]>
>
> diff --git a/arch/arm/mach-prima2/Kconfig b/arch/arm/mach-prima2/Kconfig
> index a219dc310d5d..e03d8b5c9ad0 100644
> --- a/arch/arm/mach-prima2/Kconfig
> +++ b/arch/arm/mach-prima2/Kconfig
> @@ -27,7 +27,6 @@ config ARCH_ATLAS7
> select CPU_V7
> select HAVE_ARM_SCU if SMP
> select HAVE_SMP
> - select SMP_ON_UP if SMP
> help
> Support for CSR SiRFSoC ARM Cortex A7 Platform
>
> --
> 2.1.0.rc2
>
-barry
Hi Arnd
On 02/12/2015 08:42 PM, Arnd Bergmann wrote:
> A lot of the sti device drivers require reset controller support,
> but do not all have individual 'depends on RESET_CONTROLLER'
> statements. Using 'select' here once avoids a lot of build errors
> resulting from this.
>
> Signed-off-by: Arnd Bergmann <[email protected]>
> Cc: Maxime Coquelin <[email protected]>
> Cc: Srinivas Kandagatla <[email protected]>
> Cc: Patrice Chotard <[email protected]>
> ---
> arch/arm/mach-sti/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/mach-sti/Kconfig b/arch/arm/mach-sti/Kconfig
> index 8825bc9e2553..3b1ac463a494 100644
> --- a/arch/arm/mach-sti/Kconfig
> +++ b/arch/arm/mach-sti/Kconfig
> @@ -13,6 +13,7 @@ menuconfig ARCH_STI
> select ARM_ERRATA_775420
> select PL310_ERRATA_753970 if CACHE_L2X0
> select PL310_ERRATA_769419 if CACHE_L2X0
> + select RESET_CONTROLLER
> help
> Include support for STiH41x SOCs like STiH415/416 using the device tree
> for discovery
Acked-by: Patrice Chotard <[email protected]>
Thanks
Hi Arnd,
On 02/12/2015 08:42 PM, Arnd Bergmann wrote:
> A lot of the sti device drivers require reset controller support,
> but do not all have individual 'depends on RESET_CONTROLLER'
> statements. Using 'select' here once avoids a lot of build errors
> resulting from this.
>
> Signed-off-by: Arnd Bergmann <[email protected]>
> Cc: Maxime Coquelin <[email protected]>
> Cc: Srinivas Kandagatla <[email protected]>
> Cc: Patrice Chotard <[email protected]>
> ---
> arch/arm/mach-sti/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
>
I agree with you, the board is useless without all the drivers depending
on the resets.
You can add my:
Acked-by: Maxime Coquelin <[email protected]>
Br,
Maxime
Le 12/02/2015 20:42, Arnd Bergmann a ?crit :
> In a recent rearrangement of the at91 pm initialization code, a broken
> set of declarations was added for the !CONFIG_PM-case, leading to
> this link error:
>
> arch/arm/mach-at91/board-dt-sama5.o: In function `at91_rm9200_pm_init':
> arch/arm/mach-at91/generic.h:40: multiple definition of `at91_rm9200_pm_init'
> arch/arm/mach-at91/setup.o:arch/arm/mach-at91/generic.h:40: first defined here
> arch/arm/mach-at91/board-dt-sama5.o: In function `at91_sam9260_pm_init':
> arch/arm/mach-at91/generic.h:41: multiple definition of `at91_sam9260_pm_init'
> arch/arm/mach-at91/setup.o:arch/arm/mach-at91/generic.h:41: first defined here
> arch/arm/mach-at91/board-dt-sama5.o: In function `at91_sam9g45_pm_init':
> arch/arm/mach-at91/generic.h:42: multiple definition of `at91_sam9g45_pm_init'
> arch/arm/mach-at91/setup.o:arch/arm/mach-at91/generic.h:42: first defined here
>
> This adds the missing 'static inline' to the declarations to avoid
> creating a copy of the functions in each file that includes the
> header.
>
> Signed-off-by: Arnd Bergmann <[email protected]>
> Fixes: 4db0ba22da9 ("ARM: at91: pm: prepare for multiplatform")
> Cc: Nicolas Ferre <[email protected]>
Yes:
Acked-by: Nicolas Ferre <[email protected]>
Thanks Arnd. Bye,
> Cc: Jean-Christophe Plagniol-Villard <[email protected]>
> Cc: Alexandre Belloni <[email protected]>
> ---
> arch/arm/mach-at91/generic.h | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/mach-at91/generic.h b/arch/arm/mach-at91/generic.h
> index a6e726a6e0b5..583369ffc284 100644
> --- a/arch/arm/mach-at91/generic.h
> +++ b/arch/arm/mach-at91/generic.h
> @@ -35,10 +35,10 @@ extern void __init at91sam9260_pm_init(void);
> extern void __init at91sam9g45_pm_init(void);
> extern void __init at91sam9x5_pm_init(void);
> #else
> -void __init at91rm9200_pm_init(void) { }
> -void __init at91sam9260_pm_init(void) { }
> -void __init at91sam9g45_pm_init(void) { }
> -void __init at91sam9x5_pm_init(void) { }
> +static inline void __init at91rm9200_pm_init(void) { }
> +static inline void __init at91sam9260_pm_init(void) { }
> +static inline void __init at91sam9g45_pm_init(void) { }
> +static inline void __init at91sam9x5_pm_init(void) { }
> #endif
>
> #endif /* _AT91_GENERIC_H */
>
--
Nicolas Ferre
Hi Arnd,
On Thu, Feb 12, 2015 at 08:42:34PM +0100, Arnd Bergmann wrote:
> A lot of drivers for mach-sunxi depend on RESET_CONTROLLER. While
> this is selected for the drivers that have it, we keep running
> into build errors in drivers that are used on both the SoCs with
> and without a reset controller.
>
> This patch moves the select statements into the common sunxi
> Kconfig option, which solves multiple such problems.
>
> Signed-off-by: Arnd Bergmann <[email protected]>
> Cc: Maxime Ripard <[email protected]>
Chen-Yu already submitted the exact same patch a few days ago:
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-February/322806.html
I was waiting for -rc1 to merge it, but I guess your way would work
too.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
On Thu, Feb 12, 2015 at 07:42:33PM +0000, Arnd Bergmann wrote:
> The vexpress tc2 power management code calls mcpm_loopback, which
> is only available if ARM_CPU_SUSPEND is enabled, otherwise we
> get a link error:
>
> arch/arm/mach-vexpress/built-in.o: In function `tc2_pm_init':
> arch/arm/mach-vexpress/tc2_pm.c:389: undefined reference to `mcpm_loopback'
Arnd,
We are having reports of TC2 not booting with MCPM enabled. Lorenzo
was investigating this but then headed for Linaro Connect this week,
so we don't have yet a resolution. Can this patch be postponed for
a later -rc?
Best regards,
Liviu
>
> This explicitly selects ARM_CPU_SUSPEND like other platforms that
> need it.
>
> Signed-off-by: Arnd Bergmann <[email protected]>
> Fixes: 3592d7e002438 ("ARM: 8082/1: TC2: test the MCPM loopback during boot")
> Cc: Nicolas Pitre <[email protected]>
> Cc: Kevin Hilman <[email protected]>
> Cc: Liviu Dudau <[email protected]>
> Cc: Sudeep Holla <[email protected]>
> Cc: Lorenzo Pieralisi <[email protected]>
> ---
> arch/arm/mach-vexpress/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/mach-vexpress/Kconfig b/arch/arm/mach-vexpress/Kconfig
> index d6b16d9a7838..3c2509b4b694 100644
> --- a/arch/arm/mach-vexpress/Kconfig
> +++ b/arch/arm/mach-vexpress/Kconfig
> @@ -73,6 +73,7 @@ config ARCH_VEXPRESS_TC2_PM
> depends on MCPM
> select ARM_CCI
> select ARCH_VEXPRESS_SPC
> + select ARM_CPU_SUSPEND
> help
> Support for CPU and cluster power management on Versatile Express
> with a TC2 (A15x2 A7x3) big.LITTLE core tile.
> --
> 2.1.0.rc2
>
>
--
====================
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---------------
¯\_(ツ)_/¯
On Fri, Feb 13, 2015 at 10:37:16AM +0000, Liviu Dudau wrote:
> On Thu, Feb 12, 2015 at 07:42:33PM +0000, Arnd Bergmann wrote:
> > The vexpress tc2 power management code calls mcpm_loopback, which
> > is only available if ARM_CPU_SUSPEND is enabled, otherwise we
> > get a link error:
> >
> > arch/arm/mach-vexpress/built-in.o: In function `tc2_pm_init':
> > arch/arm/mach-vexpress/tc2_pm.c:389: undefined reference to `mcpm_loopback'
>
> Arnd,
>
> We are having reports of TC2 not booting with MCPM enabled. Lorenzo
> was investigating this but then headed for Linaro Connect this week,
> so we don't have yet a resolution. Can this patch be postponed for
> a later -rc?
Why?
This patch isn't forcing MCPM to be enabled for Versatile Express.
* In order to build tc2_pm.c, MCPM must already be enabled (the
feature depends on MCPM in the Kconfig already)
* When this feature is enabled, the above link error occurs if
ARM_CPU_SUSPEND is not also enabled.
So, it is merely fixing the requirement that tc2_pm.c needs the CPU
suspend infrastructure, which in turn has no effect on whether MCPM
is enabled or not.
--
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.
On Fri, Feb 13, 2015 at 10:57:53AM +0000, Russell King - ARM Linux wrote:
> On Fri, Feb 13, 2015 at 10:37:16AM +0000, Liviu Dudau wrote:
> > On Thu, Feb 12, 2015 at 07:42:33PM +0000, Arnd Bergmann wrote:
> > > The vexpress tc2 power management code calls mcpm_loopback, which
> > > is only available if ARM_CPU_SUSPEND is enabled, otherwise we
> > > get a link error:
> > >
> > > arch/arm/mach-vexpress/built-in.o: In function `tc2_pm_init':
> > > arch/arm/mach-vexpress/tc2_pm.c:389: undefined reference to `mcpm_loopback'
> >
> > Arnd,
> >
> > We are having reports of TC2 not booting with MCPM enabled. Lorenzo
> > was investigating this but then headed for Linaro Connect this week,
> > so we don't have yet a resolution. Can this patch be postponed for
> > a later -rc?
>
> Why?
>
> This patch isn't forcing MCPM to be enabled for Versatile Express.
>
> * In order to build tc2_pm.c, MCPM must already be enabled (the
> feature depends on MCPM in the Kconfig already)
> * When this feature is enabled, the above link error occurs if
> ARM_CPU_SUSPEND is not also enabled.
>
> So, it is merely fixing the requirement that tc2_pm.c needs the CPU
> suspend infrastructure, which in turn has no effect on whether MCPM
> is enabled or not.
Because I think Lorenzo's plan was to disable MCPM for TC2. Which would
make this patch moot.
Best regards,
Liviu
>
> --
> FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
> according to speedtest.net.
>
--
====================
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---------------
¯\_(ツ)_/¯
On Fri, Feb 13, 2015 at 11:01:52AM +0000, Liviu Dudau wrote:
> On Fri, Feb 13, 2015 at 10:57:53AM +0000, Russell King - ARM Linux wrote:
> > On Fri, Feb 13, 2015 at 10:37:16AM +0000, Liviu Dudau wrote:
> > > On Thu, Feb 12, 2015 at 07:42:33PM +0000, Arnd Bergmann wrote:
> > > > The vexpress tc2 power management code calls mcpm_loopback, which
> > > > is only available if ARM_CPU_SUSPEND is enabled, otherwise we
> > > > get a link error:
> > > >
> > > > arch/arm/mach-vexpress/built-in.o: In function `tc2_pm_init':
> > > > arch/arm/mach-vexpress/tc2_pm.c:389: undefined reference to `mcpm_loopback'
> > >
> > > Arnd,
> > >
> > > We are having reports of TC2 not booting with MCPM enabled. Lorenzo
> > > was investigating this but then headed for Linaro Connect this week,
> > > so we don't have yet a resolution. Can this patch be postponed for
> > > a later -rc?
> >
> > Why?
> >
> > This patch isn't forcing MCPM to be enabled for Versatile Express.
> >
> > * In order to build tc2_pm.c, MCPM must already be enabled (the
> > feature depends on MCPM in the Kconfig already)
> > * When this feature is enabled, the above link error occurs if
> > ARM_CPU_SUSPEND is not also enabled.
> >
> > So, it is merely fixing the requirement that tc2_pm.c needs the CPU
> > suspend infrastructure, which in turn has no effect on whether MCPM
> > is enabled or not.
>
> Because I think Lorenzo's plan was to disable MCPM for TC2. Which would
> make this patch moot.
I don't think that makes a difference - the two issues are orthogonal.
As the code stands today, it requires ARM_CPU_SUSPEND to be set, so
merging this change makes total sense.
If the code is temporarily disabled, then we still need this patch
merged to fix the error when the feature is re-enabled. If the code
is changed later such that it doesn't need mcpm_loopback, then that's
the time to remove the select of this symbol.
If the code is removed, that is something which is not going to happen
during this merge window, so the patch still might as well be applied
to prevent build errors.
--
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.
On Fri, Feb 13, 2015 at 11:16:12AM +0000, Russell King - ARM Linux wrote:
> On Fri, Feb 13, 2015 at 11:01:52AM +0000, Liviu Dudau wrote:
> > On Fri, Feb 13, 2015 at 10:57:53AM +0000, Russell King - ARM Linux wrote:
> > > On Fri, Feb 13, 2015 at 10:37:16AM +0000, Liviu Dudau wrote:
> > > > On Thu, Feb 12, 2015 at 07:42:33PM +0000, Arnd Bergmann wrote:
> > > > > The vexpress tc2 power management code calls mcpm_loopback, which
> > > > > is only available if ARM_CPU_SUSPEND is enabled, otherwise we
> > > > > get a link error:
> > > > >
> > > > > arch/arm/mach-vexpress/built-in.o: In function `tc2_pm_init':
> > > > > arch/arm/mach-vexpress/tc2_pm.c:389: undefined reference to `mcpm_loopback'
> > > >
> > > > Arnd,
> > > >
> > > > We are having reports of TC2 not booting with MCPM enabled. Lorenzo
> > > > was investigating this but then headed for Linaro Connect this week,
> > > > so we don't have yet a resolution. Can this patch be postponed for
> > > > a later -rc?
> > >
> > > Why?
> > >
> > > This patch isn't forcing MCPM to be enabled for Versatile Express.
> > >
> > > * In order to build tc2_pm.c, MCPM must already be enabled (the
> > > feature depends on MCPM in the Kconfig already)
> > > * When this feature is enabled, the above link error occurs if
> > > ARM_CPU_SUSPEND is not also enabled.
> > >
> > > So, it is merely fixing the requirement that tc2_pm.c needs the CPU
> > > suspend infrastructure, which in turn has no effect on whether MCPM
> > > is enabled or not.
> >
> > Because I think Lorenzo's plan was to disable MCPM for TC2. Which would
> > make this patch moot.
>
> I don't think that makes a difference - the two issues are orthogonal.
>
> As the code stands today, it requires ARM_CPU_SUSPEND to be set, so
> merging this change makes total sense.
>
> If the code is temporarily disabled, then we still need this patch
> merged to fix the error when the feature is re-enabled. If the code
> is changed later such that it doesn't need mcpm_loopback, then that's
> the time to remove the select of this symbol.
>
> If the code is removed, that is something which is not going to happen
> during this merge window, so the patch still might as well be applied
> to prevent build errors.
Russell,
I'm not arguing either way, I was just asking for a delay until Lorenzo
(one other maintainer of the code that is in the Cc) has a chance to
have his say, because I thought it was relevant (and I have explained why).
If Arnd feels he would rather push the patch now rather than (let say) late
Monday, then I can give my Acked-by.
Best regards,
Liviu
>
> --
> FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
> according to speedtest.net.
>
--
====================
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---------------
¯\_(ツ)_/¯
Am Donnerstag, 12. Februar 2015, 20:42:41 schrieb Arnd Bergmann:
> If CONFIG_PM_SLEEP is disabled, we get a build error for rockchips:
>
> arch/arm/mach-rockchip/built-in.o: In function `rockchip_dt_init':
> :(.init.text+0x1c): undefined reference to `rockchip_suspend_init'
>
> This adds an inline alternative for that case.
>
> Signed-off-by: Arnd Bergmann <[email protected]>
> Cc: Heiko Stuebner <[email protected]>
> Cc: [email protected]
thanks for the catch,
Reviewed-by: Heiko Stuebner <[email protected]>
I guess you will apply the whole 11-patch series en block to arm-soc, right?
Heiko
On Fri, 13 Feb 2015, Liviu Dudau wrote:
> On Thu, Feb 12, 2015 at 07:42:33PM +0000, Arnd Bergmann wrote:
> > The vexpress tc2 power management code calls mcpm_loopback, which
> > is only available if ARM_CPU_SUSPEND is enabled, otherwise we
> > get a link error:
> >
> > arch/arm/mach-vexpress/built-in.o: In function `tc2_pm_init':
> > arch/arm/mach-vexpress/tc2_pm.c:389: undefined reference to `mcpm_loopback'
>
> Arnd,
>
> We are having reports of TC2 not booting with MCPM enabled. Lorenzo
> was investigating this but then headed for Linaro Connect this week,
> so we don't have yet a resolution. Can this patch be postponed for
> a later -rc?
Can you share those reports? I did boot my TC2 with v3.19-rc7 before
leaving for Linaro Connect and it just worked.
Regardless, this patch is about a build fix and doesn't change any
functionality, so I wouldn't postpone it.
>
> Best regards,
> Liviu
>
>
> >
> > This explicitly selects ARM_CPU_SUSPEND like other platforms that
> > need it.
> >
> > Signed-off-by: Arnd Bergmann <[email protected]>
> > Fixes: 3592d7e002438 ("ARM: 8082/1: TC2: test the MCPM loopback during boot")
> > Cc: Nicolas Pitre <[email protected]>
> > Cc: Kevin Hilman <[email protected]>
> > Cc: Liviu Dudau <[email protected]>
> > Cc: Sudeep Holla <[email protected]>
> > Cc: Lorenzo Pieralisi <[email protected]>
> > ---
> > arch/arm/mach-vexpress/Kconfig | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/arch/arm/mach-vexpress/Kconfig b/arch/arm/mach-vexpress/Kconfig
> > index d6b16d9a7838..3c2509b4b694 100644
> > --- a/arch/arm/mach-vexpress/Kconfig
> > +++ b/arch/arm/mach-vexpress/Kconfig
> > @@ -73,6 +73,7 @@ config ARCH_VEXPRESS_TC2_PM
> > depends on MCPM
> > select ARM_CCI
> > select ARCH_VEXPRESS_SPC
> > + select ARM_CPU_SUSPEND
> > help
> > Support for CPU and cluster power management on Versatile Express
> > with a TC2 (A15x2 A7x3) big.LITTLE core tile.
> > --
> > 2.1.0.rc2
> >
> >
>
> --
> ====================
> | I would like to |
> | fix the world, |
> | but they're not |
> | giving me the |
> \ source code! /
> ---------------
> ¯\_(ツ)_/¯
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
>
On Fri, 13 Feb 2015, Liviu Dudau wrote:
> On Fri, Feb 13, 2015 at 11:16:12AM +0000, Russell King - ARM Linux wrote:
> > On Fri, Feb 13, 2015 at 11:01:52AM +0000, Liviu Dudau wrote:
> > > On Fri, Feb 13, 2015 at 10:57:53AM +0000, Russell King - ARM Linux wrote:
> > > > On Fri, Feb 13, 2015 at 10:37:16AM +0000, Liviu Dudau wrote:
> > > > > On Thu, Feb 12, 2015 at 07:42:33PM +0000, Arnd Bergmann wrote:
> > > > > > The vexpress tc2 power management code calls mcpm_loopback, which
> > > > > > is only available if ARM_CPU_SUSPEND is enabled, otherwise we
> > > > > > get a link error:
> > > > > >
> > > > > > arch/arm/mach-vexpress/built-in.o: In function `tc2_pm_init':
> > > > > > arch/arm/mach-vexpress/tc2_pm.c:389: undefined reference to `mcpm_loopback'
> > > > >
> > > > > Arnd,
> > > > >
> > > > > We are having reports of TC2 not booting with MCPM enabled. Lorenzo
> > > > > was investigating this but then headed for Linaro Connect this week,
> > > > > so we don't have yet a resolution. Can this patch be postponed for
> > > > > a later -rc?
> > > >
> > > > Why?
> > > >
> > > > This patch isn't forcing MCPM to be enabled for Versatile Express.
> > > >
> > > > * In order to build tc2_pm.c, MCPM must already be enabled (the
> > > > feature depends on MCPM in the Kconfig already)
> > > > * When this feature is enabled, the above link error occurs if
> > > > ARM_CPU_SUSPEND is not also enabled.
> > > >
> > > > So, it is merely fixing the requirement that tc2_pm.c needs the CPU
> > > > suspend infrastructure, which in turn has no effect on whether MCPM
> > > > is enabled or not.
> > >
> > > Because I think Lorenzo's plan was to disable MCPM for TC2. Which would
> > > make this patch moot.
> >
> > I don't think that makes a difference - the two issues are orthogonal.
> >
> > As the code stands today, it requires ARM_CPU_SUSPEND to be set, so
> > merging this change makes total sense.
> >
> > If the code is temporarily disabled, then we still need this patch
> > merged to fix the error when the feature is re-enabled. If the code
> > is changed later such that it doesn't need mcpm_loopback, then that's
> > the time to remove the select of this symbol.
> >
> > If the code is removed, that is something which is not going to happen
> > during this merge window, so the patch still might as well be applied
> > to prevent build errors.
>
> Russell,
>
> I'm not arguing either way, I was just asking for a delay until Lorenzo
> (one other maintainer of the code that is in the Cc) has a chance to
> have his say, because I thought it was relevant (and I have explained why).
>
> If Arnd feels he would rather push the patch now rather than (let say) late
> Monday, then I can give my Acked-by.
Sorry but I must disagree.
As the original author of that file _and_ actually being responsible for
the bug fixed by that patch, I really don't understand why waiting for
Lorenzo would be necessary here.
Nicolas
On Sat, Feb 14, 2015 at 06:55:05AM +0800, Nicolas Pitre wrote:
> On Fri, 13 Feb 2015, Liviu Dudau wrote:
>
> > On Thu, Feb 12, 2015 at 07:42:33PM +0000, Arnd Bergmann wrote:
> > > The vexpress tc2 power management code calls mcpm_loopback, which
> > > is only available if ARM_CPU_SUSPEND is enabled, otherwise we
> > > get a link error:
> > >
> > > arch/arm/mach-vexpress/built-in.o: In function `tc2_pm_init':
> > > arch/arm/mach-vexpress/tc2_pm.c:389: undefined reference to `mcpm_loopback'
> >
> > Arnd,
> >
> > We are having reports of TC2 not booting with MCPM enabled. Lorenzo
> > was investigating this but then headed for Linaro Connect this week,
> > so we don't have yet a resolution. Can this patch be postponed for
> > a later -rc?
>
> Can you share those reports? I did boot my TC2 with v3.19-rc7 before
> leaving for Linaro Connect and it just worked.
>
> Regardless, this patch is about a build fix and doesn't change any
> functionality, so I wouldn't postpone it.
>
OK. Acked-by: Liviu Dudau <[email protected]>
Best regards,
Liviu
>
>
> >
> > Best regards,
> > Liviu
> >
> >
> > >
> > > This explicitly selects ARM_CPU_SUSPEND like other platforms that
> > > need it.
> > >
> > > Signed-off-by: Arnd Bergmann <[email protected]>
> > > Fixes: 3592d7e002438 ("ARM: 8082/1: TC2: test the MCPM loopback during boot")
> > > Cc: Nicolas Pitre <[email protected]>
> > > Cc: Kevin Hilman <[email protected]>
> > > Cc: Liviu Dudau <[email protected]>
> > > Cc: Sudeep Holla <[email protected]>
> > > Cc: Lorenzo Pieralisi <[email protected]>
> > > ---
> > > arch/arm/mach-vexpress/Kconfig | 1 +
> > > 1 file changed, 1 insertion(+)
> > >
> > > diff --git a/arch/arm/mach-vexpress/Kconfig b/arch/arm/mach-vexpress/Kconfig
> > > index d6b16d9a7838..3c2509b4b694 100644
> > > --- a/arch/arm/mach-vexpress/Kconfig
> > > +++ b/arch/arm/mach-vexpress/Kconfig
> > > @@ -73,6 +73,7 @@ config ARCH_VEXPRESS_TC2_PM
> > > depends on MCPM
> > > select ARM_CCI
> > > select ARCH_VEXPRESS_SPC
> > > + select ARM_CPU_SUSPEND
> > > help
> > > Support for CPU and cluster power management on Versatile Express
> > > with a TC2 (A15x2 A7x3) big.LITTLE core tile.
> > > --
> > > 2.1.0.rc2
> > >
> > >
> >
> > --
> > ====================
> > | I would like to |
> > | fix the world, |
> > | but they're not |
> > | giving me the |
> > \ source code! /
> > ---------------
> > ¯\_(ツ)_/¯
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to [email protected]
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at http://www.tux.org/lkml/
> >
> >
--
-------------------
.oooO
( )
\ ( Oooo.
\_) ( )
) /
(_/
One small step
for me ...
On Sat, Feb 14, 2015 at 01:34:34AM +0000, Liviu Dudau wrote:
> On Sat, Feb 14, 2015 at 06:55:05AM +0800, Nicolas Pitre wrote:
> > On Fri, 13 Feb 2015, Liviu Dudau wrote:
> >
> > > On Thu, Feb 12, 2015 at 07:42:33PM +0000, Arnd Bergmann wrote:
> > > > The vexpress tc2 power management code calls mcpm_loopback, which
> > > > is only available if ARM_CPU_SUSPEND is enabled, otherwise we
> > > > get a link error:
> > > >
> > > > arch/arm/mach-vexpress/built-in.o: In function `tc2_pm_init':
> > > > arch/arm/mach-vexpress/tc2_pm.c:389: undefined reference to `mcpm_loopback'
> > >
> > > Arnd,
> > >
> > > We are having reports of TC2 not booting with MCPM enabled. Lorenzo
> > > was investigating this but then headed for Linaro Connect this week,
> > > so we don't have yet a resolution. Can this patch be postponed for
> > > a later -rc?
> >
> > Can you share those reports? I did boot my TC2 with v3.19-rc7 before
> > leaving for Linaro Connect and it just worked.
> >
> > Regardless, this patch is about a build fix and doesn't change any
> > functionality, so I wouldn't postpone it.
> >
>
> OK. Acked-by: Liviu Dudau <[email protected]>
There is no reason to postpone it, even though TC2 builds with MCPM
enabled and both bL switcher and bL CPUidle driver disabled are
questionable but possible.
There are other issues with PM on TC2 that are not related to this
patch anyway, they can't be since this is a fix for a build issue on
a config that does not enable any PM at all.
Lorenzo
Arnd Bergmann <[email protected]> writes:
> Most platforms use void pointer arguments in these functions, but
> ixp4xx does not, which triggers lots of warnings in device drivers like:
>
> net/ethernet/8390/ne2k-pci.c: In function 'ne2k_pci_get_8390_hdr':
> net/ethernet/8390/ne2k-pci.c:503:3: warning: passing argument 2 of 'insw' from incompatible pointer type
> insw(NE_BASE + NE_DATAPORT, hdr, sizeof(struct e8390_pkt_hdr)>>1);
> ^
> In file included from include/asm/io.h:214:0,
> from /git/arm-soc/include/linux/io.h:22,
> from /git/arm-soc/include/linux/pci.h:31,
> from net/ethernet/8390/ne2k-pci.c:48:
> mach-ixp4xx/include/mach/io.h:316:91: note: expected 'u16 *' but argument is of type 'struct e8390_pkt_hdr *'
> static inline void insw(u32 io_addr, u16 *vaddr, u32 count)
>
> Fixing the drivers seems hopeless, so this changes the ixp4xx code
> to do the same as the others to avoid the warnings.
Acked-by: Krzysztof Halasa <[email protected]>
--
Krzysztof Halasa
Research Institute for Automation and Measurements PIAP
Al. Jerozolimskie 202, 02-486 Warsaw, Poland
On Friday 13 February 2015 01:12 AM, Arnd Bergmann wrote:
> davinci_cfg_reg gets called from a lot of locations that
> might get called after the init section has been discarded,
> so the function itself must not be marked __init either.
>
> The kernel build currently warns about this with lots of
> messages like:
>
> WARNING: vmlinux.o(.text.unlikely+0x24c): Section mismatch in reference from the function dm365evm_mmc_configure() to the function .init.text:davinci_cfg_reg()
> The function dm365evm_mmc_configure() references
> the function __init davinci_cfg_reg().
> This is often because dm365evm_mmc_configure lacks a __init
> annotation or the annotation of davinci_cfg_reg is wrong.
>
> This removes the extraneous __init_or_module annotation.
>
> Signed-off-by: Arnd Bergmann <[email protected]>
> Cc: Sekhar Nori <[email protected]>
> Cc: Kevin Hilman <[email protected]>
Acked-by: Sekhar Nori <[email protected]>
Thanks,
Sekhar
On Friday 13 February 2015 01:12 AM, Arnd Bergmann wrote:
> The davinci DA8xx and DMx families have incompatible zreladdr
> settings, and attempting to build a kernel with both enabled
> results in an error unless AUTO_ZRELADDR is set:
>
> multiple zreladdrs: 0xc0008000 0x80008000
> This needs CONFIG_AUTO_ZRELADDR to be set
>
> This patch changes Kconfig to make the two families mutually
> exclusive when this is unset.
>
> Signed-off-by: Arnd Bergmann <[email protected]>
> Cc: Sekhar Nori <[email protected]>
> Cc: Kevin Hilman <[email protected]>
Acked-by: Sekhar Nori <[email protected]>
Thanks for the fixes, Arnd!
Regards,
Sekhar
On Friday 13 February 2015 10:09:19 Maxime Ripard wrote:
> Hi Arnd,
>
> On Thu, Feb 12, 2015 at 08:42:34PM +0100, Arnd Bergmann wrote:
> > A lot of drivers for mach-sunxi depend on RESET_CONTROLLER. While
> > this is selected for the drivers that have it, we keep running
> > into build errors in drivers that are used on both the SoCs with
> > and without a reset controller.
> >
> > This patch moves the select statements into the common sunxi
> > Kconfig option, which solves multiple such problems.
> >
> > Signed-off-by: Arnd Bergmann <[email protected]>
> > Cc: Maxime Ripard <[email protected]>
>
> Chen-Yu already submitted the exact same patch a few days ago:
> http://lists.infradead.org/pipermail/linux-arm-kernel/2015-February/322806.html
>
> I was waiting for -rc1 to merge it, but I guess your way would work
> too.
It's not urgent, and since he came first, let's use that patch.
Feel free to add my 'Acked-by: Arnd Bergmann <[email protected]>' if you
haven't already applied it.
Arnd