[PATCH 0/9] arm-soc: randconfig fixes

[PATCH 0/9] arm-soc: randconfig fixes

[Arnd Bergmann]

Hi platform maintainers,

These patches are all fallout from randconfig testing, and I've
applied them directly to the arm-soc tree since I don't expect
them to be controversial. They will be part of the next set
of patch submissions to Linus.

Please have a look anyway.

Arnd Bergmann (9):
  ARM: tegra: Tegra114 needs CPU_FREQ_TABLE
  ARM: OMAP: build SMP code only for OMAP4/5
  ARM: imx: build CPU suspend code only when needed
  ARM: SPEAr: conditionalize l2x0 support
  ARM: imx: reset_controller may be disabled
  ARM: SPEAr: conditionalize SMP code
  ARM: OMAP: don't select SERIAL_OMAP unconditionally
  ARM: SIRF: select SMP_ON_UP only on SMP builds
  ARM: ux500: always select ABX500_CORE

 arch/arm/mach-imx/headsmp.S     | 2 +-
 arch/arm/mach-imx/src.c         | 3 ++-
 arch/arm/mach-omap2/Kconfig     | 4 ++--
 arch/arm/mach-omap2/Makefile    | 8 ++++----
 arch/arm/mach-prima2/Kconfig    | 2 +-
 arch/arm/mach-spear/Makefile    | 6 +++---
 arch/arm/mach-spear/spear13xx.c | 2 ++
 arch/arm/mach-tegra/Kconfig     | 1 +
 arch/arm/mach-ux500/Kconfig     | 2 ++
 9 files changed, 18 insertions(+), 12 deletions(-)

-- 
1.8.1.2

Cc: Barry Song <baohua.song@csr.com>
Cc: Hiroshi Doyu <hdoyu@nvidia.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Sascha Hauer <kernel@pengutronix.de>
Cc: Stephen Warren <swarren@nvidia.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Viresh Kumar <viresh.linux@gmail.com>

[PATCH 1/9] ARM: tegra: Tegra114 needs CPU_FREQ_TABLE

[Arnd Bergmann]

Like the other Tegra SoCs using the same cpufreq driver, we
have to enable CPU_FREQ_TABLE for this one.

drivers/built-in.o: In function `tegra_cpu_exit':
 drivers/cpufreq/tegra-cpufreq.c:237: undefined reference to
 `cpufreq_frequency_table_cpuinfo'

Cc: Stephen Warren <swarren@nvidia.com>
Cc: Hiroshi Doyu <hdoyu@nvidia.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 arch/arm/mach-tegra/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/mach-tegra/Kconfig b/arch/arm/mach-tegra/Kconfig
index 597e76b..9878503 100644
--- a/arch/arm/mach-tegra/Kconfig
+++ b/arch/arm/mach-tegra/Kconfig
@@ -63,6 +63,7 @@ config ARCH_TEGRA_114_SOC
 	select ARM_ARCH_TIMER
 	select ARM_GIC
 	select ARM_L1_CACHE_SHIFT_6
+	select CPU_FREQ_TABLE if CPU_FREQ
 	select CPU_V7
 	select PINCTRL
 	select PINCTRL_TEGRA114
-- 
1.8.1.2

[PATCH 2/9] ARM: OMAP: build SMP code only for OMAP4/5

[Arnd Bergmann]

The OMAP platform code assumes that SMP is only ever enabled when
CONFIG_ARCH_OMAP4 or CONFIG_SOC_OMAP5 is enabled, which is not
necessarirly true in a multiplatform configuration.

arch/arm/mach-omap2/built-in.o: In function `omap4_smp_prepare_cpus':
 :(.init.text+0x413c): undefined reference to `omap_get_wakeupgen_base'
 :(.init.text+0x415c): undefined reference to `omap_secure_apis_support'
arch/arm/mach-omap2/built-in.o: In function `omap4_boot_secondary':
 :(.cpuinit.text+0x28): undefined reference to `omap_get_wakeupgen_base'
 :(.cpuinit.text+0x3c): undefined reference to `omap_secure_apis_support'
arch/arm/mach-omap2/built-in.o: In function `omap4_cpu_die':
 :(.ref.text+0x8): undefined reference to `omap_get_wakeupgen_base'
 :(.ref.text+0x10): undefined reference to `omap_secure_apis_support'
 :(.ref.text+0x4c): undefined reference to `omap4_hotplug_cpu'
 :(.ref.text+0x50): undefined reference to `omap_secure_apis_support'

Cc: Tony Lindgren <tony@atomide.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 arch/arm/mach-omap2/Makefile | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index e50b6da..f2d19af 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -32,12 +32,12 @@ obj-$(CONFIG_SOC_HAS_OMAP2_SDRC)	+= sdrc.o
 
 # SMP support ONLY available for OMAP4
 
-obj-$(CONFIG_SMP)			+= omap-smp.o omap-headsmp.o
-obj-$(CONFIG_HOTPLUG_CPU)		+= omap-hotplug.o
+smp-$(CONFIG_SMP)			+= omap-smp.o omap-headsmp.o
+smp-$(CONFIG_HOTPLUG_CPU)		+= omap-hotplug.o
 omap-4-5-common				=  omap4-common.o omap-wakeupgen.o \
 					   sleep44xx.o
-obj-$(CONFIG_ARCH_OMAP4)		+= $(omap-4-5-common)
-obj-$(CONFIG_SOC_OMAP5)			+= $(omap-4-5-common)
+obj-$(CONFIG_ARCH_OMAP4)		+= $(omap-4-5-common) $(smp-y)
+obj-$(CONFIG_SOC_OMAP5)			+= $(omap-4-5-common) $(smp-y)
 
 plus_sec := $(call as-instr,.arch_extension sec,+sec)
 AFLAGS_omap-headsmp.o			:=-Wa,-march=armv7-a$(plus_sec)
-- 
1.8.1.2

[PATCH 3/9] ARM: imx: build CPU suspend code only when needed

[Arnd Bergmann]

The ARM CPU suspend function has its own configuration symbol,
which we need to use for conditionalizing any code calling into
it as well.

arch/arm/mach-imx/built-in.o: In function `v7_cpu_resume':
/git/arm-soc/arch/arm/mach-imx/headsmp.S:57: undefined
 reference to `cpu_resume'

Cc: Sascha Hauer <kernel@pengutronix.de>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 arch/arm/mach-imx/headsmp.S | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-imx/headsmp.S b/arch/arm/mach-imx/headsmp.S
index a58c8b0..67b9c48 100644
--- a/arch/arm/mach-imx/headsmp.S
+++ b/arch/arm/mach-imx/headsmp.S
@@ -24,7 +24,7 @@ ENTRY(v7_secondary_startup)
 ENDPROC(v7_secondary_startup)
 #endif
 
-#ifdef CONFIG_PM
+#ifdef CONFIG_ARM_CPU_SUSPEND
 /*
  * The following code must assume it is running from physical address
  * where absolute virtual addresses to the data section have to be
-- 
1.8.1.2

[PATCH 4/9] ARM: SPEAr: conditionalize l2x0 support

[Arnd Bergmann]

If the cache controller implementation is disabled at build time,
we must not call any functions related to it.

arch/arm/mach-spear/built-in.o: In function `spear13xx_l2x0_init':
arch/arm/mach-spear/spear13xx.c:47: undefined reference to `l2x0_init'

Cc: Viresh Kumar <viresh.linux@gmail.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 arch/arm/mach-spear/spear13xx.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/mach-spear/spear13xx.c b/arch/arm/mach-spear/spear13xx.c
index 8e7cb45..5403c01 100644
--- a/arch/arm/mach-spear/spear13xx.c
+++ b/arch/arm/mach-spear/spear13xx.c
@@ -35,6 +35,8 @@ void __init spear13xx_l2x0_init(void)
 	 * write alloc and 'Full line of zero' options
 	 *
 	 */
+	if (!IS_ENABLED(CONFIG_CACHE_L2X0))
+		return;
 
 	writel_relaxed(0x06, VA_L2CC_BASE + L2X0_PREFETCH_CTRL);
 
-- 
1.8.1.2

[PATCH 5/9] ARM: imx: reset_controller may be disabled

[Arnd Bergmann]

The new reset controller API is optional, so if that is disabled,
we must not call it from platform code.

arch/arm/mach-imx/built-in.o: In function
 `imx_src_init': /git/arm-soc/arch/arm/mach-imx/src.c:144:
	undefined reference to `reset_controller_register'

Cc: Sascha Hauer <kernel@pengutronix.de>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 arch/arm/mach-imx/src.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-imx/src.c b/arch/arm/mach-imx/src.c
index dc101898..10a6b1a 100644
--- a/arch/arm/mach-imx/src.c
+++ b/arch/arm/mach-imx/src.c
@@ -141,7 +141,8 @@ void __init imx_src_init(void)
 	WARN_ON(!src_base);
 
 	imx_reset_controller.of_node = np;
-	reset_controller_register(&imx_reset_controller);
+	if (IS_ENABLED(CONFIG_RESET_CONTROLLER))
+		reset_controller_register(&imx_reset_controller);
 
 	/*
 	 * force warm reset sources to generate cold reset
-- 
1.8.1.2

[PATCH 6/9] ARM: SPEAr: conditionalize SMP code

[Arnd Bergmann]

Some constant definitions are only defined for spear13xx, so
we must not attempt to build SPEAr SMP support when that
SoC is not enabled.

arch/arm/mach-spear/platsmp.c:25:35:
 error: 'VA_SCU_BASE' undeclared here (not in a function)
 arch/arm/mach-spear/platsmp.c: In function 'spear13xx_smp_prepare_cpus':
 arch/arm/mach-spear/platsmp.c:111:58: error: 'SYS_LOCATION' undeclared (first use in this function)

Cc: Viresh Kumar <viresh.linux@gmail.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 arch/arm/mach-spear/Makefile | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-spear/Makefile b/arch/arm/mach-spear/Makefile
index af9bffb..a946c19 100644
--- a/arch/arm/mach-spear/Makefile
+++ b/arch/arm/mach-spear/Makefile
@@ -7,10 +7,10 @@ ccflags-$(CONFIG_ARCH_MULTIPLATFORM) := -I$(srctree)/$(src)/include
 # Common support
 obj-y	:= restart.o time.o
 
-obj-$(CONFIG_SMP)		+= headsmp.o platsmp.o
-obj-$(CONFIG_HOTPLUG_CPU)	+= hotplug.o
+smp-$(CONFIG_SMP)		+= headsmp.o platsmp.o
+smp-$(CONFIG_HOTPLUG_CPU)	+= hotplug.o
 
-obj-$(CONFIG_ARCH_SPEAR13XX)	+= spear13xx.o
+obj-$(CONFIG_ARCH_SPEAR13XX)	+= spear13xx.o $(smp-y)
 obj-$(CONFIG_MACH_SPEAR1310)	+= spear1310.o
 obj-$(CONFIG_MACH_SPEAR1340)	+= spear1340.o
 
-- 
1.8.1.2

[PATCH 7/9] ARM: OMAP: don't select SERIAL_OMAP unconditionally

[Arnd Bergmann]

It is possible to build a kernel without TTY support, so we must not
attempt to select SERIAL_OMAP in that case.

warning: (ARCH_OMAP2PLUS_TYPICAL) selects SERIAL_OMAP which has unmet direct dependencies (TTY && HAS_IOMEM && GENERIC_HARDIRQS && ARCH_OMAP2PLUS)

Cc: Tony Lindgren <tony@atomide.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 arch/arm/mach-omap2/Kconfig | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 857b1f0..a95c7af 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -37,8 +37,8 @@ config ARCH_OMAP2PLUS_TYPICAL
 	select NEON if ARCH_OMAP3 || ARCH_OMAP4 || SOC_OMAP5
 	select PM_RUNTIME
 	select REGULATOR
-	select SERIAL_OMAP
-	select SERIAL_OMAP_CONSOLE
+	select SERIAL_OMAP if TTY
+	select SERIAL_OMAP_CONSOLE if TTY
 	select TWL4030_CORE if ARCH_OMAP3 || ARCH_OMAP4
 	select TWL4030_POWER if ARCH_OMAP3 || ARCH_OMAP4
 	select VFP
-- 
1.8.1.2

[PATCH 8/9] ARM: SIRF: select SMP_ON_UP only on SMP builds

[Arnd Bergmann]

Like all other platforms, we can only select SMP_ON_UP if SMP
is also enabled.

warning: (SOC_IMX31 && SOC_IMX35 && ARCH_MARCO) selects
 SMP_ON_UP which has unmet direct dependencies (SMP && !XIP_KERNEL)

Cc: Barry Song <baohua.song@csr.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 arch/arm/mach-prima2/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-prima2/Kconfig b/arch/arm/mach-prima2/Kconfig
index 80ca974..6988b11 100644
--- a/arch/arm/mach-prima2/Kconfig
+++ b/arch/arm/mach-prima2/Kconfig
@@ -38,7 +38,7 @@ config ARCH_MARCO
 	select CPU_V7
 	select HAVE_ARM_SCU if SMP
 	select HAVE_SMP
-	select SMP_ON_UP
+	select SMP_ON_UP if SMP
 	help
           Support for CSR SiRFSoC ARM Cortex A9 Platform
 
-- 
1.8.1.2

[PATCH 9/9] ARM: ux500: always select ABX500_CORE

[Arnd Bergmann]

The use of 'select' in the ux500 platform is a huge mess, we should
not be selecting most of the drivers that are currently selected
there, but rather enable them from the defconfig.

As a fixup for 3.10, let's at least select the dependencies for
the other drivers we already select, to make it consistent.

warning: (UX500_SOC_COMMON) selects AB8500_CORE which has unmet direct dependencies (HAS_IOMEM && GENERIC_HARDIRQS && ABX500_CORE && MFD_DB8500_PRCMU)

Cc: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 arch/arm/mach-ux500/Kconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/mach-ux500/Kconfig b/arch/arm/mach-ux500/Kconfig
index f66d7de..6a4387e 100644
--- a/arch/arm/mach-ux500/Kconfig
+++ b/arch/arm/mach-ux500/Kconfig
@@ -19,6 +19,8 @@ if ARCH_U8500
 config UX500_SOC_COMMON
 	bool
 	default y
+	select ABX500_CORE
+	select AB8500_CORE
 	select ARM_ERRATA_754322
 	select ARM_ERRATA_764369 if SMP
 	select ARM_GIC
-- 
1.8.1.2

[PATCH 2/9] ARM: OMAP: build SMP code only for OMAP4/5

[Tony Lindgren]

* Arnd Bergmann <arnd@arndb.de> [130502 14:08]:
> The OMAP platform code assumes that SMP is only ever enabled when
> CONFIG_ARCH_OMAP4 or CONFIG_SOC_OMAP5 is enabled, which is not
> necessarirly true in a multiplatform configuration.
> 
> arch/arm/mach-omap2/built-in.o: In function `omap4_smp_prepare_cpus':
>  :(.init.text+0x413c): undefined reference to `omap_get_wakeupgen_base'
>  :(.init.text+0x415c): undefined reference to `omap_secure_apis_support'
> arch/arm/mach-omap2/built-in.o: In function `omap4_boot_secondary':
>  :(.cpuinit.text+0x28): undefined reference to `omap_get_wakeupgen_base'
>  :(.cpuinit.text+0x3c): undefined reference to `omap_secure_apis_support'
> arch/arm/mach-omap2/built-in.o: In function `omap4_cpu_die':
>  :(.ref.text+0x8): undefined reference to `omap_get_wakeupgen_base'
>  :(.ref.text+0x10): undefined reference to `omap_secure_apis_support'
>  :(.ref.text+0x4c): undefined reference to `omap4_hotplug_cpu'
>  :(.ref.text+0x50): undefined reference to `omap_secure_apis_support'
> 

Acked-by: Tony Lindgren <tony@atomide.com>

> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
>  arch/arm/mach-omap2/Makefile | 8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
> index e50b6da..f2d19af 100644
> --- a/arch/arm/mach-omap2/Makefile
> +++ b/arch/arm/mach-omap2/Makefile
> @@ -32,12 +32,12 @@ obj-$(CONFIG_SOC_HAS_OMAP2_SDRC)	+= sdrc.o
>  
>  # SMP support ONLY available for OMAP4
>  
> -obj-$(CONFIG_SMP)			+= omap-smp.o omap-headsmp.o
> -obj-$(CONFIG_HOTPLUG_CPU)		+= omap-hotplug.o
> +smp-$(CONFIG_SMP)			+= omap-smp.o omap-headsmp.o
> +smp-$(CONFIG_HOTPLUG_CPU)		+= omap-hotplug.o
>  omap-4-5-common				=  omap4-common.o omap-wakeupgen.o \
>  					   sleep44xx.o
> -obj-$(CONFIG_ARCH_OMAP4)		+= $(omap-4-5-common)
> -obj-$(CONFIG_SOC_OMAP5)			+= $(omap-4-5-common)
> +obj-$(CONFIG_ARCH_OMAP4)		+= $(omap-4-5-common) $(smp-y)
> +obj-$(CONFIG_SOC_OMAP5)			+= $(omap-4-5-common) $(smp-y)
>  
>  plus_sec := $(call as-instr,.arch_extension sec,+sec)
>  AFLAGS_omap-headsmp.o			:=-Wa,-march=armv7-a$(plus_sec)
> -- 
> 1.8.1.2
> 

[PATCH 7/9] ARM: OMAP: don't select SERIAL_OMAP unconditionally

[Tony Lindgren]

* Arnd Bergmann <arnd@arndb.de> [130502 14:08]:
> It is possible to build a kernel without TTY support, so we must not
> attempt to select SERIAL_OMAP in that case.
> 
> warning: (ARCH_OMAP2PLUS_TYPICAL) selects SERIAL_OMAP which has unmet direct dependencies (TTY && HAS_IOMEM && GENERIC_HARDIRQS && ARCH_OMAP2PLUS)
> 
> Cc: Tony Lindgren <tony@atomide.com>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
>  arch/arm/mach-omap2/Kconfig | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
> index 857b1f0..a95c7af 100644
> --- a/arch/arm/mach-omap2/Kconfig
> +++ b/arch/arm/mach-omap2/Kconfig
> @@ -37,8 +37,8 @@ config ARCH_OMAP2PLUS_TYPICAL
>  	select NEON if ARCH_OMAP3 || ARCH_OMAP4 || SOC_OMAP5
>  	select PM_RUNTIME
>  	select REGULATOR
> -	select SERIAL_OMAP
> -	select SERIAL_OMAP_CONSOLE
> +	select SERIAL_OMAP if TTY
> +	select SERIAL_OMAP_CONSOLE if TTY
>  	select TWL4030_CORE if ARCH_OMAP3 || ARCH_OMAP4
>  	select TWL4030_POWER if ARCH_OMAP3 || ARCH_OMAP4
>  	select VFP

Please just drop this and pick my earlier fix instead:

[PATCH 1/3] ARM: OMAP2+: Fix unmet direct dependencies for SERIAL_OMAP

Or let me know if you prefer me to queue it.

Regards,

Tony

[PATCH 0/9] arm-soc: randconfig fixes

[Viresh Kumar]

On Fri, May 3, 2013 at 2:32 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> Arnd Bergmann (9):
>   ARM: SPEAr: conditionalize l2x0 support
>   ARM: SPEAr: conditionalize SMP code

Acked-by: Viresh Kumar <viresh.kumar@linaro.org>

[PATCH 1/9] ARM: tegra: Tegra114 needs CPU_FREQ_TABLE

[Viresh Kumar]

On Fri, May 3, 2013 at 2:32 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> Like the other Tegra SoCs using the same cpufreq driver, we
> have to enable CPU_FREQ_TABLE for this one.
>
> drivers/built-in.o: In function `tegra_cpu_exit':
>  drivers/cpufreq/tegra-cpufreq.c:237: undefined reference to
>  `cpufreq_frequency_table_cpuinfo'
>
> Cc: Stephen Warren <swarren@nvidia.com>
> Cc: Hiroshi Doyu <hdoyu@nvidia.com>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
>  arch/arm/mach-tegra/Kconfig | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/mach-tegra/Kconfig b/arch/arm/mach-tegra/Kconfig
> index 597e76b..9878503 100644
> --- a/arch/arm/mach-tegra/Kconfig
> +++ b/arch/arm/mach-tegra/Kconfig
> @@ -63,6 +63,7 @@ config ARCH_TEGRA_114_SOC
>         select ARM_ARCH_TIMER
>         select ARM_GIC
>         select ARM_L1_CACHE_SHIFT_6
> +       select CPU_FREQ_TABLE if CPU_FREQ
>         select CPU_V7
>         select PINCTRL
>         select PINCTRL_TEGRA114

I doubt which is the best place for doing this? This one or
cpufreq/Kconfig.arm with select CPU_FREQ_TABLE for
tegra?

[PATCH 9/9] ARM: ux500: always select ABX500_CORE

[Linus Walleij]

On Thu, May 2, 2013 at 11:02 PM, Arnd Bergmann <arnd@arndb.de> wrote:

> The use of 'select' in the ux500 platform is a huge mess, we should
> not be selecting most of the drivers that are currently selected
> there, but rather enable them from the defconfig.
>
> As a fixup for 3.10, let's at least select the dependencies for
> the other drivers we already select, to make it consistent.
>
> warning: (UX500_SOC_COMMON) selects AB8500_CORE which has unmet direct dependencies (HAS_IOMEM && GENERIC_HARDIRQS && ABX500_CORE && MFD_DB8500_PRCMU)
>
> Cc: Linus Walleij <linus.walleij@linaro.org>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>

I do not necessarily agree with this commit message.

The only mess I see is that this very patch is missing...

If we look at this:

config UX500_SOC_DB8500
        bool
        select CPU_FREQ_TABLE if CPU_FREQ
        select MFD_DB8500_PRCMU
        select PINCTRL_DB8500
        select PINCTRL_DB8540
        select PINCTRL_AB8500
        select PINCTRL_AB8505
        select PINCTRL_AB9540
        select PINCTRL_AB8540
        select REGULATOR
        select REGULATOR_DB8500_PRCMU

The PRCMU, the PINCTRL drivers, and the PRCMU regulators
are necessary to boot the system correctly, by which I mean
necessary so as not to cause potential damage to the hardware.

The PRCMU is a system controller without which the system
cannot really be brought up, and the ABx500's are the PMICs
which are developed in pair with the SoC and they are in practice
Siamese twins, there is no chance you can build a Ux500 system
without both of them. It just won't even start. There are deep
dependencies between the PRCMU and the ABx500, as the
PRCMU firmware will talk directly to the ABx500 without the
kernel intervening. I.e. the whole set of hardware has to be
there.

While I understand that from a compile-time point of view it does
not seem nice, and all things would be separate units that you
plug in, from a run-time and system architecture point of view it
makes a lot of sense to select these. Worlds collide...

Apart from that:
Acked-by: Linus Walleij <linus.walleij@linaro.org>

Yours,
Linus Walleij

[PATCH 1/9] ARM: tegra: Tegra114 needs CPU_FREQ_TABLE

[Arnd Bergmann]

On Friday 03 May 2013 10:27:17 Viresh Kumar wrote:
> > diff --git a/arch/arm/mach-tegra/Kconfig b/arch/arm/mach-tegra/Kconfig
> > index 597e76b..9878503 100644
> > --- a/arch/arm/mach-tegra/Kconfig
> > +++ b/arch/arm/mach-tegra/Kconfig
> > @@ -63,6 +63,7 @@ config ARCH_TEGRA_114_SOC
> >         select ARM_ARCH_TIMER
> >         select ARM_GIC
> >         select ARM_L1_CACHE_SHIFT_6
> > +       select CPU_FREQ_TABLE if CPU_FREQ
> >         select CPU_V7
> >         select PINCTRL
> >         select PINCTRL_TEGRA114
> 
> I doubt which is the best place for doing this? This one or
> cpufreq/Kconfig.arm with select CPU_FREQ_TABLE for
> tegra?

It would be much better IMHO to have an entry for TEGRA_CPUFREQ
in drivers/cpufreq/Kcofnig.arm and move the select there. However,
creating that entry has some (small) regression potential and I
didn't want to do that now but instead just made sure that all
three Tegra SoCs do the same thing for now.

	Arnd

[PATCH 9/9] ARM: ux500: always select ABX500_CORE

[Arnd Bergmann]

On Friday 03 May 2013 10:14:28 Linus Walleij wrote:
> 
> I do not necessarily agree with this commit message.
> 
> The only mess I see is that this very patch is missing...
> 
> If we look at this:
> 
> config UX500_SOC_DB8500
>         bool
>         select CPU_FREQ_TABLE if CPU_FREQ
>         select MFD_DB8500_PRCMU
>         select PINCTRL_DB8500
>         select PINCTRL_DB8540
>         select PINCTRL_AB8500
>         select PINCTRL_AB8505
>         select PINCTRL_AB9540
>         select PINCTRL_AB8540
>         select REGULATOR
>         select REGULATOR_DB8500_PRCMU
> 
> The PRCMU, the PINCTRL drivers, and the PRCMU regulators
> are necessary to boot the system correctly, by which I mean
> necessary so as not to cause potential damage to the hardware.
> 
> The PRCMU is a system controller without which the system
> cannot really be brought up, and the ABx500's are the PMICs
> which are developed in pair with the SoC and they are in practice
> Siamese twins, there is no chance you can build a Ux500 system
> without both of them. It just won't even start. There are deep
> dependencies between the PRCMU and the ABx500, as the
> PRCMU firmware will talk directly to the ABx500 without the
> kernel intervening. I.e. the whole set of hardware has to be
> there.
> 
> While I understand that from a compile-time point of view it does
> not seem nice, and all things would be separate units that you
> plug in, from a run-time and system architecture point of view it
> makes a lot of sense to select these. Worlds collide...
> 
> Apart from that:
> Acked-by: Linus Walleij <linus.walleij@linaro.org>


If they are completely essential, we should not have an entry
like 

config AB8500_CORE
        bool "ST-Ericsson AB8500 Mixed Signal Power Management chip"
        depends on GENERIC_HARDIRQS && ABX500_CORE && MFD_DB8500_PRCMU
        select POWER_SUPPLY
        select MFD_CORE
        select IRQ_DOMAIN
        help
          Select this option to enable access to AB8500 power management
          chip. This connects to U8500 either on the SSP/SPI bus (deprecated
          since hardware version v1.0) or the I2C bus via PRCMU. It also adds
          the irq_chip parts for handling the Mixed Signal chip events.
          This chip embeds various other multimedia funtionalities as well.

(and more of the same) in drivers/mfd/Kconfig. The rule is that you either
make a Kconfig option user-selectable or make it always selected by another
option.

My preference would be to make it user-selectable and enable it only in
the defconfig, but if that can damage the hardware, we should not actually
provide a named option.

	Arnd

[PATCH 1/9] ARM: tegra: Tegra114 needs CPU_FREQ_TABLE

[Viresh Kumar]

On 3 May 2013 16:50, Arnd Bergmann <arnd@arndb.de> wrote:
> On Friday 03 May 2013 10:27:17 Viresh Kumar wrote:
>> > diff --git a/arch/arm/mach-tegra/Kconfig b/arch/arm/mach-tegra/Kconfig
>> > index 597e76b..9878503 100644
>> > --- a/arch/arm/mach-tegra/Kconfig
>> > +++ b/arch/arm/mach-tegra/Kconfig
>> > @@ -63,6 +63,7 @@ config ARCH_TEGRA_114_SOC
>> >         select ARM_ARCH_TIMER
>> >         select ARM_GIC
>> >         select ARM_L1_CACHE_SHIFT_6
>> > +       select CPU_FREQ_TABLE if CPU_FREQ
>> >         select CPU_V7
>> >         select PINCTRL
>> >         select PINCTRL_TEGRA114
>>
>> I doubt which is the best place for doing this? This one or
>> cpufreq/Kconfig.arm with select CPU_FREQ_TABLE for
>> tegra?
>
> It would be much better IMHO to have an entry for TEGRA_CPUFREQ
> in drivers/cpufreq/Kcofnig.arm and move the select there. However,
> creating that entry has some (small) regression potential and I
> didn't want to do that now but instead just made sure that all
> three Tegra SoCs do the same thing for now.

I was under the impression that this entry is already there.

Acked-by: Viresh Kumar <viresh.kumar@linaro.org>

[PATCH 9/9] ARM: ux500: always select ABX500_CORE

[Linus Walleij]

On Fri, May 3, 2013 at 1:28 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Friday 03 May 2013 10:14:28 Linus Walleij wrote:

>> While I understand that from a compile-time point of view it does
>> not seem nice, and all things would be separate units that you
>> plug in, from a run-time and system architecture point of view it
>> makes a lot of sense to select these. Worlds collide...
(...)
> My preference would be to make it user-selectable and enable it only in
> the defconfig, but if that can damage the hardware, we should not actually
> provide a named option.

Hm I'd lean towards the latter. However the AB8500 has subdrivers
and *some* of these are optional, such as the RTC. And it'd be
strange to have that depend on some totally unrelated config symbol
like UX500_SOC_COMMON.

I think that in that case we should make AB8500_CORE a hidden
(non-user selectable) bool so it is more logical.

However any if these approaches will lead to unaestetic menuconfig
with AB8500 suboptions appearing right in the MFD menu instead of
being ordered under a AB8500_CORE node which is better for
anyone actually trying to use menuconfig interactively.

The latter aestetic is one of the reasons why it looks as it does
IIRC, but maybe that is HTML thinking :-)

Yours,
Linus Walleij

[PATCH 9/9] ARM: ux500: always select ABX500_CORE

[Arnd Bergmann]

On Friday 03 May 2013 14:13:20 Linus Walleij wrote:
> On Fri, May 3, 2013 at 1:28 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> > On Friday 03 May 2013 10:14:28 Linus Walleij wrote:
> 
> >> While I understand that from a compile-time point of view it does
> >> not seem nice, and all things would be separate units that you
> >> plug in, from a run-time and system architecture point of view it
> >> makes a lot of sense to select these. Worlds collide...
> (...)
> > My preference would be to make it user-selectable and enable it only in
> > the defconfig, but if that can damage the hardware, we should not actually
> > provide a named option.
> 
> Hm I'd lean towards the latter. However the AB8500 has subdrivers
> and *some* of these are optional, such as the RTC. And it'd be
> strange to have that depend on some totally unrelated config symbol
> like UX500_SOC_COMMON.
> 
> I think that in that case we should make AB8500_CORE a hidden
> (non-user selectable) bool so it is more logical.

Yes, makes sense.

> However any if these approaches will lead to unaestetic menuconfig
> with AB8500 suboptions appearing right in the MFD menu instead of
> being ordered under a AB8500_CORE node which is better for
> anyone actually trying to use menuconfig interactively.

Yes, I can see that. Right now we have:

   -*- ST-Ericsson ABX500 Mixed Signal Circuit register functions 
   [*]   ST-Ericsson AB3100 Mixed Signal Circuit core functions   
   [*]     ST-Ericsson AB3100 OTP functions                      
   -*-   ST-Ericsson AB8500 Mixed Signal Power Management chip
   [*]     ST-Ericsson AB8500 GPADC driver
   [*]       Enable debug info via debugfs
   -*- ST-Ericsson DB8500 Power Reset Control Management Unit

I think we can certainly eliminate the ABX500 option, this one can
just get selected by AB3100 and AB8500. The PRCMU can also
be silent because as you say it is always needed.

One possible reason to allow them to be selected is to enable
build-time coverage on other platforms, but at the moment, they
all depend on ARCH_U300|ARCH_U8500, presumably because until
very recently they would not actually build anywhere else.

The GPADC driver is interesting: it does not have its own user
interface (besides the debugging driver) and could just get selected
by the other drivers using its exported interfaces. It would
also be better to convert it to the standard IIO ADC interface,
but I don't know if that's realistic. This leavs the debugging
interface as the only sub-option. Do you know if that is
actually being used by developers, or is this one of those interfaces
that were created during bringup and then never touched again
after everything worked?

Regarding AB3100, I assume the relationship to U300 is similar to
that between DB8500 and AB8500. Are you able to boot a U300 system
without touching AB3100?

	Arnd

[PATCH 9/9] ARM: ux500: always select ABX500_CORE

[Linus Walleij]

On Fri, May 3, 2013 at 2:48 PM, Arnd Bergmann <arnd@arndb.de> wrote:

> I think we can certainly eliminate the ABX500 option, this one can
> just get selected by AB3100 and AB8500. The PRCMU can also
> be silent because as you say it is always needed.

OK sounds like a plan.

> The GPADC driver is interesting: it does not have its own user
> interface (besides the debugging driver) and could just get selected
> by the other drivers using its exported interfaces. It would
> also be better to convert it to the standard IIO ADC interface,
> but I don't know if that's realistic.

This should be moved over to IIO ADC, that subsystem however
did not exist when this driver was submitted, that is why it ended
up in MFD. As usual someone needs to go hack on it...

> This leavs the debugging
> interface as the only sub-option. Do you know if that is
> actually being used by developers, or is this one of those interfaces
> that were created during bringup and then never touched again
> after everything worked?

Something like that, but as long as new platforms using that
ASIC is coming out it remains quite usable for this.

It is also used for hardware validation, where you hook up the
system with a lot of electric probes and want to set specific
bits here and there to validate functionality. There just a minor
change to the silicon or packaging triggers such re-validation.

The usecase is similar to the debug interface we invented for
pin control recently, however there we managed to make things
centralized.

> Regarding AB3100, I assume the relationship to U300 is similar to
> that between DB8500 and AB8500. Are you able to boot a U300 system
> without touching AB3100?

I would say no. The system will be in some bootstrap state unless
you bring up the AB3100, and especially the regulators.

These are default y but should arguably be selected y
instead.

The U300 SoC will bootstrap power in a strange way until the
regulators are up, and then hand over to software-controlled
regulators for powering the SoC and release that bootstrap.

This is not harmful but a very strange and it's doubtful whether
I would call that "fully booted". It's something like booting
into "safe mode"
http://en.wikipedia.org/wiki/Safe_mode

Not enabling regulators on the U300 will have other strange
effects ... like MMC/SD not working. Yet we can not have
depends on REGULATORS in the Kconfig for the MMCI driver
since this driver is also used on systems without the regulator
framework (hardwired power).

All these run-time "makes sense" is in a bit of flux as compared
to config-and-compile-time "makes sense" unfortunately.

I lean toward selecting AB3100 and REGULATOR_AB3100
for the U300 actually.

Yours,
Linus Walleij

[PATCH 9/9] ARM: ux500: always select ABX500_CORE

[Arnd Bergmann]

On Friday 03 May 2013 15:33:17 Linus Walleij wrote:
> On Fri, May 3, 2013 at 2:48 PM, Arnd Bergmann <arnd@arndb.de> wrote:

> > This leavs the debugging
> > interface as the only sub-option. Do you know if that is
> > actually being used by developers, or is this one of those interfaces
> > that were created during bringup and then never touched again
> > after everything worked?
> 
> Something like that, but as long as new platforms using that
> ASIC is coming out it remains quite usable for this.
> 
> It is also used for hardware validation, where you hook up the
> system with a lot of electric probes and want to set specific
> bits here and there to validate functionality. There just a minor
> change to the silicon or packaging triggers such re-validation.
> 
> The usecase is similar to the debug interface we invented for
> pin control recently, however there we managed to make things
> centralized.

Ok, makes sense.

> > Regarding AB3100, I assume the relationship to U300 is similar to
> > that between DB8500 and AB8500. Are you able to boot a U300 system
> > without touching AB3100?
> 
> I would say no. The system will be in some bootstrap state unless
> you bring up the AB3100, and especially the regulators.
> 
> These are default y but should arguably be selected y
> instead.
> 
> The U300 SoC will bootstrap power in a strange way until the
> regulators are up, and then hand over to software-controlled
> regulators for powering the SoC and release that bootstrap.
> 
> This is not harmful but a very strange and it's doubtful whether
> I would call that "fully booted". It's something like booting
> into "safe mode"
> http://en.wikipedia.org/wiki/Safe_mode

I see.

> Not enabling regulators on the U300 will have other strange
> effects ... like MMC/SD not working. Yet we can not have
> depends on REGULATORS in the Kconfig for the MMCI driver
> since this driver is also used on systems without the regulator
> framework (hardwired power).
> 
> All these run-time "makes sense" is in a bit of flux as compared
> to config-and-compile-time "makes sense" unfortunately.
> 
> I lean toward selecting AB3100 and REGULATOR_AB3100
> for the U300 actually.

Should we still allow building them on other platforms then?
Right now, these depend on the platforms that actually use
the hardware, but in other places, we just allow everything to
be built that compiles without errors.
Is it theoretically possible to use the AB in combination with
another (non-ST-Ericsson) digital baseband?

	Arnd

[PATCH 9/9] ARM: ux500: always select ABX500_CORE

[Linus Walleij]

On Fri, May 3, 2013 at 3:56 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Friday 03 May 2013 15:33:17 Linus Walleij wrote:

>> I lean toward selecting AB3100 and REGULATOR_AB3100
>> for the U300 actually.
>
> Should we still allow building them on other platforms then?
> Right now, these depend on the platforms that actually use
> the hardware, but in other places, we just allow everything to
> be built that compiles without errors.

Not in my opinion but IIRC in 2008 or so some other
subsystem maintainer beat us up for not allowing it
to build on every other platform, and the rationale given
was that allowin this to build on e.g. x86_64 gives some
nice compile coverage.

I don't know which argument wins :-)

> Is it theoretically possible to use the AB in combination with
> another (non-ST-Ericsson) digital baseband?

Theoretically (it's just a bunch of regulators etc when all comes
around), but it won't happen since these components
are not sold separately.

Yours,
Linus Walleij

[PATCH 9/9] ARM: ux500: always select ABX500_CORE

[Arnd Bergmann]

On Friday 03 May 2013 16:06:57 Linus Walleij wrote:
> On Fri, May 3, 2013 at 3:56 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> > On Friday 03 May 2013 15:33:17 Linus Walleij wrote:
> 
> >> I lean toward selecting AB3100 and REGULATOR_AB3100
> >> for the U300 actually.
> >
> > Should we still allow building them on other platforms then?
> > Right now, these depend on the platforms that actually use
> > the hardware, but in other places, we just allow everything to
> > be built that compiles without errors.
> 
> Not in my opinion but IIRC in 2008 or so some other
> subsystem maintainer beat us up for not allowing it
> to build on every other platform, and the rationale given
> was that allowin this to build on e.g. x86_64 gives some
> nice compile coverage.
> 
> I don't know which argument wins 

I know that a certain other Linus frequently complains when ARM specific
options show up on his x86 machine during "make oldconfig" ;-)

One idea I had is to create a global CONFIG_SOC option that would
hide all on-chip peripherals when building for a PC-like system.
On ARM, we would always select CONFIG_SOC, except for a few special
cases like ARCH_RPC, ARCH_FOOTBRIDGE and ARCH_SHARK.

> > Is it theoretically possible to use the AB in combination with
> > another (non-ST-Ericsson) digital baseband?
> 
> Theoretically (it's just a bunch of regulators etc when all comes
> around), but it won't happen since these components
> are not sold separately.

Right, I was specifically asking about the technical possibilities,
not what people are likely to do. 

	Arnd

[PATCH 9/9] ARM: ux500: always select ABX500_CORE

[Linus Walleij]

On Fri, May 3, 2013 at 4:20 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Friday 03 May 2013 16:06:57 Linus Walleij wrote:
>>
>> Not in my opinion but IIRC in 2008 or so some other
>> subsystem maintainer beat us up for not allowing it
>> to build on every other platform, and the rationale given
>> was that allowin this to build on e.g. x86_64 gives some
>> nice compile coverage.
>>
>> I don't know which argument wins
>
> I know that a certain other Linus frequently complains when ARM specific
> options show up on his x86 machine during "make oldconfig" ;-)

OK let's make it SoC-specific.

> One idea I had is to create a global CONFIG_SOC option that would
> hide all on-chip peripherals when building for a PC-like system.
> On ARM, we would always select CONFIG_SOC, except for a few special
> cases like ARCH_RPC, ARCH_FOOTBRIDGE and ARCH_SHARK.

Sounds like a deal. The AB chips aren't on-chip though
they sit on I2C or SPI actually. But they are still
strongly coupled with the SoC.

I just took a stroll around the premises and found this
Aardvark I2C/SPI "embedded systems interface".

This is a USB thing that makes it possible to connect
any I2C or SPI peripheral to the desktop ... I don't know how
such things should be used with Linux really, it seems like
it's something that normally gets used from userspace by
libusb but in theory we could have a kernel driver for this
and plug in whatever SoC I2C/SPI device into a desktop.

Whatever use it would be ... but could be useful for
developing drivers for a chip outside of the target
system I believe.

Yours,
Linus Walleij

[PATCH 9/9] ARM: ux500: always select ABX500_CORE

[Arnd Bergmann]

On Friday 03 May 2013 20:43:42 Linus Walleij wrote:
> 
> Sounds like a deal. The AB chips aren't on-chip though
> they sit on I2C or SPI actually. But they are still
> strongly coupled with the SoC.
> 
> I just took a stroll around the premises and found this
> Aardvark I2C/SPI "embedded systems interface".
> 
> This is a USB thing that makes it possible to connect
> any I2C or SPI peripheral to the desktop ... I don't know how
> such things should be used with Linux really, it seems like
> it's something that normally gets used from userspace by
> libusb but in theory we could have a kernel driver for this
> and plug in whatever SoC I2C/SPI device into a desktop.
> 
> Whatever use it would be ... but could be useful for
> developing drivers for a chip outside of the target
> system I believe.

I would argue that the AB8500 is close enough to a
'system-on-a-chip' to make it depend on CONFIG_SOC, even
though it is technically one half of a 'system-on-two-chips'.

I would also allow x86 and all other architectures to enable
CONFIG_SOC, since there are lots of SoCs these days that combine
an x86 core with the same kind of peripherals we have on ARM
systems. It's just not what you you find in a regualar PC or
Laptop, and anyone building their own kernel can ignore those.

	Arnd

[PATCH 7/9] ARM: OMAP: don't select SERIAL_OMAP unconditionally

[Arnd Bergmann]

On Friday 03 May 2013, Tony Lindgren wrote:
> Please just drop this and pick my earlier fix instead:
> 
> [PATCH 1/3] ARM: OMAP2+: Fix unmet direct dependencies for SERIAL_OMAP
> 
> Or let me know if you prefer me to queue it.

I've applied your patch now. Should I also take the other two of that
series? I was not on Cc for these patches, but all three seem to be
required still.

	Arnd

[PATCH 7/9] ARM: OMAP: don't select SERIAL_OMAP unconditionally

[Tony Lindgren]

* Arnd Bergmann <arnd@arndb.de> [130503 13:40]:
> On Friday 03 May 2013, Tony Lindgren wrote:
> > Please just drop this and pick my earlier fix instead:
> > 
> > [PATCH 1/3] ARM: OMAP2+: Fix unmet direct dependencies for SERIAL_OMAP
> > 
> > Or let me know if you prefer me to queue it.
> 
> I've applied your patch now. Should I also take the other two of that
> series? I was not on Cc for these patches, but all three seem to be
> required still.

Yes go for it. Note that the two other patches have dependencies to
branches for the current merge window, but you probably already 
have some base they can be applied against.

Regards,

Tony